Aerospace Systems Engineer


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.


You get what you pay for

The Customer gets what they pay for, no more, no less.
–Kathy Morgan OSR Chief Engineer

This is a business. The customer pays for what’s in the Requirements spec.

Engineers working on analysis beyond the minimum stated in the specs are stealing from the contract.
-Suzanne Bailey OSR PM

"A $/hr spent working on "shoulds" is a $/hr not spent on requirements."  

- Ron Mandel

I may be slow, but I'm seeing a pattern here.

Its all about Requirements

Requirements, Requirements, Requirements
  • "If you are not working on requirements you are stealing from the contract." - Suzanne Bailey
  • "The customer gets what they pay for." - Kathy Morgan
  • "A $/hr spent working on "shoulds" is a $/hr not spent on requirements."  - Ron Mandel

Be specific in writing requirements

Upon X, the System shall do Y, within Z.

Upon X,

  • This is the "triggering" event. If not specified the function is required to continuously occur.
The SYSTEM shall do Y,
  • This is the function that the requirement specifies the system must perform. The system is the system identified in the title of the spec, not a sub-component of the system (i.e., avoid implementation).
Within Z.
  • This specifies the performance bounds of the function. Unbounded requirements are very dangerous.

Keep specs simple
  • What, not how
  • Don't over specify
Doors, or any other requirements database, IS A DATABASE! DO NOT USE IT AS A WORD PROCESSOR!

Requirements, Behavior, Architecture
- What the system must do
-  Capture Product: Specifications

- How the system does what it must do
-  Capture Product: Conops

- What the system consists of to do what it must do
-  Capture Product: ICDs
       •  Actors (physical and logical)
       •   Interfaces

Systems have hierarchy.
       - L0   User to system
       - LI    Major system elements
       - L2   Sub Systems
       - L3   Components
Systems Engineering activities, at the level "above", derive/define the Architecture and Requirements of the level "below" through the generation of; Specs, Conops and ICDs. And, of course these are produced as the culmination of an analysis and design synthesis process.

Universal Considerations at each level
       -  Requirements
               •  Actor Specifications
       -  Architecture
               •  Actors
               •   Interfaces
       -  Behavior
               •   Interactions between Actors

Requirements, Interfaces, Definitions
       Requirements: What the system must do.
       Interfaces: Area of highest risk.
       Definitions: Be specific and avoid ambiguity (to minimize risk)

Risk reduction

Technical and Program Management

“It’s not always about the technical!”
-Suzanne Bailey OSR PM

“Sometimes it IS about the technical!”

–Kathy Morgan OSR Chief Engineer

Systems Engineering (and program management) is all about risk reduction! Documentation reduces risk!

Requirements buy down programmatic risk! The risk of delivering the wrong thing. Or the perceived wrong thing. Requirements are the contractual agreement with the customer AND with the developer(s). Systems Engineering is the lawyer. Assume that “gentleman’s agreements” and assumed understandings will fail. Especially in our industry where we have such high personnel turnover. The customer we have at the beginning of a project is seldom the one we have at the end. Unless requirements are unambiguous you will be caught at test and deployment with “different” interpretations! (pay me now or pay me latter- and it’s cheaper up front) The development engineers also transition. The design we think we all understand WILL NOT be the same one a new person to the project will have.

Interfaces are technical risk. Two or more developer’s efforts meet at an interface. The interface must be well understood and documented. And early!   un-validated and undocumented assumptions will kill you!

Conops buys down programmatic AND technical risk. Conops IS NOT the operations manual! (but it will lead to it) Conops is the systems behavior. Conops is a design document. Its how the system MUST behave, it must be complied with by the developers. Developers must have a common vision of the behavior especially where they interact. Conops is also the behavior the customer and User sees. The Conops is generally the most “approachable” document to the customer and User.

Cutting Corners

A very experienced team may get away with cutting corners that a Jr. team can’t.   It’s also less risky to cut corners on simpler projects than more complex projects. But you must consciously KNOW you are cutting corners, know WHY you are cutting corners, and know the risk.  “its not always about the technical”, but it’s also not always about the $s. System Engineering and Program Management is not easy! Everything’s a trade. How we envy those engineering disciplines that can calculate THE right answer. Everything is gray to us.