Aerospace Systems Engineer


The Utility of Scenario Sequence Diagrams (SSDs)

Scenario Sequence Diagrams

The Scenario Sequence Diagrams are multi-purpose diagrams which capture the essential aspects of physical and functional architecture, and system behavior, in one diagram.  These diagrams supplant several of the diagrams commonly used in Systems Engineering design derivation and documentation, and provide utility beyond the combination of all of them.

Context Diagrams - The Scenario Sequence Diagram, by listing the involved actors across the top of the diagram, illustrates the system’s physical, and functional, context and shows which actors interact in the scenario.

Interface Diagrams - The Scenario Sequence Diagram, through depiction of message traffic graphically, illustrates physical and logical interfaces between actors.

Data Flow Diagram - The Scenario Sequence Diagram data messages illustrates data flow between actors.

Data Dictionary - The Scenario Sequence Diagram, and especially the companion Event Flow Table, through the capture of each specific message provides the equivalent of a data dictionary for the scenario.

Message Sequence Chart- The Scenario Sequence Diagram illustrates sequential message exchanges between actors accomplishing the scenario.

Use Case Model Diagram – The activities populating the vertical “life lines” of the actors are the Use Cases executed by each actor for the scenario.

Activity Diagram - The Scenario Sequence Diagram, through depiction of sequential Use Case execution is analogous, but superior, to the UML “Activity Diagram” in that it identifies the behaviors required of the actor in the execution of the scenario.  The UML “activity diagram” merely shows state without exposing or elaborating behavior.

Event Flow Table

In use, the Scenario Sequence Diagram or SysML Activity Diagram will typically be combined with a textual capture of the system design in an Analysis Package for the scenario.  We use the Event Flow Table as the textual mechanism.  The Event Flow Table provides significant additional aspects which enable the Analysis Package’s utility as a design and requirements validation tool. As CASE tools evolve we can see products such as Telelogic’s TAU integrating the graphic modeling tools with the traditional requirements repositories creating powerful tool sets for the practicing systems engineer and replacing the manual text approach.

Structurally the Event Flow Table is a multi column table capturing the Source, Destination, Message and Activity of each “transaction” in the Scenario Sequence Diagram or SysML Activity Diagram. Because the diagrams represent a sequence the first 2 columns of the EFT can be used to capture the sequential numbering of the transactions in the Scenario and relative times (typically t -0 times) for sequences of transactions. Additionally the Requirements and assumptions columns are used to allocate requirements to design (or derive requirements from functions) and to capture assumptions associated with either.  It is here where the integration of graphic model and requirements repositories are indicated. A comments column is often useful to capture the extraneous bits of information exposed during the analysis of the behavior.  Additional columns are often added for specific attribute capture such as constraints and fault mode identification. 

The "Operator Requirements" Conundrum

The problem we have is not a spec writing problem in isolation from our analysis and design problem space it is the merging of these and the inadequate capture of our intention through “sloppy” requirements writing. Operators are not part of the SYSTEM being procured but they are part of the system being designed. This distinction is non-trivial and I believe the root of the disconnect.

I believe we all would agree that a specification must specify what the SYSTEM (HW & SW) must do. The problem is when design implementation calls for operators to perform significant aspects of required functions using the system rather than, the system doing these tasks autonomously. This distinction must be captured clearly in the spec to avoid misunderstanding between customer and contractor (and the lawyers).

It is correct to say that we should not have “operator requirements” in the spec (although it is acceptable) however we must then address the sloppy requirements capture that necessitates placing caveats on these ambiguous requirements. Here are 3 strategies in descending order of “purist” preference:

1 .Correct the poorly worded requirements to remove ambiguity between what the system does and what the operator does.

2. Include companion “will” statements that indicate what our expectation of what the operator’s role is.

3 .Write companion assumptions and get customer buy off on our assumptions.

As with most things in life doing it right the first time is always the cheapest, fastest, best.

The Operations Concept Document

The Operations Concept document is a technical design document derived from the customers Concept of Operations (CONOPS) and developed through systems engineering’s functional and behavioral decomposition and synthesis into a viable system architecture meeting all project requirements.

