Introduction To Systems Engineering Practices:: Session I - Requirements

Introduction to Systems
Engineering Practices:
Session I - Requirements
John Azzolini
SEC jda: July, 2000

Essential Systems Engineering:
For Each System:

Requirements Analysis
Operations Analysis
Design Analysis
Risk Analysis
Verification Analysis
Validation
2
EIA 632, Process for the Engineering of a System: Summary
SUPPLY PROCESS REQUIREMENTS REQUIREMENTS DEFINITION REQUIREMENTS VALIDATION
1Product Supply PROCESS REQUIREMENTS PROCESS REQUIREMENTS
ACQUISITION PROCESS 14Acquirer Requirements 25Statements Validation
REQUIREMENTS 15Other Stakeholder 26Acquirer Requirements
2Product Acquisition Requirements Validation
3Supplier Performance 16System Technical 27Other Stakeholder
PLANNING PROCESS
REQUIREMENTS
Requirements Requirements
SOLUTION DEFINITION PROCESS Validation
4Process Implementation REQUIREMENTS
Strategy 28System Technical
17Logical Solution
5Technical Effort Definition Requirements
Representations
6Schedule and Organization Validation
18Physical Solution 29Logical Solution
7Technical Plans Representations
8Work Directives Representations
19Specified Requirements
ASSESSMENT PROCESS IMPLEMENTATION PROCESS
Validation
REQUIREMENTS REQUIREMENTS SYSTEM VERIFICATION PROCESS
9Progress Against Plans and 20Implementation
REQUIREMENTS
Schedules TRANSITION TO USE PROCESS
30Design Solution Verification
10Progress Against REQUIREMENTS 31End Product Verification
Requirements 21Transition to Use 32Enabling Product Readiness
SYSTEMS ANALYSIS PROCESS END PRODUCTS VALIDATION
11Technical Reviews REQUIREMENTS PROCESS REQUIREMENTS
CONTROL PROCESS
REQUIREMENTS 22Effectiveness Analysis 33End Products Validation
12Outcomes Management 23Tradeoff Analysis
13Information Dissemination 24Risk Analysis
3
System Requirements Analysis

Identification of Functional and
Performance Requirements
Allocation to Sub-elements
Development of Hierarchy
4
System Operations Analysis

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

Conceptualize and Synthesize Design
Analyze Design
Trade Studies
6
System Risk Analysis

