Chapter 1 Introductions, Issues, and Terminology

1. Introduction to Chapter
It is a well-documented belief that the failure to develop and document good requirements specifications is the major cause of software development failures.1'2'3 The purpose of Chapter 1 is to identify some of the major issues in software requirements development and to define terms used both in and around system and software engineering. The problems with writing good, correct, complete, and measurable system and software requirements specifications are a major issue in software development today. Some of the major issues of concern in the requirements area are: The lack of cooperation by customers when it comes to verifying that the software requirements are correct, and the lack of understanding of the structure and purpose of the software requirements specifications The problems associated with identifying which tool and/or methodology to use in developing and representing a software requirements specification The lack of knowledge that system requirements are essential to the development of good software requirements, or the unwillingness to act in accordance with that knowledge The lack of training of system engineers on how to partition and allocate system functions to software The desire of senior management in many large corporations to place personnel with little software knowledge or experience in positions of responsibility over what is essentially a major software project

The inability of engineers to write a correct software requirements specification The desire of managers to truncate requirements activity because they believe that the major effort in any software development is programming and testing

Terminology causes many problems because of the newness of the computer science and software engineering fields. Many terms do not have universally accepted definitions. System engineers, computer scientists, and software development groups define things in different ways. One of the purposes of this tutorial is to provide a common set of definitions that can be used in the area of system and software requirements engineering. The four articles in this chapter were selected to introduce the tutorial, provide definitions, and establish the requirements engineering issues and problems. The first article, by the co-editor of the tutorial, Dr. Merlin Dorfman, sets the tone for the entire tutorial and establishes the definition of system and software requirements engineering. The article by Harwell et al. defines software requirements and provides a taxonomy of software requirements definitions. An article by Scharer looks at requirements from both the user's and developer's point of view. The last article, by Siddiqi and Shekaran, Program Co-Chairs of the 1996 International Conference on Requirements Engineering, summarizes the current state of research and practice.

quantitative requirements as being measurable requirements. One of the major research areas in software engineering is in determining how to measure qualitative requirements Project and product requirements. Product requirements would be part of a requirements specification and project requirements would be part of a statement of work (SOW) or management plan Mandatory requirements, guidance (also called "desirable requirements"), and information (also called "notes")

2. Description of Articles
The first article, "Requirements Engineering" by Merlin Dorfman, is an overview of this tutorial. In this article, Dorfman discusses the value of good requirements and specifications, the place of requirements analysis in the life cycle, and the framework for developing system requirements. The article introduces the concepts of architectural design, allocation, flowdown, and traceability. It also explains the application of configuration management, interface definition, and verification and validation to the requirements activity. A brief introduction is given to some of the tools and methods to be discussed in detail later in the tutorial. The second article in the chapter, "What Is a Requirement?" by Richard Harwell, Erik Aslaksen, Ivy Hooks, Roy Mengot, and Ken Ptack, does an excellent job in defining many of the terms associated with requirements engineering. While there may be some differences of opinion in discussing some of these definitions, for the most part they appear to be those definitions in common use today. The article defines differences between: Derived and primary (also called "allocated") requirements Qualitative and quantitative requirements. The authors define qualitative requirements as being unmeasurable requirements and

The article also attempts to separate requirements from "design;" however, it does recognize that a "design" (sometimes called a design constraint) can be a requirement. The article concludes with a discussion about three attributes of a requirements specification: (1) completeness, (2) lack of ambiguity, and (3) scope (also called "measurable"). A discussion in Chapter 3 will indicate that there are a number of other attributes that can also be applied to a specification document. "Pinpointing Requirements" by Laura Scharer does a very fine job of defining the major issues involved in writing a software requirements specification. She points out that analysts and users harbor grave doubts about each other. The origins of these attitudes are obviousfailure encourages blame. Users are disenchanted, because developers constantly bungle new system developments; and developers are disenchanted because they alone are blamed for the failures. This article is about software development for an in-house user; in other words, the user belongs to the same parent company as the software development team. Because of this situation, the relationship between the developer and user is much closer than in a contract situation. Scharer points out the problems that exist between experienced and inexperienced users and between experienced and inexperienced software developers. She goes on to discuss some realistic goals and how to improve the relationship between the developer and the user. For instance, a thorough evaluation is needed as to whether or not the system can be defined. The article also points out 12 different environmental factors that influence the software development process. The article goes on to define methods for controlling the system, for selecting a user for the project team, and for training the user, and presents a welldefined approach to developing a software system. The last article, by Jawed Siddiqi and M. Chandra Shekaran, "Requirements Engineering: The Emerging Wisdom," reports on some of the work being done to improve software requirements. The article examines a
4

number of different ways to answer the question, "What constitutes a requirement?" Other issues discussed in the article are as follows: Prioritizing requirements Coping with incompleteness Making requirements methods and tools more accessible

References
1. Alford, M.W., and J.T. Lawson, Software Requirements Engineering Methodology (Development), RADC-TR-79-168, U.S. Air Force, Rome Air Development Center, Griffiss AFB, New York, N.Y., 1979. Davis, A.M., Software Requirements: Analysis and Specification, Prentice-Hall, Englewood Cliffs, N.J., 1990. Faulk, S.R., "Software Requirements," in Software Engineering, M. Dorfman and R.H. Thayer, eds., IEEE Computer Society Press, Los Alamitos, Calif., 1997.

2.

The article concludes with a statement that the authors believe there is a greater need to narrow the gap between research and practice.

3.

Requirements Engineering
Merlin Dorfman Lockheed Martin Missiles & Space Company Sunnyvale CA 94088-3504

Abstract Requirements engineering is presented and discussed as a part of systems engineering and software systems engineering. The need for good requirements engineering, and the consequences of a lack of it, are most apparent in systems that are all or mostly software. Requirements engineering approaches are closely tied to the life cycle or process model used. A distinction is made between requirements engineering at the system level and at lower levels, such as software elements. The fundamentals of requirements engineering are defined and presented: elicitation; decomposition and abstraction; allocation, flowdown, and traceability; interfaces; validation and verification. Requirements development approaches, tools, and methods, and their capabilities and limitations, are briefly discussed.

I. Introduction
When the "Software Crisis"1 was discovered and named in the 1960s, much effort was 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 in project failure."2 Development of the requirements specification "in many cases seems trivial, but it is probably the part of the process which leads to more failures than any other."3 It was determined that the benefits of good requirements include: Agreement among developers, customers, and users on the job to be done and the acceptance criteria for the delivered system A sound basis for resource estimation (cost, personnel quantity and skills, equipment, and time) Improved system usability, maintainability, and other quality attributes The achievement of goals with minimum resources (less rework, fewer omissions and misunderstandings)

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.

II. Requirements Engineering and the Development Life Cycle

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 retirement.4 (Boehm5 provides a good

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-

overview of many existing models, and presents as well a risk-driven approach that includes many other models as subsets; Davis et al.6 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 that incorporate or express the user's needs and the development objectives.7 A few of the better-known life cycle models are briefly discussed in the following sections, and the way requirements engineering fits into them is presented. A. Baseline Management Among the most extensively used models are Baseline Management and the Waterfall, on which Baseline Management is based.8 (Baseline Management differs from the Waterfall in 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 models had been noted for many years9'10 but was brought to the attention of the U.S. defense software community by a Defense Science Board report authored by F. Brooks.11 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:

REQUIREMENTS

DESIGN

CODE

TEST

INTEGRATE

Figure 1. The Baseline Management and Waterfall models.

8

The user is given some form of operational system to review (a prototype or early 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. Delivery of some operational capabilities early in the development processas opposed to the delivery of everything after many months or yearspermits incorporation of new requirements and of capabilities that did not exist or were not feasible at the start of development.

B. Prototyping The Prototyping life cycle (Figure 2) is one approach to the use of an operational system to help determine requirements.12 In this model, some system capability is built with 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.

Many tools and methods are available to help support prototyping. The term rapid prototyping is associated with some of them, to distinguish them from other forms, such 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 so-called Fourth Generation Languages (4GLs),13'14 which provide methods of generating 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. C. Incremental Development 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.

i
REQUIREMENTS TEST BUILD DESIGN PROTOTYPE PROTOTYPE PROTOTYPE DOCUMENT REQUIREMENTS DESIGN CODE TEST INTEGRATE

Figure 2. The Prototyping life cycle model.

REQ.

DES

CODE

TEST

INT.

O&M

DES

CODE

TEST

INT.

O&M

DES

CODE

TEST

INT.

O&M

DES

CODE

TEST

INT.

O&M

Figure 3. The Incremental Development model D. Evolutionary Development 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.

REQUIREMENTS

DESIGN

CODE

TEST

INTEGRATE

OPERATIONS & MAINTENANCE

REQUIREMENTS

DESIGN

CODE

TEST

INTEGRATE

OPERATIONS & MAINTENANCE

REQUIREMENTS

DESIGN

CODE

TEST

INTEGRATE

Figure 4. The Evolutionary Development model.

10

E. The Spiral Model Boehm5 describes the Spiral model, an innovation that permits combinations of the 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 spiral, from the (~x) axis clockwise through 360 degrees, represents one phase of the development. A phase may be speci-

fication 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 (-x) axis by evaluating objectives, constraints, alternatives, and status (particularly risk). 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.

CUMULATIVE COST

PROGRESS THROUGH STEPS DETERMINE OBJECTIVES, ALTERNATIVES, CONSTRAINTS EVALUATE ALTERNATIVES; IDENTIFY, RESOLVE RISKS

RISK ANALYSIS

RISK ANALYSIS

RISK ANALYSIS .OPERATION ALA ^PROTOTYPE \ COMMITMENT REVIEW PARTITION

ROTS. PLAN UFE CYCLE PLAN CONCEPT OF OPERATION SOFTWARE RQTS R A PROTOTYPE j PROTO-^ TYPE, PROTOTYPE! SIMULATIONS. MODELS. BENCHMARKS 1 I

DEVELOPMENT PLAN

REQUIREMENTS VALIDATION

SOFTWARE PRODUCT DESIGN

DETAILED DESIGN

INTEGRATIOV AND TEST ^LAN

DESIGN VALIDATION AND VERIFICATION INTEGRATION AND TEST IMPLEMENTATION ACCEPTANCE TEST UNIT TEST

CODE

PLAN NEXT PHASES

DEVELOP, VERIFY NEXT-LEVEL PRODUCT

Figure 5. The Spiral model.

11

Boehm has referred to the Spiral model as a "process model generator": given a set of conditions, the Spiral produces a more detailed development model.15 For example, in the 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.

III. System and Software Requirements

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 be read by users,16 the system requirements serve at least as a partial communications 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 software-intensive systems. They not only write system-level requirements, which demands knowledge of what functions and per-

formance 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 Capability Evaluation (SDCE)17 material about systems engineering capability and its 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.

IV. Fundamentals of Requirements Engineering

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 has proposed the following18: Elicitation Solution determination Specification Maintenance

Another is that requirements engineering consists of elicitation, analysis, specification, validation/verification, and management. The comparison with Davis's is straightforwardvalidation/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

12

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 components will consist of objects that include not only physical components of the system but also the data and functions (operations) needed by those physical components. After the lowest-level elements {Units in Figure 6) are defined, they are separately developed and then integrated to form the next larger elements (Programs in Figure 6). 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 elements. It should be noted at this point that references to the "requirements specification" are meaningless for any but the smallest systems; there will be several or many requirements specifications. A. System Requirements Next is described the mechanics of filling out the system hierarchy with requirements.19'20 It should be pointed out that, although the hierarchy used as an 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 ConOps document,16 a document that is narrative in form and describes the environment and operation of the system to be built. An important part

SYSTEM

SYBSYSTEM A

SUBSYSTEM B

SUBSYSTEM C

PROGRAM A

PROGRAM B

PROGRAM C

PROGRAM D

PROGRAM E

PROGRAM F

PROGRAM G

UNITS

UNITS

UNITS

UNITS

UNITS

UNITS

UNITS

Figure 6. Example system hierarchy.

13

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 their needs.21 Elicitation involves an understanding of psychological and sociological 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 partitioning. B. Allocation The next step is usually called allocation. Each system-level requirement is allocated to 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. C. Flowdown The next step is referred to as flowdown. (The reader should be aware that this nomenclature is not universal.) Flowdown consists of writing requirements for the lower-level 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 requirements) 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 often referred to as derived.

SYSTEM REQUIREMENTS SYS 001 SYS 002 SYS 003 SYS 004 SYS 005 SYS 006 SYS 007

SUBSYSTEM A

SUBSYSTEM B

SUBSYSTEM C

X X

X X X

X X

X X X

Figure 7. Example of allocation of system requirements.

14

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 decomposition and abstraction: the system is partitioned (decomposed) into finer and 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.

SYSTEM REQUIREMENT

SYSTEM A REQUIREMENT SSA 001 SSA 002 SSA 003 SSA 004 SSA 005

SYSTEM B REQUIREMENT SSB001

SYSTEM C REQUIREMENT

SYS 001

SYS 002

SSC 001 SSC002

SYS 003

SSB 002 SSB 003 SSB 004 SSB 005 SSB 006

SYS 004

SSA 006 SSA 007

SSC 003

SYS 005

SSB 007 SSB 008 SSB 009

SSC 004 SSC 005

SYS 006 SYS 007

SSA 008 SSA 009

Figure 8. Example of flowdown of system requirements.

15

DEVELOP SYSTEM REQUIREMENTS

DEFINE HIERARCHY

ALLOCATE (1 LEVEL)

FAIL.

VALIDATE

PASS FLOWDOWN (1 LEVEL)

FAIL

VALIDATE

PASS ALLOCATE (1 MORE LEVEL)

VALIDATE

(ETC.)

Figure 9. Iteration in partitioning, allocation, and flowdown.

D. Traceability 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. Traceability is the concept that implements the necessary bookkeeping.19'20 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.

16

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 SYSOOl's allocation and flowdown to subsystem B. Other formats such as trees and indented tables can be used to illustrate traceability, as in Dorfman and Flynn.19 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 functions. In the Software Engineering Institute's Capability Maturity Model for Software,22 these nontechnical aspects of requirements management are important 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.

. Interfaces 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^) 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.

