Very early in the drive to industrialize software development, Royce (1975) pointed
out the following truths:
ere are four kinds of problems that arise when one fails to do ade-
quate requirements analysis: top-down design is impossible; testing
is impossible; the user is frozen out; management is not in control.
Although these problems are lumped under various headings to sim-
plify discussion, they are actually all variations of one theme—poor
management. Good project management of software procurements
is impossible without some form of explicit (validated) and govern-
ese truths still apply today, and a great deal of research has veriﬁed that devot-
ing systematic eﬀort to requirements engineering can greatly reduce the amount
of rework needed later in the life of the software product and can improve various
qualities of the software cost eﬀectively.
Too often systems engineers forego suﬃcient requirements engineering activ-
ity either because they do not understand how to do requirements engineering
properly or because there is a rush to start coding (in the case of a software product).
2 Requirements Engineering for Software and Systems
Clearly, these eventualities are undesirable, and it is a goal of this book to help engi-
neers understand the correct principles and practices of requirements engineering.
What Is Requirements Engineering?
ere are many ways to portray the discipline of requirements engineering depend-
ing on the viewpoint of the deﬁner. For example, a bridge is a complex system, but
has a relatively small number of patterns of design that can be used (for example,
suspension, trussed, cable-stayed). Bridges also have speciﬁc conventions and appli-
cable regulations in terms of load requirements, materials that are used, and the
construction techniques employed. So when speaking with a customer (for exam-
ple, the state department of transportation) about the requirements for a bridge,
much of its functionality can be captured succinctly:
e bridge shall replace the existing span across the Brandywine River
at Creek Road in Chadds Ford, Pennsylvania, and shall be a cantilever
bridge of steel construction. It shall support two lanes of traﬃc in each
direction and handle a minimum capacity of 100 vehicles per hour in
Of course there is a lot of information missing from this “speciﬁcation,” but it
substantially describes what this bridge is to do.
Other kinds of systems, such as biomechanical or nanotechnology systems with
highly specialized domain language, have seemingly exotic requirements and con-
straints. Still other complex systems have so many kinds of behaviors that need to
be embodied (even word processing software can support thousands of functions)
that the speciﬁcation of said systems becomes very challenging indeed.
Since the author is a software engineer, we reach out to that discipline for a
convenient, more-or-less universal deﬁnition for requirements engineering that is
due to Pamela Zave:
Requirements engineering is the branch of software engineering con-
cerned with the real-world goals for, functions of, and constraints on
software systems. It is also concerned with the relationship of these fac-
tors to precise speciﬁcations of software behavior, and to their evolution
over time and across software families. (Zave 1997)
But we wish to generalize the notion of requirements engineering to include any
system, whether it be software only, hardware only, or hardware and software (and
many complex systems are a combination of hardware and software), so we rewrite
Zave’s deﬁnition as follows: