Alternative Requirements Analysis Techniques

This paper is an edited version of a Chapter on the subject that was contained in SEPA, 3/e. It is provided for background and historical information.

Any requirements analysis method combines a set of distinct heuristics and a unique notation to analyze information, function and behavior for a computer-based system. Through the application of the fundamental analysis principles, each method creates a model of the problem and the requirements for its solution.

Most requirements analysis methods are information driven. That is, the method provides a mechanism for representing the information domain of the problem. From this representation, function and behavior is derived and other software characteristics are established.

Liskov and Berzins [LIS86] have stated:

Every program performs some task correctly. What is of interest to computer scientists [and software engineers and their managers] is whether a program performs its intended task. To determine this, a precise and independent description of the desired program behavior is needed. Such a description is called a specification.

The role of requirements analysis methods is to assist the analyst in deriving "a precise and independent description" of the software element of a computer-based system.

Structured analysis and object-oriented analysis are analysis methods that represent today's mainstream approaches. But many other requirements analysis and modeling methods have been used. In this paper, alternative methods for analysis modeling are discussed.

1.1 Requirements Analysis Methods

Requirements analysis methods enable an analyst to apply fundamental analysis principles in a systematic fashion. We have already examined structured analysis and object-oriented analysis–two radically different approaches to the same problem. Yet in each of these methods, and in the methods described in this Chapter, there are underlying similarities and fundamental differences.

1.1.1 Common Characteristics

Requirements analysis methods have more in common than an cursory inspection might indicate. Each supports the fundamental requirements analysis principles; each creates a hierarchical representation of a system; each demands a careful consideration of external and internal interfaces; each provides a foundation for the design and implementation steps that follow, and none (with the possible exception of formal specification languages) focuses serious attention on the representation of constraints or validation criteria.

Although each method introduces new notation and analysis heuristics, all methods can be evaluated in the context of the following common characteristics: (1) mechanism for information domain analysis; (2) approach for functional and/or behavioral representations; (3) definition of interfaces;(4) mechanisms for problem partitioning; (5) support for abstraction, and (6) representation of essential and implementation views.

Even though information domain analysis is conducted differently with each methodology, common threads can be recognized. All methods address (either directly or indirectly) information flow and information content or structure. In some cases, information flow is characterized in the context of transformations (functions) that are applied to change input into output (e.g., structured analysis). Yet with other methods, content may be represented directly, but flow is implied and not explicitly modeled. Data content may be represented explicitly using a dictionary mechanism, defined in terms of a data object, or implied by first addressing the hierarchical structure of data.

Functions are typically described as information transforms or processes. Each function may be represented using specific notation (e.g., a circle, a box). A description of the function may be developed using natural language text, a pseudo-procedural language with informal syntax rules or a formal specification language. Behavioral models range from graphical representations (e.g., the state transition diagram) to an implicit indication of behavior.

A description of interfaces is generally an outgrowth of information and function representations. Flow of data and control into and out of a specific function can be matched with information flows to other functions. Interfaces are derived from an examination of information flow. Alternatively, information flow is implied by examining messages that move about a system or "connections" that couple various subsystems.

Problem partitioning and abstraction are accomplished through a layering process that enables the analyst to represent the information domain and the functional domain at different levels of abstraction. In fact, even the behavioral domain can be layered.

For example, all methods enable an analyst to represent a function such as compute all payroll taxes and to represent and manipulate the function at this level of abstraction. In addition, all methods provide a mechanism for partitioning compute all payroll taxes into a set of subfunctions: compute withholding tax, compute FICA, compute state tax, and compute local tax. Each of these functions may be represented at a lower level of abstraction using a function descriptive notation (e.g., a pseudo-procedural language). Most analysis methods allow the analyst to evaluate the essential representation of a problem prior to deriving the implementation solution. In general, the same notation is used to represent both views.

1.1.2 Differences in Analysis Methods

Each method for the analysis of computer-based systems has its own point of view, its own notation, and its own approach to modeling. Although the modeling approach and notation will differ among all methods, confusion sometimes occurs because the same symbol (e.g., a square or a circle) has different meanings in different methods. In addition, each method has its own jargon and terminology.

