

HOME

 ABOUT

 JOIN PMI

 CONTACT

 LOG IN

 REGISTER

 myPMI
 Certifications
 Membership
 Learning
 Events
 Business & Government
 PMBOK® Guide & Standards
 Store

1. Learning

2. Library

Requirements
management –
planning for success!
techniques to get it right when planning
requirements
 Share
CONFERENCE PAPER Requirements Management, Business Analysis 11 May 2015
Coventry, Tim
How to cite this article:
Coventry, T. (2015). Requirements management – planning for success!: techniques to get
it right when planning requirements. Paper presented at PMI® Global Congress
2015—EMEA, London, England. Newtown Square, PA: Project Management
Institute.

Tim Coventry

Business Analysts Pty Ltd (BAPL)

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.

What is Requirements Management?

Requirements Management is an iterative set of activities that help ensure
that elicitation, documentation, refinement, and changes of requirements is
adequately dealt with during a lifecycle, with a view toward satisfying the
overall mission or need in a quality manner and to the customers’
satisfaction.
Whether part of a project management plan or standalone, a Requirements
Management Plan (RMP) describes the requirements artifacts, requirement
types (including attributes), the requirements management process, and
 the metrics and tools to be used for measuring, reporting, and controlling
changes to the requirements.

Why Manage Requirements?

Studies have shown that requirements management improves all major
aspects of organizational strategy (portfolio, programs, and projects) or
operations management (day-to-day business) by:

 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:

 Users are not involved enough in requirements definition

 Requirements are incomplete or don't meet acceptance criteria
 Requirements are constantly changing, and these changes are not managed
effectively.
The CHAOS Summary (2009) reported that 44% were challenged (late,
over budget, and/or with less than the required features and functions); and
24% failed (cancelled prior to completion or delivered and never used).

Where are Requirements Managed in an

Organization?
Organizations exist to deliver products and/or services, which are delivered
through business processes that are decomposed into requirements.
 Requirements should be managed in organizational strategy (portfolio,
programs, and projects) or operations management (day-to-day business).
Often, requirements management is lacking in strategic planning, portfolios,
and day-to-day business initiatives (often referred to as continuous
improvement).

 Strategic Planning (strategy to execution) –business requirements (outcomes

and benefits) are defined and quantified
 Portfolio –business requirements are used to link the strategy to the portfolio
of change
 Program –business requirements are used to define the program scope and
success criteria
 Project –business and stakeholder requirements are used to define the
project scope and success criteria. Solution –nonfunctional and transition
requirements are used to build and implement a solution
 Continuous Improvement (day-to-day business) – business requirements and
stakeholder requirements are used to define the continuous improvement,
scope, and success criteria. Solution–nonfunctional and transition
requirements are used to build and implement a solution.

Figure 1: Strategy to operations

When do you plan requirements management? Anytime-it is never too late
to do a requirements management plan. The ideal situation is to manage
requirements from the strategic plan, which are often expressed as
outcomes and benefits, all the way to execution. However, the reality is that
most of the time, requirements management is not done until the start-up of
a project. One of the reasons why many organizations fail to realize value
from a good strategy is the lack of requirements management with benefits
realization.
Is there any time you don't need an RMP? Probably not, but it is important
to varying levels of detail in a requirements management plan, depending
on the project complexity and risk.

The Requirements Management Plan

(RMP)

RMP Contents
 The contents of a typical RMP contain the following sections:

 Stakeholder roles and responsibilities

 Requirements management process (elicited, analyzed, documented, and
managed)
 Requirements type definition
 Requirements type/artifact mapping
 Naming and numbering convention
 Requirements prioritization
 Requirements traceability
 Requirements versioning
 Requirements baseline (requirements change control)
 Communication strategy for requirement changes
 Requirements management tools

Stakeholder Roles and Responsibilities

Who creates the RMP?

 Business Analysts with input from the project manager

Who approves/endorses RMP?

 Leaders from each Software Delivery Lifecycle SDLC team

Who participates in the RM process?

 Business subject matter expert – source of project/product requirements

 Business analyst – gathers, analyzes, and documents requirements
 Designer – uses requirements to design solutions
 Developer – develops solutions to requirements
 Tester – verifies the solution and satisfies the requirements
 Project manager – reports project status based on requirement metrics
 Change management analyst – determines organizational change due to
requirements
Who maintains the RMP?
 Business Analysts (BA)