Tight Margins
Low maturity
Tight Schedule
Cost Risk
7
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
8
System Validation
Assumptions
Requirements to Objectives
Operations Concept to Objectives
Designto Requirements and
Operations Concept
Verification Plans to Requirements
System Validation Testing
9
NPG 7120.5A Table of Contents
Chapter 1: Overview 2.3.5 Deliver Products and Services Assessments
1.1 Introduction 2.3.6 Capture Process Knowledge 3.4.2 Capture Process Knowledge
1.2 Framework 2.4 Program Evaluation Chapter 4. Program/Project Management
1.3 Themes 2.4.1 Plan and Conduct Reviews and Systems Requirements
1.4 Process Description Assessments 4.1 Resources Management
1.5 Document Structure 2.4.2 Capture Process and Knowledge 4.1.1 Financial Management
1.6 Program/Project Management Chapter 3. Project Management 4.1.2 Life-Cycle Cost (LCC) Management and
Initiative (PPMI) Process and Functional Accounting
Chapter 2. Program Requirements 4.1.3 Information Technology Management
Management Process and 3.1 Project Formulation 4.2 Risk Management
Functional Requirements 3.1.1 Project Planning 4.2.1 Purpose
2.1 Program Formulation 3.1.2 Systems Analysis 4.2.2 Requirements
2.1.1 Program Planning 3.1.3 Technology Requirements 4.3 Performance Management
2.1.2 Systems Analysis Synthesis 4.3.1 Earned Value Management (EVM
2.1.3 Technology Requirements 3.1.4 Develop Technology and 4.3.2 Performance Assessment
Synthesis Commercialization Project Plans 4.3.3 Schedule Management
2.1.4 Develop Technology and 3.1.5 Operations and Business 4.3.4 Work Breakdown Structure (WBS)
Commercialization Program Opportunities 4.3.5 Program and Project Management Process
Plans 3.1.6 Assess Infrastructure and Plan Metrics
2.1.5 Operations and Business Upgrades/Development 4.4 Acquisition Management
Opportunities 3.1.7 Capture Process Knowledge 4.4.1 Acquisition
2.1.6 Assess Infrastructure and 3.2 Project Approval 4.4.2 Identifying
Plan Upgrades/Development 3.3 Project Implementation
2.1.7 Capture Process Knowledge 3.3.1 Project Control Requirements/Strategizing Implementation
2.2 Program Approval 3.3.2 Customer Advocacy 4.4.3 Executing Contracts and Non-procurement
2.3 Program Implementation 3.3.3 Requirements Management Instruments
2.3.1 Program Control 3.3.4 Design, Develop, and Sustain 4.4.4 Monitoring Performance
2.3.2 Customer Advocacy 3.3.5 Deliver Products and Services 4.5 Safety and Mission Success, and
2.3.3 Requirements Management 3.3.6 Capture Process Knowledge Environmental Management
2.3.4 Design, Develop, and 3.4 Project Evaluation 4.5.1 Safety and Mission Success
Sustain 3.4.1 Plan and Conduct Reviews and
10
NPG 7120.5A Table of Contents (contd)
4.5.2 Nuclear Launch Safety 4.6.1 Purpose Appendix D. Responsibilities for
4.5.3 Application of Lessons Learned 4.6.2 Requirements Program and Project Management
4.5.4 Program/Project Emergency 4.6.3 PPMI Responsibilities Appendix E. Key Document Contents
Planning/Response Appendix A. References Available Via Appendix F. Independent Reviews List
4.5.5 Environmental Management NODIS of Figures and Tables
4.6 Program/Project Management Appendix B. Definitions
Development Appendix C. Acronyms
11
PART I:
REQUIREMENTS
ANALYSIS
12
Introduction and Definitions
The Requirements Analysis Process
Summary
13
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 14
Research is what I'm doing when

I don't know what I'm doing.
Attributed to Wernher Von Braun
15
A SYSTEMATIC ENGINEERING PROCESS From EIA 632
Understand customer needs and establish Requirements Definition

objectives
Develop evaluation and rating criteria Solution Definition
Determine functions to be accomplished (functional Transition To Use

analysis)
Develop concept architecture (with alternatives) Systems Analysis
Define performance requirements for each function Requirements Validation

Synthesize and iterate the designs (trade studies)
System Verification
Evaluate the designs for acceptability (validate and
verify) End Products Validation
Rate the acceptable designs and select the best
alternative
Document the selected design
16
MIL SE Handbook
Input Requirements
Functional Acceptable Evaluation
Mission Objectives
Mission Environments Synthesis and Decision
Analysis Solution
Mission Constraints (Trade-off)
Measures of Effectiveness
OR OR
Will
Technology Selection Factors Alternatives
Work?
Hardware
Software
Reliability
Maintainability
Personnel/Human Factors
Survivability
Security
Safety
Description of
Standardization System Elements
Integrated Logistics Support
EMC
System Mass Properties
Producibility
Transportability
Electronic Warfare
Computer Resources
17
NASA SE Handbook
Define / Identify The following questions

Goals / Objectives should be considered:
and Constraints Define Define
Plausible Selection Have the goals / objectives and
Alternatives Rule
Perform Functional constraints been met?
Analysis
I the tentative selection
robust?
Define measures and Collect data on

Is more analytical refinement
measurement methods for: each alternative
needed to distinguish among
to support
System effectiveness alternatives?
evaluation
System performance or by selected
technical attributes Have the subjective aspects of
measurement
System cost the problem been addressed?
methods
Compute an estimate of system effectiveness, Is

Make a Proceed to further
performance or technical attributes, and cost for tentative
tentative resolution of
each alternative selection
selection
Compute or estimate uncertainty ranges. accept- system design,
(decision)
Perform sensitivity analyses able? or to
implementation
Analytical Portion of Trade Studies 18

Recognize
Need or Principle of Successive
Opportunity Refinement
(Boehms Spiral
Development Model)
Perform
Mission
19
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
20
Requirements Validation
Requirements Specifications
Design Synthesis
Design Validation
Trades
Issues
Risks
Design Specifications
Verification Analysis
Verification Validation
Verification Plans
Baseline New Results

Update Existing Baselines
Configure
21
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
22
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.
23
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
24
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
25
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
26
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
27
"Requirements should be based on a

combination of need and capability."
Dr. Wiley J. Larson
28
FUNCTIONAL ANALYSIS
Also called functional decomposition
The process of allocating or decomposing
functions to lower system levels
Defines system functional architecture
An example:
REQUIREMENT DESCRIPTION
2.3.1 Point HGAS antenna at TDRS
2.3.1.1 Compute S/C to TDRS LOS vector
2.3.1.2 Compute required gimbal angles
2.3.1.3 Send command to gimbals
29
"When your only tool is a hammer,

every problem looks like a nail."
Bruce Pittman & Others
30
N2 chart example
Instrument Data Spacecraft
Data
Capture
Data
Archive
Operations
Console
Science
Science Results
Console
31
Data Flow Diagram Example

Valid Cmds TL Cmds
Commands Command
Capture Command Timeline
Executive
Cmd Status TL Status
Command
CC TM Executive TL Cmds Cmd Status
RT Cmds
CE TM
Telemetry CE TM
Output
CTE TM Other
Elements
Other TM
32
Control Flow Diagram Example
Interrupts
Interrupt Requests
ISR
Real Time Executive
Resume Resume Resume

Status Status Status
Suspend Suspend Suspend
Task A Task B Task N
33
Input Requirements
Flowchart Example
Functional Acceptable Evaluation
Mission Objectives
Mission Environments Synthesis and Decision
Analysis Solution
Mission Constraints (Trade-off)
Measures of Effectiveness
OR OR
Will
Technology Selection Factors Alternatives
Work?
Hardware
Software
Reliability
Maintainability
Personnel/Human Factors
Survivability
Security Description of
Safety
Standardization System Elements
Integrated Logistics Support
EMC
System Mass Properties
Produceability
Transportability
Electronic Warfare
Computer Resources
34
Understand User
Demonstrate and
Requirements, Develop
Validate System to
System Concept and
User Validation Plan
Validation Plan
Develop System Integrate System and

Performance Specification Perform System
and System Verification to
Verification Plan Performance Specification
Expand Performance Assemble CIs and Perform

Specifications Into CI CI Verification to CI
Design-to Specifications Design-to
and Inspection Plan Specifications
Evolve Design-to
Inspect to
Specifications into
Build-to
Build-to Documentation
Documentation
and Inspection Plan
Fabricate, Assemble, and

Code to Build-to
Documentation
35
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
36
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?
37
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
38
THE REQUIREMENTS GOSPEL ACCORDING TO

JOHN - Version 4 (contd)
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
39
Background Charts
RAVISH
Example: The XTE Requirements
Database
Current Practice
41
Requirements
Analysis for
Verification
In a
Structured
Hierarchy
42
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
43
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]

