Requirements Engineering for Software and Systems

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 agendas—even among

persons within the same stakeholder group—is the “Rashomon Effect.” Rashomon

is a highly revered 1950 Japanese film 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 estimates’ inherent 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.