Overview
Operational scenarios, a key method of deriving a system’s functional requirements, are incorporated into the system requirements document (e.g., MIL-STD-498 System/Subsystem Specification (SSS) (see Appendix E) or other equivalent system documentation), and also used to develop system and software test procedures (see activity 3.3.2.1 Develop System Qualification Test Cases And Procedures).
Roles and Responsibilities
The software developer, as a member of the systems engineering group, together with the group and the principal investigator and potential users, develops the operational scenarios. During this activity, the following roles are assigned to systems engineering group members:
The recorder documents all scenarios, updates the data dictionary, and records issues and other information that has been discussed in the scenario meetings.
The domain experts (e.g., the principal investigator, potential users, and other individuals with a detailed knowledge of how the system should perform and can make decisions on the system performance) describe the system operations.
The coach leading the meetings has experience developing scenarios.
Controls
The selected method of developing and documenting the scenarios. The availability of system engineering tools affects the methods of developing and documenting the scenarios.
Inputs
Project goals and/or requirements that vary in level of detail depending on the iteration (see activity 3.1.1.1 Establish Project Goals And Requirements).
Preliminary system interface descriptions (see activity 3.1.1.2 Define System Interfaces).
System mode definitions and transitions (see activity 3.1.1.4 Determine Required System Modes).
Defects documented on an inspection defect list (see Appendix B of the Instructional Handbook for Formal Inspections) during formal inspection (see activity 3.1.1.5 Participate In System Requirements Inspection).
Procedures
These steps are common to most of the methodologies for developing and documenting scenarios. This activity is iteratively performed as details are added when the scenarios become better defined. For more information on scenarios, see:
M. Coats, J. Ragan, B. Biekert, C. Kennedy, T. Peterson, "User-Oriented Requirements Analysis. A Clean Room Approach for Object-Oriented Development," IBM Federal Sector Services Corp., Houston, TX, 1994.
J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice-Hall Inc., 1991, pp. 169-172.
G. Booch, Object-Oriented Analysis and Design with Applications, Second Edition, Benjamin/Cummings Publishing Company, Inc., Reading, MA., 1994, pp. 305 - 312.
This activity clarifies and defines the required system operations. It is important to maintain and update the data dictionary (see activity 3.1.1.1 Define System Goals and Requirements) throughout this activity. Any assumptions or constraints on using a term should be documented in the data dictionary to eliminate ambiguity.
If available, any preliminary project goals or requirements, interface descriptions, documentation from previous projects, and mode descriptions are referenced throughout this activity to ensure scenario accuracy and maintain consistent terminology.
If a defect, found during a formal inspection and documented on a defect list, is being corrected, each step is reviewed to verify that no additional changes are needed.
Step 1 is performed first, and the rest of the steps then are sequentially performed and iterated through as many times as necessary. The purpose of the iterations is for refinement of details in the scenarios, first covering normal operations, and then again for handling error situations.
1) In this activity, domain experts (e.g., the principal investigator, potential users, hardware designers, laser or cryo-cooler experts, and any other individuals with a detailed knowledge of how the system should perform and who can make decisions on the system performance) interact with an assigned member of the systems engineering group (i.e., the coach), to produce clear, well-defined, user-based scenarios. The domain experts should have experience with similar projects and be able to make sound technical decisions. The coach leads the session and has experience developing scenarios. This person has strong leadership qualities and helps select domain experts. The coach's goal is to extract well-defined scenarios from the domain experts.
It is recommended that no more than seven domain experts participate in the scenario definition sessions because it becomes increasingly more difficult to reach a consensus with more than seven domain experts. No scenario meeting should continue for more than two hours [Coats, 1994, p. 18].
The coach also selects the recorder, who documents all scenarios, updates the data dictionary, and records issues and other information discussed in the scenario meetings. The recorder provides updated copies of the product before each meeting.
2) Participants identify all external system interfaces being constructed that directly originate some event (i.e., information exchange between the system and an outside agent).
The systems engineering group reviews any available system interface descriptions to determine the event sources. Interfaces that only receive system output and cannot generate inputs do not originate events. Thus, the interfaces identified here are a subset of those identified in activity 3.1.1.2 Define System Interfaces. The recorder maintains a list of sources originating events which are identified by the systems engineering group.
Example:
Sources include:
The user who issues system commands and associated parameters.
The backscatter signal received by the system’s sensors.
3) Develop the scenarios. A scenario is a series of events. There are two types of events:
External Event. An external event is originated by an agent outside of the system.
Example:
External events include:
Commands issued by users.
An environmental change causing the system to reconfigure itself.
An input received from another interfacing system.
Effect Event. An effect event is directly triggered by an external event or another effect event. An effect event may be divided into a more detailed set of effect events. A scenario consists of one external event, followed by one or more effect events. To reduce redundancy, one scenario may "call" another because the same effect events may occur in different situations.
In the early sessions, the group focuses on scenarios for "normal" situations, without getting bogged down in handling errors or bad data. These situations must be addressed after the normal situations and actions are clearly defined and understood.
Because a scenario has two event types (i.e., external and effect events), this step is divided into two substeps. It is important to complete substep A before attempting substep B so the group understands the interfaces before starting work on the individual scenarios. This facilitates planning meetings because an estimate of the number of scenarios is available.
A) For each event source defined in step 2, identify all events providing external system stimulation. The recorder documents each event.
Example:
Events originated by outside agents:
The user issues a command to the system to begin gathering data.
The user issues a command to the system to stop gathering data.
The user issues a command to the system to perform a self-diagnostic.
The user issues a command to the system to go into a "standby" configuration.
The target surface moves from darkness into daylight.
The target surface moves from daylight into darkness.
The target surface emits radiation.
An external system requests the radiation measurements be downloaded.
B) For each external event, determine all effect events. This can require having multiple sets of scenarios for a single event identified above to capture the series of effect events during normal and off-normal situations. Each scenario is assigned a unique number for tracking. Scenarios are developed by defining all possible effect events that can be triggered by the single external event originated by an outside agent, and the order in which the effect events may occur. The coach prompts the domain expert to define the effect events for each external event defined in substep A. The recorder documents the effect events for the group as they are defined, and keeps the data dictionary and the interface definitions updated with any information gathered during the sessions.
Example:
Scenario:
External Event:
The user issues a command to the system to go into a "standby" configuration.
Effect Events:
The instrument stops firing the laser.
The instrument stops gathering science data.
The instrument ceases transmission of the science data.
The instrument awaits a new command.
In Coat’s user-oriented requirements method [Coats, 1994, p. 5], this scenario would be graphically shown as illustrated in Figure 3.1.1.3-1:
Figure 3.1.1.3-1 Example of a User-Oriented Requirements Method Scenario
4) Experience shows that identifying errors in scenarios before the system design begins allows corrections to be made with less cost. The domain experts check each scenario as they step through simulated system interactions. The systems engineering group can graphically map how one scenario may lead to others [Coats, p. 6]. The group looks for any scenarios that do not prompt other scenarios, indicating that a scenario might be missing. The recorder verifies that the data dictionary and the interface definitions are updated with any information gathered during the sessions.
5) The functional system requirements can be mapped to the scenarios using a traceability matrix incorporated into the System Capability Requirements section of the SSS or other system requirements document. This table contains the number of each scenario mapped to the individual system requirements.
Outputs
The set of system-level operational scenarios developed and documented in the System Capability Requirements section of the SSS or other equivalent system requirement documentation. The traceability matrix also is in this section, mapping the scenarios to the textual system requirements.