In developing a requirements specification for a project, it is necessary to do the work within some framework. A projects-specific feedback system model of requirements-building for a training program for an Air Traffic Control (tATC) system is given in Fig. 1.

The model in Fig. 1 includes a Humphrey ETVXM architecture to ensure an orderly transition from one task to another task in developing an SRS. The availability of a tATC plan is an entry condition which must be satisfied to start the requirements for the system. It is assumed that this plan is the result of interaction with project stakeholders. This interaction continues during the development of system requirements. The procedure block in Fig. 1 will be fleshed-out by following the IEEE standard for developing a Software Requirements Specification (SRS).

6.2 Parts of the SRS [SRS for air traffic control system given in textbook]

Executable object models are also called statecharts. A statechart specifies system behavior, how objects communicate and collaborate to accomplish some goal. States describe abstract situations in an object’s life cycle. It is fairly easy to "read" code from a statechart because its arcs are labeled with trigger conditions and lists of actions. A trigger is either an event (e.g., mode = stop) or request for an action (e.g., change(term)). An action is a sequence of event-generating expressions, or operation calls, or C++ statements. Using the Statemate MAGNUM toolset, statecharts can be executed, and provide a means of rapid prototyping [Harel and Politi, 1998]. Using statecharts, the description of a system can be created in a modular fashion using information hiding. The details of the design of each module are hidden in a layering of statecharts. The states in the top-level description of a module such as an tATC scanner can be decomposed into more detailed statecharts. Lower-level statecharts reveal detail which explain the mechanisms underlying a top-level statechart. The visual formalism provided by statecharts aids understanding and facilitates clean, simple descriptions of hierarchies in the operational structure of a system.

This section presents section 3 of the SRS for the tATC organized by statecharts. To make it easier to read, the skeletal structure of section 3 is given entirely.

SRS-3 Specific Requirements

3.1 External interface requirements

3.1.1 User interfaces

3.1.2 Hardware interfaces

3.1.3 Software interfaces

3.1.4 Communication interfaces

3.2 Statecharts

3.2.1 Statechart 1

A high-level description of the tATC system is given in Fig. 5.

3.2.2 Decomposition of the scan state

3.2.3 Decomposition of aircraft state

A detailed view of the aircraft portion of the user interface for an air traffic control system is given in Fig. 7. The assumption made in the statechart in Fig. 7 is that the system relies on input from pilots as well as its sensors (radar) to locate an aircraft in a sector of an airspace in the neighborhood of an airport tower. An controller relies on a user interface to track and guide an identified aircraft.

Fig. 7 Description of Aircraft Scanner Behavior

3.2.4 Decomposition of locate state

The locate state in Fig. 7 decomposes into the statechart in Fig. 8.

Fig. 8 Locating an Aircraft

3.2.4 Decomposition of guide state

Locate and guide functions are associated with each aircraft. Guiding an aircraft requires some form of user interface which make it possible for a controller to interact with a display. A decomposition of the guide state is given in Fig. 9. This is a partial description of guide-activities which function independently of each other. The assumption made in this description is that a controller use mouse-clicks to change states in a number of ways.

• Transfer of an aircraft from airport tower to enroute center control.
• Enclosing an area of a display with a map indicated a part of the airspace which has been restricted due to some emergency.
• Restriction imposed on aircraft being controlled.
• Talking with pilots and giving instructions.

Notice that each of the states in Fig. 9 are part of a hierarchy. To see more of this hierarchy, these states must decomposed into other statecharts.

Fig. 9 Guiding an aircraft

The decomposition of the states in the guide statechart in Fig. 9 as well as the remaining parts of Section 3 of the SRS are part of the problem set for this chapter.

3.2.5 Decomposition of weather

3.2.6 Decomposition of airspace

3.2.7 Decomposition of airport

3.2.8 Decomposition of score

3.3 Performance requirements

3.4 Design constraints

3.5 Software system constraints

3.6 Other requirements

[Harel and Politi, 1998]

D. Harel, M. Politi, Modeling Reactive Systems with Statecharts: The Statemate Approach. Boston, MA: i-Logix Inc., 1998. Part No. D1100-43-B, 4/98.