Who is involved in a requirements management plan? As a BA, you must
work fairly closely with the project manager in creating a requirements
management plan. The project manager will have project planning
requirements that he/she needs to satisfy, so the BA needs to be aware of
that and needs to help ensure the requirements management plan works
well for the project.
In some cases, the project management plan may actually encompass the
main components of the RMP, so it may not be necessary to have a
separate document. Who endorses the RMP? Typically each of the team
leaders in the application lifecycle. Who participates in the process?
Subject matter experts are people who are going to help define and specify
requirements. TBAs will gather, analyze, document the requirements. The
designers and developers will design and develop the solution components
from the requirements that BAs have elicited. The testers then take those
requirements and test them to help ensure they still fit the purpose and
satisfy the original requirements. Finally, the change management analyst
reviews and implements changes to the organization based on the
requirements.
The project manager can use requirements to provide meaningful reporting
on the status of the project using the metrics that we keep talking about -
things like how many requirements are still yet to be approved or
outstanding to be approved by stakeholders; how many requirements are
deferred which are going to potentially change the scope; and critically,
what the impacts are on the project.
So there are a lot of people interested in requirements and they all have a
slightly different view so we need to make sure upfront that we consult with
each of those people. The RMP is the mechanism to engage so we
understand what they need and keep them engaged throughout the entire
project.
Use a RACI matrix, if possible, to show the stakeholder their role in
requirements, their interest, and when in the process they are typically
involved. Identifying the stakeholders helps define and verify the
requirements management process.

Requirements Management Process

 Identify stakeholders
 Gather/elicit requirements
 Analyze requirements
 Specify/document requirements
 Baseline requirement groups (verify, validate, and prioritize requirements-
i.e.: agree and sign-off on requirements)
 Communicate requirements
 Monitor/track requirements
 Manage and control changes to requirements
 Report requirements compliance
The process is a really important part of the requirements management
plan. You need to have a process that pulls together the steps: identify
stakeholders; solicit the requirements; analyze the requirements; document
requirements; baseline;, communicate; monitor and track; manage and
control; and report. The process is important because you want it to be
repeatable, so that a change of the requirements does not want initiate a
different process.
It is important to document and articulate the process so that everybody
who has an interest in requirements change complies. It should also link in
nicely to the project change management control. Naturally, this would link
directly into your issues register and that is where you would hook into your
lower level requirements process. It is important that those two controls
mesh together on any project.

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.

Figure 2: Requirement types

Requirements Artifacts
Requirement artifacts are the documents produced that contain
requirements and other supplementary information for the stakeholders.
 Figure 3: Requirement artifacts
One of things we need to do early on is to work out what artifacts are to be
produced. Figure 3 shows examples of some artifacts that have been
produced on a project. The terminology used is general terminology. Often,
organizations will call these artifacts different things, and it is important to
identify what artifacts are going to be produced on a project. The RMP
should include these artifacts and identify them right at the start of a
project.
The project approach is going to influence the different levels of artifacts.
Likewise, we need to identify what types of requirements are going to be
used on the project. Have you worked on a project where you have only
had solution and nonfunctional requirements? If so, you've gone straight
into solution requirements without understanding the business benefits.
By identifying higher level requirement types, we create linkages to
strategy.-What are the business goals and objectives? What are they trying
to achieve? What is the need? We need to make sure that, as we move
through the requirement types, we distill them down into lower level
requirements. It is important that we understand where those requirements
came from and what their main purpose was.
To put this in context, at the top we are looking at a high-level need, the
next level down is business requirements, and still further down, we get a
technical focus. I've seen organizations talk about a systems agnostic
approach. This is where you use business process to flush out where those
business requirements sit, and then drop down into the nonfunctional and
functional requirements. The levels evolve from a business focus drawing
down into a more technical focus. You can see a direct correlation between
the requirements types and the interest of the different stakeholders.
Requirements types are specifically targeted toward different types of
stakeholders.
Remember that different organizations use different names for their
artifacts (this is an example only). The first hurdle is understanding what
different types of requirements exist within your organization and who uses
them. In this article, I've use industry standards with requirements types to
reduce confusion.

Requirement Attributes
The following requirement attributes should be captured for all
requirements:
 Requirement identifier (unique)
 Requirement name
 Requirement description
 Requirement version number
 Requirement type
 Requirement change history
 Requirement status
 Requirement priority
 Requirement owner
 Requirement trace information
 Requirement process/activity reference
