171
9Chapter
Requirements
Management
Introduction
Requirements management involves identifying, documenting, and tracking sys-
tem requirements from inception through delivery. Inherent in this definition is
understanding of the true meaning of the requirements and the management of
customer (and stakeholder) expectations throughout the system’s lifecycle. A solid
requirements management process is the key to a successful project.
Most organizations do not have an explicit requirements management process
in place, but this does not mean that requirements management does not occur
within the organization. e requirements practices probably exist implicitly in the
organization, but these practices are not usually documented. One of our recom-
mendations, obviously, is to document the requirements management practices in
your organization.
Managing Divergent Agendas
Each stakeholder has a different requirements agenda. For example, business
owners seek ways to get their money’s worth from projects. Business partners want
explicit requirements because they are like a contract.Senior management expects
more financial gain from projects than can be realized. And systems and software
developers like uncertainty because it gives them freedom to innovate solutions.
172 Requirements Engineering for Software and Systems
Project managers may use the requirements to protect them from false accusations
of underperformance in the delivered product.
One way to understand why the existence of different agendaseven among
persons within the same stakeholder group—is the “Rashomon Effect.Rashomon
is a highly revered 1950 Japanese lm directed by Akira Kurosawa. e main
plot involves the recounting of the murder of a samurai from the perspective of
four witnesses to that event—the samurai, his wife, a bandit, and a wood cutter,
each of whom has a hidden agenda, and tells a contradicting accounting of the
event. Stated succinctly “your understanding of an event is influenced by many
factors, such as your point of view and your interests in the outcome of the event”
(Lawrence 1996).
e smart requirements manager seeks to manage these agendas by asking the right
questions up front. Andriole (1998) suggests the following questions are appropriate:
1. What is the project request?
Who wants it?
Is it “discretionary” or “nondiscretionary?”
2. What is the project’s purpose?
If completed, what impact will the new or enhanced system have on orga-
nizational performance?
On profitability?
On product development?
On customer retention and customer service?
3. What are the functional requirements?
What are the specific things the system should do to satisfy the purpose-
ful requirements?
How should they be ranked?
What are the implementation risks?
4. What are the nonfunctional requirements, like security, usability, and
interoperability?
How should they be ranked?
What are the implementation risks?
How do you trade off functional and nonfunctional requirements?
5. Do we understand the project well enough to prototype its functionality?
6. If the prototype is acceptable, will everyone sign off on the prioritized func-
tionality and nonfunctionality to be delivered, on the initial cost and schedule
estimates, on the estimatesinherent uncertainty, on the project’s scope, and
on the management of additional requirements?
Andriole asserts that by asking these questions up front, hidden agendas can be
uncovered and differences resolved. At the very least, important issues will be raised
up front and not much later in the process.

Get Requirements Engineering for Software and Systems now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.