TRENDS
September 1, 2006
The Root Of The Problem: Poor Requirements
Three Strategies For Addressing Three Types Of Requirements Problems
by Carey Schwaber
with Gene Leganza and Megan Daniels
EXECUT I V E S U M MA RY
The quality of software requirements is a limiting factor on the success of software development projects.
And it’s the rare IT organization that couldn’t improve its requirements practices. When it comes to getting
requirements right, companies struggle on two primary fronts: requirements definition and requirements
management. But the market places a disproportionate emphasis on tools for requirements management.
The real opportunity for improvement lies in requirements definition and in how different development
methodologies treat changing requirements.
TARGET AUDIENCE
Application development professional
DIFFERENT TYPES OF REQUIREMENTS PRACTICE, DIFFERENT TYPES OF REQUIREMENTS PAIN
Poor requirements practices alone can doom any application development initiative. No matter how wellarchitected, well-constructed, or well-tested an application might be, it is essentially useless if it fails to
meet business needs. Defects in requirements are the source of the majority of defects that are identified
during testing, and problems with requirements are among the top causes of project failure.1 There are
three types of common requirements problems: incomplete or inaccurate requirements, poorly managed
requirements change, and missed requirements. These problems correspond to different requirements
disciplines: in descending order of importance, requirements definition, requirements change management
processes, and tools and techniques for requirements management.
Requirements Definition Offers The Most Room For Improvement
The old aphorism “garbage in, garbage out” couldn’t apply more than it does in this context. Even the
best requirements management practices can’t make up for inaccurate requirements. If anything, an
overemphasis on requirements management can lend the illusion that requirements management
problem has been “solved.” And when business stakeholders aren’t in close communication with the
development team, the importance of proper requirements definition only increases; for this reason,
requirements definition is even more critical in the context of outsourced software development and
maintenance.2 IT organizations that want to do a better job of requirements definition need to:
Headquarters
Forrester Research, Inc., 400 Technology Square, Cambridge, MA 02139 USA
Tel: +1 617/613-6000 • Fax: +1 617/613-5000 • www.forrester.com
Trends | The Root Of The Problem: Poor Requirements
2
· Balance business and IT involvement. The act of eliciting and documenting requirements
is a collaborative process that requires equal involvement from business and IT. The most
common pitfalls in requirements definition? Either too little or too much business involvement.
Because requirements definition is a shared responsibility, it is all too frequently an abdicated
responsibility. One shop reported, “Our customer’s attitude is that requirements are our
problem.” But the opposite also occurs. A different IT organization complained to us, “The
business usually hands IT a document that dictates a solution.” Better articulation of business
and IT roles and responsibilities for requirements definition goes a long way toward solving this
problem (see Figure 1).
· Recognize that text isn’t always the best medium. Requirements come in all shapes and sizes
and are found in a wide variety of places. In addition to the traditional business requirements
document and standard functional and nonfunctional requirements, development teams must
also take into account requirements that live in existing applications, service interfaces, security
standards, prototypes, business process models, and business rules. Embracing different media
for requirements definition helps involve a wider range of constituents in the process and helps
ensure requirements aren’t excluded merely because of their format.
· Secure proper training for business analysts. The lynchpin of the requirements definition
process is the business analyst, a hybrid creature expected to move with ease between the worlds
of business and technology. But business analysts all too often fall into the role and aren’t given
adequate training to do their job properly. IT shops should aim to equip their business analysts
with an arsenal of requirements definition techniques. To grow a corps of skilled analysts,
enterprises can look to user groups like the International Institute of Business Analysis and
training courses like those offered by tools vendors and training companies like B2T Training
and ESI International.
Figure 1 Sample Division Of Responsibilities Between Business And IT
Business responsibilities
IT responsibiltiies
• Develop business requirements that do not
presuppose design or implementation details
• Prioritize requirements based on relative need
and available resources
• Provide signoffs only after carefully evaluating all
materials and ensuring thorough comprehension
• Communicate changing business needs and
collaborate with development to determine the
impact of these changes
• Understand business goals and business context
• Identify and employ appropriate techniques to
define functional and nonfunctional requirements
• Communicate about progress toward fulfillment
of requirements
• Manage relationships between requirements and
other life-cycle artifacts to ensure fulfillment of
requirements
40309
September 1, 2006
Source: Forrester Research, Inc.
© 2006, Forrester Research, Inc. Reproduction Prohibited
Trends | The Root Of The Problem: Poor Requirements
3
Requirements Change Processes Are Tightly Tied To Development Methodology
IT organizations commonly lament that the world would be a better place if only they could stamp
out requirements change. But while better requirements definition practices will help reduce
unnecessary requirements change, they won’t eliminate it altogether. It’s an IT organization’s choice
of development methodology — more than its choice of requirements change processes — that
determines its ability to accommodate requirements change:
· Waterfall processes treat changing requirements as the exception. In waterfall processes,
requirements are defined at the beginning of the life cycle and presumed to remain constant
over time. The impact of a requirements change — and the associated costs — increases
dramatically as the project progresses and more derivative artifacts are produced. When
waterfall processes are in use, open communication with business stakeholders about the true
cost of requirements change to enable informed decision-making is absolutely essential. Shorter
release cycles make requirements change in a waterfall context less expensive and represent a
step in the right direction.
· Iterative processes accommodate requirements change. Where a waterfall process would have
a single long release cycle, incremental, iterative development processes consist of a sequence
of short release cycles. One of the greatest benefits of this type of development methodology?
The end of each iteration represents an opportunity to make changes to requirements without
incurring significant costs (see Figure 2). Iterative methodologies also encourage the use of
more modular architecture, which makes it easier for the software under development to evolve
in parallel with business needs.
IT organizations that incur high costs from requirements churn should revisit their choice of
development methodology. Using a waterfall development process in an environment where
business needs are changing rapidly will only lead to budget and schedule overruns and low levels of
customer satisfaction.
September 1, 2006
© 2006, Forrester Research, Inc. Reproduction Prohibited
Trends | The Root Of The Problem: Poor Requirements
4
Figure 2 Two Models For Managing Changes To Requirements
Project A: waterfall development process
Release
J
F
M
A
M
Requirements definition
J
J
A
S
O
N
D
Formal approval process for requirements change
Project B: iterative, incremental development process
Release 1
Iteration 0
J
F
M
A
Release 2
M
J
Release 3
J
A
Release 5
Release 4
S
O
N
D
Opportunity for Opportunity for Opportunity for Opportunity for
requirements
requirements
requirements
requirements
change
change
change
change
40309
Source: Forrester Research, Inc.
Requirements Management Tools Increase The Efficiency Of Mature Requirements Processes
Requirements management — tracking requirement status, associating requirements with other
life-cycle artifacts, managing changes to requirements, and identifying the impact of these changes
on these associated artifacts — can’t improve the quality of requirements, but it can help ensure
the correspondence of requirements to derived artifacts like specifications, models, and test cases.
An insurance company that lacks solid requirements management practices told Forrester, “We
often hear that requirements have been overlooked. The link between what we really need to build
in the first place and what’s getting built is missing.” But when it comes to adopting requirement
management tools, user companies must be careful to (see Figure 3):
· Avoid tools that are too complex. Leading requirements management tools are relatively
complex, and, as a result, the category has a high incidence of shelfware. These tools offer value
for larger waterfall development projects, but for small and midsize projects — and especially
for projects using Agile processes — the cost of using the tool sometimes exceeds the benefit.3
At a global systems integrator’s .NET delivery centers, smaller projects store requirements as
work items in Visual Studio Team System, but larger projects store them in Borland Caliber
using the Caliber plug-in for Team System. And Rally Software Development’s solution lets each
project choose between two models of requirements management, one lightweight and the other
traditional.
September 1, 2006
© 2006, Forrester Research, Inc. Reproduction Prohibited
Trends | The Root Of The Problem: Poor Requirements
5
· Make end user comfort the No. 1 selection criterion. Shops that opt for traditional requirements
management software must make end user comfort the ultimate driver of their tool selection effort
so as to not let their requirements management software spend go to waste. Users should expect
vendors to conduct live proof-of-concepts where representative business analysts can sit down in
front of each tool. It’s important to look closely at the depth of support that is offered for business
analysts’ preferred means of requirements specification (e.g., Word, Web interface, use cases,
process models, storyboards) and for the ease with which they can use requirements to generate
other relevant artifacts (e.g., traceability matrices, UML models, test cases).
· Adopt tools with an eye toward life-cycle integration. Although most of requirements
management tools’ value comes from life-cycle integration, it’s all too common for these tools
to be silos.4 User companies must remember to think about intended integration targets before
making a tool purchase and to investigate the difficulty of building and maintaining these
integrations.5 To remove barriers to integration, MKS and Serena Software have both built
requirements management and process-centric software configuration management (SCM)
solutions on top of a common repository.6 The most valuable integration for a requirements
management tool is not SCM, but rather test management. Integration of requirements
management and test management enables traceability from requirements to test cases, or even
requirements-driven testing.
Figure 3 Tools For Requirements Definition And Requirements Management
Purpose-built tools
Requirements definition • Axure RP
• Borland DefiniteIT
• Compuware Optimal Trace
• iRise
• Ravenflow
• Serena Composer
• Sofea Profesy
Requirements management • Borland CaliberRM
• Compuware Optimal Trace
• IBM Rational RequisitePro
• Serena Dimensions RM
• Telelogic DOORS
40309
September 1, 2006
Other types of tools commonly used
• Modeling tools (e.g., Microsoft Visio)
• Microsoft Office,
• Graphics packages (e.g., Adobe Illustrator)
• HTML
• Homegrown applications
• Test management tools
• Change management tools
Source: Forrester Research, Inc.
© 2006, Forrester Research, Inc. Reproduction Prohibited
Trends | The Root Of The Problem: Poor Requirements
6
R E C O M M E N D AT I O N S
IDENTIFY YOUR REQUIREMENTS PAIN POINTS BEFORE STARTING TO THINK ABOUT TOOLS
The recent proliferation of tool support for different requirements activities has created
much confusion in the marketplace. In the past, the only specialized requirements tools were
requirements management tools like Borland CaliberRM, IBM Rational RequisitePro, and Telelogic
DOORS. The emergence of new tools like iRise and Ravenflow that target requirements definition
has increased the amount of attention that is paid to this part of the problem. However, this
has also led to confusion in the marketplace. As one Forrester client put it, “We know we have a
problem with requirements, but we can’t tell what type of tool can help us fix it.” Each type of tool
support helps address a different type of problem:
· Requirements definition tools to improve the initial quality of requirements. Better
requirements definition practices reduce the number of defects and the amount of rework
resulting from misunderstood requirements, misarticulated requirements, and unknown
requirements. High-fidelity prototyping tools in particular help increase business stakeholder
engagement in the requirements definition process and help IT secure real buy-in — as
opposed to just formal sign-off — on requirements.7
· Requirements management tools to help carry requirements through the life cycle.
In contrast, requirements management tools help reduce the number of defects and the
amount of rework that stems from missed requirements, missed changes to requirements,
and missed impact from requirement change. These tools also minimize the burden of
managing relationships between requirements and between requirements and other lifecycle artifacts like models and test cases.
ENDNOTES
1
The Standish Group’s 1994 Chaos Report found that the top three project impairment factors across 352
companies and 8,000 projects were lack of user input (12.8% of respondents), incomplete requirements
and specifications (12.3%), and changing requirements and specifications (11.8). Other research has shown
almost 50% of defects identified during testing to be due to defects in requirements. Source: “Calculating
your return on investment from more effective requirements management.” See http://www-128.ibm.com/
developerworks/rational/library/347.html.
2
In offshore outsourcing relationships, companies often struggle with communications challenges. This
struggle is most debilitating during the requirements and specification stage: Users are unable to express
their requirements clearly enough for a vendor to properly interpret and implement those requirements.
This problem leads to extensive rework and end user dissatisfaction. Firms can avoid this by employing topnotch business analysts with outsourcing experience who can bridge the communication gap. See the April 7,
2006, Trends “To Eliminate Communication Issues, Introduce Your Offshore Vendor To Your Customer.”
September 1, 2006
© 2006, Forrester Research, Inc. Reproduction Prohibited
Trends | The Root Of The Problem: Poor Requirements
7
3
Agile methods tend to deemphasize the decomposition of requirements into specs and detailed models,
instead relying on real-time specification with guidance from an on-site customer. While Agilists are
interested in tracing from high-level requirements to test cases, they’re rarely interested in tracing from one
type of requirement to another or to various types of models. Consequently, development teams using Agile
processes have little use for traditional requirements management tools.
4
Project managers and business analysts, the typical end users of requirements management (RM) tools,
often fail to see the value of integrating RM with software configuration management. These resources focus
on goals like schedule, scope, and budget, but they should consider expanding their emphasis from these
ends to include some of the means by which they can be achieved. Integrating RM with SCM helps these
employees understand not only what progress the team is making but also how; this integration supports
more informed decision-making and helps ensure that development teams deliver the right functionality
on time and under budget. See the September 21, 2005, Quick Take “Integrate Requirements Management
With SCM To Enable More Informed Project Management.”
5
When user companies ask about tool integrations, they too often accept “yes” or “no” answers. To
determine how well and how easily a vendor’s tools really integrate with each other and with third-party
tools, inquire about the technologies used to accomplish this integration. A multichannel retailer that’s had
great success building out an integrated suite of tools from multiple vendors goes so far as to quiz customer
references about integrations, talk to the vendor’s engineering staff, and even start working the APIs
themselves, if they’re available. See the August 18, 2006, Trends “The Changing Face Of Application LifeCycle Management.”
6
A spate of mergers and acquisitions has left Serena Software the largest SCM pure play. And the strength
of the MKS process-centric software configuration management solution is particularly impressive given
MKS’s size — $40 million in annual revenues — and relatively recent entry into the SCM space. See the
November 14, 2005, Tech Choices “Process-Centric Software Configuration Management Scorecard
Summary: Serena Software” and see the November 14, 2005, Tech Choices “Process-Centric Software
Configuration Management Scorecard Summary: MKS.”
7
If communicating requirements from business users to IT or communicating intentions from IT to
business stakeholders is a source of frustration — and it is in a great many organizations — take a look at
specification tools. With their combination of ease of use, rapidity of prototyping, and high fidelity, they can
bridge gaps in ways that little else, short of actually building the code, can achieve. See the August 11, 2005,
Trends “Show, Don’t Tell.”
Forrester Research (Nasdaq: FORR) is an independent technology and market research company that provides pragmatic and forward-thinking advice about
technology’s impact on business and consumers. For 22 years, Forrester has been a thought leader and trusted advisor, helping global clients lead in their markets
through its research, consulting, events, and peer-to-peer executive programs. For more information, visit www.forrester.com.
© 2006, Forrester Research, Inc. All rights reserved. Forrester, Forrester Wave, Forrester’s Ultimate Consumer Panel, WholeView 2, Technographics, and Total
Economic Impact are trademarks of Forrester Research, Inc. All other trademarks are the property of their respective companies. Forrester clients may make one
attributed copy or slide of each figure contained herein. Additional reproduction is strictly prohibited. For additional reproduction rights and usage information,
go to www.forrester.com. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change. To purchase reprints
of this document, please email [email protected].
40309