Aerospace Systems Engineer


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.

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.


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.

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

Structured Requirements Writing

Structured Requirements Writing

Michael J LaRue

My rationale begins with the working definition that I have adopted for word “requirement’ as it pertains to system specification.

Paraphrased from DeMarco (Structured Methodologies, Yourdon Press) - A requirement is a mandatory testable attribute of a system that must be implementable and testable. The ideal form of a requirement is “Upon INPUT or TRIGGER, the system shall STRONG VERB resulting in OUTPUT (must be testable, an “on flag” or “SOME VALUE IN SOME UNITS&rdquoWinking or OBSERVABLE BEHAVIORAL RESPONSE under STATED CONDITIONS (as needed).” Furthermore the requirement should be clear, readable and unambiguous, and preferably written in a structured syntax such as Structured English. Structured English is defined in the DeMarco book, but I have pretty much paraphrased it here.

Ultimately a requirement represents the establishment of a test point that will be a measure of acceptability of the system being delivered. There is no value to testing to a capability - the system either demonstrates the behavior when the prompting conditions are met or it does not.

The phrase shall be capable of fails in that it is not a strong verb, it detracts from clarity and ultimately does nothing to enhance testability. How do you test a capability? I think it is unproductive to test for a capability. Why not just specify the mandatory, testable behavior that must occur, and be clear about when (under what conditions) the BENAVIOR or OUTPUT must be manifest?

The challenge of systems engineering is to clearly capture the mandatory behaviors and outputs and to be clear about stating the associated conditions.

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)