# Presentation: 322607

## Introduction to Systems Engineering Practices:  Session I - Requirements

John Azzolini

- John Azzolini

- SEC jda:  July, 2000

## For Each System:
Requirements Analysis
Operations Analysis
Design Analysis
Risk Analysis
Verification Analysis
Validation

- Requirements Analysis
- Operations Analysis
- Design Analysis
- Risk Analysis
- Verification Analysis
- Validation

## EIA 632, Process for the Engineering of a System:  Summary

**EIA 632, *****Process for the Engineering of a System: ***** Summary**

## System Requirements Analysis

Identification of Functional and Performance Requirements

Allocation to Sub-elements

Development of Hierarchy

- Identification of Functional and Performance Requirements
- Allocation to Sub-elements
- Development of Hierarchy

## System Operations Analysis
Launch, Separation, and Deployment
In-Orbit Checkout
Science Observations
Housekeeping
First Partitioning of Functions Among Launch, Ground, and Flight Segments

- Launch, Separation, and Deployment
- In-Orbit Checkout
- Science Observations
- Housekeeping
- First Partitioning of Functions Among Launch, Ground, and Flight Segments

- System Design Analysis
- Conceptualize and Synthesize Design
- Analyze Design
- Trade Studies

## System Risk Analysis
Tight Margins
Low maturity
Tight Schedule
Cost Risk

- Tight Margins
- Low maturity
- Tight Schedule
- Cost Risk

## System Verification Analysis
Identify Verification Methods
Identify Verification Levels
Identify Verification BTE and GSE
Develop Verification Procedures
Validate Methods, Levels, Procedures, and BTE and GSE

- Identify Verification Methods
- Identify Verification Levels
- Identify Verification BTE and GSE
- Develop Verification Procedures
- Validate Methods, Levels, Procedures, and BTE and GSE

## System Validation
Assumptions
Requirements to Objectives
Operations Concept to Objectives
Design to Requirements and Operations Concept
Verification Plans to Requirements
System Validation Testing

- Assumptions
- Requirements to Objectives
- Operations Concept to Objectives
- Design to Requirements and Operations Concept
- Verification Plans to Requirements
- System Validation Testing

## NPG 7120.5A Table of Contents

**NPG 7120.5A Table of Contents**

## NPG 7120.5A Table of Contents (cont’d)

**NPG 7120.5A Table of Contents (cont’d)**

## PART I:

REQUIREMENTS ANALYSIS

- REQUIREMENTS ANALYSIS

## Introduction and Definitions

The Requirements Analysis Process

Summary

- The Requirements Analysis Process
- Summary

- Requirements Analysis

## An engineer doesn't know what he's doing until a REQUIREMENT has been agreed to
You can't do a job without a PLAN
A professional makes a COMMITMENT to meet the Requirements Analysis within his planned resources
If you can't demonstrate TRACEABILITY from your plan to where you are, you're trying to fool the public

A. Thomas Young

- You can't do a job without a PLAN
- A professional makes a COMMITMENT to meet the Requirements Analysis within his planned resources
- If you can't demonstrate TRACEABILITY from your plan to where you are, you're trying to fool the public
- A. Thomas Young

- Requirements Analysis

## 
“Research is what I'm doing when I don't know what I'm doing.”

Attributed to Wernher Von Braun

- “Research is what I'm doing when I don't know what I'm doing.”
- Attributed to Wernher Von Braun

- Requirements Analysis

## Understand customer needs and establish objectives

Develop evaluation and rating criteria

Determine functions to be accomplished (functional analysis)

Develop concept architecture (with alternatives)

Define performance requirements for each function

Synthesize and iterate the designs (trade studies)

Evaluate the designs for acceptability (validate and verify)

Rate the acceptable designs and select the best alternative

Document the selected design

- Develop evaluation and rating criteria
- Determine functions to be accomplished (functional analysis)
- Develop concept architecture (with alternatives)
- Define performance requirements for each function
- Synthesize and iterate the designs (trade studies)
- Evaluate the designs for acceptability (validate and verify)
- Rate the acceptable designs and select the best alternative
- Document the selected design

