Aerospace Systems Engineer


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.

That Process Problem

Engineers, I believe, tend to create and follow "process" just because it's our nature.  We like to organize and pigeonhole things.  It makes us feel productive.  But we seldom ask the hard question "Why".  Where is the cost benefit trade.  Where is the 80% solution, the "good enough".  Begin with the end in mind.  These are programmatic issues that are supposed to be part of the decision equation.

DOORS is a relational database.  We use it as a CM/DM tool and a word processor.  And, I think, just because we can.

DOORS is appropriate for managing the relationships between objects.  Requirements and possibly their relationships through ICDs and CONOPS documents might be a possible a candidate for incorporation into DOORS.  But then the Pandora's box is opened,…  We will ask (or have asked) ourselves,…Why not link the documents through DOORS.  This means the documents must be entered/ingested into DOORS.  And the links established.  And validated (mistakes are very possible/probable).  Which creates another mindless audit opportunity for the bureaucrats; "how many orphans?", "What's your 'burndown' rate?" 

It's hard for me to argue against "process" and "tools"; but somebody has got to ask the hard questions and do the trades;  Where is the "value added"?, Where is "good enough"?  These are programmatic questions.  Engineers don't like to address them because we can't calculate the "right" answer.  They aren't quantitative and there is risk.  We don't like that.  

I think the commercial world may "work" because of the Dilbert "pointy haired" boss, who we "Dilberts" like to make sport of.  Maybe there is method in his madness?  Maybe we actually need more programmatic management?  Maybe those aren't "stoopid" questions?

I had the good fortune (I think) of growing up as a Systems Engineer in an environment with a very strong Chief Engineer and a very strong Program Manager and hearing these two very strong women argue (cooperatively and respectfully); "It's not always about the technical, cost and schedule matter", "Sometimes it is about the technical".  These are not easy decisions but they are extremely important to a program's viability.

Systems Engineering was supposed to help Program Management by performing the technical management but we have abandoned that role and replaced it with armies of adminichrats who generate and execute "process" mindlessly.  And play with the tools; DOORS, Rationale ROSE, TAU, Rhapsody, etc,…

Begin with the end in mind!   Why are we doing "X"?  What are the benefits?  What are the risks?  What is the cost in dollars and schedule?  (Hey- that's the basis of any change process)  WHY DON"T WE FOLLOW IT FOR THESE BUREAUCRATIC DECISIONS!?

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.