Every requirement needs a unique identifier and a meaningful name. The
requirement needs a brief description that is understandable to the
business. I've seen some implementations where descriptions can be some
kind of a graphic that you attach (a screen shot or something that you might
put on the web with your requirements). The version number of the
requirement (e.g. we are now at version 1.3 of this business requirement) is
important to track changes which are inevitable through a project.
Requirement types and change history are a little more subtle in that
typically, if you're managing your requirements in a text document, it is the
document that is versioned and not the individual requirement. That is
probably not too bad in a simple project, but when you have different
stakeholders interested in different sets of requirements, you may actually
want to publish a particular version of requirements to subgroups of people.
Requirements status is an important input to your project metrics. An
example of this is when a draft requirement waiting approval has been
approved, has been deferred, and has been removed. An analysis of status
metrics can help you understand why things in a project might be taking
longer than expected. At a point in time, you might want to say, “give me all
of the requirements that were actually created at this point in time, but still
have to be approved two months later.” This leads to questions such as:
What is going on? What is the issue? What is the problem? Why have I got
50 requirements that have been removed, suspended, or deferred? What is
the cause of that? Why is that not going to go ahead?
Requirements priority is particularly important for stakeholders. Questions
that may be asked are: What are my mandatory requirements? Which ones
are not mandatory, but are desirable so that if I have time constraints, I
canlook at deferring implementation of those requirements?
 The requirements owner needs to be identified, so that if a requirement is
not understood, more information can be obtained. If the developer comes
back and says that something is a good idea, but it will cause grief in terms
of implementation, you can also go back and ask the owner if there is
something else that can be done with thatrequirement. Going back and
talking to the business stakeholder helps ensure that he/sheis aware of this
and gainstheir truast and approval. You may also have a stakeholder that is
going on leave and his script of requirements may go to someone else who
can manage those requirements temporarily and then update the
stakeholder on changes when they return.
Just a word of caution, do not put in too many attributes the requirements
management plan to start with. There is a real temptation to put in lots of
attributes, but then you end up being a slave to your requirements
management plan. Start with the simple ones and expand out as you have
some different projects and different company needs.

Requirements Traceability
One of the most important components of requirements management is
traceability. Tracing allows us to understand why the requirement exists,
the impact of change, if the set of requirements is complete, and helps
prioritize requirements.

Figure 4: Requirements tracing

Figure 4 shows how traceability starts off with the business requirements’
outcomes/benefits and traces through the stakeholder requirements,
solution requirements, supplementary requirements/nonfunctional, and
down into testing scenarios and test cases. The complexity of tracing could
be very simple or it could be quite extensive. It really depends upon the
maturity of the organization and the groups that you are working with. You
can see that the volume of requirements at a high level is quite small, but
as you go down, you go down into a lower level of granularity where the
volume is going to grow. Yet, it is critically important to understand how
they relate back up to the top.

Requirements Artifacts, Types, and

Traceability
 Putting it all together is how an expert BA will differentiate him or herself.
Once all the requirements artifacts are traced tightly together, we start to
achieve clarity and control of the scope.

Figure 5: Requirements artifacts, types, and traceability

Finally, trace information gives you the ability to look at a particular
requirement and trace whether it is a genuine solution requirement. Does it
relate back up to a stakeholder requirement which relates back up to a
Subject Matter Expert (SME)? Does that solution requirement have any
associated nonfunctional requirements?
At the next level, publish a baseline set of requirements to the development
team. The development team then tags the code components back to
those original requirements and the test team actually takes their test cases
back to those requirements as an extension of that traceability. When we
talk about traceability, it is not just between solution and nonfunctional
requirements; it is the whole gambit back to strategy.
When we trace consistently, it becomes second nature and its value
becomes apparent. Every time you are looking at changing a requirement,
you must think of the impact it will have and what else it will affect. You
have to go back and look at what other requirements this is traced to and
make sure that you have not upset anything else. Typically, this happens
more frequently in the early analysis. Then as you go through to
development, you are still always trying to ensure that you trace between
requirements and maintain integrity between the solution and the strategy.

Requirements Versioning
Requirements versioning is the process of documenting and maintaining a
history of all changes to a specific requirement. The primary purpose of
versioning an individual requirement is to help ensure that the project team
is working from the exact same requirement.
Versioning is important to increment changes to a requirement. Unless you
are using a requirements management tool, this is probably something that
you are not going to continually do. Important requirements may change a
number of times-10, 20, 50 times, and this may occur through the whole
lifecycle of the project. It is important to track what version of that
requirement and what the specifics of the changes to that requirement are.
This allows you to link it to the owner, who is the one who performed the
change.
 Other purposes for versioning include:

 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.

 Formal - A prescribed project milestone that carries a formal acceptance of

requirements (all requirement attributes need to be populated and
requirements need to be validated as complete, unambiguous, and verifiable)
 Informal - An agreement between project team members that requirements
are correct at a point in time (minimum set of requirement attributes need to
be populated)
 Balance the number of baselines with the project size. Once the formal
baseline is created, then any changes to any of these requirements needs
to be handled through the project's change management procedure.

