Why Model?!

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”

Modeling

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 and SysML Activity Diagrams

Scenario Sequence Diagram or SysML Activity Diagrams provide, 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.

Error! Reference source not found. illustrates these SSD elements in a trivially simple system.

Figure 1 - 3-way lamp Scenario Sequence Diagram

Utility of the Scenario Diagrams

The Scenario Sequence Diagram or SysML Activity Diagram 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 or SysML Activity 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 or SysML Activity Diagram, through depiction of message traffic graphically, illustrates physical and logical interfaces between actors.

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

Data Dictionary - The Scenario Sequence Diagram or SysML Activity 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 or SysML Activity 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 or SysML Activity 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.

Table 1 Event Flow Table (format)

#	T/L	Source	Destination	Message	Action	Requirement	Assumption/Comment

Function/Utility of the Scenario Sequence Diagram or SysML Activity Diagram and EFT Elements

Event Flow Table Column(s)	Function/Utility
Source - Destination-Message-Activity columns	The Source — Destination —Message- Activity columns provides textual description of each transaction represented in the Scenario Sequence Diagram or SysML Activity Diagram. Together the SS and EFT allow customer validation/clarification of contractor interpretation of requirements and customer Conops intent. (A-Spec, System Conops) Scenario Sequence Diagram or SysML Activity Diagram and Event Flow Table consists of linkages of Segment level Use Cases (activities) necessary to implement the system use case. (System Conops)
Activity Column	The Activity column identifies behavior, as next level Use Cases, which correspond to necessary next level Spec requirements. (B-Specs) Identified next level Use Case list provides starting point for next level behavioral decomposition. (C-Specs)
Source — Destination -Message Columns	The Source — Destination -Message sequence defines necessary system interfaces and their function. (ICD/IRS)
Requirements Column	Shows contractors association of requirements with system behavior (Conops) allows customer validation/clarification of intent. (A-Spec, System Conops)
Assumptions Column	Identifies contractor assumptions regarding ambiguous requirements allows customer validation/clarification of intent.
Design Comments Column	Identifies contractor assumptions regarding ambiguous conops intentions allows customer validation/clarification of intent.

Additional discussion of Scenario Sequence Diagram conventions can be found at http://www.sanelson.com/Work/SAN_work.htm#Papers

The analysis package may be revisited several times during the development lifecycle with emphasis on various aspects of systems engineering appropriate to the time in the lifecycle. Requirements derivation, design validation, verification planning and test development, operations procedure development, and troubleshooting are some of the aspects of systems engineering that are assisted through use of the Analysis Package.

Blog	Steve’s Home Page