No matter how good a job you think you’ve done on eliciting project requirements from a client, there will always be gaps; nobody really knows when one is done gathering all requirements, because new wishes and demands continue to trickle in throughout a project’s lifecycle.
A project with an excessive rate of change suggests that important requirements may have been overlooked during the elicitation phase. But how do you keep missing requirements to a minimum?
Hard to Spot
Missing requirements are a common type of requirement defect; they’re hard to spot because they’re not obvious—and in many cases, they’re invisible. The following techniques should help you detect previously undiscovered requirements:
- Break down high-level requirements into more detail, to show what really is being requested.
- Make sure that all users have provided their input, and that each requirement has at least one user that will receive some value from it.
- Trace the requirements to the functional specifications to make sure that all the necessary functionality was created accurately.
- Try and represent information about the requirements in ways beyond text. Think visuals: diagrams and mind maps, for example, make it much easier to spot potentially missed requirements.
- Sets of requirements with boolean logic (ANDs, ORs, and NOTs) often are incomplete. If a set of logical conditions has no corresponding functional requirement, the developer has to guess at what the system should do. “Else” conditions may be overlooked. Represent complex logic by using decision tables or decision trees to cover all the possible situations.
- A checklist of common functional areas to consider may also help. Examples may include error logging, backup and restore, access security, reporting, etc.; regularly compare this list to the functions you’ve already specified in order to find gaps.
- A data model may also reveal missing functionality. Create a possibilities grid, and make sure you can identify the functionality in your application that performs the necessary operations on all of your entities that need them.
Uncovering missing requirements brings with it the risk of analysis paralysis, which involves spending too much time on requirements in an attempt to avoid overlooking any. At some point, you need to move forward and establish a stable requirements baseline that you can use for the next release/iteration.
Be mindful that most projects contain requirements that aren’t explicitly stated. Uncovering those requires that you ask context-free questions, such as high-level and open-ended ones that elicit information about global characteristics of both the business problem and the potential solution.
Business analysts are not going to discover and document every single requirement for a software system of any size—that’s impossible. However, if you keep your eyes open for missing, assumed, and implied requirements, you’ll close a lot of the gaps that otherwise might cause development headaches further down the road.
- Why a Business Analyst’s Role Is So Hard to Define
- 4 Interview Qs for Business Analysts in Product or Marketing
- Tech Skills Every Business Analyst Needs to Know
Image: Sergey Nivens/Shutterstock.com