SYSTEM REQUIREMENT

SUBSYSTEM A REQUIREMENT

PROGRAM A REQUIREMENT PGA 001 PGA 002

PROGRAM B REQUIREMENT

PROGRAM C REQUIREMENT

SSA001 SYS 001 SSA002

PGB001

PGA 003

PGC 001 PGC002

SSA003

PGB 002 PGB003

SYS 002

SSA004

PGA 004

PCB004 PCB005 PCB 006

PGC 003 PGC 004 PGC 005

SSA 005

PGA 005

Figure 10. The requirements traceability path.

17

SYSTEM

B 3 4

Figure 11. Increasing detail of interface definition.

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. F. The Refined Life Cycle Model 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: Staff can be employed more efficiently, since the schedules for each element can be phased to avoid excessive demand for any technical specialty at any time Integration can be carried out in a logical fashion, by adding one element at a time, rather than by the "big bang" approach of integrating all or many elements at the same time

G. Validation and Verification A final point in the framework of fundamentals relates to another requirements management task, the review of the requirements.23 Validation and verification of the partitioning, allocation, flowdown, and interfaces is 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 before the requirements phase was completed.24 The Baseline Management model requires that all the requirements at all levels be fully and properly reviewed before design and implementation begin. The life cycle models

18

System Life-Cycle
A Phased-Delivery Model

Jfa&zr,
Concept Requirements Design Implementation Coordnation Integration Acceptance Sustaining Engineering & Operations & Test Test Phaseout

Concept

Requirements

Design

Inptementation Coordination

Integration Acceptance Test

Maintenance

<23&fc?^^W*>32r^2*^l v&

Concept

Requirements

Design

IfflpteflMfiation

airing AEwkiatfon

MointBnance

Concept

Requirements

Design

irrpiementaton Coordnation

integrasonj Acceptance last

Maintenance

Concept

ReqJrements

Design

Implementation Coordination

Integration Acceptance Test &*T9St

Maintenance

Concept

Requirements

Design

int igratiori Acceptance i Test Test

Maintenance

Concept

Requirements

Design

Integration Acceptance Test

Maintenance

Detailed Design

Code & Unit Test

Unit Integration A Test

Adapted from NASA Software Management and Assurance Program

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 attributes of a good requirements specification are addressed by Boehm.23 Among the most important attributes are the following: Clear/unambiguous Complete Correct Understandable Consistent (internally and externally) Concise Feasible

It should be apparent that the evaluation of a requirements specification with respect to these attributes may be highly subjective and qualitative. Davis et al. 25 demonstrate the 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 possible and as quantitatively as possible. Boehm 23 and Davis et al.25 address approaches to validation and verification of requirements.

the extent possible, a pure "what," addressing the desired characteristics of the complete system. The next steps, determining the next level of the hierarchy and allocating system requirements to the elements, are in fact a "how": they do not address objectives beyond the system requirements, but they define a subsystem structure that enables the requirements to be met. Flowdown is again a "what," determining what each element should do (functions, performance, and so on). Development of the architectural design is, then, a process in which the steps of requirements analysis and design alternate, with more detail being brought out at each cycle. The output of requirements analysis is input to the next stage of design, and the output of design is input to the next stage of requirements analysis. 7 If different people perform the two functions, one person's requirement is the next person's design, and one person's design is the next person's
28

V. Requirements Engineering and Architectural Design

In the previous section, an overview is given of the process of partitioning, allocation, and flowdown. The result of this process (a definition of the hierarchy down to some level, generation of the requirements for all elements, and determination of the interfaces between them) is known as the architectural design or top-level design of the system. Although it is called a design, requirements engineering is involved throughout the process. What, then, is the distinction between requirements analysis and design in this process? Requirements analysis is often defined as the "what" of a problem: implementation free; containing objectives, not methods. Design, then, is the "how": the implementation that will meet the requirements. The two are supposed to be kept distinct, although of course the feasibility of meeting a requirement always needs to be considered. However, if you look closely at the process of generating the architectural design, you will see that both requirements analysis and design are involved.26 The generation of system-level requirements is, to

requirements. Pure requirements analysis, like pure design, can only go so far. Both disciplines are needed to achieve the desired result, a system that meets its user's needs. Note that the character of requirements analysis, like that of design, changes as we move down in the hierarchy: requirements analysis for a low-level element is much more detailed, and involves knowledge of previous design decisions. The tools and methods used for "analysis" do in fact support all aspects of architectural design development: partitioning, allocation, and flowdown. They therefore are useful in both the requirements analysis and design stages of the process.

VI. Requirements Engineering Practices

The principles of requirements engineering described above are valid and important, but for practical application additional specifics are needed. These specifics are provided by methods and tools. A method, sometimes referred to as a methodology, describes a general approach; a tool, usually but not always automated, provides a detailed, step-by-step approach to carrying out a method. A. Methods Requirements analysis methods may be roughly divided into four categories, as shown in Figure 13. The categorizations should not be regarded as absolute: most methods have some of the characteristics of all the categories, but usually one viewpoint is primary. Process-oriented methods take the primary viewpoint of the way the system transforms inputs into outputs, with less emphasis on the data itself and control aspects. Classical structured analysis (SA)29 fits into

19

PROCESS ORIENTED

i OBJECT I ORIENTED

SYSTEM REQUIRE MENTS

DATA ORIENTED

CONTROL ORIENTED

Figure 13. Categories of requirements analysis methods. this category, as do Structured Analysis and Design Technique (SADT),30 and formal methods such as VDM31 and Z.32 Data-oriented methods emphasize the system state as a data structure. While SA and SADT have secondary aspects of the data viewpoint, Entity-Relationship modeling33 and JSD7 are primarily data oriented. Control-oriented methods emphasize synchronization, deadlock, exclusion, concurrence, and process activation and deactivation. SADT and the real-time extensions to SA34'35 are secondarily control oriented. Flowcharting is primarily process oriented. Finally, object-oriented methods base requirements analysis on classes of objects of the system and their interactions with each other. Bailin36 surveys the fundamentals of object-oriented analysis and describes the variations among the several different methods in use. B. Tools The number of tools that support requirements engineering is growing rapidly, and even the most cursory survey is beyond the scope of this paper. Nevertheless, some discussion of the characteristics of requirements engineering tools, and trends in these characteristics, is in order. Davis18 has classified requirements tools as follows: Graphical editing Traceability Behavior modeling Databases and word processingnot designed for requirements engineering, but used in requirements applications Hybrid (combinations of the above) Early requirements tools, such as SREM37 and PSL/PSA,38 were stand-alone, that is, were not integrated with any other tools, and supported the requirements analysis function by providing automation, either for a specific method or a group of methods. These tools consisted of hundreds of thousands of lines of code and ran on large mainframe computers. PSL/PSA used only very limited graphics in its early versions but later versions had improved graphics capabilities. SREM made heavy and effective use of graphics from the beginning. Both included some form of behavior modeling. In this same time frame, standalone traceability tools began to be developed.19 By the mid-1980s, integrated software development environments began to become available that, while they were more complex software products than the earlier tools, ran on powerful (usually UNIXbased) workstations that were smaller in size and lower in cost than mainframes. Examples include Software through Pictures,39 CADRE Teamwork, and similar products. These environments included requirements analysis tools, which generally supported one of the standard graphical analysis methods, and might also include traceability tools that enabled the requirements to be traced through design, implementation, and test. Some of the integrated environments provided a choice of analysis tools, such as tools that supported different methods. As computers continued to become smaller, more powerful, and lower in cost, full software development environments (known as Computer-Aided Software Engineering [CASE] or Software Engineering Environments [SEE]) became available on desktop computers, and economics permitted providing such a computer to each member of the development team and networking them together. CASE environments seemed full of promise during the late 1980s but somehow that promise has not been

20

translated into pervasive use in the embedded systems and scientific software markets40; perhaps there was a perception that the environments supported a Waterfall or Baseline Management model of end-to-end software development better than the Prototyping, Evolutionary, or Incremental models that became increasingly popular. The requirements tools that are part of these integrated environments are, of course, limited to the market penetration of the environments themselves. In the application area of transactionoriented systems such as financial and database, tools implementing an Entity-Relationship model such as Texas Instruments's Information Engineering Facility have revolutionized the way software is developed, but in the scientific and embedded application areas standalone tools, if any, are used. Perhaps the current trend toward object-oriented technologies will revitalize the market for tools and for integrated tool environments. C. The Role of Tools and Methods In conclusion, a few words are in order about the role of tools and methods in requirements engineering, and indeed across the full scope of software and systems engineering. Proper use of tools and methods is an important part of process maturity as advocated by the Software Engineering Institute,22 and process maturity has been shown to lead to improvements in a software development organization's productivity and quality.41 It has equally been shown that developers cannot adopt or purchase methods and tools and just throw them at the problem. Selection of tools and methods requires study of their applicability and compatibility with the organization's practices. A process must be identified that meets the organization's needs; methods must be selected that support the process, with tool availability one of the factors to be considered; then and only then should tools be purchased. Commitment, training, and the time to make the transition are essential. Tools and methods are not a panacea: if selected and used correctly they can provide great benefits; if regarded as magic solutions or otherwise misused, they will prove an expensive failure.

