000712_azzolini

7/22/2019 000712_Azzolini

1/52

Introduction to SystemsEngineering Practices:

Session I - Requirements

John Azzolini

SEC jda: July, 2000

7/22/2019 000712_Azzolini

2/52

Essential Systems Engineering:

2

For Each System:

Requirements Analysis

Operations Analysis

Design Analysis

Risk Analysis

Verification Analysis

Validation

7/22/2019 000712_Azzolini

3/52


3

SUPPLY PROCESS REQUIREMENTS

1Product SupplyACQUISITION PROCESS

REQUIREMENTS

2Product Acquisition

3Supplier PerformancePLANNING PROCESS

REQUIREMENTS

4Process ImplementationStrategy

5Technical Effort Definition6Schedule and Organization

7Technical Plans

8Work DirectivesASSESSMENT PROCESS

REQUIREMENTS

9Progress Against Plans and

Schedules10Progress Against

Requirements

11Technical ReviewsCONTROL PROCESS

REQUIREMENTS

12Outcomes Management

13Information Dissemination

REQUIREMENTS DEFINITION

PROCESS REQUIREMENTS

14Acquirer Requirements

15Other Stakeholder

Requirements16System Technical

Requirements

SOLUTION DEFINITION PROCESSREQUIREMENTS

17Logical Solution

Representations

18Physical SolutionRepresentations

19Specified RequirementsIMPLEMENTATION PROCESS

REQUIREMENTS

20ImplementationTRANSITION TO USE PROCESSREQUIREMENTS

21Transition to UseSYSTEMS ANALYSIS PROCESS

REQUIREMENTS

22Effectiveness Analysis

23Tradeoff Analysis24Risk Analysis

REQUIREMENTS VALIDATION


25Statements Validation

26Acquirer Requirements

Validation27Other Stakeholder

Requirements

Validation28System Technical

Requirements

Validation29Logical Solution

Representations

ValidationSYSTEM VERIFICATION PROCESS

REQUIREMENTS

30Design Solution Verification31End Product Verification32Enabling Product ReadinessEND PRODUCTS VALIDATION


33End Products Validation

EIA 632, Process for the Engineer ing of a System: Summary

7/22/2019 000712_Azzolini

4/52


4

System Requirements Analysis

Identification of Functional andPerformance Requirements

Allocation to Sub-elements

Development of Hierarchy

7/22/2019 000712_Azzolini

5/52


5

System Operations Analysis

Launch, Separation, and Deployment

In-Orbit Checkout

Science Observations

HousekeepingFirst Partitioning of Functions Among

Launch, Ground, and Flight Segments

7/22/2019 000712_Azzolini

6/52


6

System Design Analysis

Conceptualize and Synthesize Design

Analyze Design

Trade Studies

7/22/2019 000712_Azzolini

7/52


7

System Risk Analysis

Tight Margins

Low maturity

Tight Schedule

Cost Risk

7/22/2019 000712_Azzolini

8/52


8

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

7/22/2019 000712_Azzolini

9/52


9

System ValidationAssumptions

Requirements to Objectives

Operations Concept to Objectives

Design to Requirements and Operations

Concept

Verification Plans to Requirements

System Validation Testing

7/22/2019 000712_Azzolini

10/52


10

Chapter 1: Overview

1.1 Introduction1.2 Framework

1.3 Themes

1.4 Process Description

1.5 Document Structure1.6 Program/Project Management

Initiative (PPMI)

Chapter 2. Program

Management Process and

Functional Requirements

2.1 Program Formulation2.1.1 Program Planning

2.1.2 Systems Analysis2.1.3 Technology Requirements

Synthesis2.1.4 Develop Technology and

Commercialization ProgramPlans

2.1.5 Operations and BusinessOpportunities

2.1.6 Assess Infrastructure and

Plan Upgrades/Development

2.1.7 Capture Process Knowledge

2.2 Program Approval

2.3 Program Implementation

2.3.1 Program Control

2.3.2 Customer Advocacy2.3.3 Requirements Management

2.3.4 Design, Develop, and

Sustain

2.3.5 Deliver Products and Services

2.3.6 Capture Process Knowledge2.4 Program Evaluation

2.4.1 Plan and Conduct Reviews and

Assessments

2.4.2 Capture Process and Knowledge

Chapter 3. Project Management

Process and Functional

Requirements

3.1 Project Formulation3.1.1 Project Planning

3.1.2 Systems Analysis3.1.3 Technology Requirements

Synthesis3.1.4 Develop Technology and

Commercialization Project Plans3.1.5 Operations and Business

Opportunities3.1.6 Assess Infrastructure and Plan

Upgrades/Development3.1.7 Capture Process Knowledge

3.2 Project Approval

3.3 Project Implementation

3.3.1 Project Control3.3.2 Customer Advocacy

3.3.3 Requirements Management

3.3.4 Design, Develop, and Sustain

3.3.5 Deliver Products and Services3.3.6 Capture Process Knowledge

