Structured requirements definition

Structured requirements definition

4.1 Purpose

Structured requirements specification, a data driven, output-oriented, bottom-up methodology, was initially proposed by Orr² and builds on the work of Warnier.^4,5 The focus of this methodology is designing a system to provide the right outputs to satisfy the user’s needs.

4.2 Strengths, weaknesses, and limitations

The methodology’s output orientation gives it a strong user focus; the objective is to provide the users with exact data they need to perform their jobs. The bottom-up approach tends to reinforce the output orientation because the methodology starts by investigating the necessary outputs, uses those outputs to determine the data and data structures, and then uses the data structures to suggest the necessary functions and/or modules. The methodology’s tools and techniques, such as Wanier-Orr diagrams (Chapter 33), can be used to support other systems analysis and design methodologies.

In part because of the bottom-up orientation, data redundancy is a concern. The methodology’s report and/or output orientation can lead the analyst to overlook such significant design criteria as the business environment, corporate policy and goals, and upper management philosophy. Also, this methodology lacks a strategic perspective.

4.3 Inputs and related ideas

The structured requirements definition methodology can be viewed as a special case of the system development life cycle introduced in Chapter 1. Relevant tools include entity-relationship diagrams (Chapter 26) and Warnier-Orr diagrams (Chapter 33).

4.4 Concepts

Structured requirements specification, a data driven, output-oriented, bottom-up methodology, was initially proposed by Orr and builds on the work of Warnier.

4.4.1 System outputs

The methodology is output oriented. It focuses on the system outputs, the exact data the users need to perform their jobs. More specifically, the analyst’s objective is to define:

1.  The layouts, formats, volumes, frequencies, and response times of the system outputs.

2.  The risks, costs, and benefits associated with the system outputs.

3.  The assumptions, constraints, and limitations that restrict and/or impact the system outputs.

4.  The definitions, attributes, descriptions, and relationships of the data and the data structures needed to generate the system outputs.

4.4.2 The logical definition phase

The analyst begins by analyzing and designing a logical system and then specifying the system’s logical requirements. The steps in the logical design phase are outlined in Figure 4.1.

4.4.2.1 Define the application context

The first task is to define a separate entity diagram for each major user. An entity diagram is a simplified entity-relationship diagram (Chapter 26) that identifies a major user’s primary data entities (the things about which data are stored) and shows how those entities are related without regard for cardinality.

Next, the individual user entity diagrams are combined to form a merged entity diagram and eventually an application entity diagram. The application entity diagram can be viewed as an initial entity-relationship diagram that does not detail the attributes associated with each entity or specify the cardinality of the relationships.

Key objectives of this first phase include establishing a clear boundary for the proposed application or system and identifying the application’s internal and external entities. Next, the system’s major functions (the tasks or processes the system must perform) are defined and translated into measurable system objectives. The major functions produce the desired system outputs. Note that the objectives are stated in terms of the required system outputs.

4.4.2.2 Define the application functions

The entities and relationships (the interactions between the entities) are defined in the entity diagram, but the process details are not yet known. Thus, the next step is to add process information to the functions implied by the entity diagram by identifying the mainline functional flow (the primary logical path) through the system.

After studying the interrelationship between various entities in the application entity diagram, the analyst prepares a mainline functional flow diagram (analogous to an assembly line) to sequentially link all the processes in the proposed system (Figure 4.2). Key data entities are shown inside document symbols, with the related processes listed below. Note (in Figure 4.2) that once the Customer order is completed, the processes that generate a Reorder can be performed concurrently with the processes that generate a Delivery document.

After the mainline functional flow diagram is completed, the inputs, outputs, and processes are analyzed and the time frame factor (or execution frequency) is added to the diagram, yielding a sense of the system’s scope, or magnitude. (In this methodology, scope refers to input, processing, and output time, not cost, although the methodology does not exclude estimating system size or cost.) For example, billing is a monthly, process, delivery occurs daily (or on demand), and so on.

Figure 4.1  The steps in the logical design phase.

Figure 4.2  A mainline functional flow diagram.

Given a sense of the mainline functional flow, the complex functions and/or processes are decomposed into feasible, simple sub-functions. Decomposition continues until the sub-functions at the lowest level accomplish a single task. As part of this process, the logical data structures associated with the key data entities are defined. The detailed data structures are further defined in the next stage (Section 4.4.2.3).

