Schedule pressure can cause us to gather requirements before
the stakeholders are fully ready to define what they really would like. So in order to meet the deadline we may
gather a high-level requirement such as “The system shall capture additional
data from the client on the screen XYZ”.
This may be used as a placeholder to be further defined during system
design or development. It may seem
harmless to just put in this placeholder; however, it may end up causing more
harm than good to the project in the end.
High-level requirements can be beneficial when first meeting
with a stakeholder to help define the scope of the project and to determine a
schedule and resource plan. However, if
as business analysts we do not delve into the details as we are generating the
business requirements, we leave ourselves open to confusion and conflicts later
on. Many times during a project a group
of stakeholders may only be available during the requirements gather process. For instance, the Compliance department will
attend the requirement gathering sessions and sign-off on the Business
Requirements Document and then not participate in the design, testing, or
implementation portions of the project.
If we include a requirement that is too open-ended, it forces those
reading it to interpret for themselves what it really means. This can lead to conflict between
stakeholders as to what the system should really be doing.
Another potential issue with vague requirements is around
other projects that may be relying on the work that is being done within your
project. If they are handed a list of
requirements to base their work on that is not detailed enough they will also
have to interpret and assume. The other
option for them would be to wait for your project to fully define the
requirements which could cause delays in their project. If they begin their design with your vague
requirements and then you present them with the details later on it may cause a
great impact to their project with the rework that is involved. You have basically injected a change into
their project without going through the formal change process.
The final issue with vague requirements looks at the test
planning that occurs based on the requirements that were gathered. During most projects the test plan and test
scenarios are written based on the requirements that were gathered. One of the tenants of a good requirement is
that it needs to be testable and verifiable.
If we look at the requirement I mentioned in the beginning of this post,
“The system shall capture additional data
from the client on the screen XYZ”, how do we test this? What additional
data is supposed to be captured? The
testing team may write a test script based on this requirement, but when it
comes to executing it how will they know if they can pass that step or not?
As you can see, the inclusion of a requirement that is too
vague in a Business Requirements Document can affect a lot of downstream within
a project. What are we to do as business
analysts when presented with this issue?
Here are a few suggestions:
- Get as much detail as you can from the
stakeholders and include that in your requirements document. Using the example above, maybe the
stakeholder knows 6 of the 10 additional data items they would like to
capture. Gather detailed requirements
around those 6 and then either include information about the other 4 through a
Change Request to this project or included it in a future project. In most organizations the Change Request
process involves input from many different groups that will be affected. This allows all impacted groups/projects to
provide input on what that change will impact.
- If there are enough vague requirements being
gathered then maybe the project should be delayed. If the business is not ready to make a
decision about what they would like or need then time and resources should not
be wasted waiting around for them to make a decision. This may not always be a feasible solution,
but should be considered
- Force the stakeholder to make a decision. This
may sound drastic, but many times the business owner needs to be directed. Your job as a Business Analyst is to elicit
quality requirements. If the project has
good stakeholder management, then all of the necessary stakeholders should have
been defined. Use this list to setup
sessions where everyone can attend and the best solution can be
determined. If everyone understands the
goal of the session then you should be able to come out of it with the detailed
requirements that you need.
This post is a small part of what goes into good requirement
documentation and system design. For
more information see the Business Analyst Body of Knowledge at theiiba.org