The degree to which the method established a firm foundation for design differs greatly. In some cases, the analysis model can be mapped directly into a working program (using a number of transformations that are described later in this Chapter). In other cases, the analysis, method established a starting point only and the designer is left to derive the design with little help from the analysis model.

The level of CASE tools support varies greatly among the methods. Structured analysis–the most widely used method –is supported by dozens of high quality CASE tools. But other more obscure methods may have only one rudimentary tool available.

To complicate matters even further, there are a number of different versions of many of the analysis methods presented. Most software engineers, however, view these as "dialects." Once the basic "language" of analysis modeling is understood, a dialect can be easily learned. Lastly, the degree of mathematical rigor varies significantly, with formal methods leading the pack in this characteristic.

In the sections that follow we examine a number of different analysis methods. Each has characteristics that are similar to those methods that have already been presented, and each has aspects that make it unique.

1.2 Data Structure-Oriented Methods

We have already noted that the information domain for a software problem encompasses flow, content and structure. Data structure-oriented analysis methods represent software requirements by focusing on data structure, rather than data flow. Although each data structure-oriented method has a distinct approach and notation, all have some characteristics in common: (1) each assists the analyst in identifying key information objects (also called entities or items) and operations (also call actions or processes); (2) each assumes that the structure of information is hierarchical; (3) each requires that the data structure be represented using the sequence, selection and repetition constructs discussed in Chapter 7, and (4) each provides a set of steps for mapping a hierarchical data structure into a program structure.

Like their flow-oriented counterparts, data structure-oriented analysis methods lay the foundation for software design. In every case, an analysis method may be extended to encompass architectural and procedural design for software.

In the sections that follow, an overview of two important data structure oriented analysis methods is presented.

1.3 Data Structured Systems Development

Data Structured Systems Development (DSSD), also called the Warnier-Orr methodology, evolved from pioneering work on information domain analysis conducted by J. D. Warnier [WAR74, WAR81]. Warnier developed a notation for representing information hierarchy using the three constructs for sequence, selection and repetition and demonstrated that the software structure could be derived directly from the data structure.

Ken Orr [ORR77, ORR81] has extended Warnier's work to encompass a somewhat broader view of the information domain that has evolved into Data Structured Systems Development. DSSD considers information flow and functional characteristics as well as data hierarchy.

1.3.1 Warnier Diagrams

The Warnier diagram [WAR74] enables the analyst to represent information hierarchy in a compact manner. The information domain is analyzed and the hierarchical nature of the output is represented. To illustrate, let us consider an automated composition system used by a newspaper to prepare each day's edition. The general organization of the paper takes the following form.

FRONT SECTION

EDITORIAL SECTION

SECOND SECTION


Figure 1.1

