This article was originally published in News at SEI on: March 1, 1999

Software requirements engineering

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.

In this section

In this release of SEI Interactive, we explore requirements engineering from several

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

SEI Interactive, 03/99 page 2

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

fronts. You can learn more about the work briefly described here in this issue’s Spotlight

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


· A significant aspect of systems engineering is the focus on tradeoff analysis. A good

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.

· Tradeoffs must also be considered when incorporating commercial off-the-shelf

(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

Researching the potential of the commercial marketplace to meet system

performance requirements is an essential element of building a sound set

of requirements. In developing system performance requirements, DoD

Components shall evaluate how the desired performance requirements

could reasonably be modified to facilitate the use of potential commercial

or non-developmental items, components, specifications, open standards,

processes, technology, and sources.

· Concerns about network security and information survivability are introducing new

requirements into the process of developing systems.

· The Capability Maturity Model® Integration (CMMI) project, a joint effort of the

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

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

· New work at the SEI is focused on how to use technology to improve the

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

organizations establish requirements and evaluate tradeoffs for survivable systems,

SEI Interactive, 03/99 page 3

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

those requirements will meet a particular quality standard. The SEI’s work in these

areas is motivated by the growing interest in spiral development [2].

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.

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


SM IDEAL, Interim Profile, Personal Software Process, PSP, SCE, Team Software

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.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.