**A SYSTEMATIC ENGINEERING PROCESS**

**Requirements Definition**
**Solution Definition **
**Transition To Use **
**Systems Analysis **
**Requirements Validation**
**System Verification **
**End Products Validation**

**From EIA 632**

- Requirements Analysis

## Requirements Analysis

## Requirements Analysis

**Plausible **
**Alternatives**

**NASA SE Handbook**

**Compute an estimate of system effectiveness,**
**	****performance or technical attributes, and cost for **
**	****each alternative**
**Compute or estimate uncertainty ranges.**
**Perform sensitivity analyses**

**Perform Functional**
**Analysis**

**Define**
**Selection**
**Rule**

**The following questions **
**should be considered:**
**Have the goals / objectives and**
**	****constraints been met?**
**I the tentative selection**
**	****robust?**
**Is more analytical refinement**
**	****needed to distinguish among**
**	****alternatives?**
**Have the subjective aspects of**
**	****the problem been addressed?**

**Define measures and**
**measurement methods for:**
**System effectiveness**
**System performance or**
**	****technical attributes**
**System cost**

**Collect data on**
**each alternative**
**to support**
**evaluation**
**by selected**
**measurement**
**methods**

**Make a**
**tentative**
**selection**
**(decision)**

**Proceed to further**
**resolution of**
**system design, **
**or to**
**implementation**

**Is **
**tentative **
**selection **
**accept-**
**able?**

**Define / Identify **
**Goals / Objectives**
**and Constraints**

**Analytical Portion of Trade Studies**

## Requirements Analysis

**Quantify Goals**

**Create**
**Concepts**

**Do Trade**
**Studies**

**Select**
**Design**

**Increase**
**Resolution**

**Increase**
**Resolution**

**Increase**
**Resolution**

- Implementation Decisions

**Identify and**
**Quantify Goals**

**Identify and**
**Quantify Goals**

**Create**
**Concepts**

**Create**
**Concepts**

**Do Trade**
**Studies**

**Do Trade**
**Studies**

**Select**
**Design**

**Select**
**Design**

**Recognize**
**Need or**
**Opportunity**

**Perform**
**Mission**

**Principle of Successive**
**Refinement**
**(Boehm’s Spiral**
**Development Model)**

## At each stage
Document the results
Identify trade studies
Identify risks
Identify issues
Prioritize and work trade studies, risks, and issues
Iterate

At the end of each phase
Baseline the new results
Update existing baselines
Put into configuration management

- Document the results
- Identify trade studies
- Identify risks
- Identify issues
- Prioritize and work trade studies, risks, and issues
- Iterate
- At the end of each phase
- Baseline the new results
- Update existing baselines
- Put into configuration management

- Requirements Analysis

## Requirements Analysis

## A SYSTEM
The solution to a problem in the full context of its environment over its useful life - B. Pittman
The entirety needed to meet a defined set of requirements - Code 700 SE Implementation Plan

My subsystem may be your system

- The solution to a problem in the full context of its environment over its useful life - B. Pittman
- The entirety needed to meet a defined set of requirements - Code 700 SE Implementation Plan
- My subsystem may be your system

- Requirements Analysis

## DEFINITIONS
A system is defined by a set of objectives
System objectives are a set of goals and constraints that define the success of the system.  These include what the system must accomplish, the system lifetime, the environment in which the system must perform, and cost, schedule, legal, and mandated constraints.  
A successful system is one which meets the set of objectives.
Functional Requirements define what functions the system must perform to be successful
Performance Requirements define how well the system must perform these functions to be successful
Assumptions are derived objectives which are defined in order to proceed with the development process.  Generally, assumptions define a subspace of the solution space.

- A *system* is defined by a set of *objectives*
- System *objectives* are a set of *goals* and *constraints* that define the success of the system.  These include what the system must accomplish, the system lifetime, the environment in which the system must perform, and cost, schedule, legal, and mandated constraints.
- A *successful** **system** *is one which meets the set of objectives.
*Functional Requirements *define what functions the system must perform to be successful
*Performance Requirements *define how well the system must perform these functions to be successful
*Assumptions* are derived objectives which are defined in order to proceed with the development process.  Generally, assumptions define a subspace of the solution space.

