directed at finding the causes of the now-familiar syndrome of problems. The

investigations determined that requirements deficiencies are among the most important

contributors to the problem: “In nearly every software project which fails to meet

performance and cost goals, requirements inadequacies play a major and expensive role

trivial, but it is probably the part of the process which leads to more failures than any

It was determined that the benefits of good requirements include:

acceptance criteria for the delivered system

and time)

misunderstandings)

It was also observed that the value of good requirements, and the criticality of doing them

well, increased dramatically with the size and complexity of the system being developed.

Additionally, software-intensive systems seemed to have more inherent complexity, that

is, were more difficult to understand, than systems that did not contain a great deal of

software; thus these systems were more sensitive to the quality of their requirements.

The products of a good requirements analysis include not only definition, but proper

documentation, of the functions, performance, internal and external interfaces, and

quality attributes of the system under development, as well as any valid constraints on the

system design or the development process.

As the value of good requirements became clear, the focus of investigation shifted to the

requirements themselves: how should they be developed? How can developers know

when a set of requirements is good? What standards, tools, and methods can help; do they

exist, or must they be developed? These investigations are by no means complete: not

only are new tools and methods appearing almost daily, but overall approaches to

requirements, and how they fit into the system life cycle, are evolving rapidly. As a

result, requirements engineering has been well established as a part of systems

engineering. Requirements engineers perform requirements analysis and definition on

specific projects as well as investigate in the abstract how requirements should be

developed.

Many models exist for the system and/or software life cycle, the series of steps that a

system goes through from first realization of need through construction, operation, and

describe conditions under which various models might be used.) Almost all models

include one or more phases with a name like “requirements analysis” or “user needs

development.” Many models require generation of a document called, or serving the

function of, a requirements specification. Even those that do not call for such a document,

for example Jackson System Development, have a product such as a diagram or diagrams

A few of the better-known life cycle models are briefly discussed in the following

sections, and the way requirements engineering fits into them are presented.

Among the most extensively used models are baseline management and the waterfall, on

that it specifically requires each life cycle phase to generate defined products, which must

pass a review and be placed under configuration control before the next phase begins.) In

these models, as shown in Figure 1, determination of requirements should be complete, or

nearly so, before any implementation begins. baseline management provides a high

degree of management visibility and control, has been found suitable for developments of

very large size in which less complex methods often fail, and is required under many

military standards and commercial contracts. This model, however, has been somewhat

discredited, because when large complex systems are developed in practice it is usually

impossible to develop an accurate set of requirements that will remain stable throughout

the months or years of development that follow completion of the requirements. This

essential and almost unavoidable difficulty of the waterfall and baseline management

Brooks pointed out that the user often did not know what the requirements actually were,

and even if they could be determined at some point in time they were almost certain to

change. To resolve this problem Brooks recommended an evolutionary model, as is

discussed below. The approach advocated by Brooks provides the following advantages:

evolution), which provides better definition of the true needs than can be achieved by

reading a draft specification. This approach avoids what Brooks identified as the

unacceptable risk of building a system to the a priori requirements.

opposed to the delivery of everything after many months or years—permits

incorporation of new requirements and of capabilities that did not exist or were not

feasible at the start of development.

The prototyping life cycle (Figure 2) is one approach to the use of an operational system

minimum formality and control to be run for or by the user, so that requirements can be

determined accurately. Several successive prototypes will usually be built. The amount of

requirements analysis that precedes prototyping depends on the specifics of the problem.

It is normally recommended that the prototype should be used only to help generate a

valid set of requirements; after the requirements are available, they should be

documented, and development should proceed as in the baseline management model. If

this recommendation is followed, the prototyping portion of the life cycle may be

considered as a tool or method supporting requirements analysis within the baseline

management model.

as development of high-risk hardware and software components, which is a slow,

expensive process. Much of rapid prototyping is concentrated in two application areas:

user interfaces and heavily transaction-oriented functions such as database operations. In

these areas, a distinction can be made between prototyping tools and approaches that

provide only “mockups” (simulate the system’s response to user actions) and those that

actually perform the operations requested by the user. In the latter category are the socalled

code for user operations included within the 4GL’s capability. Such tools provide the

option of retaining the prototype as (part of) the final system; considerations of execution

time and efficiency of memory usage are weighed against the time and cost of building a

system using the baseline management model and requirements determined from the

rapid prototyping effort.

The incremental development life cycle model calls for a unitary requirements analysis

and specification effort, with requirements and capabilities allocated to a series of

increments that are distinct but may overlap each other (Figure 3). In its original

conception the requirements are assumed to be stable, as in the baseline management

model, but in practice the requirements for later increments may be changed through

technology advancement or experience with the early deliveries; hence this model may in

effect be not very different from the evolutionary development model described next.

