IBM Software

Requirements definition and management

Ten steps to effective requirements

management

July 2013

Ten steps to effective requirements management

Introduction
Requirements definition and management is recognized as a
core discipline for the successful delivery of software and
systems engineering projects; this discipline is also required by
standards, regulations and quality improvement initiatives such
as Capability Maturity Model Integration (CMMI). In addition,
requirements definition and management is applicable whether
you are using a waterfall, iterative, agile or hybrid approach to
the systems and software engineering lifecycle.
Creating and managing requirements are a challenge for IT,
systems and product development projects or any activity where
you have to manage a contractual relationship. You must effectively define and manage requirements to meet your customer
needs, while managing compliance and staying on schedule and
within budget.
A poorly defined requirement can have a negative impact; it
can have a domino effect that could potentially lead to timeconsuming rework, inadequate deliveries or budget overruns.
Even worse, a poorly defined requirement can make business
processes non-compliant or cause potential damage to the
organization; in worse cases, it can lead to shutdown of business.
Requirements definition and management is an activity with
great potential to deliver a higher and faster return on
investment (ROI).

Defining a requirement
Requirements are the foundation of systems and software development. Therefore, project teams must understand the various
attributes of a good requirement. A well-defined requirement is:

Correct. A requirement is technically accurate and legally

appropriate.
Complete. A requirement presents a complete idea.
Clear. A requirement is clearly defined and not ambiguous.

Consistent. A requirement must not be in conflict with other

requirements.
Verifiable. A requirement must be verifiable; the application
must be suitable to address requirements.
Traceable. Each requirement is distinctively identified and
tracked.
Feasible. A requirement must be effectively addressed within
the specified cost and schedule constraints.
Modular. A requirement must be easily changed without
excessive effort.
Design-independent. A requirement does not pose specific
solutions on design.

Each requirement definition must first form a complete sentence, containing a subject and a predicate. These sentences
must consistently use the verb shall, will or must to show
the requirements mandatory nature and should or may to
show that the requirement is optional. The whole requirement
specifies a desired goal or result and contains a success criterion
or other measurable indication of quality.
Once these basic but necessary rules are applied, ten steps that
help developers at organizations better define and manage
requirements can be used.

Step 1: Structure requirements

Structuring requirements is the first step in controlling and
improving the quality of your defined requirements.
Duplicate requirements can lead to twice the quantum of work,
conflicts and eventually double your maintenance costs.
Omitted requirements may lead to missing functionality or cause
shortcomings. Therefore, requirements must be structured to
enhance understanding and to avoid duplication and omission.
Traceability to higher- and lower-level requirements enables
your teams to assess coverage more effectively.

IBM Software

Step 2: Address and link customer

needs, requirements and contracts
Specialists at organizations typically collect their customer needs,
captured as is. These needs undergo an internal translation to
requirements in a format that meets the requirements characteristics described above. These needs may also be made more
generic and less customer-specific so the system can address
multiple customer needs. In addition, a stable contractual
agreement, which is a legally binding third document, is often
used. Specialists must capture these levels of user requirements
to maintain intelligent traceability and enable change impact
analysis between them.
Specifications and contractual documents must be generated
from the requirements repository. With this central location,
you must also maintain links to outside elements, for example,
customer documents, emails and contracts.
By managing multiple representations of customer needs, project
teams have better control over contractual agreements and they
can help increase the possibility of project success.

Step 3: Manage constraints

Requirements must not only describe functional behavior but
also non-functional requirements, which are also known as
constraints. Non-functional requirements can be critical for
compliance and regulations and can add quality to the system.
Typical non-functional requirements can specify:

Performance
Interface
Security
Safety
Reliability
Availability
Maintainability

Writing better requirements includes providing coverage for

constraints because of shortcomings in these areas. For example,
performance, reliability and ease-of-use generally cannot be
reengineered back into the system once developed. By taking
into account all types of constraints relevant to your industry,
your project teams can greatly increase their chances of success.

Step 4: Visualize requirements

Most requirements analysts find augmenting textual requirements with modeling helpful, whether that includes drawing
pictures on a whiteboard, utilizing presentation tools such as
Microsoft PowerPoint or creating a mental model. These
representations must be managed along with the requirements
to help ensure consistency, traceability and change control.
Visual requirement modeling provides a simpler and more
powerful way to communicate with and elicit requirements from
customers and users. Visual requirement modeling also helps
clarify requirements and create a common understanding
between all development team members and stakeholders.
Although models and images should not replace clear, unambiguous textual requirements, your teams can enhance communication and collaboration among all stakeholders with visual
requirements.

Step 5: Integrate requirements with

your quality management plan
An efficient way to manage requirements is to ensure that they
are clearly mapped to test cases. Ensuring that each requirement
is clearly verifiable from the start not only helps prepare later
phases of your project but also puts the writer in the correct
perspective. This is true for the nominal functional mode confirming that the system or software does what it is designed to
do. Requirements and their associated tests must also indicate
what the system should not do and what happens at the limits
or degraded mode.

Ten steps to effective requirements management

This rule also applies to constraints that indicate how they

would be tested is a suitable way to write better requirements.
For instance, how would you test the requirement The software
must be highly usable? A better requirement would be, An
untrained user will be able to generate a report in less than
three minutes.
When you ensure that your requirements are clearly testable
early on in the process, you can more effectively improve project
success rates and quality.

Step 6: Prioritize the requirements that