opment Center, Griffiss AFB, NY, June 1979 (DDCAD-A073132). 3. Schwartz, J.I., "Construction of Software, Problems and Practicalities," in Practical Strategies for Developing Large Software Systems, E. Horowitz, ed., Addison-Wesley, Reading, Mass., 1975. IEEE Standard 610.12-1990, "IEEE Standard Glossary of Software Engineering Terminology," IEEE, New York, N.Y., 1990. Boehm, B.W., "A Spiral Model of Software Development and Enhancement," Computer, Vol. 21, No. 5, May 1988, pp. 61-72. Davis, A.M., E.H. Bersoff, and E.R. Comer, "A Strategy for Comparing Alternative Software Development Life Cycle Models," IEEE Trans. Software Eng., Vol. 14, No. 10, Oct. 1988, pp. 1453-1461. Cameron, J.R., "An Overview of JSD," IEEE Trans. Software Eng., Vol. 12, No. 2, Feb. 1986, pp. 222-240. Royce, W.W., "Managing the Development of Large Software Systems," Proc. IEEE Wescon, 1970. Reprinted in Proc. 9th Int'l Conf Software Eng., IEEE Computer Society Press, Los Alamitos, Calif., 1987, pp. 328-338. McCracken, D.D. and M.A. Jackson, "Life Cycle Concept Considered Harmful," ACM Software Eng. Notes, Vol. SE-7, No. 2, 1982, pp. 29-32.

4.

5.

6.

7. 8.

9.

10. Gladden, G.R., "Stop the Life Cycle, I Want to Get Off," ACM Software Eng. Notes, Vol. SE-7, No. 2, Apr. 1982, pp. 35-39. 11. Brooks, F.P., Jr., Chairman, Report of the Defense Science Board Task Force on Military Software, Office of the Under Secretary of Defense for Acquisition, U.S. Department of Defense, Washington D.C., Sept. 1987. 12. Gomaa, H. and D.B.H. Scott, "Prototyping as a Tool in the Specification of User Requirements," Proc. 5th Int'l Conf Software Eng., IEEE Computer Society Press, Los Alamitos, Calif., 1981, pp. 333-342. 13. Verner, J. and Graham T., "Third-Generation versus Fourth-Generation Software Development," IEEE Software, Vol. 5, No. 4, July 1988, pp. 8-14. 14. Cobb, R.H., "In Praise of 4GLs," Datamation, July 15, 1985, pp. 36-46. 15. Boehm, B.W., ed., Software Risk Management, IEEE Computer Society Press, Los Alamitos, Calif., 1989, p. 434. 16. Fairley, R.E. and R.H. Thayer, "The Concept of Operations: The Bridge from Operational Requirements to Technical Specifications," in Software Engineering, M. Dorfman and R.H. Thayer, eds., IEEE Computer Society Press, Los Alamitos, Calif., 1997. 17. Acquisition Software Development Capability Evaluation (2 volumes), AFMC Pamphlet 63-103, Depart-

References
1. Naur, P. and B. Randell, eds., "Software Engineering: Report on a Conference Sponsored by the NATO Science Commission," Garmisch, Germany, 7-11 Oct. 1968. Scientific Affairs Division, NATO, Brussels, Jan. 1969. Alford, M.W. and J.T. Lawson, "Software Requirements Engineering Methodology (Development)," RADC-TR-79-168, U.S. Air Force Rome Air Devel-

2.

21

ment of the Air Force, HQ Air Force Material Command, Wright-Patterson AFB, OH, June 15, 1994. 18. Davis, A.M., private communication, 1996. 19. Dorfman, M. and R.F. Flynn, "ARTSAn Automated Requirements Traceability System," J. Systems and Software, Vol. 4, No. 1, 1984, pp. 63-74. 20. Palmer, J.D., 'Traceability," in Software Engineering, M. Dorfman and R.H. Thayer, eds., IEEE Computer Society Press, Los Alamitos, Calif., 1997, pp. 266-276. 21. Goguen, J.A. and C. Linde, 'Techniques for Requirements Elicitation," Proc. Int'l Symp. Requirements Eng. IEEE Computer Society Press, Los Alamitos, Calif., 1993. 22. Paulk, M.C. et al., Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-24, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, P.A., Feb. 1993. See also Paulk, M . C ,

Communicating Ideas," IEEE Trans. Software Eng., Vol. 3, No. 1, Jan. 1977, pp. 16-33. 31. Bjoerner, D., "On the Use of Formal Methods in Software Development," Proc. 9th Int'l Conf Software Eng., IEEE Computer Society Press, Los Alamitos, Calif., 1987, pp. 17-29. 32. Norris, M., "Z (A Formal Specification Method). A Debrief Report," STARTS, National Computing Centre, Ltd., 1986. Reprinted in System and Software Requirements Engineering, R.H. Thayer and M. Dorfman, eds., IEEE Computer Society Press, Los Alamitos, Calif., 1990. 33. Reilly, J.R., "Entity-Relationship Approach to Data Modeling," in Software Requirements Engineering, 2nd ed., R.H. Thayer and M. Dorfman, eds., IEEE Computer Society Press, Los Alamitos, Calif., 1997. 34. Ward, P.T. and S.J. Mellor, Structured Development Techniques for Real-Time Systems (3 vols.), PrenticeHall, Englewood Cliffs, N.J., 1985. 35. Hatley, D.J., "The Use of Structured Methods in the Development of Large Software-Based Avionics Systems," AIAA Paper 84-2592, Proc. 6th Digital Avionics Systems Conf, AIAA, New York, N.Y., 1984. 36. Bailin, C.A., "Object Oriented Requirements Analysis," in Encyclopedia of Software Engineering, John J. Marciniak, ed., John Wiley & Sons, New York, N.Y., 1994. 37. Alford, M.W., "SREM at the Age of Eight: The Distributed Computing Design System," Computer, Vol. 18, No. 4, Apr. 1985,36-46. 38. Sayani, H., "PSL/PSA at the Age of Fifteen: Tools for Real-Time and Non-Real-Time Analysis," in System and Software Requirements Engineering, R.H. Thayer and M. Dorfman, eds., IEEE Computer Society Press, Los Alamitos, Calif., 1990, 403-417. 39. Wasserman, A.I. and P.A. Pircher, "A Graphic, Extensible Integrated Environment for Software Development," ACM SIGPLAN Notices, Vol. 12, No. 1, Jan. 1987, pp. 131-142. 40. Lewis, T., "The Big Software Chill," Computer, Vol. 29, No. 3, Mar. 1996, pp. 12-14. 41. Herbsleb, J. et al., "Benefits of CMM-Based Software Process Improvement: Initial Results," CMU/SEI-94TR-13, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, P.A., Aug. 1994.

et al., Key Practices of the Capability Maturity Model for Software, Version LI, CMU/SEI-93-TR25, Carnegie Mellon University, Pittsburgh, P.A., Feb. 1993. 23. Boehm, B.W., "Verifying and Validating Software Requirements and Design Specifications," IEEE Software, Vol. 1, No. 1, Jan. 1984, pp. 75-88. 24. Boehm, B.W., Software Engineering Economics, Prentice-Hall, Englewood Cliffs, N.J., 1981. 25. Davis, A. et al., "Identifying and Measuring Quality in a Software Requirements Specification," Proc. 1st Int'l Software Metrics Symp., IEEE Computer Society Press, Los Alamitos, Calif., 1993. 26. Swartout, W. and R. Balzer, "On the Inevitable Intertwining of Specification and Design," Comm. ACM, Vol. 27, No. 7, July 1982, pp. 438-440. 27. Hatley, D.J., and LA. Pirbhai, Strategies for Real-Time System Specification, Dorset House, New York, N.Y., 1987. 28. Davis, A.M., Software Requirements: Objects, Functions, and States, Prentice-Hall, Englewood Cliffs, N.J., 1993. 29. Svoboda, C.P., "Tutorial on Structured Analysis," in System and Software Requirements Engineering, R.H. Thayer and M. Dorfman, eds., IEEE Computer Society Press, Los Alamitos, Calif., 1990. 30. Ross, D.T., "Structured Analysis (SA): A Language for

22

What Is A Requirement?
Richard Harwell Lockheed Aeronautical Systems Company 86 S. Cobb Drive; Marietta, GA 30063-0685 Erik Aslaksen University of Technology, Sydney, and Ewbank Preece Sinclair Knight PO Box 572, St. Leonards Sydney, NSW 2065 Australia Roy Mengot Texas Instruments PO Box 650311 Dallas, TX 75075 Ivy Hooks Bruce G. Jackson & Assoc, Inc. 17629 El Camino Real, Suite 207 Houston, TX 77058

KenPtack PRC, Inc. Crystal Gateway One, Suite 1211 1235 Jefferson Davis Highway Arlington, VA 22202

Abstract Each contract specialist, lawyer, engineer, systems engineer, manager, or anyone else involved in the transition of vision into product, has his or her own definition of a requirement With the rare exception, all are applicable and meaningful - but most are forgotten or ignored in the crunch to produce an effective requirements document under constrained schedule and funding environments. Yet, the need for effective requirements generation is probably the number one priority today in product development needs. Rather than approaching this problem from the theoretical or apriori standpoint, this paper examines the nature of a requirement through a process of identifying key characteristics and relationships from the viewpoint of the requirements manager/analyst and the requirements user (design team). It also discusses the importance of determining that requirements convey a need (as opposed to a directed solution), and ascertaining quality in terms of contextual adequacy. INTRODUCTION This is the first of three papers addressing the topic "What is a requirement?". It concentrates on: (l)thc use of characteristics and relationships to analyze and integrate requirements sets, (2) identification of the transition from requirement to design, and (3) determining quality in terms of completeness, lack of ambiguity, and scope. The second paper expands on the concept of requirements characteristics to include selected optional characteristics which may be used by

requirements analysts for special purpose needs. The last in the series is an in-depth examination of "Requirement Structure", providing a means of assisting the requirements analyst in better understanding the structure of an individual requirement from z linguistic and contextual standpoint

All projects begin with a statement of requirements, whether it be an innovator's simple statement of concept, a formal DoD System Specification, or a Marketing Analysis. However, the "rush" to convert concepts to products - the "real stuff* you can touch and manipulate - often overpowers the requirements development process. This, in turn, hampers the ability to produce the concept as originally envisioned Prior papers on this subject range from an examination of requirements from a micro-specification viewpoint to academic treatises on the theory of requirement constructs. However, program personnelfrequentlyset aside such treatises as being too difficult to interpret and apply in the day to day efforts of getting the job done. This paper establishes a means of identifying the clear-cut characteristics of a requirement which can be used by both requirements analysts and design teams. These characteristics can help determine the source, applicability, depth, and other factors needed for assessing and implementing an integrated, and coherent,

"What is a Requirement?" by R. Harwell et al. from Proc. 3rd Ann. Int'l Symp. Nat'I Council Systems Eng., 1993, pp. 17-24. Reprinted with permission.

