Capturing requirements can be the most challenging part of a
software development project. If you don’t get the requirements right, or miss
key requirements, your project is in vain. Even if you do meet budget and
schedule objectives, your project will fail to deliver the benefits your
sponsors envisioned for it.
Here are some simple tips to follow in order to avoid a
disaster. Be forewarned: these tips sound simple and straightforward but can be
very tricky to implement. This is not meant to be a complete set of
instructions for managing requirements on any project, it is meant to help you
avoid some common pitfalls.
Identify
the right stakeholders to contribute requirements. The key stakeholders
are the ones that will be using the software to conduct their business,
the ones who will be maintaining it after deployment, and the business
sponsor. Exclude those who wish to influence the outcome of the project
but who don’t have a stake in the success of the project. If you’re given
a list of stakeholders who should be included, verify that the list
includes all the stakeholders. Click here for some handy tips on how to identify the right stakeholders
Identify
the right requirements capture tools and techniques. You should choose
techniques that are a fit for the stakeholders who will be defining their
requirements and are suitable for the organization’s makeup. For example,
if your stakeholders are a geographically diverse group, techniques such
as storyboarding or brainstorming will not work. Click here for more information on requirements gathering techniques.
Work
with your stakeholders to capture requirements in plain English.
Requirements should speak to some aspect of the business benefit to be
derived from the project. The requirement should be feasible (that is they
should be possible to code by the development team). They should also be
verifiable. To ensure a requirement is verifiable, ask the question: How
are you going to test the requirement? If you don’t get an answer to that
question, you need to work on the requirement to convert it into something
that is verifiable. Click here for more information on capturing clear requirements.
Define
a schedule for the requirements gathering exercise that will allow
building to start on time, and then stick to the schedule. Hold the
stakeholders responsible for meeting their scheduled deadlines. Make sure
the team understands that delivering requirements late will delay the
project end date. Click here for more information on scheduling requirements gathering activities.
Identify
the approver, or approvers, for the requirements; this is the person, or
people, who your business sponsor empowers to speak on their behalf, if
the sponsor is not to be responsible for sign off. You will have to hold
these people accountable for meeting the schedule deadlines. Don’t proceed
to the build phase without the requirements having been approved. Click here for more information on identifying approvers.
Identify
each requirement with a unique id. This is the key to traceability. The id
should be tracked in the functional specs, design specs, and tests. Click here for more information on tracing requirements.
