Systems 101

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

Requirements

- What the system must do

- Capture Product: Specifications

Behavior

- How the system does what it must do

- Capture Product: Conops

Architecture

- What the system consists of to do what it must do

- Capture Product: ICDs

• Actors (physical and logical)

• Interfaces

Levels

Systems have hierarchy.

- LO 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)

ICD Verification and Audits

ICDs define the interface between two systems. ICDs address, the Physical, Protocol and Application level details of the interface. ICDs provide design information to the designers implementing the system functionality.

1. Where there are no options there is no design latitude and no ambiguity (i.e., the physical envelop of a device)

2. Where design latitude provides implementation options the ICD documents the design agreements (i.e., device B configured as 1553 RT 5).

3. Some systems may have utilization options (i.e.. Control directive 123 or control directive ABC will turn on the device. Typically there will be factors to consider in the choice of these control directives. ) IRS's are sometimes used to enforce an implementation.

Verification

ICDs

ICDs need not be verified. We do, of course want to demonstrate and convince ourselves that the ICD is, in fact, correct! That is different from verification.

The design required to achieve the functionality defined by the requirements; Spec A, Spec B and their parent, demand that the ICD be adhered to. If not it won't work. Therefore the successful verification of the requirement indicates that the ICD was adhered to. There is no option for the function to execute successfully unless the interface is adhered to. Where the interface provides implementation latitude (#3 above) and a specific implementation is not identified in the requirement, the designer chooses. Verification doesn't care which choice is made.

IRS

An IRS contains requirements; "Shall" statements. If the IRS approach is chosen the IRS imposed design implementation, the IRS requirement, is verified.

Managing ICD Development and Implementation What are the salient items of the ICD?

Differentiating between descriptive material and essential interface design elements in the ICD is important. The spec writing approach of the use of "Will" is helpful to identify these necessary interface design elements. Tracking of the "Wills' can then be managed. "Wills" are not verified, but we do want to assure that they are correct.

How do we insure ICD items are correct?

This is often what is meant by "verifying" the ICD. It is really a method of confirming that the interface is correctly documented. It is NOT verification in the sense that we verify requirements.

Peer Reviews by Subject Matter Expert and Systems Engineering provide a level of assurance of the correctness of the data.

Placing the ICD under configuration control and the process of "boarding" the ICD add another layer.

Component acceptance testing provides an opportunity to confirm that the expected interface behavior agrees with the documented behavior. This also provides risk reduction prior to assembly.

These things assure us, and the customer, that we are managing our interface risk.

How do we insure both sides know what "truth" is?

Achieving successful functionality requires that both sides of the interface have the same understanding of the interface. There should be only one interface document between interfacing entities. An audit of the requirements specifications can be used to provide assurance that the interfacing entities are both referencing the same interface document for the same functions. Auditing the respective specifications, of the interfacing products, assures that they each reference the appropriate specific section of the correct ICD.

ICD validation occurs when the interfacing products requirements are verified.

A validation plan, mapping the interfacing products functional requirements to the associated ICD "wills" provides a mechanism to track validation of adherence to the ICD.

One should NEVER SAY we will have a "validation" product for ICDs. This would just open ourselves up to a mindless tracking of a meaningless effort. The true value is in the engineering exercise of incrementally defining, coordinating, documenting, communicating, evaluating the interface agreements so that there are NO SURPRISES when the two things interface for the first time.

Analysis

A standard SE Analysis approach, tools and implementations will vary.

Design Synthesis

Changing gears from Conceptual Design to Actual Design.

Synthesis of THE Architecture and Behavior that will satisfy parent requirements requires engineering THE system solution that mitigates constraints of the components

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.

Blog

Steve’s Home Page