- Requirements Analysis

## A constraint is a requirement which is imposed on the system.
An Operations Concept is a set of plans and requirements defining the manner in which the system will be operated.  This includes operations activities, facilities, equipment, commanding and data collection, and staffing.  The operations concept evolves into operations plans and procedures.  
A Validation Basis is a set of functional and performance requirements which define the success of a system element.  In the case of the full system, the validation basis is the set of objectives.  
All requirements can be type classified as functional, or performance, however, it is sometimes useful to think in terms of requirements categories

- An *Operations Concept *is a set of plans and requirements defining the manner in which the system will be operated.  This includes operations activities, facilities, equipment, commanding and data collection, and staffing.  The operations concept evolves into operations plans and procedures.
- A *Validation Basis *is a set of functional and performance requirements which define the success of a system element.  In the case of the full system, the validation basis is the set of objectives.
- All requirements can be type classified as functional, or performance, however, it is sometimes useful to think in terms of requirements *categories*

- Requirements Analysis

## REQUIREMENTS CATEGORIES
Level I Requirements are the top level requirements agreed to by NASA Headquarters and the developing installation to define mission success
Operational Requirements define how users and operators interact with the system and its command and data products
Apportioned Requirements are requirements which are quantitatively distributed to lower levels and for which the units of measure remain unchanged
Derived Requirements are requirements defined by the decomposition of higher level requirements for which the units of measure may change

*Level I Requirements *are the top level requirements agreed to by NASA Headquarters and the developing installation to define mission success
*Operational Requirements *define how users and operators interact with the system and its command and data products
*Apportioned Requirements *are requirements which are quantitatively distributed to lower levels and for which the units of measure remain unchanged
*Derived Requirements *are requirements defined by the decomposition of higher level requirements for which the units of measure may change

- Requirements Analysis

## Reflected Requirements are requirements uncovered in the Requirements analysis process that another subsystem or element must meet
Interface Requirements are requirements which specify details of the command, data, electrical, thermal, and mechanical characteristics at the boundaries of a subsystem or element
Environmental Requirements are requirements which are defined in order for the system to meet the test, transport, launch, ascent, and on-orbit environments
Design Requirements are requirements which define the standards and guidelines which a particular design must adhere to
Programmatic Requirements include fault tolerance, risk, cost, schedule and other resource constraints

*Interface Requirements *are requirements which specify details of the command, data, electrical, thermal, and mechanical characteristics at the boundaries of a subsystem or element
*Environmental Requirements *are requirements which are defined in order for the system to meet the test, transport, launch, ascent, and on-orbit environments
*Design Requirements *are requirements which define the standards and guidelines which a particular design must adhere to
*Programmatic Requirements *include fault tolerance, risk, cost, schedule and other resource constraints

- Requirements Analysis

## THE REQUIREMENTS ANALYSIS PROCESS
Requirements Analysis is a part of systems engineering
Everyone has systems engineering responsibilities
A system of any complexity will always require many iterations

- Requirements Analysis is a part of systems engineering
- Everyone has systems engineering responsibilities
- A system of any complexity will always require many iterations

- Requirements Analysis

## 

"Requirements should be based on a combination of need and capability."

Dr. Wiley J. Larson

- "Requirements should be based on a combination of need and capability."
- Dr. Wiley J. Larson

- Requirements Analysis

## FUNCTIONAL ANALYSIS
Also called functional decomposition
The process of allocating or decomposing functions to lower system levels
Defines system functional architecture
An example:

- Also called functional decomposition
- The process of allocating or decomposing functions to lower system levels
- Defines system functional architecture
- An example:

- Requirements Analysis

## 

"When your only tool is a hammer,
every problem looks like a nail."

Bruce Pittman & Others

- "When your only tool is a hammer,
- every problem looks like a nail."
- Bruce Pittman & Others

- Requirements Analysis