The evolutionary development life cycle calls for a series of development efforts, each of

which leads to a delivered product to be used in the operational environment over an

extended period of time (Figure 4). In contrast with the prototyping model, in which the

purpose of each early product is only to help determine requirements, each delivery or

evolution provides some needed operational capability. However, there is feedback from

users of the operational systems that may affect requirements for later deliveries.

Each delivery in this model represents a full development cycle, including requirements

analysis. The deliveries may overlap, as shown in Figure 4, or one delivery may be

completed before the next is begun. The product of each requirements analysis phase is

an addition or improvement to the product(s) of the requirements analysis phase of the

previous delivery. Similarly, the implementation portions of each delivery may add to, or

upgrade, products of earlier deliveries. With this understanding, each delivery may be

looked at as a small example of a baseline management life cycle, with a development

process and time span small enough to minimize the problems discussed above.

conventional (baseline management), prototyping, and incremental models to be used for

various portions of a development. It shifts the management emphasis from

developmental products to risk, and explicitly calls for evaluations as to whether a project

should be terminated. Figure 5 summarizes the spiral model.

The radial coordinate in Figure 5 represents total costs incurred to date. Each loop of the

development. A phase may be specification oriented, prototyping oriented, an

evolutionary development step, or one of a number of other variants; the decision on

which form to use (or whether to discontinue the project) is made at each crossing of the

The spiral model thus makes explicit the idea that the form of a development cannot be

precisely determined in advance of the development: the re-evaluation at the completion

of each spiral allows for changes in user perceptions, results of prototypes or early

versions, technology advances, risk determinations, and financial or other factors to affect

the development from that point on.

Boehm has referred to the spiral model as a "process model generator”: given a set of

situation where requirements can be determined in advance and risk is low, the spiral will

result in a baseline management approach. If requirements are less certain, other models

such as the incremental or prototyping can be derived from the spiral. And, as mentioned

above, re-evaluation after each spiral allows for changes in what had been (tentatively)

concluded earlier in the development.

System and software requirements are often treated together because the tools and

methods used to derive them, and the techniques of documenting them, are very similar.

(It may be remarked that most of the tools and methods originated with software

developers and were then found to be appropriate for system use as well.) However, some

important differences between system and software requirements should be pointed out.

System requirements describe the behavior of the system as seen from the outside, for

example, by the user. Although requirements documents and specifications cannot easily

vehicle to the more technically inclined users, or to a purchasing organization, as well as

to analysts and designers who are concerned with the development of system elements or

components.

Requirements for elements below the system level, whether they are for elements that are

all hardware, all software, or composite (both hardware and software), are normally of

minimal interest to users. These requirements serve to communicate with the developers,

who need to know what is expected of the elements for which they are responsible, and

who also need information about those elements with which they must interface.

This distinction is important for several reasons. First, like any communications vehicle,

a requirements document should be written with its intended audience in mind. The

degree to which nontechnical users must read and understand a requirements document is

a factor in how it is written. Second, and perhaps most important, the skills and

experience of the requirements developers must be considered. All too frequently,

systems engineers with limited software knowledge are responsible for softwareintensive

systems. They not only write system-level requirements, which demands

knowledge of what functions and performance a software-intensive system can be

expected to meet; they also allocate functions and requirements to hardware and

software. Thus the software developers are asked to develop designs to meet

requirements that may be highly unrealistic or unfeasible. Software developers seem to

be reluctant to get involved in systems engineering; one of the results is that the

development of software elements often starts with poor requirements.

The U.S. Air Force Aeronautical Systems Center has recognized the importance of

systems engineering to a software development by including in its software development

interface with software engineering. The SDCE is an instrument used to help acquisition

organizations determine whether bidders who have submitted proposals for a software

contract are likely to be able to perform acceptably.

Section IV carries further the distinction between system and software requirements as

the approach to generating requirements for all system elements is outlined.

This section presents the overall framework within which requirements engineering takes

place. Information about tools and methods is not presented here; at this point concern is

focused on the sequence of events.

Several taxonomies have been proposed for requirements engineering. Prof. Alan Davis

Another is that requirements engineering consists of elicitation, analysis, specification,

validation/verification, and management. The comparison with Davis’s is

straightforward—validation/verification is included in maintenance, and management is

implicit in all four of Davis’s activities.

A system of any but the smallest size will be decomposed into a hierarchy of elements.

Starting with the lowest levels, the elements are integrated into larger-size elements at

higher levels, back up to the full system (Figure 6). Several approaches are available for

development of the hierarchy, but all produce definitions of elements at all levels of the

hierarchy. In the functional approach (implied by the element names used in Figure 6),

the elements represent the parts of the system that will meet particular system

requirements or carry out particular system capabilities. In a physical decomposition, the