23

requirements set. Analysis of assigned characteristics can help a design team identify whether a specific requirement establishes a quantifiable threshold, if it needs further analysis to determine its impact, or if it can be treated as a goal or customer desire. In a specification environment it is a common practice to identify multiple classes of requirements (i.e., functional requirement, reliability requirement, constraints, etc.) according to a designated specification structure. However, in a requirements management system environment (database), a specification is simply a "slice" of the database according to pre-defined attributes. In this environment, requirements classes are treated as a specified characteristic of a requirement (or as a relationship/attribute to a requirement), rather than as a separate class of requirements. Therefore, this paper is based on the concept that

analysis, etc.) levied on a contractor/producer under force of contract. The identification is unambiguous. If it is: (1) contractually applicable, or has the force of a contract as in a market analysis, and (2) comes from a source external to program personnel, it's a primary requirement. An example would be The payload shall be transported into orbit in the payload bay". Derived. Those requirements (whatever their source - internal, supplier, team member, customer, etc.) that are generated apartfromthe primaryrequirements.The identification is unambiguous. If it is not a primary requirement, it is a derived requirement. An example would be "The payload shall have a diameter of less than 14 feet". The specifying of payload diameter is derivedfromthe payload bay size based on the original primary requirement. That derivation may have been accomplished by die Contractor's Program Manager, be dieresultof a trade analysis, or physical examination of an object Or it may have been suggested by the customer's Contracting Officer - but not as an amendment to the contract It doesn't matter, it is still a derivedrequirementwith the primaryrequirementas if s parent for traceability. The requirement type enables the product team to assess the difficulties associated with changing a requirement. By definition, if it is a primary requirement, a Contract Change, or perhaps a new market analysis, will be required. But if it is a derived requirement, the decision to change (as long as tne change is within the scope of the "parent" primary requirement) rests with program management. Withrespecttorequirementsentered into a database, there may be a need to modify the exact customer statement - particularly when a specification combines several different requirements into a single sentence. The precise splitting of such arequirement,including the creation of transitional phrases, does not constitute a derived requirement because no assumptions or expansions of the primary requirement will have been made. However, each split-out segment will be a child of the parent (original) primary requirement Requirement Application. The requirement application identifies the object of a requirement. There are only two requirements applications: Product Parameter. A product parameter is a requirement that applies to the product or service to be developed. The identification is unambiguous. If it directly acts on the product or service, it is a product parameter. Examples of such requirements would include "The external surfaces of all equipment shall be painted white", and "The operator training program shall result in a pass rate of not less than 95% for qualified candidates".

/ / it mandates that something must be accomplished, transformed, produced, or provided, it is a requirement - period.
The qualifiers follow - in the form of characteristics and relationships. This allows a requirement to be the focus, i.e., the key player or authority, for all related information in a requirements management database environment Yet, this approach preserves the use of familiar identifiers (albeit in a different format) for use in specification-based developments. In the latter case,

a reliability requirement becomes a rcqu having the qualifier reliability as one of its relationships (other relationships might include radar
subsystem, WBS1237. MTBF. etc.). REQUIREMENTS CHARACTERISTICS Although it may be difficult to find the "right" definition of a requirement that provides us with omnipotent insight into requirements generation forevermore,we can consistently identify the "fingerprints" of a requirement. There are nine characteristics in all three essential characteristics **KI six optional characteristics, as shown in Tablesl and 2, respectively. As noted in the tables, each of these characteristics has subsets which may be used as deemed appropriate for each program. (The terms "program" and "project" are synonymous in this paper.) A discussion of the three fundamental characteristics, with examples, follow. Requirement Type. The requirement type identifies the source and contractual applicability of a requirement There are only two requirements types: Primary. Those requirements (whatever their form contract provision, specification, database, market

24

Product parameters have two primary subdivisions: Qualitative. - This product parameter contains no measurable requirement. An example would be "The mixer shall produce a mixture of homogeneous appearance". A qualitative product parameter usually necessitates further analysis to determine suitable quantifiable criteria; i.e., usually necessitates the development of derived requirements), with the qualitative product parameter serving as the parent.

Regulatory - Identifies administrative elements such as "Deliverable data shall be furnished with unlimited rights to the Government". Requirement Compliance Level. The requirement compliance level identifies the depth of compliance mandated for a requirement. There are only three compliance levels:

Mandatory, Whether a primary or derived requirement, it must be implemented. Such Quantitative - This product parameter requirements usually include a "shall" statement in contains a measurable requirement. An their structure. If it is & primary requirement and is not example would be "The mixer shall produce a achievable, then a contract change or deviation/waiver mixture having afinenessgranularity qfXYZ within is necessary. If it is a derived requirement and is not achievable, then a briefing must be presented to five minutes ". A quantitative product parameter management (or in rare instances, the customer) for may have children, but such children would be lessening of the requirement. An example might be a generated for the purpose of specifying directive to use an in-house component, which is not particular approaches to meeting this deemed to conform to a primary requirement. If there measurable requirement are no alternatives to the derived requirement in such an instance, it is very likely that a higher ordered (parent) Program Parameter. A program primary requirement may not be achievable and will parameter is a requirement that applies to the also need to be changed. activities associated with enabling die creation of a product or service, such as conducting Guidance. Whether a primary or derived tradeoffs or holding design reviews. This also requirement, it is desirable that it be implemented. In includes contract provisions which define the general, failure to implement does not constitute noncompliance so long as it can be demonstrated that a customer / contractor relationship; e.g., reasonable degree of implementation was attempted. confidentiality, intellectual property rights, This is equivalent to specifying a goal or desire on the warranties, etc. In short, a program parameter part of the customer or management. An example defines activities related to the technical and would be "Use Afil-Std-499B as a guide in administrative management of product implementing the systems engineering process." development. The identification is unambiguous. If it does not directly act on the Information. This unique characteristic is product or service, it is a program parameter. essential when requirements management systems Examples of such requirements would include (requirements databases) are used in lieu of hard copy "The contractor shall develop a concept of source documents. By strict interpretation, these operations" or "The contractor shall conduct "requirements" are not actually requirements, but are non-binding statements which significantly influence internal design reviews every two weeks." the context, meaning, and understanding of other requirements. An example might be a reference to the Program Parameters have three primary subdivisions: customer's reasoning for specifying a particular approach or requirement. Task - Identifies an analysis or other effort to be performed. Examples would include Priority. This characteristic identifies the relative "Prepare a Systems Engineering Management Plan" importance of a requirement in terms o f or "Perform an analysis of the structural loads on the implementation, particularly in establishing criteria for bridge pylons". trade studies. In a cost reimburseable environment, a customer may use priorities to mandate that certain Compliance Evaluation - Identifies the elements must be completed before a specified ceiling methodology for measuring compliance with is reached. The priority characteristic may also be used for establishing the sequence in which specified design parameter. (There should be a verification or test activities should occur. Unlike the other program parameter associated with each characteristics, the values of priority will be dependent product parameter.) on program and company needs.

25

REQUIREMENT ALLOCATION AND/OR RELATIONSHIP ASSIGNMENT Determining the characteristics of a given requirement enables the product team to understand nature of a requirement. Correspondingly, allocation of a requirement (or assignment of a relationship to a requirement in a database) enables the product team to visualize and understand the interactive and interdependent nature of a balanced requirements set. This insight is achieved by being able to scope and group an otherwise disconnected series of requirements into meaningful structures for analysis and implementation. After the characteristics are defined, anomalies identified, and decisions made with respect to team handling of the anomalies (until customer or management resolution), the product team is primarily interested in identifying requirements applicable to the team components. As with requirements characteristics, definition of the allocation/relationship assignment process should be approached from the viewpoint of the user. Therefore, the initial effort is usually the assignment of responsibility (i.e., ownership) of each requirement to the respective team. As the program progresses, this assignment may change, but a known baseline for performance responsibility will maintained. The key in this effort is not the specifics of the allocation (each program has its own needs), nor the process followed (each company has its own version of the systems engineering process). Rather, the key is establishing an agreed upon hierarchy of relationships that will enable the teams to examine large quantities of requirements (potentially hundreds of thousands on some programs) according to program needs. For example, a typical relationship hierarchy might include the following: Product Elements - Segments, subsystems, interface components, etc. Keywords - Indices (terms not usually appearing in requirements text such as "affordability", "mission applicability", etc.), work breakdown structure (WBS) elements, technical budgeting, trade study references, etc. Parent/Child Relationships - Traccability between higher and lower level requirements Assignments to Specifications - Identification of the various specifications into which the requirement will be incorporated

Test Plan/Test Methods Applicability Identification of the applicable test plan reference and methods for demonstrating compliance Other Assignments, Discriminators. Observations, and

Particularly when used in conjunction with a requirements management system, these relationships enable product teams to examine requirements through insights gained by selective groupings. These examinations will help to further identify anomalies for resolution, but more importantly they can help to integrate the requirements statements and thus identify before integrated test and evaluation the suitability of a given requirements set to accomplish the customer's objective. REQUIREMENT VERSUS DESIGN IMPLEMENTATION There are two aspects of this issue of "Is it a requirement or is it a design implementation?" The first occurs when the customer mandates a design solution as a requirement. The other occurs when the product team generates derived requirements which actually may be design solutions instead of requirements. Both aspects arc discussed below, Requirements - Needs Versus Implementation. An RFP was released last summer for the development of a requirements management tool. The first requirement was to "provide a database". The statement is one of implementation and not of need, and it is common to find such statements in requirements documents. Requirements documents should state what is needed, not how it is to be provided. Yet this is a common mistake made by requirements authors. Most authors do not intend to state implementation, they simply do not know how to state the requirement correctly. In the case above, the author of the document continued with many valid requirements Provide the capability for traceability between requirements (Qualitative product parameter), Provide the capability to add attributes to requirements (Qualitative product parameter), Provide the ability to sort requirements (Qualitative product parameter). Granted, each of these requirements will result in a database type of system, but a separate requirement for a database was not needed.

26

There are two major dangers in stating implementation. The one most often cited is that of forcing a design when not intended. If all the needs can be met without a database, then why state the need for a database. If they cannot be met another, or better, way, then a database will be the selected design solution. The second danger is more subtle and potentially much more detrimental. By stating implementation, the author may be lulled into believing that all requirements have been covered. In fact, very important requirements may be missing. This may result in the contractor/producer conforming with the requirements document, yet not delivering a system or product which accomplishes the customer's real intent. For example, providing a database in the above instance will not be sufficient for someone needing a requirements management tool. It is the capabilities of the requirements management tool that are needed. At each level of requirements development the problem of needs versus implementation Hill occur. At the system level the requirements must state WHAT is needed. The system designer will determine HOW this can be accomplished - and then must define WHAT is needed at die subsystem level. The subsystem designer will determine HOW the need can be met - and then must define WHAT is needed at die component level, and so forth. Another illustration of how implementation creeps into needs statements is that of a proposed system requirement on a different program which included the expression "/am/ing in TBD sea state conditions". Since there was no vehicle design - the vehicle could have landed in water or on land - it was difficult to justify this requirement as written. On being asked why such a requirement was needed, the author indicated the real concern was about crew rescue. If the vehicle were to land in the water, rescue by helicopter could only be accomplished under certain sea conditions. In further discussions, however, it was noted that if the vehicle made a landing on the ground, there would also be a limited amount of time to reasonably leave the crew inside and unattended - an equal crew rescue concern. The requirement, therefore, was changed to reflect the real need "time to remove the crew from the vehicle". To ensure that a requirement statement represents a need and not an implementation, ask WHY the requirement is needed. If this does not lead to a "real" need statement, then die original requirement statement is probably appropriate, citing a need rather than implementation.