## Requirements Analysis

- Spacecraft

- Data
- Capture

- Data
- Archive

- Science
- Console

- Instrument  Data

- Science Results

## Requirements Analysis

## Requirements Analysis

- Real Time Executive

- Task A

- Task B

- Task N

- Interrupts

- Interrupt Requests

- Resume
- Suspend

- Resume
- Suspend

- Resume
- Suspend

- Status

- Status

- Status

## Requirements Analysis

## Requirements Analysis

- Decomposition &
- Definition Sequence

- Integration and
- Verification Sequence

**Understand User**
**Requirements, Develop**
**System Concept and**
**Validation Plan**

**Demonstrate and**
**Validate System to**
**User Validation Plan**

**Develop System**
**Performance Specification**
**and System**
**Verification Plan**

**Expand Performance**
**Specifications Into CI**
**“****Design-to” Specifications**
**and Inspection Plan**

**Evolve “Design-to”**
**Specifications into**
**“****Build-to” Documentation**
** ****and Inspection Plan**

**Integrate System and**
**Perform System**
**Verification  to**
**Performance Specification**

**Assemble CIs and Perform**
**CI Verification to CI**
**“****Design-to”**
**Specifications**

**Inspect to**
**“****Build-to”**
**Documentation**

**Fabricate, Assemble, and**
**Code to “Build-to”**
**Documentation**

## DESIGN MARGINS
An integral part of the requirements analysis and design synthesis process
Proper margins minimize risk
Reduce the impact of requirements changes
Allow the balancing of allocations between subsystems and subsystem elements
Margin levels (percentages) may be reduced as the design matures
Robustness is the capability of a design to meet functional and performance requirements as the environment or design parameters change
Flexibility is the ability of the design to adapt to failures, modeling inadequacies,  changes in requirements , or operational changes

- An integral part of the requirements analysis and design synthesis process
- Proper margins minimize risk
- Reduce the impact of requirements changes
- Allow the balancing of allocations between subsystems and subsystem elements
- Margin levels (percentages) may be reduced as the design matures
*Robustness* is the capability of a design to meet functional and performance requirements as the environment or design parameters change
*Flexibility* is the ability of the design to adapt to failures, modeling inadequacies,  changes in requirements , or operational changes

- Requirements Analysis

## SOME GENERAL GUIDELINES
Look one level up in the hierarchy to clearly understand the objectives, constraints, and environment of your system
Use creative thinking processes
First diverge then converge
Turn off the critic as you diverge
Work top-down - a level at a time - work for breadth rather than depth at each iteration
Do not ignore standard assemblies, components, subsystems, etc. - Do not force fit either
Take a step back occasionally to consider how the system "feels" - can you envision it meeting its objectives, or is the feeling discordant?

- Look one level up in the hierarchy to clearly understand the objectives, constraints, and environment of your system
- Use creative thinking processes
- First diverge then converge
- Turn off the critic as you diverge
- Work top-down - a level at a time - work for breadth rather than depth at each iteration
- Do not ignore standard assemblies, components, subsystems, etc. - Do not force fit either
- Take a step back occasionally to consider how the system "feels" - can you envision it meeting its objectives, or is the feeling discordant?

- Requirements Analysis

## THE REQUIREMENTS GOSPEL ACCORDING TO JOHN - Version 4
A SYSTEM is defined by a set of OBJECTIVES, its environment, its useful life, and its constraints
A system cannot be VALIDATED until the objectives are defined by a set of measurable SYSTEM (FUNCTIONAL AND PERFORMANCE) REQUIREMENTS
System requirements are ALLOCATED and DECOMPOSED  to define lower level requirements
Confirm the TRACEABILITY of lower level requirements to system requirements

- A SYSTEM is defined by a set of OBJECTIVES, its environment, its useful life, and its constraints
- A system cannot be VALIDATED until the objectives are defined by a set of measurable SYSTEM (FUNCTIONAL AND PERFORMANCE) REQUIREMENTS
- System requirements are ALLOCATED and DECOMPOSED  to define lower level requirements
- Confirm the TRACEABILITY of lower level requirements to system requirements

