Hi, Everybody!
Dr. White here.
The Business Analysis Doctor.
Today I’ll be talking about missed requirements.
Finding out about a missed requirement is one of the worst feelings for a BA and in
some cases, can be expensive for a project.
So, I’ll be giving you 7 tips to avoid missed requirements
Tip #1 Identify all stakeholders/ requirements sources
You always want to get your requirements off to a good start by developing an exhaustive
list of stakeholders for the initiative.
For details on how to do this, see my previous post on identifying stakeholders early.
Tip # 2 - Fully understand the business need.
First, you need to determine if you are trying to solve a problem or take advantage of an
opportunity.
If trying to solve a problem, make sure you perform a root cause analysis to ensure you
are addressing the proper issue.
If you are taking advantage of an opportunity, be sure you and the key stakeholders have
a relatively solid understanding of the potential value of this opportunity.
Tip # 3 - Understand the Current state
Fully understanding the current state includes knowing the key stakeholders, processes, systems,
needs, constraints, and the overall business architecture.
Having knowledge of all of these components will give you the proper context to be able
to better analyze the requirement and increase your ability to detect gaps or conflicting
information.
Understanding the current state can also, help you ask more relative and meaningful
questions during elicitation, which will ultimately lead to better requirements.
Tip # 4 - Perform a Gap Analysis
A gap analysis is essentially the process of defining the current and future state in
an effort to determine how what gaps in the current state are preventing the goals and
objectives for the desired future state.
These gaps then need to be elaborated to define a change strategy.
Describing the current and future state with the same technique will increase the effectiveness
of the gap analysis by making the gaps easier to detect.
Tip # 5 - Document requirements from multiple viewpoints.
A requirements viewpoint is the ways requirements are modeled and represented.
A complete requirements architecture consists of multiple viewpoints that support one another
because each viewpoint is more effective at representing certain aspects of the requirements
than others.
Key viewpoint include:
User, process, and data information,
The user viewpoint might be represented with user stories or uses cases,
The process viewpoint could be represented with various kinds of process models such
as BPMN, UML, or Value Stream mapping,
The data and information viewpoint may include techniques such as data dictionaries, ERDs,
or Class diagrams.
Including each viewpoint relative to the project is essential to providing a complete set of
requirements because it requires you to use multiple modeling formats including text,
matrices, and diagrams to convey information.
Also, cross-referencing the various viewpoint will allow you to detect holes and missing
requirements as the varying model formats emphasizes something different making it easier
to detect information gaps.
Tip # 6 - Verification activities
All requirement activities should include verification activities.
Requirement Elicitation activities should include a follow-up with key stakeholders
to confirm the accuracy and completeness of the information that was recorded.
Requirement documentation should include verification activities to compare various formats against
one another to verify that the needs are consistent and that those requirements are not missed.
Requirements checklists are a great way to detect missing requirements.
Checklists include requirement types and modeling formats that could be forgotten.
They could also include the various requirement quality standards, which includes a completeness
check.
Tip # 7 - Reviews and Walkthroughs
You definitely want to include the business as they are most qualified to verify correctness
and conformance to the business needs.
The development team is more qualified to assess the feasibility and raise issues regarding
non-functional requirements.
Tester from QA or UAT should also be involved in the reviews as they are likely to detect
gaps regarding testability, scenarios, and exceptions.
Also, as you are specifying and documenting requirements, envision how it requirement
would be tested, this is a great way to detect missing requirements early in the process.
Requirement reviews are a very effective technique for ensuring the work product is complete
and correct.
There are various review techniques to choose from depending on the type of documentation
and the organizational structure.
Reviews can be performed iteratively and should include various stakeholder perspectives.
Well, there are your 7 tips to avoid missed requirements.
For more business analysis mastery tips, be sure to subscribe.
And for more resources, visit my website at thebadoc.com.
That’s t-h-e-b-a-d-o-c .com
See you next time!