elements will represent physical components of the system. In a data-driven approach, the

components will contain different parts of the key data needed by the system, and most

likely also the operations carried out on that data. In an object-oriented approach, the

system but also the data and functions (operations) needed by those physical components.

These elements are then integrated into larger-size elements at the next level, and so on

until the entire system has been developed, integrated, and tested. Thus the life cycle

models presented earlier can be seen to be oversimplified in that they do not account for

the development and integration of the various elements that compose the system. This

aspect can be considered to be outside the responsibility of the requirements engineer,

but, as discussed below, it affects cost, feasibility, and other factors that bring the realities

of implementation to the development of requirements, in contrast to the strict separation

of “what” and “how” often postulated for system development.

The requirements engineer needs to be concerned with all the requirements work that

takes place. As described above, this includes requirements for the entire system, for

composite (hardware and software) elements at lower levels, and for all-hardware and allsoftware

specification” are meaningless for any but the smallest systems; there will be several or

many requirements specifications.

Next is described the mechanics of filling out the system hierarchy with

example is functional, the process, and the traceability aspects that accompany it, are

valid whether the decomposition is functional, physical, data driven, or object oriented.

Early in the development process, the system-level requirements are generated. A

primary tool used in generating the system requirements is the Concept of Operations or

and operation of the system to be built. An important part of the development of both the

ConOps and the system requirements is the process of requirements elicitation, which is

defined as working with the eventual users of the system under development to determine

methods as well as system development and the application domain of the system to be

built.

While the system requirements are being developed, requirements engineers and others

begin to consider what elements should be defined in the hierarchy. By the time the

system requirements are complete in draft form, a tentative definition of at least one and

possibly two levels should be available. This definition will include names and general

functions of the elements. Definition of the system hierarchy is often referred to as

one or more elements at the next level; that is, it is determined which elements will

participate in meeting the requirement. In performing the allocation, it will become

apparent that (1) the system requirements need to be changed (additions, deletions, and

corrections), and (2) the definitions of the elements are not correct. The allocation

process therefore is iterative, leading eventually to a complete allocation of the system

requirements, as shown in Figure 7. The table in Figure 7 shows which element or

elements will meet each system requirement; all requirements must be allocated to at

least one element at the next level. In this example, we have called the level below

system the Subsystem level; in practice, the names are arbitrary, depending on the

number of levels in the entire hierarchy and the conventions in use by the systems

engineering organization. Figure 7 shows that the system-level requirement denoted as

SYS001 is allocated to subsystems A and B, SYS002 is allocated to A and C, and so

forth.

nomenclature is not universal.) Flowdown consists of writing requirements for the lowerlevel

elements in response to the allocation. When a system requirement is allocated to a

subsystem, the subsystem must have at least one requirement that responds to that

allocation. Usually more than one requirement will be written. The lower-level

requirement(s) may closely resemble the higher-level one, or may be very different if the

system engineers recognize a capability that the lower-level element must have in order

to meet the higher-level requirement. In the latter case, the lower-level requirements are

The level of detail increases as we move down in the hierarchy. That is, system-level

requirements are general in nature, while requirements at low levels in the hierarchy are

very specific. A key part of the systems engineering approach to system development is

finer elements, while the requirements start at a highly abstract (general) level and

become more specific for the lower-level elements. Large software-intensive systems are

among the most logically complex of human artifacts, and decomposition and abstraction

are essential to the successful management of this complexity.

When flowdown is done, errors may be found in the allocation, the hierarchy definition,

and the system requirements; thus the flowdown process is also iterative and may cause

parts of previous processes to be repeated. Figure 8 shows the results of the first level of

the flowdown process: a complete set of requirements for each of the subsystems.

System-level requirement SYS001 was allocated to subsystems A and B; subsystem

requirements (in this example, SSA001, SSA002, and SSB001) are written in response to

the allocation. Similarly SYS002 was allocated to A and C, and subsystem requirements

SSA003, SSA004, SSA005, SSC001, and SSC002 are the flowdown of SYS002 to

subsystem levels. The result is a complete set of requirements for each of the

subsystems. After completion of this level of flowdown, allocation of the subsystem

requirements is carried out to the next level, followed by flowdown to that level. Again

the processes are iterative and changes may be needed in the higher-level definition,

allocation, or flowdown.

The process of partitioning, allocation, and flowdown is then repeated to as low a level as

needed for this particular system; for software elements this is often to the module level.

Figure 9 emphasizes the iterative nature of this process at each level in the many levels of

partitioning, allocation, and flowdown.

The number of requirements proliferates rapidly during the allocation and flowdown

process. If we assume that there are four levels in the hierarchy, that each element

partitions to four at the next level, that each requirement is allocated to two of the four,