44
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]
45
THE XTE REQUIREMENTS DATA BASE

Spacecraft Requirements Organized
Hierarchically by:
Subsystem
Mission Operational Phase
Functional Category
Function
Performance Required
46
THE XTE REQUIREMENTS DATA BASE

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. 47
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
48
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.
49
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.
50
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
51
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>>
52

Introduction To Systems Engineering Practices:: Session I - Requirements

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To Systems Engineering Practices:: Session I - Requirements

Uploaded by

Copyright:

Available Formats

Introduction to Systems

SEC jda: July, 2000

For Each System:

System Requirements Analysis

System Operations Analysis

System Design Analysis

System Risk Analysis

System Verification Analysis

Introduction and Definitions

The Requirements Analysis Process

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

Research is what I'm doing when

Understand customer needs and establish Requirements Definition

Determine functions to be accomplished (functional Transition To Use

Define performance requirements for each function Requirements Validation

Define / Identify The following questions

Define measures and Collect data on

Compute an estimate of system effectiveness, Is

Analytical Portion of Trade Studies 18

At the end of each phase

Baseline New Results

My subsystem may be your system

A constraint is a requirement which is imposed on the system.

Reflected Requirements are requirements uncovered in the

THE REQUIREMENTS ANALYSIS PROCESS

"Requirements should be based on a

Dr. Wiley J. Larson

"When your only tool is a hammer,

Bruce Pittman & Others

Data Flow Diagram Example

Real Time Executive

Resume Resume Resume

Task A Task B Task N

Develop System Integrate System and

Expand Performance Assemble CIs and Perform

Fabricate, Assemble, and

SOME GENERAL GUIDELINES

Turn off the critic as you diverge

Work top-down - a level at a time - work for breadth rather

THE REQUIREMENTS GOSPEL ACCORDING TO

THE REQUIREMENTS GOSPEL ACCORDING TO

Verification is a bottom up process:

At integration verification becomes system level

Most work breakdown structures assign subsystem

The result is that it is most efficient to develop a requirements

RAVISH: Requirements Analysis

Allocation flow is from system to subsystem, to mission

Functional requirements are specified without performance

Performance requirements which quantify each functional

[A requirements validation walkthrough is conducted]

The verification method for each functional

THE XTE REQUIREMENTS DATA BASE

THE XTE REQUIREMENTS DATA BASE

By associating performance requirements with each functional

By grouping requirements by subsystem, each subsystem lead

By specifying requirements for each mission phase, design

By specifying the verification methods, procedures for each

By conducting walkthroughs for requirements validation,

Identify trades , risks, and issues

Identify risk mitigation efforts - prototyping, special testing, etc.

You might also like