The key objective of the Operations Concept document is to capture system behavior. System behavior analysis (Use Case analysis) is the systematic application of requirements, constraints and system behavior goals (CONOPS) to derive a desired behavior. System behavior is captured in the Operations Concept document and expressed in system design implementation

The Operations Concept Document is an architecture driving document. The three components of system design; HW design, SW implementation and Operations Procedures are all equal elements of the system architecture. The Operations Concept Document defines & drives SW and HW implementation providing the context of system behavior.

Documentation reduces risk.

Good requirements specifications buy down programmatic risk. The risk of delivering the wrong thing. Or the perceived wrong thing.

Interfaces present technical risk. Two or more developer’s efforts meet at an interface. The interface must be well understood and documented, and early. A solid IRD will buy down technical risk documenting both “nuts and bolts”, and higher level design. Un- validated and undocumented interface assumptions are very dangerous.

System Behavior is documented in the Operations Concept document. The Operations Concept document buys down both programmatic AND technical risk. The Operations Concept document defines the systems behavior; as such the Operations Concept document is a design document. Its how the system MUST behave, it must be complied with by the developers.

The Operations Concept document also defines the behavior the customer and User sees. The Operations Concept document is generally the most “approachable” document to the customer and User.

Operations Concept Development

The Operations Concept document is developed in conjunction with the derivation of system design. Functional decomposition derives and allocates functions to sub- components of the overall system. But this is always done with a concept of behavior in mind. Therefore these functional allocations captured as requirements in B and C level specifications carry with them expectations of behavior. While these must also be captured as requirements in the specifications they are detailed as system behavior in the Operations Concept document.

The analysis package technique, used during system design derivation, facilitates the flow of derived requirements into the requirements documents and the scenario, captured in the Operations Concept document facilitates validation, verification and O&M procedures development.


The Operations Concept document is a design driving document that describes the mission of the system, its operational and support environments, and the functions and characteristics of the system within an overall operational environment.

Collateral Benefits

*      System design derived or validated

*      System requirements derived or validated
*      Critical timelines derived or validated
*      Architectural design derived or validated
*      Integration steps & stages derived
*      Requirement verification groups derived
*      Development of verification procedures fac
*      Development of operations procedures facilitated
*      Development of System Documentation facilitated
*      Troubleshooting or anomaly investigation facilitated

The Operations Concept document is developed in conjunction with system design development capturing system behavior detailing the interactions between HW, SW and operators. The Operations Concept document IS NOT the operations manual, but it paves the way towards development of the Operations and Maintenance documents.

Detailing system scenarios of operations also facilitates development of verification plans and procedures as well as pre-deployment readiness activities (rehearsals and training).

Operations Concept document Structure and Function

Operations Concept document Functions

*       Provides BIG picture to contractor team members.
*       Describes functions and interfaces to software developers.
*       Reassures Customer that we are all on the same page.
*       Quickly orients stakeholders to the new system; operators, maintainers, customer, testers, system engineers, managers....
*       Guides the contractor team as it develops and deploys its System.

Operations Concept document Characteristics

*       Written in the user’s language.
*       Written in narrative prose (in contrast to a technical requirements specification).
*       Uses visual forms (diagrams, illustrations, graphs) and story boards whenever possible.
*       Provides a bridge between the users needs and the developer’s technical requirements documents.
*       Helps bring to the surface the users’ views and expectations.
*       Contains a series of scenarios from different stakeholder viewpoints (customer, maintainer, operators, developers, testers, system engineers / architects, managers, etc.).
*       Integrates the scenarios into a composite system behavioral timeline with internal and external system inputs/outputs.

The Operations Concept document follows the AIAA and IEEE standard for Operations Concept documents typically organized as follows;

1.0 Scope

2.0 Referenced Documents
3.0 Operations
3.1 Operational Overview
3.2 Personnel
3.3 Operational Processes
4.0 Operational Needs
5.0 System Overview
5.1 System Scope
5.2 Users
5.3 System Interfaces
5.4 System States & Modes
5.5 System Capabilities
5.6 System Goals & Objectives
5.7 System Architecture
6.0 Operational Environment
7.0 Maintenance Environment
8.0 System Operational Scenarios