Communication of Requirements
Changes
The communication strategy for changes to requirements should be linked
to a change control process.

 Waterfall processes treat changing requirements as the exception

 Iterative and agile processes accommodate requirements change
A robust communications strategy will facilitate the auditing of requirements
by internal and external groups to help ensure that the delivered solution
accurately reflects the requirements.
A good communications strategy is particularly important if you are working
in a complex environment, with many internal stakeholders and external
stakeholders. Your communications strategy needs to be some sort of plan
around a communication method, and it needs to be a repeatable process.
You need to formalize it into the plan. This will help ensure that it is
repeatable. On large projects, it is going to be quite complex. On smaller
projects, it will be pretty easy, but it is important to think about that.
Embrace requirements change, as it is inevitable as you validate and verify
requirements. However, control change carefully so that it is managed.

Reasons for Using Requirements

Management Tools
A requirements management tool can increase the efficiency of an
established requirements management process by:

 Managing requirement version and content changes

 Storing requirement attributes
 Linking requirements to other system elements
 Providing multiple views of groups of requirements based on their attribute
values
 Monitoring the state of each requirement or groups of requirements
 Controlling access to requirements and therefore, preventing unauthorized
changes
 Facilitating the communication of requirements to requirement stakeholders
Why do we use tools? We have shown that there are a number of
requirements management attributes to collect and there is an overhead in
doing this. You can use requirements management tools to help you with
tasks such as storing requirement attributes, traceability, the change history
to requirements, the automated updated versioning, and the importance of
requirements.
A tool can help to provide multiple views to user groups of requirements.
You may have a particular stakeholder or project manager that needs a
regular report or a regular understanding of where their requirements are
at. This may be for a subcomponent of a project or the entire project, and
he/she may need to know which requirements are waiting to be approved,
who are they waiting to be approved by, and how many requirements have
been deferred this week.
Controlling access to requirements is a common feature of a requirements
management tool. We have all seen the situation where we have got soft
copies of work documents and inadvertently changed the content of those
documents without following all change control procedures. If you have
your requirements controlled inside a requirements management tool, the
access that particular analysts or stakeholder have is what they require.
For instance, the BA may have update access, while other stakeholders
may only have read-only access to your requirements. This helps ensure
that stakeholders do not change any requirements outside of an agreed
upon process.
Some requirements management tools allow you to publish the
requirements in a document or as browser-based content. It is a
mechanism that allows you to be a bit more flexible and integrated about
how you communicate your requirements to your stakeholders.
The important thing is to have a requirements management plan first and
then implement it through the tool. Do not let the tool drive the plan. Use a
business process first and then venture into a functionality tool. Tools cost
money so they require justification. We have performed requirements
management without a tool using spread sheets or locally-built databases.
Typically, it is only when these become too complex that a tool is justified. It
is probably a staged process to move to a full blown requirements
management tool. Hopefully, we have given you enough reason to go back
and talk to your company about your potential need for a tool.
Requirements Management Tools
Lessons Learned
Tool complexity should match the budget and business analyst capabilities
and needs of the organization.
Understand your requirements management needs before you purchase a
tool.

 Standalone requirements management

 Integration with other modeling tools
Don't take the vendor's word regarding functional capabilities. It is best to
conduct a proof of the concept before buying in.

Critical Success Factors for a

Requirements Management Plan
 Work to ensure that the Requirements Management Plan is implemented at
project start and adhered to and incorporated throughout the full lifecycle of
the project or product
 Work to ensure customers, stakeholders, managers, developers, and users
are all involved in the requirements management process
 Try to ensure that all team members understand the importance of adhering
to the Requirements Management Plan
 Foster good communication among team members during the process of
gathering, documenting, verifying, and managing changes to requirements
 Work to ensure that a requirements management tool is used to show
traceability and consistency and to assist in validation, verification, and
testing of the requirements
 Try to ensure Analysts have the discipline to continually maintain the
requirements traceability when using RM tools that will assist you, but won't
enforce the discipline of continually updating traceability
 Work to ensure that a requirements configuration management process is
implemented and that no changes are made to baselined requirements
without performing a risk analysis, re-estimating impacts to cost and
schedule, and validation amongst the stakeholders
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.

References
IAG Consulting. (2009). Business analysis benchmark : The path to
success (2nd ed.). New Castle, DE: Author.
The Standish Group International, Incorporated. (2004). CHAOS report.
The Standish Group International, Incorporated. (2009). CHAOS summary
report.
This material has been reproduced with the permission of the copyright owner.
Unauthorized reproduction of this material is strictly prohibited. For permission to
reproduce this material, please contact PMI or any listed author.
© 2015, Tim Coventry
Originally published as a part of the 2015 PMI Global Congress
Proceedings – London, UK