The newspaper outline shown below is an information hierarchy. The Warnier diagram may be used to represent the hierarchy at any level of detail. Referring to Figure 1.1a, the newspaper information hierarchy is represented using Warnier notation. The brace ( { ) is used to differentiate levels of the information hierarchy. All names contained within a brace represent a sequence of information items (each item may be a composite of other items or an elementary item). The notation next to some names represents repetition, that is, the number of times the particular item appears in the hierarchy. For example, 1 to c columns will appear in the editorial section, while a cartoon may or may not be present (appears 0 to 1 times).

The Warnier diagram may be used to further partition the information domain by refining composite data items. Figure 1.1b illustrates refinement for the second section. The exclusive-or symbol ( ) indicates a conditional occurrence (selection) of an information item; in this case, the business news section will contain either a management profile or a labor profile, but not both.

1.3.2 The DSSD Approach

Rather than beginning analysis by examining information hierarchy, DSSD first examines the application context, that is, how data moves between producers and consumers of information from the perspective of one of the producers or consumers. Next, application functions are assessed with a Warnier-like representation that depicts information items and the processing that must be performed on them (this is similar in concept to the data flow diagram). Finally, application results are modeled using the Warnier diagram. Using this approach, DSSD encompasses all attributes of the information domain: data flow, content and structure.

To illustrate DSSD notation and to provide an overview of the analysis method, we present a simple example. A mail/phone order business, called The Software Store, sells personal computer software. A computer-based order processing system is to be specified for the business.


Figure 1.2

To illustrate the overall flow of information for The Software Store, refer to the data flow diagram in Figure 1.2 (Note: The DFD is not part of the DSSD method, but has been used because it is an already familiar analysis notation.) Phone orders are received by a sales clerk who records the order and builds an order file that is comprised of the data items shown in Figure 1.2. An order number is assigned to a particular order and passed to the shipping department, which prepares shipment using information in the order file. Other business functions (e.g., accounting) have access to the order file.

1.3.3 Application Context

To determine the DSSD application context, the problem must be stated in a manner that enables us to answer three questions:

1. What are the information items that must be processed

2. Who/what are the producers and consumers of information

3. How does each producer/consumer view information in the context of other constituencies

DSSD proposes an entity diagram as a mechanism for answering these questions.

The entity diagram uses a notation that is, regrettably, very similar to the data flow diagram. However, similar symbols have different meanings. The circle in an entity diagram depicts a producer or consumer (a person, a machine, another system) of information. The five producers and consumers of information for The Software Store are shown in Figure 1.3a. An entity diagram for the sales: order receiving department is illustrated in Figure 1.3b. All interfaces between sales: order receiving and other constituencies are shown from the point of view of sales: order receiving. Entity diagrams for other producers and consumers of information could also be developed.

Figure 1.3

After each entity diagram is reviewed for correctness, a combined entity diagram is created for all producers and consumers of information. Those entities that fall within the bounds of the proposed system (an automated order processing system) are indicated by identifying an application boundary. The detail within the application boundary may be hidden (temporarily. Information moving across the application boundary must be processed by the order processing system to be analyzed.

1.3.4 Application Functions

The functions that must be implemented to accomplish the automated order processing system can be discerned by examining information flow across the application boundary. The sequence in which data items move across the boundary is noted and using a Warnier-like notation called an assembly line diagram (ALD), DSSD provides a mechanism for coupling information and the processes (transforms or functions) that are applied to it. Conceptually, the ALD plays the same role as the data flow diagram.

An ALD for the order processing system is shown in Figure 1.4. Read left to right, the monthly report (based on monthly data to accounting) is derived by taking bank receipt information and applying a report generation process. The plus sign indicates the coupling between process and information. Receipts information is derived from a bank deposit (information) and the associated
function that processes the deposit, producing a receipt.

Each process in the ALD is refined by developing a processing narrative that addresses output, action, frequency of action and input. A Warnier-Orr diagram, described in the next section, may be used to represent procedural details for each process.

Figure 1.4 


1.4 Jackson System Development

Jackson System Development (JSD) evolved out of work conducted by Michael A. Jackson [JAC75, JAC83] on information domain analysis and its relationship to program and system design. Similar in some ways to Warnier's approach and DSSD, JSD focuses on models of the "real world" information domain. In Jackson's words [JAC83]: "The developer begins by creating a model of the reality with which the system is concerned, the reality which furnishes its [the system's] subject matter ..."

To conduct JSD, the analyst applies the following steps:

Entity Action Step. Using an approach that is quite similar to the object oriented analysis technique described in Chapter 8, entities (people, objects or organizations that a system needs to produce or use information) and actions (the events that occur in the real world that affect entities) are identified.

Entity Structure Step. Actions that affect each entity are ordered by time and represented with Jackson Diagrams (a tree-like notation described later in this section).

Initial Modeling Step. Entities and actions are represented as a process model; connections between the model and the real world are defined.

Function Step. Functions that correspond to defined actions are specified.

System Timing Step. Process scheduling characteristics are assessed and specified.

Implementation Step. Hardware and software are specified as a design.

The last three steps in JSD are closely aligned with system or software design. Therefore, in this paper we discuss only the first three steps.

1.4.1 The Entity Action Step

The entity action step begins with a brief (usually one paragraph) natural language statement of the problem. As an example we shall analyze requirements for a software based control system for the University Shuttle Service (USS) described below:

A large university is spread over two campuses which are over a mile apart. To help students who must travel between campuses to get to lectures on time, the university plans to install a shuttle service.The shuttle service makes use of only one high speed shuttle that travels over tracks between a station at each campus. Each station has a call button that students can use to request transport to the other station. When students arrive at a station, they push the call button. If the shuttle is already there, they board it and depart for the other station. If the shuttle is in transit, they must wait for it to stop at the other station, board students (if any) and return. If the shuttle is at the other station, it leaves to come and pick up the students who pushed the button. The shuttle will wait at a station until the next request for service (a button is pushed) occurs.

Entities are selected by examining all nouns in the description. After review of the above description, the following candidate entities are chosen: university, campus, students, lectures, shuttle, station and button. We are not directly concerned with campus, students, lectures or station–all of these lie outside the model boundary and are rejected as possible entities. University is merely a collective term for both campuses, so we reject it as a possible entity. We select shuttle and button.

An action occurs at a specific point in time and is applied to an entity. Actions are selected by examining all verbs in the description. Candidate actions are: travels, arrive, push, board, leaves, waits. We reject travels because it refers to student and student has not been selected as an entity. Waits is rejected because it represents a state, rather than an atomic action. We select arrive, push and leaves.

It should be noted that by rejecting candidate entities and actions, we have bounded the scope of the system to be developed. For example, by rejected student, we have precluded later enhancements such as the generation of information on how many students used the shuttle system today. However, the list of entities and actions may be modified as analysis continues.

1.4.2 The Entity Structure Step

When used in the context of JSD, the structure of an entity describes the entity's history by considering the impact of actions over time. To represent entity structure, Jackson introduced the diagrammatic notation represented as hierarchically organized rectangles. Actions are applied to an entity as a sequence, as part of an either-or (represented with an "0" in the upper right hand corner of the rectangle) selection or repetitively (an iteration, represented with an "*" in the upper right hand corner of the rectangle).

Figure 1.5

The entity structure for shuttle and button are shown in Figures 1.5a and 1.5b. In the structure diagram shown in Figure 1.5a, the shuttle begins and ends its history at station 1. The actions that affect the entity are arrivals and departures. The diagram indicates that the shuttle begins at station 1, spends its time moving back and forth between stations 1 and 2, and ultimately returns to station 1. We indicate that an arrival at a station is followed by a departure from the same station by representing both actions (arrive (i) and leave (i)) with the same station index i. Notes may accompany the diagram to specify constraints that cannot be represented directly with JSD notation. For example:

The value of i must be 1 or 2 and in any two successive occurrences of station, the value of i must change.

A single repetitive action (push) may be applied to the entity button (Figure 1.5b).

The structure diagram presents a time-ordered specification of the actions performed on or by an entity. For this reason, it is a more precise representation of the real world than a simple list of actions and entities. A structure diagram is created for each entity and may be accompanied with narrative text.

 

1.4.3 The Initial Model Step

The first two steps of JSD are concerned with "an abstract description of the real world." [JAC83] Entities and actions are selected and related to each other through structure diagrams. The initial model step begins to construct a specification of the system as a model of the real world. The specification is created with a system specification diagram (SSD. A data stream connection (represented by a circle with a "D" connecting two processes) occurs when one process transmits a stream of information (e.g., writes records) and the other process receives the stream (e.g., reads records). Arrowheads represent the direction of information flow, the circle represents the data stream which is assumed to be placed in a FIFO buffer of unlimited capacity. A state vector connection (represented by a circle with an "SV" connecting two processes) occurs when one process directly inspects the state vector of another process. Arrowheads represent the direction of information flow and the diamond indicates the state vector. This connection is common in process control applications in which it is necessary to check the state of some electromechanical device. By convention, the suffix 0 represents a real world process and the suffix 1 represents a system model process.


Figure 1.6


The system specification diagram for USS is illustrated in Figure 1.6. Whenever possible, we prefer to connect model processes with real world entities by data streams because direct correspondence between the behavior of the model and the real world is assured. In our example, the call button emits a pulse when pressed. This can be transmitted to the button-1 process as a data stream connection. However, we shall assume that the sensors that detect arrival or departure of the shuttle do not emit a pulse, but do close an electric switch. The state of the switch (on/off) can be accessed. Hence, a state vector connection is required.

The internal details of model processes are specified using what Jackson calls structure text. The structure text for button-1 is:

BUTTON-1

read BD;

PUSH-BDY itr while BD

PUSH;

read DB;

PUSH-BDY end

BUTTON-1 end

The structure of BUTTON-1 corresponds identically to the structure of BUTTON-0, with the addition of read operations that connect the real world to the system.

As noted earlier, the SHUTTLE-1 process cannot be connected to its real world counterpart by a data stream connection. Instead, we must interrogate the switches that are turned on/off by the arrival/departure of the shuttle at a station. The system process must inspect the real world entity frequently enough to ensure that no actions pass undetected. This is accomplished by executing a getsv (get state vector) operation that obtains the state vector of the real world entity. It is likely that the system process will obtain each value of the state vector a number of times before it is changed, and the model process can be elaborated to show these "in transit" values of the state vectors. A structure text description of SHUTTLE-1 follows:

SHUTTLE-1 seq

getsv SV;

WAIT-BDY itr while WAIT1

getsv SV;

WAIT-BDY end

LEAVE (1);

TRANSIT-BDY1 itr while TRANSIT1

getsv SV;

TRANSIT-BDY1 end

SHUTTLE-BDY1 itr

STATION seq

ARRIVE (i);

WAIT-BDY itr while WAITi

getsv SV;

WAIT-BDY end

LEAVE (i);

TRANSIT-BDY itr while TRANSITi

getsv SV;

TRANSIT-BDY end

STATION end

SHUTTLE-BDY end

ARRIVE (1);

SHUTTLE-1 end

The state values WAIT and TRANSIT represent appropriate values of the arrival and departure switch. The real world process SHUTTLE-0 produces a change of state in the switch, and the system process SHUTTLE-1 executes getsv operations to sense this change.

JSD continues with additional steps that allow the analyst to make the transition to software design. It is important to note, however, that the three JSD steps presented in this section provide an analysis and specification approach that is unique, and potentially, quite powerful.

1.5 SADT

Structured analysis and design technique (SADT) is a technique that has been widely used as a notation for system definition, software requirements analysis and system/software design [ROS77, ROS85]. SADT consists of procedures that allow the analyst to decompose software (or system) functions; a graphical notation, the SADT actigram and datagram, that communicates the relationships of information (data and control) and function within software, and project control guidelines for applying the methodology.


Figure 1.7

Using SADT, the analyst develops a model comprised of many hierarchically defined actigrams and datagrams. A format for this notation is shown in Figure 1.7. Each box within the actigram can be further refined in much the same way that a data flow diagram undergoes refinement.

The SADT methodology encompasses automated tools to support analysis procedures and a well-defined organizational harness through which the tools are applied. Reviews and milestones are specified, allowing validation of developer — customer communication. Staff responsibilities are similar to those found on the chief programmer team, stressing a team approach to analysis, design and review.

1.6 Summary

Requirements analysis methods provide a systematic approach for problem analysis. Although each method has a unique set of procedures and symbology, all provide mechanisms for assessment and representation of the information domain, partitioning of the functional domain, and modeling procedures for both the physical and logical world.

DSSD and JSD are not as widely used as structured analysis, nor a "current" as OOA, but they have many things in common with these methods. More importantly, each introduces its own unique view of the analysis modeling, and in some ways, each is more powerful than the methods discussed in Chapters 7 and 8. These data structure-oriented methods identify information items and actions (processes) and model these according to the information hierarchy (structure) of the problem.

Formal, mathematical specification techniques provide a foundation for specification environments that may become predominant later in this decade. Using a rigorous notation, such techniques enable a software engineer to develop specifications that are unambiguous, consistent and complete.

Language-based requirements analysis methods model a system in a more formal manner than graphical techniques, enabled automated processing to uncover inconsistency, omissions and other errors. Today, these methods are coupled with tools that enable the analyst to create the model graphically and then automatically translate the "picture" into the language form.

We conclude our discussion of requirements analysis methods with the words of Gehani and McGettrick [GEH86]:

There are important benefits which stem from writing specifications, i.e., stating in precise terms the intended effect of a piece of software. For then it is possible to talk about such issues as the correctness of an implementation, a measure of the consistency between that specification and the effect of the program. The range of benefits are actually wider than this: they relate to methods of programming, to possible approaches to verification and validation of programs, and even to the management and control of large software projects.

The "map" that has been created by the requirements analysis defines the road into design. If an analysis method has been applied correctly, it is likely that the road will be direct and the journey will be successful.

REFERENCES

[ALF85] Alford, M., "SREM at the Age of Eight; The Distributed Computing Design System," IEEE Computer, vol. 18, no. 4, April, 1985, p. 36-46.

[FIC88] Fickas, S. and P. Nagarajan, "Critiqing Software Specifications," IEEE Software, November, 1988, pp. 37-47.

[GEH86] Gehani,N. and D. McGettrick (eds.), Software Specification Techniques, Addison-Wesley, 1986, p. 1.

[GUT85] Guttag, J.V., J.J. Horning and J.M. Wing, "An Overview of the Larch family of Specification Languages," IEEE Software, vol. 2, no. 5, September, 1985, pp. 24-36.

[HOR85] Hoare, C.A.R., Communicating Sequential Processes, Prentice-Hall International, 1985.

[JAC75] Jackson, M.A., Principles of Program Design, Academic Press, 1975.

[JAC83] Jackson, M.A., System Development, Prentice-Hall, 1983.

[JON90] Jones, C.B., Systematic Software Development Using VDM, second edition, Prentice-Hall, 1990.

[LIS86] Liskov, B.H. and V. Berzins, "An Appraisal of Program Specifications," in Software Specification Techniques, (N. Gehani and A.T. McGettrick, eds.), Addison-Wesley, 1986, p. 3.

[MAR88] Marca, D.A. and C.L. McGowan, SADT–Structured Analysis and Design Technique, McGraw-Hill, 1988.

[MOR90] Moore, A.P., "The Specification and Verified Decomposition of System Requirements Using CSP," IEEE Trans. Software Engineering, vol. 16, no. 9, September, 1990, pp. 932-948.

[ORR77] Orr, K.T., Structured Systems Development, Yourdon Press, New York, 1977.

[ORR81] Orr, K.T., Structured Requirements Definition, Ken Orr & Associates, Inc., Topeka, KS, 1981.

[ROS77] Ross, D. and K. Schoman, "Structured Analysis for Requirements Definition," IEEE Trans. Software Engineering, vol. 3, no. 1, January, 1977, pp. 6-15.

[ROS85] Ross, D. "Applications and Extensions of SADT," IEEE Computer, vol. 18, no. 4, April, 1984, pp. 25-35.

[SAY90] Sayani, H.H., "PSL/PSA at the Age of Fifteen," System and Software Requirements Enginering (R. Thayer and M. Dorfman, eds.), IEEE Computer Society Press, 1990, pp. 403-417.

[SEI85] Sievert, G.E and T.A. Mizell, "Specification-based Software Engineering with TAGS," IEEE Computer, vol. 18, no. 4, April, 1985, pp. 56-65.

[TEI77] Teichroew, D. and E. Hershey, "PSL/PSA: A Computer Aided Technique for Structured Documentation and Analysis of Information Processing Systems," IEEE Trans. Software Engineering, vol. 3, no. 1, 1977, p.41-48.

[THA90] Thayer, R.H. and M. Dorfman, System and Software Requirements Engineering, IEEE Computer Society Press, 1990.

[WAR74] Warnier, J.D., Logical Construction of Programs, Van Nostrand-Reinhold, 1974.

[WAR81] Warnier, J.D., Logical Construction of Systems, Van Nostrand-Reinhold, 1981.

[WIL87] Wiltala, S.A., Discrete Mathematics: A Unified Approach, McGraw-Hill, 1987.

FURTHER READINGS

Books by Warnier [WAR81] and Orr [ORR81] provide necessary background for an understanding of DSSD. However, a comprehensive treatment of this analysis method has not been published in a single volume. It is described in a multi-volume series that is available from the originator of the method, Ken Orr.

The Jackson System Development method is described in an excellent book by Cameron (JSP & JSD: The Jackson Approach to Software Development, second edition, IEEE Computer Society Press, 1989). A complete description of the method is complemented with a set of interesting examples.

Marca and McGowen's book [MAR88] on SADT is the most comprehensive treatment of the subject that is readily available. A detailed treatment of SADT notation, accompanied by worthwhile examples, provides good insight into this analysis technique.