When Does the Transition Occur Requirement to Design Implementation?

From

The second aspect of the requirements versus implementation concern most often occurs with software development. Many of the systems engineering and software engineering interface difficulties stem from the fact that software developers views the continuum from customer requirement to acceptable code as a requirements process - rather than as a transition from requirement to design to product Stated in another way, what the systems engineer may view as a "design solution ", the software engineer may view as a lower level "requirement". The same concern occurs in hardware development as the requirements process progresses to lower and lower levels. A point is reached when the question must be asked: Is this a requirement or a design solution?" There are no absolute answers. But establishing a general guideline such as the following is feasible: If there are no viable alternatives which can be implemented, other than the statement in question ifs highly probable the statement is a design solution. In effect, it's mandating a solution as discussed above. As such, it should be removed from whatever requirements document intended and included in a design description document, a drawing, or code. However, even if there is a lack of viable alternatives, when implementation as a design solution is not feasible without further customer or systems engineering interface, it should continue to be treated as a requirement (particularly in software development). This is due to the fact that implementation is dependent upon an understanding of the context in which the requirement/solution is to be implemented, and as such, cannot stand alone as a true design solution. Requirement Quality Definition Of Requirement Quality. The quality of an object or process is often defined as the degree to which it meets specification requirements. It is sometimes also defined as fitness for purpose. So what is the specification of a requirement, what is its purpose? Execution of a requirement may be considered to occur as an interface between two processes: The definition process, in which an intellectual intent (concept) is transformed into a written statement (specification), and the interpretation process, in which the written statement is transformed into the intellectual input to a process which produces a set of more detailed (derived)requirementsor design description.

27

The purpose of a requirement is to reproduce in the mind of the reader the intellectual content which was in the mind of the writer. The quality of a requirement is then the extent to which this takes place. Two features of this definition emerge: The quality of a requirement is not an absolute characteristic - it is only defined relative to the reader. The quality of a requirement is not a measurable trait - it can only be inferred a posteriori. The first of these features is inherent in the nature of a requirement and would be a feature of any definition of quality. The second feature is a result of the high level of the definition; a much more detailed (and complex) definition could have been introduced which would be measurable. This is not considered to be a particularly practical solution. Instead, the approach will be to define some subordinate traits/factors which are more easily measurable. Necessary Elements for Requirement Quality. Completeness. A requirement must be complete in die sense that it provides all the program-specific (i.e. non common domain) information necessary for the user to cany out the next process step. To understand what this means, consider the case where the next step is development of derived (i.e. more detailed) requirements. Such a step consists of analyzing the parent requirements, identifying the options available to satisfy these requirements, choosing the best option, specifying (i.e. giving new, more detailed/derived requirements), and finally verifying that these derived requirements will collectively achieve the intent of the parents. The crucial activity here is choosing the best option; the criterion for making that choice is determined by the given requirements. For example, a requirement for minimum weight will give a different choice than one for minimum cost. Conversly, the absence of a requirement to differentiate among options for a specific parameter implies that parameter is not a criteria for completeness. For example, if the requirement says nothing about the color of the equipment, the author of the requirement does not care and cannot complain if the equipment turns out, say, shocking pink. If the author does care, then the requirement was not complete. These examples demonstrate that completeness of a requirement is dependent upon the author's intent. Therefore, while it is possible to measure or test for completeness, such measurement is only possible in conjunction with the author.

Lack of Ambiguity. A requirement must be unambiguous in the sense that different users (with similar backgrounds) would give the same interpretation to the requirement This has two aspects. On the one hand there is the aspect of grammatical ambiguousness, i.e. the poorly constructed sentence. On the other hand there is the aspect of ambiguousness arising from a lack of detail allowing different interpretations. The first of these can be measured or tested independently of author or user, but die second aspect can be measured only in conjunction with a set of users, since it depends on what assumptions the user makes automatically, i.e. as a result of the user's background knowledge. Scope. A requirement must be properly scoped in the sense of providing a definite amount of information. Poor requirements in this regard include motherhood statements as "shall use their best efforts", "shall ensure the higheifc system integrity", "shall be of a high quality", "shall provide a reliable service", etc. Although scope is intrinsic to the requirement; measurement of the depth of scope would need a procedure tailored to the program needs. CONCLUSION The accurate translation of a customer's need by the product team is essential. Identifying requirements characteristics, determining that the stated requirement conveys a need (as opposed to a directed solution), and ascertaining contextual adequacy are essential for assessing the accuracy of translation before the product team proceeds. These criteria enable the analysis team to better understand the customer's intent and to better identify where disjoints, ambiguities, and conflicts exist early in the program. The objective is to be able to integrate a collection of requirements (preferably through manipulation in a database using these characteristics and relationships as "grouping" devices) and to establish their achievability prior to design implementation - rather than during test and evaluation. In addition, as we learn the effects certain combinations of characteristics and relationships have on the development process, we can more readily identify potential difficulties and correct them before we are committed to an approach that may be impracticable.

28

Type

A. Primary-Usually a contract requirement, but may be a requirement in a pre-contract document Also may be a requirement established by Marketing or survey teams as in Commercial applications.

B. Derived - Derived from Primary Requirements or higher level Derived Requirements.

Application

A* Product Parameter - The Product Parameter refers to a requirement which applies to the product or service to be developed. It may be adjusted for a specific application or phase. For example, some programs and tools distinguish between a "design" and a "constraint" parameter. Other programs may need to distinguish between "design," "build," and "operate". In any application, subsets may include: 1. Qualitative - Not directly measurable Functional (What it does/A capability of the product) Process (Leading to a result/product) 2. Quantitative - Directly measurable. Performance Design Point (Altitude, endurance, temperature, mix-rate, etc.) Procedural (Specified sequence of events, specified algorithm) Physical (What it is)

lent which is not directly B. Program Parameter Hie Program Parameter refers to a n involved in the development, production, or operation of the product. Butratherpertains to programmatic activity associated with supporting these aforementioned aspects. There must be a "Compliance Evaluation Program Parameter19 for each product parameter which specifies how accomplishment of the product parameter can be measured. 1. Task (Perform an analysis, build to a product specification, operate a system, etc.) 2. Compliance Evaluation (Measure compliance with a product parameter.) 3. Regulatory (Administrative, corporate policies/practices, etc.)

Compliance Level

A. Mandatory - Typically a "shall" statement - mandates conformance. B. Guidance (Goal) (Objective) - Typically a "will" statement - accomplishment is desired/preferred. It is still essential to demonstrate and document why accomplishment is not achievable, if requirement is not met. C. Information- Statement supporting or giving insight to a measurable requirement, the absence of which would lead to a misunderstanding of the associated requirement (A practice necessitated by the use of databases in requirements management systems which will be used by die team in lieu of the source document) The particular values of priority will be program and company dependent Table 1. - Essential Requirements Characteristics

Priority

29

Good requirements definition can be an important factor in the success of a system development project.

PINPOtmNG REQUIREMENTS
by Laura Scharer
One of the most common reasons systems fail is because the definition of system requirements is bad. Why are we consistently unable to produce a good statement of requirements? Because it is difficult; we have a poor attitude about working with users (and vice versa); our expectations for this phase of systems design is different from the users* expectations; we let the situation control us; and we don't always use the techniques that are most appropriate. More specifically: Sophisticated problem solving is required to produce good statements of requirements. Problems must be translated into corrective goals, which must be translated into solutions, which must in turn be reduced to functional terms. There is no guarantee that the functions will create the desired results. The articulation of requirements is unusually difficult. Functions and processes are not easily described. System requirements change, and the definition must be able to absorb these changes. Tools and techniques for optimizing the definition process are not generally available. Heavy user involvement can introduce interpersonal and project management problems. User motivation is difficult because reinforcement for their work is traditionally postponed until the implementation stage, by which time they have learned to expect disappointment. The definition process can become highly political. Definition is mentally taxing. Compromises which will eventually disenchant some of the users and analysts are required. We have no real yardstick other than the ultimate success or failure of the system; there is no way to judge the quality of our definition. While we can't expect these difficulties to disappear, we can minimize their impact. Analysts and users harbor grave doubts about each other (Table I), and the origins of these attitudes are obvious. Failure encourages blame. Users are disenchanted because we consistently bungle new system development; we are disenchanted because we alone are blamed for the failures. Somehow, even when users participate heavily in the definition process, they succeed with the help of unquestioned corporate mores in abdicating responsibility for system results. In other words, users provide the system definition but the systems people are responsible for it. However, we should not expect users to metamorphose into analysts just because they are sitting on a project team. Remember: Assume that the user is trained in his own functional field but not necessarily in systems skills. Give him work assignments involving existing system education and new system definitionwork that he can perform better than an analyst just because he is a user. The user's primary objective on the project is to protect his own interests. Let him. If you have recruited good users for the project team, they are usually good workers who receive recognition in the company and have confidence in their own abilities. In other words, they have delicate egos. It is very easy to insult users' intelligence by appropriate work assignments: we can't give them all the dirty work. The systems group, although responsible for project management, has no real organizational authority over users on the project team. The users can't be forced to do anything for the project. Users need periodic, if not constant, attention. After we've received all their input, we can't leave them hanging. Provide written status reports on a regular schedule and contact them personally whenever possible. Another problem is that users and analysts don't even share a common goal for the definition process. Certainly both groups would agree that the objective of requirements definition is to produce a specification of what the system will do. Let's define what the system will do from the analyst's point of view. We are to produce this definition, but we impose some conditions on it. For one thing, the definition must be translatable into a system design. This requires that it be a functional specification, expressed in terms of processes, outputs, inputs, and data structures. We want the definition to be precise, clear and not open to misinterpretation. Quite understandably, we hope that the definition will be complete, because design is optimized when all features are known and can thus be integrated neatly into databases and programs. In the best of situations, the specification is frozen so that design, coding, and testing will never have to be reworked. Now, two important time constraints surface which affect the definition of the system and the system itself. Because the systems group is responsible for the project, we ask that the definition be produced within the time allotted to this project phase. The specification activity to do this must have a definite beginning and end, and the end of this phase must precede the beginning of the design phase. Additionally, we must insist that the system thus defined can be implemented within project schedules and budget, both of which are usually preset before definition begins and thus before the real size and complexity of the system are known. Finally, analysts are interested in developing a definition for a good system. We want to specify a system that is not only technically feasible but also elegant. We want integrated functions, clean and simple databases, efficient computer runs, and economical output. Now, let's start again, this time from the user's point of view. The users seem to be more satisfied with a qualitative definition which, in many

ANALYSTS DEFINE SYSTEM

"Pinpointing Requirements" by L. Scharer from Datamation, Apr. 1981, pp. 139-151. Reprinted with permission.

30

TABLE I!

"WHAT" THE SYSTEM IS TO DO.