While the organization and structure of the AIAA and IEEE Operations Concept document is very good the key elements from a design capture perspective are the System Overview (Sect 5) with emphasis on system interfaces, states & modes and architecture. The other key section is System Operational Scenarios (Sect 8). Section 8 captures the behaviors of the system.

System Behavior Scenarios

System Behavior scenarios are Use Cases. They are depicted as threads of behavior across the system. Not all Use Cases are equally important, during the system design process the Use Cases are prioritized based on risk and the high priority Use cases are elaborated.

       Mission Success Risk- Essential Mission Functionality

       Integration Risk -Complex Interfaces & Interactions

       Development Risk - New technology or application

Analysis of thread path variants may indicate additional potential risk areas.

>>Warning<< - Potential for infinite path variations is possible Alternate-path Use Cases rarely warrant full elaboration during system design efforts and are generally not captured in the Operation Concept document. The typical approach is to identify significant risks with the major ones understood to the extent that contingency strategies are definable. Contingency processes and procedures are the domain of the 0&M documentation not the Operations Concept document.

Each System Behavior is introduced in the Operation Concept document with explanatory text and illustrated using several key elements from the behavior analysis process; Context Diagram, Message Sequence Chart and Event Flow Table.

Shall be capable of,...

A requirement to be “capable” does NOT specify that the system be delivered be ready to do the job, but that is never the intention of the spec writer. We must purge the phrase from our requirements writing. This alone does not doom a spec but it is indicative of lack of rigor in the requirements analysis and spec generation process.  I think most of the time its just lazy writing but sometime we use the phrase intentionally.  Don’t.

We often intentionally get into this “shall be capable of…” requirements writing trap in the situation where we want to specify a performance level but allow latitude as to when the specified performance is employed, “be capable of producing really dark toast, but not all the time”. This trap can be avoided by decomposing the problem space and creating multiple requirements, typically one to specify the performance range and another to specify the selectable control within that range. The system shall produce toast in the range of “warm” to “really dark”. AND.  The selection of toastification shall be selectable by operator input. Together these meet the need of specifying a maximum capability of the system but allowing the range of options to be employed.


Concept (knowledge) Reuse vs Product Reuse

Concept (knowledge) Reuse vs Product Reuse

Benefits of re-use are not equal across the board, and typically NOT product (document, code, or hardware) reuse — at least at the higher levels. The benefit of “re-use” is problem-space understanding. The curve of re-use benefit is greater at the bottom (component), less so at the top (system)

An invalid understanding of the areas of benefit of re-use often impact top down analysis.


            “Pulling up” predecessor programs specs and assuming re-use with out doing top down analysis.

            Expectation of design migration without analysis of appropriate “fit” into the new problem-space.

Requirements Verification & System Validation

Requirements Verification & System Validation
Validation is not verification - and visa versa.

We must do BOTH.

Verification is the contractual effort to sell off requirements. Long ago this industry learned that verified requirements does not necessarily equate to a viable product achieving its "essential elements of design". We do several things to assure "mission success", these are not driven by customer concern (although they align), they are command media directed.

The Systems Engineering challenge is to demonstrate the processes in place to:

1.  Identify the "essential elements of design" (key Scenarios)

2.  Identify high risk items "Big Fish" (Critical Events)

3.  Systematically track and address both the "essential elements of design" and the "Big Fish".

4.  Assess and manage technical performance issues (TPMs)

5.  Validate functional performance (TLYF, DITL, Scenario based testing)

6.  Audit key data elements

7.  oh, yeah,... and verify requirements.

IMHO requirement verification is less important than Functional Validation.  Function validation ALWAYS catches more than the most complex suite of negative testing, threshold testing, envelope extremes testing, etc. of individual requirements ever does.

A PDR Outline

The objectives of PDR are to demonstrate through presentation and support material that the program understands its requirements and has developed a preliminary design that fulfills the requirements.
Typical PDR Entrance Criteria

The following items are complete (to PDR level of development) and typically provided as read material. Read package may also contain analysis material, trade studies, etc. (i.e., Technical Memos)

            System Specification

            Segment Specification
            Element Specification(s)
            Interface Requirements Specifications IRS(s)
            Software Requirements Specifications SRS(s)
            System verification matrix and verification plan
            System Integration & Test Plan
            System Engineering Design Document (SEDD)