3.4 Project Evaluation

3.4.1 Plan and Conduct Reviews and

Assessments

3.4.2 Capture Process KnowledgeChapter 4. Program/Project Management

Systems Requirements

4.1 Resources Management

4.1.1 Financial Management4.1.2 Life-Cycle Cost (LCC) Management and

Accounting4.1.3 Information Technology Management

4.2 Risk Management4.2.1 Purpose

4.2.2 Requirements4.3 Performance Management

4.3.1 Earned Value Management (EVM4.3.2 Performance Assessment

4.3.3 Schedule Management4.3.4 Work Breakdown Structure (WBS)

4.3.5 Program and Project Management ProcessMetrics

4.4 Acquisition Management

4.4.1 Acquisition

4.4.2 Identifying

Requirements/Strategizing Implementation4.4.3 Executing Contracts and Non-procurement

Instruments

4.4.4 Monitoring Performance

4.5 Safety and Mission Success, and

Environmental Management

4.5.1 Safety and Mission Success

NPG 7120.5A Table of Contents

7/22/2019 000712_Azzolini

11/52


11

4.5.2 Nuclear Launch Safety

4.5.3 Application of Lessons Learned4.5.4 Program/Project Emergency

Planning/Response4.5.5 Environmental Management

4.6 Program/Project Management

Development

4.6.1 Purpose

4.6.2 Requirements4.6.3 PPMI Responsibilities

Appendix A. References Available ViaNODIS

Appendix B. DefinitionsAppendix C. Acronyms

Appendix D. Responsibilities for

Program and Project ManagementAppendix E. Key Document Contents

Appendix F. Independent Reviews Listof Figures and Tables

NPG 7120.5A Table of Contents (contd)

7/22/2019 000712_Azzolini

12/52


12

PART I:

REQUIREMENTSANALYSIS

7/22/2019 000712_Azzolini

13/52


13

Introduction and Definitions

The Requirements Analysis Process

Summary


7/22/2019 000712_Azzolini

14/52


14

An engineer doesn't know what he's doing until a

REQUIREMENThas been agreed to

You can't do a job without a PLAN

A professional makes a COMMITMENTto meet the

Requirements Analysis within his planned resources

If you can't demonstrate TRACEABILITYfrom your

plan to where you are, you're trying to fool the public

A. Thomas Young


7/22/2019 000712_Azzolini

15/52


15

Research is what I'm doing when I

don't know what I'm doing.

Attributed to Wernher Von Braun


7/22/2019 000712_Azzolini

16/52


16

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

Rate the acceptable designs and select the bestalternative

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


7/22/2019 000712_Azzolini

17/52


17

MIL SEHandbookInput Requirements

Mission Objectives

Mission Environments

Mission Constraints

Measures of Effectiveness

Functional

AnalysisSynthesis

Description of

System Elements

Evaluation

and Decision

(Trade-off)

Acceptable

Solution

Will

Alternatives

Work?Technology Selection Factors

Hardware

Software

Reliability

Maintainability

Personnel/Human FactorsSurvivability

Security

Safety

Standardization

Integrated Logistics Support

EMC

System Mass Properties

Producibility

Transportability

Electronic Warfare

Computer Resources

OR OR


7/22/2019 000712_Azzolini

18/52


18

Define

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 selectionrobust?

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


7/22/2019 000712_Azzolini

19/52


19

RecognizeNeed or

Opportunity

Perform

Mission

Principle of Successive

Refinement

(Boehms Spiral

Development Model)


7/22/2019 000712_Azzolini

20/52


20

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


7/22/2019 000712_Azzolini

21/52


21

Trades

Risks

Issues


Requirements Validation

Verification Analysis

Verification Validation

Design Synthesis

Design Validation

Requirements Specifications

Design Specifications

Verification Plans

Baseline New Results

Update Existing Baselines

Configure


7/22/2019 000712_Azzolini

22/52


22

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


7/22/2019 000712_Azzolini

23/52


23

DEFINITIONS A systemis defined by a set of objectives

System objectivesare a set of goalsand constraintsthat define the

success of the system. These include what the system must

accomplish, the system lifetime, the environment in which thesystem must perform, and cost, schedule, legal, and mandated

constraints.

A successfulsystemis 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

Assumptionsare derived objectives which are defined in order to

proceed with the development process. Generally, assumptions

define a subspace of the solution space.


7/22/2019 000712_Azzolini

24/52


24

A constraintis 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 intooperations 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


7/22/2019 000712_Azzolini

25/52


25

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


7/22/2019 000712_Azzolini

26/52


26

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 mechanicalcharacteristics 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 standardsand guidelines which a particular design must adhere to

Programmatic Requirements include fault tolerance, risk, cost,

schedule and other resource constraints


7/22/2019 000712_Azzolini

27/52


27

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


7/22/2019 000712_Azzolini

28/52


28

"Requirements should be based on a

combination of need and capability."

Dr. Wiley J. Larson


7/22/2019 000712_Azzolini

29/52


29

FUNCTIONAL ANALYSISAlso called functional decomposition

The process of allocating or decomposingfunctions to lower system levels

Defines system functional architecture

An example:

REQUIREMENT DESCRIPTION2.3.1 Point HGAS antenna at TDRS

2.3.1.1 Compute S/C to TDRS LOS vec tor

2.3.1.2 Compute required gimbal angles

2.3.1.3 Send command to g imbals


7/22/2019 000712_Azzolini

30/52


30

"When your only tool is a hammer,

every problem looks like a nail."

Bruce Pittman & Others


7/22/2019 000712_Azzolini

31/52


31

N2 chart exampleSpacecraft

Data

Capture

Data

Archive

Operations

Console

Science

Console

Instrument Data

Science Results


7/22/2019 000712_Azzolini

32/52


32

Data Flow Diagram Example

Commands Command

Capture Command Timeline

Executive

CC TM

CTE TM

CE TM

Valid Cmds TL Cmds

CE TM

Cmd Status TL Status

Telemetry

Output

Command

ExecutiveRT Cmds

Cmd StatusTL Cmds

Other TM

Other

Elements


7/22/2019 000712_Azzolini

33/52


33

Control Flow Diagram Example

Real Time Executive

Task A Task B Task N

ISR

InterruptsInterrupt Requests

Resume

Suspend

Resume

Suspend

Resume

SuspendStatus Status Status


7/22/2019 000712_Azzolini

34/52


34

Flowchart ExampleInput Requirements

Mission Objectives

Mission Environments

Mission Constraints

Measures of Effectiveness

Functional

AnalysisSynthesis

Description of

System Elements

Evaluation

and Decision

(Trade-off)

Acceptable

Solution

Will

Alternatives

Work?Technology Selection Factors

Hardware

Software

Reliability

Maintainability

Personnel/Human FactorsSurvivability

Security

Safety

Standardization

Integrated Logistics Support

EMC

System Mass Properties

Produceability

Transportability

Electronic Warfare

Computer Resources

OR OR


7/22/2019 000712_Azzolini

35/52


35

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 Documentationand 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-toDocumentation

Fabricate, Assemble, and

Code to Build-to

Documentation


7/22/2019 000712_Azzolini

36/52


36

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

Robustnessis the capability of a design to meet functional and

performance requirements as the environment or design parameterschange

Flexibilityis the ability of the design to adapt to failures, modeling

inadequacies, changes in requirements , or operational changes


7/22/2019 000712_Azzolini

37/52


37

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?


7/22/2019 000712_Azzolini

38/52


38

THE REQUIREMENTS GOSPEL ACCORDING TO

JOHN - Version 4

A SYSTEMis defined by a set of OBJECTIVES, its environment, its

useful life, and its constraints

A system cannot be VALIDATEDuntil the objectives are defined by a

set of measurable SYSTEM(FUNCTIONAL AND PERFORMANCE)

REQUIREMENTS

System requirements areALLOCATEDand DECOMPOSED to define

lower level requirements

Confirm the TRACEABILITYof lower level requirements to system

requirements


7/22/2019 000712_Azzolini

39/52


39

THE REQUIREMENTS GOSPEL ACCORDING TO

JOHN - Version 4 (contd)

A system is VERIFIEDwhen it is shown to meet all requirements

A system is VALIDATEDwhen 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


7/22/2019 000712_Azzolini

40/52

7/22/2019 000712_Azzolini

41/52


41

Background Charts RAVISH

Example: The XTE Requirements

Database

Current Practice

7/22/2019 000712_Azzolini

42/52


42

Requirements

Analysis forVerification

In a

Structured

Hierarchy


7/22/2019 000712_Azzolini

43/52


43

RAVISH: Motivation Design is a top-down process:

Functional allocation flows from mission to system to subsystem toassembly, to component

Verification is a bottom up process:

Verification flows from component to assembly to subsystem tosystem

At integration verification becomes system level

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

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


7/22/2019 000712_Azzolini

44/52


44

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]


7/22/2019 000712_Azzolini

45/52


45

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 isconducted]


7/22/2019 000712_Azzolini

46/52


46

THE XTE REQUIREMENTS DATA BASE

Spacecraft Requirements Organized

Hierarchically by: Subsystem

Mission Operational Phase

Functional Category

Function

Performance Required


7/22/2019 000712_Azzolini

47/52


47

THE XTE REQUIREMENTS DATA BASEAn 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.


7/22/2019 000712_Azzolini

48/52


48

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


7/22/2019 000712_Azzolini

49/52


49

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 andcompleteness) of the process is ensured.


7/22/2019 000712_Azzolini

50/52


50

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.


7/22/2019 000712_Azzolini

51/52


51

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


7/22/2019 000712_Azzolini

52/52


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 - Processesfor Engineering a System

NPG 7120.5A


000712_azzolini

Documents