PROBLEMS cases, specifies the system in generalities and in terms of benefits to be derived. To reach the level of detail that analysts desire, the users must actually enter what they consider to be problem solving, or design (how) mode: they must arrive at functions that will solve their problems. They can't quite understand us when we distinguish our whats and hows: we're usually thinking a step ahead of them (Table II). The qualitative nature of the user's definition suggests that it is to be interpreted, to be fleshed out in greater detail, at a later time. But the users, since you are asking them what they want and since they're telling you, expect that all requests will be met in the new system. They are often sincerely puzzled by arguments of technical feasibility or advisability, especially because they usually believe firmly that they need all requested features in order to achieve their stated goals. Flexibility is a key consideration for the users. The system specification must be changeable with their needs, as must be the system after it is developed. This emphasis on flexibility also suggests that the users do not consider system definition to be a front-end activity with a definite ending point; it becomes, in essence, an ongoing process. Finally, users are simply interested in defining a system that will work. They are not as interested in the project budget as they are in the impact of the system on their individual budgets. They want the system to perform specified functions without flaw, to be operationally efficient for their people, and to achieve the subjective goals. Users who try to define a system with the analysts' goals in mind can find themselves in a predicament, particularly when one of the following is true: The system in question is just not definable by traditional means. The system can be defined but the user doesn't really know what he wants. The user knows what he wants but can't articulate it. To defend themselvesto produce a system specification that will satisfy the analysts despite the above conditionsusers have developed strategies which by now are classic. The Kitchen Sink. This strategy, employed by users who throw everything into their system definition, has as its outstanding characteristics exaggeration and a protective overstatement of needs. An overabundance of reports, exception processing, and politically motivated system features are also symptomatic. The Kitchen Sink also provides a marvelous cover-up for the user who doesn 't know what he wants but who can bury TRANSLATING BUSINESS PROBLEMS INTO BUSINESS OBJECTIVES. TO THE USER/WHAT THE SYSTEM IS TO DO. Example: Problem: Objective: OBJECTIVES TRANSLATING BUSINESS OBJECTIVES INTO FUNCTIONS WHICH WILL ACCOMPLISH THE OBJECTIVES. TO THE USER, "HOW" THE SYSTEM IS TO WORK. BUT TO THE ANALYST, "WHAT THE SYSTEM IS TO DO. Example: Function: Allocate inventory to warehouse using specific allocation algorithms (the user's M howH, but the analyst's "what"). Unavailability of inventory causes lost sales of $1 million annually. Increase stock availability (the user's "what").

FUNCTIONS

TRANSLATING FUNCTIONS INTO COMPUTER HARDWARE, DATABASE, AND PROGRAM, DESIGN. TO THE ANALYST, "HOW" THE SYSTEM IS TO WORK. Example: System: design:

Design of files and programs (the analyst's "how"). COMPUTER SYSTEM DESIGN

TABLE HI

THE OBJECTIVE OF REQUIREMENTS DEFINITION

Objective:To define what the system will do. ANALYSTS USERS Qualitative definition Interpretation to be expected All requests to be met Flexible definition Definition an ongoing process Favorable impact of system on departmental budgets System will work everything he asks for). In both cases, the full set of system requirements submitted by the users must be reduced to one that is necessary, sufficient, manageable, and achievable Surprisingly, despite his premeditation, the Smoker is easier to work with because he has a realistic idea of what he really wants. The Same Thing. Sometimes a euphemism for the embarrassing words, "I don't know," sometimes a sign of laziness, the Same Thing is manifest by the statement: 14 Just give me the same thing I'm getting

USERS DEFINE SYSTEMS

Functional definition Precise Complete Frozen Definition produced within alloted time Resulting system implemented within project schedule and budget Good system that fact in the sheer volume of his requests. Smoking: Known also by its full name, *'Smoke Gets in Your Eyes," this strategy is practiced by the user who sets up a smokescreen by requesting 10 system features, knowing that he really wants only one of them. The nine extra requests give him bargaining power. The Smoker is usually a rather experienced user who is consciously manipulating the definition process (as contrasted to the Kitchen Sink user, who is usually naive in believing that he really needs

31