and that each flowdown results in three requirements per allocated element (all

reasonable assumptions), there will be more than 250 requirements in the hierarchy for

each system-level requirement. Keeping track of all these requirements is essential, to

make sure that all requirements are properly flowed down to all levels, with no

requirements lost and no “extras” thrown in. Reading and understanding the requirements

to answer these questions is difficult enough; without a way to keep track of the

flowdown path in a hierarchy of thousands of requirements, it becomes impossible.

Establishment of traceability as allocation and flowdown are done helps ensure the

validity of the process. Then, if changes are needed (such as a system-level requirement

due to user input, or a lower-level requirement due to a problem with allocation,

flowdown, or feasibility), traceability enables the engineer to locate the related

requirements, at higher and lower levels, that must be reviewed to see if they need to be

changed.

Figure 10 shows the traceability path corresponding to the allocation and flowdown in

Figures 7 and 8. System requirement SYS001 traces downward to SSA001, which in turn

traces downward to PGA001, PGA002, and PGB001. SYS001 also traces to SSA002,

which further traces to PGA003, PGC001, and PGC002. Upward traceability also exists,

for example, PGB001 to SSA001 to SYS001. A similar hierarchy exists through

SYS001’s allocation and flowdown to subsystem B. Other formats such as trees and

Note that, while allocation and flowdown are technical tasks, traceability is not strictly an

engineering function: it is a part of requirements management and is really only

“bookkeeping.” A case can be made that more of the requirements problems observed in

system development are due to failures in requirements management than to technical

enough that they are one of the six key process areas that a software development

organization must satisfy to move beyond the first ad hoc or chaotic level of maturity.

An additional step is interface definition. Before development of system requirements can

begin, the system’s external interfaces (the interfaces between the system and the outside

world) must be known. As each level of partitioning, allocation, and flowdown takes

place, the interfaces of each element to the rest of the system must be specified. This

definition has two parts. First, interfaces defined at higher levels are made more specific;

that is, the external interfaces to the entire system are identified as to which subsystem(s)

actually perform the interface. Second, internal interfaces at that level are defined, that is,

the subsystem-to-subsystem interfaces needed to enable each subsystem to meet the

requirements allocated to it.

Figure 11 illustrates this concept. In the top diagram, A represents an external interface of

the system, for example, an output produced by the system. When subsystems 1, 2, 3, and

4 are defined, as shown in the lower diagram, A is identified to subsystem 1, that is, the

output originates in subsystem A, and internal interfaces, such as B between 3 and 4, are

found to be necessary. This process continues throughout development of the hierarchy.

It is also possible that errors in partitioning, allocation, and flowdown will be discovered

when interface definition is taking place, leading to iteration in those earlier steps.

Next, let’s examine the implications of the above processes for the life cycle models

discussed earlier. It should now be apparent that the single “requirements analysis” phase,

even if extended to “system requirements analysis” and “software requirements analysis,”

is inadequate. The life cycle model should account for the multiplicity of levels in the

hierarchy, and furthermore should recognize that the various subsystems and other

elements at any level do not need to be synchronized. That is, if we are willing to accept

the risk that flowdown to the last subsystem will surface some errors in partitioning or

allocation, we can phase the subsystems, and of course the lower-level elements as well.

Figure 12 is the more realistic, and more complicated, life cycle chart that results from

the above considerations. Although it builds on a baseline management approach, the

nesting and phasing shown will apply to any of the models discussed earlier, or to

combinations. The key features of Figure 12 are as follows:

1. For all but the lowest level of the hierarchy, the implementation phase of its life cycle

becomes the entire development cycle for the next lower elements. Thus the

subsystems have their development cycle shown as a phase of the system life cycle.

2. Elements at any level may be phased. Thus the subsystems are shown as starting and

finishing their development cycles at different times. This approach has at least two

advantages:

be phased to avoid excessive demand for any technical specialty at any time.

time, rather than by the “big bang” approach of integrating all or many elements

at the same time.

A final point in the framework of fundamentals relates to another requirements

partitioning, allocation, flowdown, and interfaces are equally as important as their

generation. It has been shown repeatedly that requirements errors not found until later in

the development cycle are many times more expensive to fix than if they were found

requires that all the requirements at all levels be fully and properly reviewed before

design and implementation begin. The life cycle models wherein the requirements are not

all determined and “frozen” before design begins specify review of requirements as they

are considered ready to be the basis for some design and further development.

the most important attributes are the following:

It should be apparent that the evaluation of a requirements specification with respect to

extreme difficulty of attempting to quantify the degree to which a specification exhibits

these qualities. Nevertheless, these attributes are so important that the verification and

validation of requirements against these criteria must be carried out, to the degree

to validation and verification of requirements.

In the previous section, an overview is given of the process of par