Aerospace Systems Engineer

Design Derivation

How do we derive a system?

First of all, I define a system as having requirements, architecture and behavior.
These are present at every level of the system hierarchy.
And, every system has hierarchy.

Requirements, obviously are what the system has to accomplish.  Requirements are Use Cases.

       An aside on requirements;
       Upon X, the system shall do Y, within Z.
       I believe this simple little construct helps requirement crafting more than any multi-day academic training session on requirement writing and specification development.
       The “within z” picks up, at least to some extent, non-functional requirements. 

Architecture includes the HW and SW elements that have functionality.  They perform definable functions.  Not to split hairs or get religious about terms but they are actors in the scenarios.  I call them actors.  Actors have interfaces and behavior.  At every level, except maybe L0, the system has external and internal interfaces between its actors.  Interfaces internal to the actors of the level are not discussed at that level.

Behavior is how the system performs the function.  Sometimes the specific sequence of actions and timing is significant.  Sometimes it’s not so important.  When it is, we tend to document the behavior.  Otherwise we tend to ignore it and just capture the architecture and requirements.  This is a trap.  They are all related and should be considered together.

Behavior and requirements are the same thing, depending on the perspective.  Behavior internal to an actor of the level are not discussed at that level. The elaboration of a Use Case as a scenario of behavior derives lower level (internal) architecture and the necessary functions of the actors.  These “necessary functions” are derived Use Cases allocated to the actor.  “necessary function” == Use Case == Requirement. 

Do we allocate requirements to external actors?  Technically no, but actually, yes.  We may need to allocate “wills” (rather than shalls) to identify contractually binding expectations of behavior of the external actor.

Design Derivation (Synthesis or Decomposition)
These all; requirements, architecture, and behavior, decompose.  Their decomposition is not linear top down flow and is very much a “chicken or egg” situation. 

I have used “Analysis Packages” to execute this design and requirement derivation process. We triage and assign various Use Cases to engineers for elaboration.  Each analysis package elaborates a Use Case and must begin with Source or Driving requirements which define the objective to be achieved (the Use Case). 

Each “Analysis Package” also starts with a notional architecture of decomposed HW and SW elements and interfaces between them and external elements.  These architectural elements are all Actors in the Use Case elaboration exercise.  The notional architecture is necessary to provide a starting point for analysis but may change as a result of analysis (Chicken – Egg). 

The achievement of functionality requires that we identify interactions between actors, hence we define the existence (and maybe the specifics) of the interfaces (an architectural element).  We also identify/allocate functionality to specific actors, thus creating requirements for those actors which are children of the Use Case source requirement.  The Elaborated Use Case is a behavior that often must follow a specific sequence to be successfully achieved.

So how do we document this?  Basically I think we need two things; a requirements document and a design document.  I have thought for quite awhile that the Operations Concept Document, following the IEEE/AIAA format of OCDs is the almost perfect design document.  The LM IS&GSs ABD document was also pretty good.  The goal is to capture the hierarchies of architecture; Actors and Interfaces and the behavior necessary to achieve the function.  Since Functions/Use Cases/Requirements are derived from the analysis that arrived at the architecture and behavior the requirements spec aligns with the design document.

Now the bugaboo. - Is the design document a design driving document or a design capture document?  The answer, I think, may well be, Yes.

Analysis & Design

Functional Decomposition
Initial analysis should be a “pure” analysis of system function divorced from any implementation.

This is never the case; we always have at least a notional architecture within which to understand and discuss the functions. The process always iterates with notional implementations traded at an appropriate level of abstraction and feeding back into the functions problem space to be captured in the specification. One of the most difficult tasks of the Systems Engineer is to remain at the appropriate layer of abstraction. By definition this ends at SFR.

Design is the implementation of functionality. A design has physical, logical performance and behavioral aspects. A Systems Engineering Design Document can be used to capture the Systems Engineering artifacts; Conops, Use Case Model diagram, Context diagram, Interface diagram, Scenario Sequence Diagram and component diagram. When created AT THE APPROPRIATE LEVEL these, along with the system specification, are helpful in understanding and communicating the system. Together the specification, Conops and Design documents capture the essence of the system; Requirements, behavior, architecture and Performance.

       Requirements — Contractual statements of what the delivered system “shall” do.

       Behavior — How the system must behave to achieve the desired functionality (conops).

       Architecture — HW, SW and Human implementation of design.

       Performance — Quantifiable parameters within which the system will perform.

Ideally all four of these should be aligned and of “excellent” quality. It’s acceptable to have a “weakness” or lesser attention to one or two of these, f the others are exceptionally robust.

Basic Steps

1.    Identify the < 10 essential objectives of the system (L0)?
        a.    These are the system's key Use Cases
        b.    Note: Universal Use Cases applicable to every system: Install, Initialize, Operate, FD/FI, Disposal

2.    Identify "a" (not "the") notional L1 architecture?

3.    Perform Use Case Elaboration exercises to determine how the < 10 essential objectives of the system are to be executed by the notional L1 architecture?  .

        a.    Functions allocated to L1 Architectural Elements by Use Case Elaboration exercises are requirements on that element to be captured in the element's Specification.
                i.    Requirement format: Upon X, the L1 Architectural Element shall do Y, within Z.
        b.    Interactions between L1 Architectural Elements identify interfaces to be captured in the L1 Architectural Element ICD.
        c.    Interactions between L1 Architectural Element define Behaviors to be captured in the L0 Operations Concept Document.

4.    Repeat step 2 and 3 for the L2 architecture of the L1 Architectural Elements

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.

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


Basics of timeline analysis

Tasks consume time. Only tasks are shown on a timeline.

Some tasks are sequential: Erik and Steve can’t both get off the plane at the same time.

Some tasks are separate but can occur in parallel: Erik gets the food while Steve is still getting off the plane; Erik gets the Car while Steve gets the luggage.

Some tasks are parallel and the same; Erik & Steve both drive to work together in the car. The fact that they need a level of performance from the car to meet their overall system level requirement to get from touch down, to work in 2 hrs levies a requirement on Erik to get the Lamborghini. This performance requirement is not shown on the timeline, but derives from the timeline analysis.