Users provide the system definition, but the systems people are responsible for it.
now/* The statement may be qualified in many ways, such as, ". . . but more accurately, " or *\ . . more timely, "or *\ . .but computerize it/* The user who employs the Same Thing is often quite satisfied he has told the analysts everything they need to know to proceed. The only thing the analysts really know, however, is that the user probably isn 't aware of what his current system does, and that he doesn't want to take the time for an introspective review of his own functions and problems. Here, the systems group has little chance of succeeding because only the user can fully discover his own needs and problems. Each time we witness one of these syndromes, we are reminded that despite our prodding and despite users* (usually) good intentions, they just don't seem to produce the kind of system specification we envision. It would be easy to play the blame game here and conclude that users are not capable of system definition, but it would be more productive to reexamine our goals for the definition process and to ask if our objective is possible to achieve. A concept known as definability can help us answer that question. Definability is the ability of a system to be defined; it is not a repeat of the * "feasibility " question (can a computerized solution to this problem be developed at all?). Rather, it assesses the relative ease or difficulty of defining this system in this environment, and is assigned a loose value on a scale from "low" to "high." By assessing definability, you have an opportunity to establish more realistic goals for the definition process and to select definition techniques that are most appropriate to your situation. Definability is affected by characteristics of the system itself. For example: Type of system. Transactipn processors and reporting systemswith very traditional accounting systems at one extreme are functionally specific, finite, and quite tangible, and hence highly definable. At the other extreme, management support systems, decision support systems, simulators, and other systems that may be lumped together as 4 'management information systems*' are by nature less definable, because their purpose is to support a dynamic and changing management environment. Size of system. Size is measured in several ways, including: number of functions performed number of departments affected number of individuals contributing to the definition number of subsystems number of system interfaces

TABLE 1

THE USER - ANALYST RELATIONSHIP

HOW WE SEE USERS They... Don't really know what they want. Can't articulate what they want. Have too many "needs" which are politically motivated. Want everything right now. Can't prioritize needs. Want "me first," not company first. Refuse responsibility for the system. Are unable to provide a definition for a system that will work. Are not committed to system development projects. Are unwilling to compromise. Can't remain on schedule. HOW USERS SEE US We. . . Don't understand "the business." Handle company politics awkwardly. Try to tell them how to do their jobs. Can't translate a system definition into a successful system. Say no all the time. Place too much emohasis on technicalities. Are always over budget. Are always late. Ask users for time and effort even to the detriment of their primary duties. Set unrealistic standards for requirements definition. Are unable to respond quickly to legitimately changing needs.

CAN WE DEFINE

in

As size increases, definability decreases and the possibility for error and omission is greater. There is also a hesitancy to attack each element of a very large system with the thoroughness that is possible with smaller systems. Complexity of system. Complexity decreases the definability of a system. It is determined by: number of variables degree of interdependence of the variables number of databases accessed and updated difficulty of logic degree of flexibility need for specialized knowledge (e.g., mathematical, statistical, forecasting) Similarity to existing systems. Definability is enhanced when experience data for similar systems is available. Environmental factors can also have an overriding influence on the definition process. These include: 1. Users' understanding of their own needs. Definability is positively affected by users who know what they want, or who at least can work with analysts to discover what they want. 2. Consensus among users. Definability is increased when each user department 32

makes an effort to gain a consensus opinion before going to the systems group with requests. 3. Systems1 understanding of user needs. Analysts who know the business application favorably impact definability. 4. Ability to communicate ideas. Definability often suffers because users and analysts cannot communicate with each other. Development of system models, or use of a structured documentation format which uses an unambiguous language, can help. 5. Accessibility to all affected users. "Representative" user participation is usually mandatory because of the size of the user community affected by a new system. But definability is enhanced by direct user contact, so analysts should make an effort to talk to as many users as possible. 6. Systems development experience. Definability increases when analysts and users have experience in new systems development. Experienced participants have more realistic expectations as well as the knowledge and skills that contribute to successful definition. 7. Personalities. Good users improve definability. A good user is willing to make decisions, sticks by his decisions, cooper-

Definability is enhanced when experience data for similar systems is available.

ates, and thinks positively and aggressively. 8. Availability of human resources. Project staffing that places appropriate emphasis on front-end definition by including users and analysts with specification skills is important. More often, however, there are a disproportionate number of programmers on the project team. 9. Project length. The longer project minimizes definability because it gives the users more time to change their mind and the environment more time to change around the system. 10. Schedule. Definability decreases when inadequate time is allowed for the definition process. 11. Budget. Monies allocated to a project translate into available man hours; time for consulting, training, and software aids; and proportion of time assigned to frontend work. 12. Corporate stress. Corporate pressure, project visibility, reasonableness of expectations for system results, and the time and budget allowed for a system all influence definability. Unreasonable stress leads to fear, frustration, defeatism, and mistakes, but some degree of stress and attention, some feeling of high-level support and of accountability for results, can enhance the quality of the definition process. ganization and learn as much as you can from their experiences. 7. Reduce the number of variables and of databases affected by the system. 8. Eliminate flexibility that users cannot realistically control. Determine whether flexibility is needed to support changing conditions of normal operations or if it is requested only to handle rare exceptions. 9. Reject a system feature if your equipment or your personnel do not possess the required technical capabilities for implementing it (the technical veto). 10. Reject a system feature if it will consume computer time, disk storage, printer time, or other machine resources out of proportion to its potential benefits (the operations veto). 11. Reject a system feature (or features, taken together) if they cannot be implemented with available manpower within imposed time constraints (the manpower veto) In other words, if you recognize that the system is getting out of hand, speak up. Go formally on record with your recommendations for reduction. Submit amendments to the official project documents describing scope, feasibility, and cost justification, and require user approval of these changes. Because the system may be altered significantly by reduction, the corporate view of the system and the time and money allocated to it may also change, hopefully so that expectations are more realistic than in earlier project relate well to persons above and below him in his area have authority to commit his area in matters such as policy, budget, and interdepartmental procedures be accountable for his performance as a representative Select users who have a thorough knowledge of their functional areas and of corporate policies, procedures, and organizational nuances which could affect definition. Look for users who enjoy being busy, are positively motivated to work on the project, and are organized, flexible, realistic, decisive, responsible, and able to express themselves. TRAINING j|| USERS

CONTROL

Our o a l should

**t0 con"

jUP trol the system before it QVQTCM controls us. Reduction of SYSTcm the system is accomplished by examining each proposed feature to determine whether it is valid and necessary. 1. Before definition begins, develop a precise scope document which clearly demarcates project boundaries. Obtain written acceptance of project scope from the users, then utilize the scope document to weed out requests that do not belong with this system. 2. Break the system into smaller pieces to be attacked separately. This may increase interface considerations, but it will also increase the possibility for understanding completely each part of the system. 3. Separate transaction-oriented portions of the system from management support sections so they can be considered as distinct entities. 4. Require users to justify each requested feature, in terms of either decisions, supported, benefits derived, or money saved. 5. Ask the users to assign a relative priority to each of their requests. This is helpful because it takes the pressure of saying no off the systems group and it provides a framework for partitioning the system into smaller pieces. 6. Find a similar system in another or-

You undoubtedly are reading this list with a growing smile on your face because such users don't exist. We can strengthen the background knowledge of project participants by conducting a thorough existing system review with heavy user participation; providing books, seminars, or coursework in this particular business application; and providing formal training in the requirements definition technique which will be used in the project. All these considerationsfrom getting good users assigned to the project to training them wellrequire time, money, and corporate commitment, which lead us to our final opportunity for controlling the environment. We must do two things for ourselves. First, we must take the time to make We also have an opportunity to con- realistic project estimates for time, manpowtrol the external factors. Our goals in control- er, and money. Then, we must be honest ling the environment should be to surround when communicating these constraints to ourselves with good users, to strengthen the corporate management. In this way we can base of knowledge upon which the users and establish a. realistic schedule which gives us the analysts are building, and to place realis- time to do things right; work with a budget tic constraints on the project. that is adequate for staffing the project and Users heavily influence the atmo- educating participants; gain some credibility sphere of a project, so they should be chosen with management by sticking to budget and for the project team very carefully. Be sure schedule; reduce undue stress. that every area impacted by the system is When confronted by an undefinable system, represented. Balance the team so that users the users are faced with the impossible task of are equally represented, not only in numbers, deciding what they want without knowing if but also in rank, authority, and seniority. Se- what they want will work. They must perform lect users who can and will truly function as some very difficult activities, such as reducrepresentatives. As representatives, a user ing problem solutions to functional terms, visualizing system components and their must: provide regular status reports to his constit- interaction and effect on everyday operations, and discriminating between alternative uents give everyone a chance to contribute to the approaches. definition and to review formal definition Unfortunately, the only sure way to documents determine if a system will work is to try it. present consensus opnions to the systems Often users find themselves in the frustrating group position of defining and building a system, favorably influence his constituents toward only to realize that the system they really need the project will have to come next time.

33

Our goal should be to control the system before it controls us.

We must realize that in many cases the users need to try a system before they can define it. Prototyping addresses this problem. With prototyping, construction of a quick and dirty system begins after the bare minimum of a specification has been prepared. This quick and dirty system has one purpose, and that is to show the users what they are asking for, giving them some working knowledge of the results that can be achieved by the system they have defined. There is no attempt to create a good system from the technical or operational point of view, but rather to build a working, scaled model of the critical and most difficult portions of the system. After definition is complete, the prototype will be discarded and replaced by the operating version of the system. Prototyping is relatively untried, so we don't have a great deal of experience data available. Examination of the concept reveals several potential benefits: The prototype system provides a concrete frame of reference for the users and analysts. Most important, the users can see how their definition has been interpreted by the systems group. The understanding of the analysts is evident by what they do rather than by what they say. The time lag between system definition and system demonstration is minimized. System demonstration and implementation are different, but they have traditionally occurred at the same time. This time lag has been very expensive to development projects, since changes are not discovered until considerable time and effort have already been invested in design and coding. Definitional changes can be incorporated into the model rather rapidly encouraging active user participation and enthusiastic feedback. Prototyping is more attuned to the normal style and work habits of the usersusually managerswho sit on the project team. Emphasis is placed on active, hands-on evaluation of a working system rather than passive study and review of written documents. The technique provides at least some programmersthe ones working on the prototypewith closer user contact and longer project involvement, resulting in greater understanding of the permanent system. Experience data gained during prototyping can favorably influence the design of the permanent system. There are, of course, potential drawbacks. Prototyping may be overkill for very simple systems and yet too involved for the whole of an extremely large system. Prototyping is unproven, quite different, and potentially expensive, so management support for the technique can be lacking. In addition, prototyping is not an academically pleasing technique. Distinctly bounded project phases are absent, and the prototype itself replaces the formal documentation which traditionally evolves during the definition stage. Finally, prototyping is so new that the high-level programming tools and the personnel skills required to perform prototyping are not generally available. 1. Textual description is the predominant definition tool, resulting in a specification document that is lengthy, ambiguous, and boring. 2. Top-down decomposition is not a requirement, and as a result, functions are described to inconsistent levels of detail. 3. Requirements are presented in list form rather than modeled; dynamic system flows and relationships are lost in the static, piece-by-piece specification. 4. Data analysis is deemphasized, if performed at all. Traditional definition is also relatively inexpensive, if we consider its cost alone and not the costs incurred during design and coding to make up for inadequate specifications. Also, there is little or no learning curve involved with traditional definition in most organizations. So, because it is comfortable, and perhaps not always by choice, it appears that we will be performing requirements definition using traditional techniques for some time to come. Rather than resigning ourselves to failure, we can borrow some of the important principles of prototyping and the well-defined methods to improve the results of definition activity. And rather than perpetuating the traditional methodologies without improvement, we can subtly begin to change common practice so that we accomplish a transition toward more structured techniques without unduly alienating the users or our managers. We can begin by placing renewed emphasis on illustration of the functional specifications. Illustration may be in the form of charts or graphs, but should also include visitations to other companies with similar systems, walk-throughs of the proposed system with the users, and simulations of everyday procedures using newly defined functions and reports. And after coding oegins, we can provide sample output to users as it becomes available, rather than waiting for official system implementation. Results of incremental testing can thus be used almost as a prototype, providing a concrete point of reference and eliciting comments from users much earlier than under normal circumstances. We should also encourage use of a systematic approach to definition. We can use top-down decomposition to assure lhat all functions have been discovered and explored. We can also make a conscious effort to perform data analysis in addition to function analysis, thus providing at least external data needs to the design team. The initiative for improving requirements definition must be ours, but it is an effort which is sure to be repaid with increased success. #

WELLSystems that promise to be DEFINED difficult to define require an orderiv APPROACH ' methodical ap#trrnUfU*n p r O ach to needs analysis and requirements definition. In these instances, functional definition will occur in a more traditional mode, as a bounded, frontend project phase, with development of an official written specification for the system. In selecting a definition technique for these cases, we will want one which is repeatable (based on general concepts which can be applied to many situations), productive (efficient use of analyst and user time), and which, of course, produces a high-quality system definition. We have several formal methodologies available. The characteristics which these techniques have ir common are: 1. strict separation of functional specification (what the system is to do) from system design (how the system is to work) 2. development of a definition that is, however, easily translated into c physical system design 3. orderly decomposition of system requirements from the highest to the lowest level 4. representation of system requirements as a logical model expressed in graphic terms, using a minimum of textual explanation 5. active participation of the user groups, with emphasis on the user's role as a review agent 6. strict attention to system boundaries 7. separation of activities analysis from data analysis 8. documentation technique that is relatively easy to change and that records the evolution of the system definition 9. procedure for using the methodology is well defined and training materials are available Traditional definition, despite its drawbacks, still has its place for one very simple reason: it is familiar, so users feel comfortable with it. Characteristics of traditional definition are:

34

Unfortunately, the only sure way to determine if a system will work is to try it.

35

REQUIREMENTS ENGINEERING:

THE EMERGING WISDOM

JAWED SlDDlQl,

Sheffield Hallam University, and M. CHANDRA SHEKARAN, Microsoft

Developments in requirements engineering as in system development, have come in waves. The next wave of requirements techniques and tools will account for the problem and development context, accommodate incompleteness, and recognise the evolutionary nature of requirements engineering

he field traditionally known as system analysis was first applied to information systems, and so had an organizational and application orientation. The field of requirements engineering seeks to incorporate an engineering orientation into systems analysis. The most widely known, and perhaps the most significant, products of this engineering orientation are the various development methods and their associated automation support tools. Unfortunately, many of these prescriptive methods pay little or no attention to how context influences decomposition and evolution. Practitioners, who are used to focusing on context, find these methods to be inadequate. So the gap between practice and research is still verv wide.

T h e conventional wisdom about requirements engineering is rapidly evolving, however, and the latest research is taking context into account. Developments in requirements engineering are following trends in system development: In the first wave of system development, the focus was on writing code. Small and large system development alike were viewed as a single activity, not an organized process with several stages. The next wave saw the introduction of the development life cycle, of which requirements analysis was the first phase. Next came the adoption of evolutionary development models and the acknowledgment, at least from practitioners, that implementation may often proceed from incomplete requirements. The evolution of

Reprinted from IEEE Software, Vol. 13, No. 2, Mar. 1996, pp. 15-19. Copyright 1996 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved. 36

ARTICLE SUMMARIES: REQUIREMENTS ENGINEERING Identifying Qualityriences developing the approach, combined with an Requirement Conflicts, pp. QARCC-1 prototype using advanced query facility, pro25-35. an early version of Win Win, duces higher quality requireBany Boehm and Hoh In and our integration of the ments documents in less time. Despite well-specified resulting improvements into Our experience shows functional and interface QARCC-2. that conceptual metamodelrequirements, many softing technology can be a ware projects have failed Technology to Manage valuable complement to because they had a poor set Multiple Requirements informal teamwork methods of quality-attribute requirePerspectives, pp. 37-48. of business analysis and ments. TofindtherightbalHans IV. Nissen, Manfred requirements engineering. ance of quality-attribute A. Jeusfeld, Matthias Jarke, In particular, the use of reprequirements, you must Georg V. Zemanek, and resentations and cross-peridentify the conflicts among Harald Huber spective analysis can help desired quality attributes Stakeholder conflicts can be identify a wide variety of and work out a balance of productive in requirements conflicts and, perhaps more attribute satisfaction. engineering. A requirementsimportant, monitor them. We have developed The engineering project should Quality Attribute Risk and ensure that crucial requireAn Object-Oriented Tool Conflict Consultant, a ments are capturedfromat for Tracing Requirements, knowledge-based tool that least two perspectives, preferpp. 52-64. Francisco A.C Pinheiro can be used early in the sysably in a notation of the cusand Joseph A. Gogtien tem life cycle to identify tomer's choosing. Capturing, potential conflicts. QARCC monitoring, and resolving Tracing requirements operates in the context of the multiple perspectives is diffihelps verify system features cult and time-consuming Win Win system, a groupagainst the requirements ware support system that when done by hand. Our specification, identify error determines software and sysexperience with ConceptBase, sources, and most importem requirements as negotia meta-data-management systantly manage change. ated win conditions. This tem, shows that a simple but We describe a tool called article summarizes our expecustomizable metamodeling TOOR (Traceability of requirements engineering has benefited from both the information-systems and software-engineering paradigms. Today a variety of approaches judiciously mix techniques borrowed from both strands. Definitive claims about the superiority of one paradigm over the other are not only premature but of little practical use. Such debates distract us from addressing important fundamental questions that include: What activities should be included in requirements engineering? What constitutes a requirement? What issues of practice need further attention? REQUIREMENTSENGINEERING ACTIVITIES Most software-engineering professionals believe that the requirements phase has its own life cycle. The phases of it have been given different labels. In the '80s Herb Krasner identified five phases: need identification and problem analysis; requirements determination; requirements specification; requirements fulfillment; and requirements change management. 1 More recently, Matthias Jarke and Klaus Pohl proposed a three-phase cycle: elicitation, expression, and validation.2 However the phases may be sliced, it has long been realized that requirements evolve through a series of iterations. T h e Inquiry Cycle Model proposed by Colin Potts and colleagues takes this view.3 It integrates three phases documentation, discussion, and evolution and has stakeholders use scenarios to identify and validate requirements. The validation is accomplished by stakeholders challenging proposed requirements with the intent of obtaining a clearer understanding of the justifications for the requirements' existence. On the basis of this validation, stakeholders can freeze or change a requirement in the final phase. The software-engineering community had focused its efforts on the problem-analysis phase, which is what many decomposition methods address. In general terms, these methods are designed to help the analyst define the

Object-Oriented Requirements), based on Joseph Goguen's broad view of requirements, which suggests that not only technical but also social factors play a significant role in software development. Of course, the requirements themselves are not necessarily object-oriented. Our tool's name is derived morefromits use for object-oriented development and its object-oriented implementation, which allows the definition of classes and subclasses of objects and relationships among objects. Requirements traceability is our primary topic, but the scope of the tool reflects our view that requirements issues are pervasive and occur throughout the life cycle. Therefore, requirements traceability should be available at all times, and traceability of any desired artifacts should be supported.

range of all possible solutions. More specifically, according to Alan Davis, the problem-analysis phase encompasses learning about the problem, understanding the needs of the potential users, discovering who the user really is, and understanding all the constraints on the solution.4 The outcome the requirements-specification document is assumed to be a complete description of the product's external behavior. Lately, the software-engineering community has extended this decomposition paradigm to propose that systems can be built using a standard repertoire of components. Jarke and Pohl have suggested, for example, that one-shot requirements-engineering projects may be replaced by a "requirements-engineering practice," which puts together standard components in innovative fashions rather than continuing the practice of reinventing the components themselves.2 As we've said, the biggest drawback of the reductionist view of partitioning things into smaller parts is that context will influence the decomposition.

37

Indeed, for Jarke and Pohl the juxtaposition of vision and context is at the heart of managing requirements. They define requirements engineering as a process of establishing visions in context and proceed to define context in a broader view than is typical for an information-systems perspective. Jarke and Pohl partition context into three worlds: subject, usage, and system. The subject represents a part of the outside world in which the system represented by some structured description exists to serve some individual or organizational purpose or usage. WHAT CONSTITUTES A REQUIREMENT? The oldest and perhaps most widely shared piece of conventional wisdom is that requirements constitute a complete statement of what the system will do without referring to how it will do it. The resiliency of this view is indeed surprising since researchers have long argued against this simple distinction.5 Clearly, requirements and design are interdependent, as practitioners surely realize. Perhaps the continuing prevalence of the "what vs. how" distinction is due to the well-meaning desire on the part of requirements engineers to avoid overconstraining implementers. Other reasons for the persistence of this debate are explored elsewhere.6 Another common distinction is the separation of functional (or behavioral) and nonfunctional r e q u i r e m e n t s . Again, practitioners have found that, for many applications, this distinction is not clear. Some requirements that may appear to be nonfunctional at first become, in due course, functional. In the past, most researchers have focused on functional requirements. The article by Barry Boehm and Hoh In in this issue reflects the more recent trend to direct attention to nonfunctional requirements issues. For some time now, the software community has realized the need to broaden its view of requirements to consider the context

within which the system will function. Alex Borgida, Sol Greenspan, and John Mylopoulos' work on the use of conceptual modeling as a basis for requirements engineering was a major signpost in directing researchers to this perspective.' T h e article by Hans Nissen and his colleagues in this issue reports on recent experiences in applying conceptual-modeling techniques. More recently, Michael Jackson has advanced another way to look at context.8 Jackson faults current softwaredevelopment methods for focusing on the characteristics and structure of the solution rather than the problem. Software, according to Jackson, is the description of some desired machine,

The oldest, most widely held piece of conventional wisdom is that requirements are complete.
and its development involves the construction of that machine. Requirements are about purposes, and the purpose of a machine is found outside the machine itself, in the problem context. He has, therefore, argued for a shift towards a problem-oriented approach that seeks to distinguish different characteristics and structures in the application domain. Adopting this problemoriented approach means that the requirements for a system can simply be viewed as relationships among phenomena in the domain and a specification is a restricted kind of requirement; it is restricted because it must be expressed in terms of domain phenomena that are shared with the machine to be constructed. This characterization of requirements and specification is indeed very general. However, Jackson animates it into a method by devising a general

problem frame, analogous to those proposed by the mathematician, George Polya. In Polya's terms, software development is a three-part problem: the domain, the requirements, and the machine. Jackson argues that for any method to be powerful it must exploit the specific features of the problem and because problem features vary widely, we need a repertoire of methods each suitable for a certain class of problems. This view puts the knowledge of both the domain expert and the analyst at the heart of requirements engineering. Joseph Goguen shares Jackson's broad view of requirements. 9 But, while Jackson's distinctive contribution is primarily concerned with how requirements are represented, Goguen's novel contribution centers on how requirements should be produced. Goguen argues that requirements are information, and all information is situated and it is the situations that determine the meaning of requirements. Taking context (or situations) into account means paying attention to both social and technical factors. Focusing on technical factors alone fails to uncover elements like tacit knowledge, which cannot be articulated. Therefore, an effective strategy for requirements engineering has to attempt to reconcile both the technical, context insensitive, and the social, contextually situated factors. For Goguen, requirements are not things "out there" flying about like butterflies. Nor is the job of the analyst to find some suitable net to capture them. Requirements emerge from the social interactions between the system users and the analyst. This goes beyond taking multiple viewpoints of the different stakeholders and attempting to reconcile them because it does not attempt, a priori, to construct some abstract representation of the system. Current methods of eliciting tacit information, such as questionnaires, interviews, introspection, and focus groups are inadequate, as Goguen points out.

38

Trends in the last decade have made the requirementsas-contract model irrelevant to most developers today.

most software developers today. of having no missing parts) in requireOther issues are more important: ments specifications. However, incompleteness in requirements specifica Supporting market-driven inventors. The bulk of the software devel- tions is a simple reality for many pracoped today is based on market-driven titioners. Some may even claim that criteria. The requirements of market- completeness in real-world requiredriven software are typically not elicit- ments specifications is a Utopian state ed from a customer but rather are cre- about as achievable as getting it right ated by observing problems in specific thefirsttime!Goguen echoes this view domains and inventing solutions. Here in his criticism of current methods for requirements engineering is often done their prescriptiveness and their insisafter a basic solution has been outlined tence on the existence of a complete 9 and involves product planning and specification. The real challenge is market analysis. The paramount con- how to decide what kinds and levels of siderations are issues such as available incompleteness the developer can live market window, product sizing, feature with. To this end we need techniques sets, toolkit versus vertical application, and tools to help determine appropriand product fit with the development ate stopping conditions in the pursuit organization's overall product strategy. of complete requirements specificaClassical requirements engineering tions enabling such clarification to offers very little support for these be postponed to a later development problems. Only recently have stage (or a later "spiral" in the system's researchers begun to acknowledge evolution). their existence.10 Integrating design artifacts. REALITY CHECK Developers need faster ways to conve Prioritizing requirements. CompeDescending from the lofty consid- titive forces have reduced time to mar- niently express the problem to be erations of the fundamental nature of ket, causing development organizations solved and the known constraints on requirements, here we recommend to speed development by deliberately the solution. Often, getting to this fast some practical issues that require limiting the scope of each release. This outweighs the risk of overconstraining greater attention. A careful examina- forces developers to distinguish design. As Shekaran and others have tion of these issues actually reveals a between desirable and necessary (and observed elsewhere, requirements considerable level of compatibility with indeed, between levels of needed) fea- engineering becomes more of a design the perspective shifts urged by Jackson tures of an envisioned system. Further, and integration exercise in this 11 modifying certain noncritical require- context. We need "wide-spectrum" and Goguen. Most requirements-engineering ments may enable an envisioned system requirements techniques that can capwork to date has been driven by organi- to be realized using one or more off- ture and manipulate design-level artizations concerned with the procure- the-shelf components. Yet there has facts, such as off-the-shelf components. ment of large, one-of-a kind systems. In been little progress to date on mecha- To date, there have been very few conthis context, requirements engineering nisms for prioritizing requirements and crete results in providing support for is often used as a contractual exercise in making choices on which of those the task of evaluating alternative stratewhich the customer and the developer among a set of optional requirements gies for satisfying requirements (a organizations work to reach agreement will be satisfied by a given system "design-like" task). However, the burgeoning interest and activity in on a precise, unambiguous statement of release. what the developer would build. Coping with incompleteness. One requirements tracing may offer some Trends in the last decade system impetus for the switch in the '80s to solutions in the near future. In this issue, Pinheiro and Goguen offer an downsizing, shorter product cycles, the the evolutionary development model early look at tool support that can be increasing emphasis on building was the recognition that it was virtually provided for tracing requirements. reusable components and software impossible to make all the correct Making requirements methods and architectural families, and the use of off- requirements and implementation the-shelf or outsourced software have decisions the first time around. Yet tools more accessible. Today, many pracsignificantly reduced the percentage of most requirements research agendas titioners use general tools like word systems thatfitthis profile. The require- continue to emphasize the importance processors, hypertext links, and spreadments-as-contract model is irrelevant to of ensuring completeness (in the sense sheets for many requirements engi-

Instead, he advocates "ethnomethodology." In this approach, the analyst gathers information in naturally occurring situations where the participants are engaged in ordinary, everyday activities. Furthermore, the analyst does not impose so-called "objective," preconceived categories to explain what is occurring. Instead, the analyst uses the categories the participants themselves implicitly use to communicate.

39

neering tasks. Given the wide variety of contexts in which requirements are determined and systems are built, researchers may be well-advised to focus on specific requirements subproblems (for example, tracking and managing software priorities) and consider building automation support in the form of add-ons to existing general-purpose tools. Less accessible to practitioners are methods that prescribe a major overhaul of an organization's requirements process and the use of large, monolithic tools.

REFERENCES
1. H. Krasner, "Requirements Dynamics in Large Software Projects, A Perspective on New Directions in the Software Engineering Process," Proc. 1FIP, Elsevier, New York, pp. 211-216. 2. M. Jarke and K. Pohl, "Requirements Engineering in 2001: (Virtually) Managing a Changing Reality," Software Engineering, Nov. 1994, pp. 257-266. 3. C. Potts, K. Takahashi, and A. Anton, "Inquiry-Based Requirements Analysis," IEEE Software, Mar. 1994, pp. 21-32. 4. A Davis, Software Requiretnents, Analysis and Specification, Prentice-Hall, Englewood Cliffs, N.J., 1990. 5. W. Swartout and R. Balzer, "On the Inevitable Intertwining of Specification and Design," Cotn7tiACM)\i\y 1982, pp. 438-440. 6. J. Siddiqi, "Challenging Universal Truths in Requirements Engineering," IEEE 'Software, Mar. 1994. pp. 18-19. 7. A. Borgida, S. Greenspan, and J. Mylopoulos, "Knowledge Representation as the Basis for Requirements Specifications," Computer, Apr. 1985, pp. 82-91. 8. M. Jackson, Software Requirements and Specifications, Addison-Wesley, Reading, Mass., 1995. 9. J. Goguen, "Formality and Informality in Requirements Engineering," Proc. IEEE Int'I Conf. Requirements Eng., IEEE CS Press, Los Alamitos, Calif., 1996. 10. C. Potts, "Invented Requirements and Imagined Customers: Requirements Engineering for Off-the-Shelf Software," Proc. Inrt Syrup. Requirements Engineering, IEEE Press, New York, 1995, pp. 128-130. 11. M.C. Shekaran and J.F. Tremlett, "Reasoning about Integration Issues During Requirements Definition: A Knowledge-Based Approach," Proc. Int'IConf. Systems Integration, IEEE CS Press, Los Alamitos, Calif.. 1992, pp. 229-239. 12. P. Checkland, Systems Thinking, Systems Practice, John Wiley, Chichester, UK, 1990.

e believe the key mission for the requirementsengineering community is to continually narrow the ever-growing gap between research and practice. To that end, we close with some apt advice from the poet Stevie Smith, cited by Peter Checkland:12 It is very nice to have feet on the ground if you are afeeton-the-ground person. I have nothing against feet-on-theground people. And its very nice to have feet off the ground if you are a feet-off-the-ground person. I have nothing against feet-off-the-ground people. They are all aspects of truth or motes in the coloured rays that comefromcoloured glass and stains the white rays of eternity. +

40