Professional Documents
Culture Documents
Tim Coventry
Managing requirements is a key tool for business and project success. This
paper explains some of the concepts of requirements management and
introduces a number of techniques that can be applied. Through these
approaches, you can help ensure that the final delivery from a project or
initiative aligns with the initial strategic intent. In other words, you can deliver
exactly what the stakeholders expect and what the business needs.
What is a Requirement?
Requirements exist within all organizations; all organizations exist to delivery
products and/or services to customers, which are always delivered through
business processes that are decomposed into individual requirements.
Requirements are simply a capability needed by a stakeholder (person) to
deliver a product and/or service.
Reducing cost
Improvings quality
Decreasing time taken
Decreasings risks
Enabling effective scope management
In 2009, IAG Consulting conducted a Business Analysis Benchmark survey,
68% of companies surveyed used poor requirements practices and reported
that while having estimated a project at US$3 million, it will be on budget less
than 20% of the time. On average, these companies with poor requirements
practices will pay US$5.87 million per project, a significant increase over
estimation.
According to the 2004 CHAOS Report, three of the top five reasons projects
fail are related to requirements:
RMP Contents
The contents of a typical RMP contain the following sections:
Requirements Types
Requirement types are a mechanism to enable a cascading hierarchy of
requirements. This allows the initial broad coverage of requirements with a
business focus to be traced to detailed requirements with a technical focus.
Requirements Artifacts
Requirement artifacts are the documents produced that contain requirements
and other supplementary information for the stakeholders.
Requirement Attributes
The following requirement attributes should be captured for all requirements:
Enable the project team to determine how and why a requirement has
changed over time
Help ensure that a review of requirements is being conducted on the
correct version of requirements, and not an old version
Requirements Baseline
A baseline is a basis for comparison between requirements (all or subset)
over a period of time; it is a “snapshot” of requirements (not a one-time event).
Each project should define a baseline strategy that includes defining the
baseline in terms of creation, frequency, content, and publishing. A baseline is
the vehicle for communicating changes in the detail of requirements to
interested parties.
Baselining is a mechanism to package a set of requirements at a particular
point in time and pass that off to the next group in the project team.
It is important in your RMP to specify when to create a baseline and how
frequently they are going to be tied to formal project milestones. The content
of the baseline and how it is going to be published also need to be specified.
Is the baseline published into a document? Is it published using a tool that will
actually take a set of requirements and then send them to the development
environment, so that the developers can code against those requirements?
There are a number of ways this can be performed.
The important thing is that the requirements management plan is all about this
upfront planning. We are trying to make sure that we have planned these
activities and as we move through the application lifecycle of the project, we
don't want to have to make these decisions as we are getting to critical
delivery points.
A baseline can be formal or informal.
Summary
Requirements management should be performed in strategy planning,
implementation, and operations. Try to ensure your customer, stakeholders,
project managers, and business managers are engaged and involved in the
requirements management process from the start. The key is to have no
surprises—we should all know our roles and when they are going to happen.
Work to ensure that team members know the importance of adhering to the
requirements management plan. Your BAs have to do things consistently and
they have to understand and enforce requirements change management. The
designers, developers, and testers need to understand that Bas are all using
this requirements management plan. This tells them how they are specifying
requirements, when they are going to get a baseline, how we are going to
communicate the changes, and how to communicate amongst team members
during the process for verifying and managing the changes to those
requirements.
The requirements management traces across the whole lifecycle. The BAs
must have the discipline to maintain all aspects of the traceability and must be
disciplined to help ensure that everything fits together. They have to be sure
that there is requirements configuration and that baselining is being done in a
controlled way, and that requirements are being understood and approved.
This approach has a dramatic effect in improving project outcomes.