Finally, such factors as user needs (output data and form), system objectives (query versus report), and the constraints and/or requirements placed on the results are used to define the system’s decision support (decision-making) functions. These less tangible factors are significant when the logical data structures developed previously are converted into physical data structures.

4.4.2.3 Define the application results

For each process, a Warnier-Orr in-out diagram (Chapter 33) is prepared and all the required inputs and outputs are generated. Data layouts for each output are determined, samples of the various output forms (including such specific data as heading, title, date, page number, etc.) are prepared, the output structures are defined, and the logical structures (sequence, selection, and repetition) implied by the data structures are identified. The data items are documented in the data dictionary. Finally, during the organizational cycle analysis step, the report frequency (annually, quarterly, monthly, weekly, daily, hourly, on demand, and interactive) is defined.

4.4.3 The physical design phase

The physical design phase converts the detailed requirements determined by the logical design phase into a physical specification for developing the system. The steps are outlined in Figure 4.3.

4.4.3.1 Determine the constraints

During this step, system performance requirements (throughput, response time, and turnaround time) are set; system features such as security, locking, authentication, control, and audit are specified; and operating/execution requirements (processing speed and storage space) are defined.

4.4.3.2 Identify alternatives

Several alternatives for implementing the system are identified and documented.

4.4.3.3 Perform cost/benefit and risk analysis

Tangible and/or intangible benefits, costs, and associated risks are identified for each alternative. Cost/benefit and risk analyses are then performed for each alternative using the tools and techniques described in Part V.

Figure 4.3  The steps in the physical design phase.

4.4.3.4 Select and recommend the best alternative

The best alternative is selected and recommended.

4.4.3.5 Prepare requirements definition document

A final report containing all analysis and design documents is prepared.

4.5 Key terms

Application entity diagram —

An entity diagram that combines all the user entity diagrams and merged entity diagrams for the entire application.

Bottom-up —

A methodology that starts with the details and works upward.

Cardinality —

A measure of the relative number of occurrences of two entities.

Data dictionary —

A collection of data about a system’s data.

Data-driven —

A methodology or tool that starts with the data and derives the processes.

Data structure —

A set of related data elements.

Decision support function —

A function or operation that supports managerial decision making, often based on responding to “what-if” questions.

Entity —

A thing about which data are stored.

Entity diagram —

A simplified entity-relationship diagram that uses bubbles instead of rectangles and ignores cardinality.

Entity-relationship diagram —

A model of a system’s data that shows how the primary data entities are related.

Function —

A meaningful operation or process that produces a desired result for a proposed system; similar to a process.

Logical data structure —

A set of related data elements that ignores how the data are physically stored.

Logical design phase —

The phase in the structured requirements definition methodology during which the system’s logical requirements are defined.

Mainline functional flow diagram —

A diagram that sequentially links all the processes in a proposed system.

Merged entity diagram —

An entity diagram that combines the lower-level entity diagrams from two or more major users.

Output oriented —

A methodology or tool that works backward from the output, through the processes, to the input.

Physical data structure —

A set of related data elements as they are physically stored.

Physical design phase —

The phase in the structured requirements definition methodology during which the detailed requirements determined by the logical design phase are converted into physical specifications for developing the system.

Process —

An activity that changes, moves, or manipulates data.

Scope —

In the structured requirements definition methodology, an estimate of input, processing, and output time; more generally, size or magnitude; often, a preliminary estimate of the size or cost of an information system.

System objective —

A desired function of and/or operation performed by a proposed system.

System outputs —

The exact data the users need to perform their jobs.

Time frame factor —

A processing cycle; e.g., annually, monthly, daily, hourly, on demand, and so on.

4.6 Software

The diagrams in this chapter were prepared using Visio. Other charting programs (such as Micrografx’s Flowcharter and SPSS’s allCLEAR) and most paint programs can be used to create Warnier-Orr and related diagrams. Some CASE tools support this methodology.

4.7 References

1.  Connor, D., Information Systems Specification and Design Road Map, Prentice-Hall, Englewood Cliffs, NJ, 1985.

2.  Orr, K. T., Structured Requirements Definition, Ken Orr and Associates, Inc., Topeka, KS, 1981.

3.  Orr, K. T., Structured Systems Development, Yourdon, Inc., New York, 1977.

4.  Warnier, J.-D., The Logical Construction of Programs, Van Nostrand Reinhold, New York, 1976.

5.  Warnier, J.-D., Program Modification, Martinus Nijhoff, London, 1978.