System/Sub-System Architecture

            Block Diagrams
            Interface Diagrams
            Operations Concept Document (OCD)

System Behavior (Threads & Use Cases)

            System Design/Cost Analysis
            SFR Action Items

Completed Mitigation Plan

Typical PDR Presentation Outline


*      Program Overview
*      Program Processes
*      Security/P2
*      Program Staffing
*      Schedule
*      Entrance Criteria

System Introduction

*      System Architecture
*      Functions
*      OPSCON (Behavior) – L0 Thread
*      Thread Mapping
            Critical Use Cases
            Segment Behavior Allocation
*      Timeline Allocations
*      TPMs
*      Risk

Design Description Element

Expectations --

System Architecture
The segment should present the key design areas of their system; Functional, Hardware and Software. Each area should be presented graphically as an architectural diagram. Each will be expanded upon during the Functional, Hardware and Software segments of the PDR presentation. Sub-Segment Architecture Diagram Hardware Implementation & Deployment Diagram Software Implementation & Deployment Diagram

Context Diagram
The segment should present a context diagram illustrating where their segment functionally, physically and logically (SW) fits within the larger system.

Interface Diagram
The segment should present an interface diagram illustrating the physical and logical interfaces with entities outside the segment.

Functional Architecture
The segment should demonstrate they understand the functions required of their system. The segment should present the allocations of functions to HW and SW elements of the design.

Key Function(s) Design
The segment should demonstrate they understand the driving requirements of their segment that support the overall program.

The segment should demonstrate the flow down and understanding of system level requirements to Segment and Element.

The segment should demonstrate they understand the necessary behavior of their segment in support of program requirements and in conjunction with other segments.

The segment should demonstrate they understand and are managing identified areas of design and development risk.

Systems Analysis and Studies
The segment should demonstrate they have performed, with adequate rigor, the analysis of their preliminary design. The segment should present design trades and supporting material for design decisions.

Design Margins
The segment should present design analysis demonstrating design closure and indicating design margin, where applicable.

Development Assurance
*      Requirements Verification Plans & Status
*      Integration & Test
*      Software Engineering
*      Specialty Engineering
*      Reliability/Availability Allocations
*      Maintainability
*      Logistics

Modeling System Behavior

Probably the biggest problem we face in systems engineering is maintaining continuity of vision throughout the project lifecycle. We have recognized for some time that specifications alone are inadequate.  Initially the problem space is interpreting what it is the customer is really asking for.  Then we move into design iterations, followed by development, test and delivery.

Throughout, even perfectly crafted requirements and specifications are subject to reinterpretation over time and especially when individual requirements are viewed with out context.  Generally it is not the quantitative performance requirements that cause problems but rather the functional or behavior requirements.

The elements of behavior that must be understood include the architectural components and abstractions (both logical and physical), the interactions between components, and the activities of individual components.  All the while recognizing that every system is hierarchical, and every aspect; architectural, interactions and activities decompose downward and abstract upwards.

We have seen a variety of diagrams and techniques come in and out of vogue as systems engineers struggle to perform the basic tasks of systems engineering; Define the problem, Design a solution, Communicate the design, Build the product system, and Test the product system against the design.  Notice I didn’t say; write requirements, create a DOORS database, generate specifications, write a Conops Document, generated FFBD, IDEF0 diagrams, Rose models, etc.  These are artifacts and tools (the means not the end) to achieve the true goal; a product system that fulfills the customer’s needs within the programmatic constraints of budget, time and the reality of physics.  These artifacts and tools only have value when they are used towards the goal and not seen as ends in themselves.  “Begin with the end in mind”

Through a single model…
  • we derive the product system requirements?
  • we design the product system?
  • we communicate the product system design?
  • we test the product system?
By recognizing that every system is hierarchical a suite of multiple levels of diagrams depict the system.  An activity of a part of any system is a Use Case or activity of that part of the system. That is a natural decomposition. That “part” owns its Use Case as a requirement to be implemented by the components of that part. Just as the “part” decomposes into components or elemental parts, the behavior (the Use Case/Activity/Requirement) decomposes into elemental behaviors. Behavior and architecture decompose. The typical specification tree captures this as A-Specs, B-Specs, etc. The hierarchal model inherently does the same. The point is not to model individual requirements but to model the system in its entire hierarchical state because the whole is indeed more than the sum of its parts and only in understanding the whole can we avoid the ambiguity of analysis in isolation.

