Do you face out-of-control software development projects? Completed
software that doesn’t meet users’ needs? Consider requirements management, a
discipline which helps deliver on-time and on-budget software which meets users’
By Mathew Schwartz
Does the software you develop meet your users’ or customers’ actual needs?
Practically every piece of software built today is new, in the sense that it
utilizes new techniques, tools, or technologies, and solves problems existing
software can’t handle. Accordingly, many software development efforts are “educated
guess” affairs. Business analysts chart users’ problems, and developers
try to code software to solve those problems. Everyone, to some extent, is
learning as they go.
Frequently, however, developers run into one of two complications: they
produce software with too much functionality Â¿ users don’t need and won’t use
all the bells and whistles Â¿ which means development time was wasted; or else
the software doesn’t meet users’ real needs, leading to delayed, costly
projects and software which, when delivered, may be solving last year’s
Fed up with the continuing stream of software projects that over- or
under-shoot, many project and product managers are turning to requirements management.
Simply put, requirements management is the discipline of managing a project by
correctly gathering, disseminating, applying, and verifying that software meets
Building the Right Software
The purpose of software development is clear enough: “to deliver
working code that solves customer problems,” notes Dean Leffingwell,
co-author of Managing Software Requirements: A Unified Approach
Yet building software is incredibly difficult Â¿ no matter whether you’re
working for an independent software vendor (ISV), or on a company’s in-house
software development team Â¿ because it involves accurately gauging customers’
requirements. Thus the job of requirements management is “to mitigate the
risk that requirements-related issues will prevent a successful project
outcome,” says Leffingwell. “If there were no such risks, then it
would be far more efficient to go straight to code and eliminate the overhead
of requirements-related activities.”
Managing requirements throughout the project lifecycle helps projects
succeed. According to requirements management expert Harold Halbleib, “effective
requirements management helps to control quality, cost, organization, and
schedule, thus substantially improving your odds of a successful project.”
Requirements Management Techniques
How does requirements management work? In general, you gather four sets of
- User Â¿ Tasks users must
- Technical Â¿ The hardware and
- Business Â¿ All business goals
such as higher revenues and increased efficiency.
- Functional Â¿ How the product
will be built.
Techniques for gathering this information must be tailored to the project at
hand, and in particular designed to defuse any potential risks the project team
will encounter. As noted in Managing Software Requirements, such techniques
- Interviewing Â¿ Identify
stakeholders and their actual needs.
- Requirements workshops Â¿
Achieve consensus between stakeholders.
- Brainstorming Â¿ Find
innovative new approaches.
- Storyboarding Â¿ Ensure the
product meets actual needs.
- Use cases Â¿ Verify the
product will meet users’ real needs and work styles.
- Change management Â¿ Manage
the impact of changes the software will produce.
Requirements Management Tools
A variety of tools and techniques exist to help manage requirements, though
they tend to be specific to the development methodology used.
For example, more traditional software development practices Â¿ including
Waterfall and Spiral methodologies Â¿ are plan-driven: they specify all
requirements up front, build a project plan, then commission technical staff to
meet that plan. Accordingly, requirements must be precisely specified Â¿ indeed,
near-perfect Â¿ or else developers may create over-engineered software which
meets the wrong needs. Some of the tools used for plan-driven requirements
management include Borland CaliberRM, Compuware SteelCase, IBM Rational
RequisitePro, Mercury’s Quality
Center, and Telelogic
By contrast, so-called agile development techniques, including Crystal, Extreme
Programming (XP), Lean, and Scrum, are predicated on not knowing all
requirements, and expecting requirements to change during development.
Accordingly, agile software development teams tend to prioritize requirements,
then tackle the highest priorities first, delivering new software in short
intervals (typically 1-4 weeks), with each iteration vetted by users. If users
sign off on an iteration, that requirement is complete. Otherwise, user feedback
guides further development.
Ongoing requirements management is essential for agile projects since
anything can change at any moment. Accordingly, useful tools tend to be less
focused on creating and disseminating a plan, and more on rapid collaboration.
Such tools, then, may include spreadsheets, wikis, dedicated agile software
development tools, or even the tools used for more plan-driven software
development (though they may be overkill).
Requirements Exercises for Agile Teams
As noted, requirements management includes the process of collecting user
requirements, typically dubbed “use cases” or “user stories.”
Simply put, these record everything a user needs to do, such as “print the
security report on standard-size paper for archiving purposes,” but preferably
without going into too much detail about how developers should realize this
For agile development teams, after collecting these user stories, “typically,
there are a couple of exercises that boil to the top,” says Ryan Martens,
founder and chief technology officer of Rally Software Development Corp., which
offers agile software development and requirements management products and
training. First, he says, write a high-level data sheet detailing what the
product needs to accomplish. Then create a product box with the high-level
marketing detail: note the value, the audience, the top six features, and the
He recommends actually creating this product box. “Cover a cereal box
with paper, and use crayons, to make sure metaphorically it’s the right
approach,” he says. Better make four or five. If users reach a consensus
on one of the product boxes, developers can start coding. Otherwise, make more.
A product box focuses developers on delivering a software application that
meets the highest-priority requirements first. Lesser requirements may be
handled later, or users may decide such features aren’t even needed. This is
the beauty, then, of applying requirements management: to deduce the most
successful approach, for the least amount of time, effort, and money.
Mathew Schwartz is a freelance business and technology journalist based
in Cambridge, Mass.