- Requirements Analysis

## THE REQUIREMENTS GOSPEL ACCORDING TO JOHN - Version 4 (cont’d)
A system is VERIFIED when it is shown to meet all requirements
A system is VALIDATED when its requirements are shown to satisfy all objectives and its design is shown to satisfy all requirements
If lower level requirements are not traceable (ORPHAN requirements), then the system being built is not JUSTIFIED 
If system requirements are not allocated (UNALLOCATED requirements), then the system being built is not VALID

- A system is VERIFIED when it is shown to meet all requirements
- A system is VALIDATED when its requirements are shown to satisfy all objectives and its design is shown to satisfy all requirements
- If lower level requirements are not traceable (ORPHAN requirements), then the system being built is not JUSTIFIED
- If system requirements are not allocated (UNALLOCATED requirements), then the system being built is not VALID

- Requirements Analysis

## Slide 40

## Background Charts

**RAVISH**
**Example:  The XTE Requirements Database**
**Current Practice**

## Requirements
Analysis for
Verification
 In a
Structured
Hierarchy

- Analysis for
- Verification
-  In a
- Structured
- Hierarchy

- Requirements Analysis

## RAVISH:  Motivation
Design is a top-down process:
	Functional allocation flows from mission to system to subsystem to assembly, to component

Verification is a bottom up process:
	Verification flows from component to assembly to subsystem to system

At integration verification becomes system level

Most work breakdown structures assign subsystem responsibility to a single subsystem lead (or manager)

The result is that it is most efficient to develop a requirements hierarchy which reflects the WBS hierarchy

- Design is a top-down process:
- 	Functional allocation flows from mission to system to subsystem to assembly, to component
- Verification is a bottom up process:
- 	Verification flows from component to assembly to subsystem to system
- At integration verification becomes system level
- Most work breakdown structures assign subsystem responsibility to a single subsystem lead (or manager)
- The result is that it is most efficient to develop a requirements hierarchy which reflects the WBS hierarchy

- Requirements Analysis

## RAVISH:  Requirements Analysis methodology consists of:
A strict top-down allocation of requirements

Allocation flow is from system to subsystem, to mission phase, to functional category, to function, to performance specification

Functional requirements are specified without performance numbers using a single simple sentence for each

Performance requirements which quantify each functional requirement are attached to the functional requirement

[A requirements validation walkthrough is conducted]

- A strict top-down allocation of requirements
- Allocation flow is from system to subsystem, to mission phase, to functional category, to function, to performance specification
- Functional requirements are specified without performance numbers using a single simple sentence for each
- Performance requirements which quantify each functional requirement are attached to the functional requirement
- [A requirements validation walkthrough is conducted]

- Requirements Analysis

## The verification method for each functional and performance requirement is specified
[A requirements verification methods walkthrough is conducted]
The verification procedure for each functional and performance requirement is specified
[A verification specification walkthrough is conducted]

- [A requirements verification methods walkthrough is conducted]
- The verification procedure for each functional and performance requirement is specified
- [A verification specification walkthrough is conducted]

- Requirements Analysis

## Requirements Analysis

- Spacecraft Requirements Organized Hierarchically by:
-   Subsystem
-   Mission Operational Phase
-   Functional Category
-   Function
-   Performance Required

## Requirements Analysis

- An Example:
-  First Level:  System:  01:  XTE Spacecraft
-  Second Level:  Subsystem:  08:  Mechanical
-  Third Level:  Mission Phase:  00:  General
-  Forth level:  Functional Category:  01:  Design
-  Fifth Level:  Function:  01:  Strength
-  Sixth level:  Performance:  01:  Limit Loads		Safety Factor
- “An ultimate factor of safety of 1.4 on limit loads shall
- be used for design requirements.”

## RATIONALE FOR RAVISH METHODOLOGY
By making each functional requirement separate from its associated performance requirements, functional validation of the requirements is simplified.  (Associatively)

By associating performance requirements with each functional requirement, the items which are needed to verify the functional requirement are clearly identified as a group.  (Modularity)