>>>WARNING<<<  Such a hierarchy is exponential, especially when alternate or exception flows are considered.  Triage – not everything is essential to be modeled.  The number one attribute of a systems engineer is common sense.  Focus on risk; essential functionality, new technologies, and interfaces. Model the high risk areas.
Scenario Sequence Diagrams.

Scenario Sequence Diagram, in a single diagram, the capability to model; architectural components and abstractions (both logical and physical), the interactions between components, and the activities of individual components. By focusing on the essential behaviors of every system; Installation, Initialization, Operation, Fault detection, Fault restoration & Maintenance, and Disposal a set of scenarios will define the Level 0 system.  Architecture and interactions are exposed during this exercise thus the first level of decomposition is realized.


The Scenario Sequence Diagram and SysML Activity Diagram are graphic depictions of a behavior sequence.  The key elements of the SSD are:

       *      Actors – Actors are represented as boxes, except for human actors which are shown as stick figures. The actors of a scenario are shown across the top of the diagram.

       *      Lifelines – Lifelines are the vertical lines drawn down from each actor.  Time proceeds down the page.

       *      Use Case – Use Cases are the behaviors of the actors.  Use Cases are shown as “bubbles” on the lifeline of the actor executing the behavior.

       *      Messages – Messages are sent from a source to a destination actor.  Messages typically trigger an activity of the destination actor.  Messages contain data and/or control directives.

       *      Transaction – A transaction is a sequence of behavior consisting of a message from a source actor to the destination actor, initiating the Use Case of the destination actor.

The SysML Activity Diagram, in the Swim Lane version, provides the same functionality but uses a slightly different vernacular.  Actors are “Parts”, Lifelines are replaced with Swim lanes, Use Case are termed activities, and Messages can be richly represented.

It's just a toaster

The "stuff" we work on is big and complex, but the principles are simple and basic. To keep the thinking simple, think of "the system" as a toaster. The same basic SE principles hold true for a toaster as any highly complex system, but we can conceptualize the application to the development of a toaster without getting lost in "interesting" technical problems.

Basic Questions
What are we doing?
What is the objective of the program?
This should be very simply and straightforwardly stated. What Designing
Complex Systems with Models and Objects calls "the essential elements of
design". Typically less than 10.

Who is the Customer?

Who is the System operator?
Who is the System's User (the user of the system's product)?
What is the System?
  • Physical & Logical Architecture
  • Key (driving) requirements "the essential elements of design".
  • Key Use Cases
               Operate (and Maintenance)

  • What is the administrative structure of the program?
  • Should align with physical logical architecture
  • What is the Period of Performance?
  • What are the deliverables?
  • What is the schedule for deliverables?
Spec tree
  • Should align with physical logical architecture and administrative structure
  • Should include Specs (including SRS), conops documents, and ICDs

Processes & Procedures
Documented in a Systems Engineering Management Plan (SEMP)
A SEMP is important from a communication with the team perspective but even more so for being forced, by generating the SEMP, to think about and coordinate within the management team, an implementable process understood and supported by the management team. Process is essential, but fight unnecessary bureaucracy.

SEMP Content (not exhaustive)

  • Program phases and schedule (defines actions and products)
  • Products (with descriptions, include cmd media and/or DID references)
  • Technical Review process (with entrance and exit criteria)
  • CM/DM process
  • Change process
  • Tools & Techniques
  • Systems Engineer F&Rs
  • Functions: Analysis, Design, Review, Audit, Approve
  • Responsibilities:

Systems Engineering emphasis varies over the lifetime of the program

Analysis Package Development Process

This is written for system SEIT level Systems Engineering, but is applicable when tailored (i.e., identify appropriate participants) for use in the segment level SE process also.  The names may vary, the basic functional responsibilities won't.  Every program/project has its own level of necessary ceremony. 

