NEWS AT SEI
This article was originally published in News at SEI on: March 1, 1999
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
In this section
In this release ofSEI 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’sSpotlight
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
·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 , 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. TheSEI’s work in these
areas is motivated by the growing interest inspiral development .
Finally, our Links feature offers a guided tour of information available on the Web about
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
SMIDEAL, 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.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.