deliver the greatest business value
In many cases, the route to better requirements management is
to have fewer requirements. Project teams cannot always offer
the luxury of implementing all customer requests, marketing
ideas and business suggestions when they also have to meet
budget and deadline objectives. Rather than trying to manage
every requirement, project and product managers must be able
to make decisions related to those requirements that bring the
most value to the customer and help improve innovation. Such
effective decision-making can be achieved by combining value
and priority information from stakeholders and by defining the
appropriate combination of requirements.
By creating and maintaining this link between engineering
requirements and business and customer needs, the senior management can help ensure that resources are spent efficiently.
Development and implementation can similarly align technical
decisions with your organizations strategy.

Step 7: Respond more rapidly but

accurately to changing requirements
Requirements are subject to continual change. As a project
progresses, project teams need to remain agile, adapt to engineering imperatives and respond to evolving marketplace
situations and customer needs. Writing a perfect first requirement is insufficient if its evolution is not well-managedpoorly
controlled change can lead to inadequate systems and software,
rework effort and loss of revenue.
Your project teams must implement a reliable and repeatable
change control process that helps turn this challenge into an
opportunity. With this change control process, your teams can
be more competitive, control schedules and respond to evolving
customer needs.

Step 8: Capture and track metrics

and trends
Todays complex projects demand automated data collection and
reporting facilities to streamline project management. As such,
project managers and all stakeholders need a management
dashboard of metrics and trends that enable them to quickly
monitor project activities such as progress, growth and volatility
of actual requirements. In other words, project managers
must keep their focus on decision making instead of manually
collating data and preparing reports. Most importantly, the
display of key requirements monitoring information must be
at a high level, enabling users to manage by exception and spot
trouble areas more quickly. A high-change frequency on a
specific requirement or a whole subsystem may indicate that
the requirement must be revisited with the customer. A
large amount of rework on implementation may point to a
poorly-specified original requirement.

IBM Software

Trends should also be used to learn lessons from past systems

and software projects: could issues and problems have been
identified earlier on? This wealth of information must be used
to build the organizations knowledge database.

Step 9: Provide examples of good

requirements
By providing examples and counterexamples of good requirements and documents, project teams can enhance the quality,
consistency and completeness of their requirements. These
attributes can originally be templates, industry standards and
rules inside a repository or a corporate intranet.
The next step must be to use good requirements from each project that reflect your teams domain expertise to build a corporate
knowledge database. Textbook requirement examples rarely
ref lect a companys needs and its own previous experience. Past
requirements must be annotated during a project postmortem
to indicate any notable information whether positive or negative.
New projects can, for example, examine the traceability that previous projects have used for regulations to understand how they
were taken into account and to identify teams that have already
achieved compliance for their projects.

Step 10: Reuse requirements

When a good requirement has been written for a previous project and is applicable to a present situation, the natural reaction
would be to reuse it by copying and pasting the description.
However, this duplication breaks the traceability and eliminates
impact analysis. A smarter approach to reusing requirements is
to maintain a link between the two requirements; for example,

creating a reuse type link. With this link, analysts can access
the original requirement at any time to check allocation of
implementation. Similarly, any changes made to the original
requirement such as detected issues, updates, can lead to the
notification of reusing teams.
By implementing smart requirements reuse, your project teams
can improve knowledge sharing across teams and facilitate
impact analysis.

Conclusion
Requirements definition and management are among the most
important activities in any project and efforts in this regard can
help improve and accelerate ROI. Requirements definition and
management is also the first process improvement area to focus,
based on the garbage in, garbage out rule: if requirements are
not clear, any other effort may help you to produce the wrong
product faster.
The first step to effective requirements management is to understand the simpler rules that make a requirement good. In addition, training courses and guidance can help your project teams
achieve this goal.
After the basic rules are in place, your specialists can further
increase the quality of their requirements by implementing
todays tested practices. These process improvement steps are
greatly aided by implementing requirements management software that not only helps project teams to manage requirements
more effectively but also helps improve their future projects by
implementing lessons learned from past and present projects.

For more information

To learn more about requirements management and
IBM Rational software for requirements management,
contact your IBM representative or IBM Business Partner, or
visit: ibm.com/software/products/us/en/subcategory/SW740
Read our blog on requirements management:
http://ibm.co/requirementsmanagementblog

Additionally, IBM Global Financing can help you acquire the

software capabilities that your business needs in the most
cost-effective and strategic way possible. Well partner with
credit-qualified clients to customize a financing solution to
suit your business and development goals, enable effective cash
management, and improve your total cost of ownership. Fund
your critical IT investment and propel your business forward
with IBM Global Financing. For more information, visit:
ibm.com/financing

Copyright IBM Corporation 2013

IBM Corporation
Software Group
Route 100
Somers, NY 10589.
Produced in the United States of America
July 2013
IBM, the IBM logo, and ibm.com are trademarks of International Business
Machines Corp., registered in many jurisdictions worldwide. Other product
and service names might be trademarks of IBM or other companies.
A current list of IBM trademarks is available on the web at Copyright
and trademark information at ibm.com/legal/copytrade.shtml
Microsoft is a trademark of Microsoft Corporation in the United States,
other countries, or both.
This document is current as of the initial date of publication and may be
changed by IBM at any time. Not all offerings are available in every country
in which IBM operates.
THE INFORMATION IN THIS DOCUMENT IS PROVIDED
AS IS WITHOUT ANY WARRANTY, EXPRESS OR
IMPLIED, INCLUDING WITHOUT ANY WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND ANY WARRANTY OR CONDITION OF
NON-INFRINGEMENT. IBM products are warranted according to the
terms and conditions of the agreements under which they are provided.
The client is responsible for ensuring compliance with laws and regulations
applicable to it. IBM does not provide legal advice or represent or warrant
that its services or products will ensure that the client is in compliance with
any law or regulation.
Please Recycle

RAW14059-USEN-03