By grouping requirements by subsystem, each subsystem lead has a definitive set of system level requirements which drives the design.  (Clarity)
The fundamental functional and performance requirements for the subsystem are known
This provides each subsystem with a validation basis

- By making each functional requirement separate from its associated performance requirements, functional validation of the requirements is simplified.  (*Associatively*)
- By associating performance requirements with each functional requirement, the items which are needed to verify the functional requirement are clearly identified as a group.  (*Modularity*)
- By grouping requirements by subsystem, each subsystem lead has a definitive set of system level requirements which drives the design.  (*Clarity*)
- The fundamental functional and performance requirements for the subsystem are known
- This provides each subsystem with a validation basis

- Requirements Analysis

## By specifying requirements for each mission phase, design consideration is given to each phase equally.  This avoids "band-aid" approaches to providing the functionality required.  (Uniformity)

By specifying the verification methods, procedures for each requirement, early identification of special verification tasks, equipment, and facilities is provided.  (Verifiability)

By conducting walkthroughs for requirements validation, verification methods, and verification procedures, the quality (correctness and completeness) of the process is ensured.

- By specifying the verification methods, procedures for each requirement, early identification of special verification tasks, equipment, and facilities is provided.  (*Verifiability*)
- By conducting walkthroughs for requirements validation, verification methods, and verification procedures, the quality (*correctness and completeness*) of the process is ensured.

- Requirements Analysis

## REQUIREMENTS VALIDATION WALKTHROUGH
Identify and correct
Unallocated system requirements
Orphan requirements

Validate
From the bottom up ensure that all top level requirements (objectives, constraints, environment, and lifetime) are being met

Establish margins

Identify trades , risks, and issues
Identify and prioritize trade studies
Identify risk mitigation efforts - prototyping, special testing, etc.

- Identify and correct
- Unallocated system requirements
- Orphan requirements
- Validate
- From the bottom up ensure that all top level requirements (objectives, constraints, environment, and lifetime) are being met
- Establish margins
- Identify trades , risks, and issues
- Identify and prioritize trade studies
- Identify risk mitigation efforts - prototyping, special testing, etc.

- Requirements Analysis

## Current Practice

- The Operational Phase level has been eliminated.  It proved to be cumbersome.
- For early iterations only 3 levels are often needed
- Commercial tools like DOORS and SLATE are increasingly being used at NASA

- Requirements Analysis

## SUGGESTED READING:
Center for Systems Management, “PPMI SYSTEMS ENGINEERING”, Course materials
Pittman & Associates, “DYNAMIC SYSTEM ENGINEERING”, Course materials
Shisko & Chamberlain, NASA SYSTEMS ENGINEERING HANDBOOK, Draft, September 1992
Wertz & Larson, SPACE MISSION ANALYSIS AND DESIGN
Azzolini, John, Essential Systems Engineering:  A Life-cycle Process, 5th Annual Symposium of NCOSE, 1995
Martin, James N., Overview of the EIA 632 Standard - “Processes for Engineering a System”
NPG 7120.5A <<http://nodis.hq.nasa.gov/Library/ Directives/ NASA-IDE/Procedures/ Program_Formulation/ N_PG_7120_5A.html>>

- Center for Systems Management, “*PPMI SYSTEMS ENGINEERING*”, Course materials
- Pittman & Associates, “*DYNAMIC SYSTEM ENGINEERING*”, Course materials
- Shisko & Chamberlain, *NASA SYSTEMS ENGINEERING HANDBOOK*, Draft, September 1992
- Wertz & Larson, *SPACE MISSION ANALYSIS AND DESIGN*
- Azzolini, John*, Essential Systems Engineering:  A Life-cycle Process*, 5th Annual Symposium of NCOSE, 1995
- Martin, James N., *Overview of the EIA 632 Standard - “Processes for Engineering a System”*
- NPG 7120.5A <<http://nodis.hq.nasa.gov/Library/ Directives/ NASA-IDE/Procedures/ Program_Formulation/ N_PG_7120_5A.html>>

- Requirements Analysis