Done well, requirements engineering presents an opportunity to reduce costs and increase

the quality of software systems. Done poorly, it could lead to a software project failure.

So it’s no surprise that there has been much interest in software requirements engineering

over the past 10 years or so. Many software project failures have been attributed to

requirements engineering issues. These include poorly documented requirements,

requirements that were impossible to satisfy, requirements that failed to meet the needs of

users, and requirements creep--the gradual inclusion of unanticipated, undocumented, and

poorly considered requirements.

Even when projects do not fail outright, software developers now recognize that errors

that occur early in the development life cycle, particularly at the requirements stage, turn

out to be the most difficult and costly to fix. This is especially true when the errors are not

discovered until late in the life cycle--perhaps at implementation.

The relatively recent attention to requirements engineering is fairly typical of the patterns

seen in earlier advances in software engineering. Software engineers initially focused on

programming methods, then on design methods, and are now focusing on requirements

methods, in an attempt to introduce more discipline in the software engineering process.

In the early days, requirements were developed in English text, but over time have

evolved into structured and in some cases formal specifications.

More recently there has been interest in requirements elicitation, because working with

non-technical people can be among the most challenging areas of software development.

In an effort to communicate with non-technical customers and understand their needs,

software developers have teamed with experts from the social sciences to gain new

perspectives on solving the thorny communication problems that can plague an

acquisition effort.

complementary points of view. Our Background article, “Requirements Engineering” by

Merlin Dorfman, is reprinted here by permission from the Institute of Electrical and

Electronics Engineers. First published in 1997, this article provides a high-level, tutoriallike

presentation of the field of requirements engineering. The article reviews the progress

made in requirements engineering over the past decade and characterizes different

development methodologies as they pertain to requirements.

As befits a challenge of this magnitude, every area of research at the SEI confronts some

aspect of requirements engineering, and is resulting in exciting work on a number of

article, “Requirements Engineering at the SEI,” and in our “Requirements Engineering

Roundtable”:

example of the current synergy between systems and software is the recent work that

the SEI has done on software architecture analysis. Architecture analysis reveals how

the choice of architectural structure affects questions such as how maintainable a

system is, how well it performs, how well it scales, how secure it is, and how reliable

it is.

(COTS) products into systems. Developers and acquirers of systems must be aware of

the rapid changes in commercial technology and how they affect the requirements

engineering process. Department of Defense (DoD) policy strongly encourages the

DoD program manager to be innovative and to embrace best commercial practice

with respect to requirements. Section 2.3.1 of DoD 5000.2-R [1], Evaluation of

Requirements Based on Commercial Market Potential, states

requirements into the process of developing systems.

SEI, government, and industry, takes a holistic view of the requirements engineering

process and acknowledges that software and systems cannot easily be separated.

requirements process. For example, the SEI is developing simulators to help

organizations establish requirements and evaluate tradeoffs for survivable systems,

and to determine how long it will take a team to develop requirements and how well

Finally, our Links feature offers a guided tour of information available on the Web about

requirements engineering.

1. “Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and

Major Automated Information System (MAIS) Acquisition Programs,” DoD Regulation

5000.2-R, Change 2, paragraph 2.3.1. October 6, 1997.

http://www.acq.osd.mil/api/asm/product.html

2. For information about how spiral development was used in the Expeditionary Force

eXperiment, (FX), an ongoing effort on the leading edge of DoD acquisition, see

The Software Engineering Institute (SEI) is a federally funded research and development

center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon

University.

Process, and TSP are service marks of Carnegie Mellon University.

® Capability Maturity Model, Capability Maturity Modeling, CERT Coordination

Center, CERT, and CMM are registered in the U.S. Patent and Trademark Office.