Most software development projects are overwhelmed by
requirements from stakeholders of the project. The deluge of requirements may
make it seem impossible that any requirements that are critical to the success
of your project could be missed, but it is possible to miss them! Remember that
requirements will differ from your Scope Statement, or SOW, in that they are
the details of how the goals and objectives will be built. Your requirements
are like the blueprints for a building or bridge. The requirements must capture
all the elements implied in the Scope Statement or SOW, otherwise your project
can’t meet those goals and objectives.
You may be capturing so many requirements that you get
requirements that conflict. You need to be discerning when capturing the
requirements. Requirements that are in conflict with one another cannot be
delivered. One, or both, of the requirements is bogus and should be dropped.
Requirements that don’t support the stated goals and objectives of the project
are unnecessary overhead and will add to the expense of the project without
delivering any business benefit. Building a software system is a business
venture, not a popularity contest so some project stakeholders will be
disappointed in the system. Your job is to ensure that you deliver a system
that meets your customer’s/client’s/sponsor’s expectations.
It is a myth that most projects have budget constraints. All
projects have budget constraints. Completion of the project within the
committed budget may not be the Number 1 project priority but the project must
deliver within some budget, otherwise we wouldn’t set budgets at all. Another
area where project managers often struggle is the delivery of the required
functionality within the budget. The people that you select to define
requirements for the project are not concerned with a budget, that’s your job.
To deliver your project within budget you will need to ensure that a stated
requirement delivers the functionality required to meet an expectation, not
exceed it. Telephone carriers actually install redundant systems in their
equipment offices to ensure that there is no loss of service should one or the
other system experience a problem. They do this because providing service is
mission critical. Installing redundant order systems, duplicating all the
servers, terminals, and databases involved in the system to provide a 99.9999%
availability rate for the system, would be overkill and hugely expensive. Not
all "gold plating” requirements are that clear, but they don’t need to be in
order to blow your project budget and/or schedule baselines.
Requirements may be within the stated scope of the project,
and be as pared down as it is possible to make them, but if they are notclearly understood by the analysts and testers who will read them and make
design decisions based on them, you will encounter trouble. Many a project has
started out with a great set of requirements – the requirements needed to
deliver all the project goals and objectives within the budget and schedule
baselines, only to founder when those requirements were not built and tested as
intended. Correcting these misunderstandings after the system is delivered to a
QA or User Acceptance Test (UAT) group is the second most expensive way of
correcting the error, with the first being having a customer in the field
identify the error.
You can guard against the overwhelming deluge of
requirements by choosing a requirements gathering method that suits your team
and project, then engaging the right number of stakeholders to state
requirements. Educate your stakeholders in the proper use of the method and
what is expected of them so that time isn’t wasted in education when you are
trying to elicit requirements. Gathering requirements for a function or
business unit from one stakeholder will eliminate conflicting requirements.
Workshops can be used where it isn’t possible to limit input to just one
stakeholder per function or business unit. You will need to review the
requirements yourself, or with a business analyst, where you can’t use these
methods to reconcile the requirements.
Features that are used to support several functions or
business units are another source of conflict. For example, your log on feature
should be used to provide log on facilities for everyone that will use your
order entry and tracking system. Accepting requirements from everyone that will
log on to the system is almost certain to cause conflict. You will be better
off to identify a stakeholder or SME who is a security specialist and have that
person supply the requirements for the log on feature.
Each requirement that you gather must support a deliverable
in your SOW or goal or objective in your Scope Statement. Requirements must be
captured in a document that relates it to the Scope Statement or SOW. That
means that you need to start with a Scope Statement or SOW where each
deliverable has a unique identifier. Any requirement that cannot be directly
tied to a deliverable, goal, or objective must be questioned. The requirement
should be ignored if you aren’t satisfied that the requirement will deliver
some functionality that directly supports something in the Scope Statement or
Cost each requirement as it is captured. You don’t have to
provide a monetary estimate for the requirement, or even an effort estimation
(although an ROM effort estimation would be valuable). You can simply rate the
feature as large, medium, or small, in terms of cost. You’ll have to have a
development SME do this for you, unless you are knowledgeable to do it
yourself. You may also want to assess the complexity of the feature, e.g.
complex, intermediate, simple. My example is an ordinal system, but you can use
a cardinal system if that is your preference. Question any requirements that
are large and complex (you may want to set a threshold for this exercise). Is
there another way to state this requirement that will be less costly to
deliver? Empower your business analysts and programmers to identify
opportunities for simplifying a requirement so that it delivers the required
business function but for less cost.
Requirements should also be prioritized. The purpose of this
is to facilitate de-scoping the project during the construction phase, should
your initial estimates prove too aggressive. Use an ordinal system for the
purpose, for example: high, medium, low. The combination of rating systems for
size, complexity, and priority, will allow you to quickly reduce the scope of
your project should you need to.
Requirements should be stated in plain language. If you are
collecting requirements in a workshop, other workshop attendees should be able
to understand the requirement even if they aren’t from the same functional area
or business unit. Where you are collecting requirements using a polling method,
you should be able to understand the requirement as stated. You may also want
to use another team member, from any area other than the person who submitted
the requirement, as a sounding board to ensure that the requirement is stated
Ask the stakeholder to describe how they would go about
testing the system to ensure their requirement has been met. You don’t need
your stakeholder to completely define a test case, but they should be able to
describe a test scenario to you. Capturing their description in the
requirements document will go a long way to eliminating misunderstandings
between the stakeholder, business analyst, developer, and tester. Your last line
of defense will be the stakeholders; the stakeholders should be willing to
contribute to system quality during the UAT phase.
tips and tricks described in this article are intended to help the project
manager using the best practices promoted by the PMI. Project managers who are
certified have already implemented those best practices. If you haven't been
certified as a PMP® (Project Management Professional) by the PMI
and would like to learn more about certification, visit the three O Project
Solutions website at: http://threeo.ca/pmpcertifications29.php.
three O Project Solutions also offers a downloadable software based training
tool that has prepared project managers around the world to pass their
certification exams. For more information about this product, AceIt, visit the
three O website at: http://threeo.ca/aceit-features-c1288.php.