1. Assign Use Case to engineer for elaboration and analysis
2. Specify Source (driving) requirement(s) for Use Case (A-Spec)
3. Develop Data Flow Diagram (functional context diagram)
4. Develop Scenario Sequence Diagram (SSD) and associated Event Flow Table
5. Identify source requirements for each transaction (row) of EFT
6. Identify where derived (B-Spec) requirements are needed
7. Identify design assumptions, as required, for each transaction (row) of EFT
8. Include comments/concerns as required, for each transaction (row) of EFT
9. Schedule community review
10. Hold community review
     (Note; this is a non-trivial activity which should be allocated at least I day per use case)
        a. System Architect
         b. Use Case Model Owner
         c. System Model Owner
         d. System SEIT Conops team
         e. System SEIT I&T
        f. System SEll Requirements
        g. Segment representation

11. Make updates to analysis packages as required

12. Perform requirements audit (AP identified Use Case to B-Spec requirement)
13. Generate new derived requirements, as needed
14. Link requirement to AP in DOORS (create an A attribute in DOORS)
15. Prep for SFR
         a. Focus on High Risk requirements (requirements that are vague and have high potential for malicious interpretation with cost/schedule impact)
         b. Make and capture clarifying assumptions for each of above
         c. Insure APs are available in read file

Post SFR System Engineering Design Document (SEDD) development

16. Merge approved/reviewed scenario into System model
17. Support configuration change process, as required, based on review

The Analysis Package

The Analysis Package is a structured engineering artifact that captures architecture and behavior and validates design against requirements.  The typical structure of an Analysis Package is,…




Context Diagram:

Scenario Sequence Diagram (SSD):

Event Flow Table


Some Thoughts on “Operator” Requirements

Every system is a combination of Hardware, Software and human operators. Consider a toaster, even the best toaster doesn’t unwrap the bread, put it in the toaster and “operate” the controls. The system (toaster) is useless without the operator yet we don’t think of the operator as part of the system. A delivered system consists of the hardware and software items that the contractor provides to the procurement agency under the contract. However, THE SYSTEM CANNOT OPERATE WITHOUT OPERATORS hence (I think) the quandary; how do we reconcile customer requirement like the system shall “turn bread into toast” without levying requirements on the operators?

We have a couple of requirements writing strategies to help us, but first we must understand our intended design well enough to migrate the customer’s intention into a contractual specification (A-Spec). This requires analysis.

The first analysis step is to define the context of the system. What is internal and what is external? There can be multiple perspectives on this, procuring agency, operating agency, using agency, but the ONLY one that matters is the contractors. Of course the contractors perspective must be accepted by the procuring agency, operating agency, using agency, etc, which is why we have SFRs, PDRs, CDR, and a multitude of TEMs, demos and working groups.

The goal is to have consensus on what the system is and does. THIS IS THE NUMBER 1 GOAL OF SYSTEMS ENGINEERING — reaching internal and external consensus on what the system is and does.

Requirements are never generated in isolation from system architecture. System architecture consists of HW, SW and human elements. Both requirements and architecture must be decomposed.

System designers may/must allocate responsibilities to Hardware, Software AND operators. With a toaster the allocation to the operator can be unstated, it is understood. Given the complexity of the systems we usually develop, what is the systems responsibility and what is operator responsibility must be unambiguously communicated, understood and agreed to. We have some requirements writing strategies to help us but Operations Concepts, system modeling (like scenario analysis — threads and Use Cases) and prototypes all help the communication.

Requirements Writing Strategies

First Choice
Requirements writing strategies include using phrases like “Upon operator input the system shall...”. This phrase clearly indicates that the system is not doing something automatically. Without this the customer(s) could legitimately argue that we agreed to provide an automatic function when none was intended. Expectations of automatic or autonomous action by the system are typically very costly, if possible at all.

Second Choice
The second is to use “will” statements, “The operator will...”, this indicates that the designers and architects of the system clearly intend that the function following the will, is not being performed by the system. That function might be unwrapping the bread and putting it in the toaster, or it might be calculating the required delta V to perform a maneuver. A “will” in the spec defines performance of units outside the system, and is contractually binding. Since “wills” are not requirements they need not be verified.

Last Resort
Assumptions can be used to document the contractors understanding of acceptable implementation and to aid reaching customer concurrence, but un-validated assumptions have no weight.

The analysis necessary to craft proper specs is non-trivial