Azzolini

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
Essential Systems Engineering:

EIA 632, Process for the Engineering of a System: Summary
SUPPLY PROCESS REQUIREMENTS
1Product Supply
ACQUISITION PROCESS REQUIREMENTS
REQUIREMENTS DEFINITION PROCESS REQUIREMENTS
2Product Acquisition 3Supplier Performance

PLANNING PROCESS REQUIREMENTS
14Acquirer Requirements 15Other Stakeholder Requirements 16System Technical Requirements

SOLUTION DEFINITION PROCESS REQUIREMENTS
REQUIREMENTS VALIDATION PROCESS REQUIREMENTS
4Process Implementation Strategy 5Technical Effort Definition 6Schedule and Organization 7Technical Plans 8Work Directives
ASSESSMENT PROCESS REQUIREMENTS
17Logical Solution Representations 18Physical Solution Representations 19Specified Requirements

IMPLEMENTATION PROCESS REQUIREMENTS
25Statements Validation 26Acquirer Requirements Validation 27Other Stakeholder Requirements Validation 28System Technical Requirements Validation 29Logical Solution Representations Validation
9Progress Against Plans and Schedules 10Progress Against Requirements 11Technical Reviews
CONTROL PROCESS REQUIREMENTS
20Implementation
SYSTEM VERIFICATION PROCESS REQUIREMENTS
TRANSITION TO USE PROCESS REQUIREMENTS
21Transition to Use
SYSTEMS ANALYSIS PROCESS REQUIREMENTS
30Design Solution Verification 31End Product Verification 32Enabling Product Readiness

END PRODUCTS VALIDATION PROCESS REQUIREMENTS
12Outcomes Management 13Information Dissemination
22Effectiveness Analysis 23Tradeoff Analysis 24Risk Analysis
33End Products Validation
System Requirements Analysis
Identification of Functional and Performance Requirements Allocation to Sub-elements
Development of Hierarchy
System Operations Analysis

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

5
System Design Analysis

Conceptualize Analyze Trade
and Synthesize Design
Design
Studies
System Risk Analysis

Tight Low
Margins Schedule Risk
maturity
Tight Cost
System Verification Analysis

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

8

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

9
Verification System

NPG 7120.5A Table of Contents
Chapter 1: Overview 1.1 Introduction 1.2 Framework 1.3 Themes 1.4 Process Description 1.5 Document Structure 1.6 Program/Project Management Initiative (PPMI) Chapter 2. Program Management Process and Functional Requirements 2.1 Program Formulation 2.1.1 Program Planning 2.1.2 Systems Analysis 2.1.3 Technology Requirements Synthesis 2.1.4 Develop Technology and Commercialization Program Plans 2.1.5 Operations and Business Opportunities 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 Advocacy 2.3.3 Requirements Management 2.3.4 Design, Develop, and Sustain 2.3.5 Deliver Products and Services 2.3.6 Capture Process Knowledge 2.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 Formulation 3.1.1 Project Planning 3.1.2 Systems Analysis 3.1.3 Technology Requirements Synthesis 3.1.4 Develop Technology and Commercialization Project Plans 3.1.5 Operations and Business Opportunities 3.1.6 Assess Infrastructure and Plan Upgrades/Development 3.1.7 Capture Process Knowledge 3.2 Project Approval 3.3 Project Implementation 3.3.1 Project Control 3.3.2 Customer Advocacy 3.3.3 Requirements Management 3.3.4 Design, Develop, and Sustain 3.3.5 Deliver Products and Services 3.3.6 Capture Process Knowledge 3.4 Project Evaluation 3.4.1 Plan and Conduct Reviews and Assessments 3.4.2 Capture Process Knowledge Chapter 4. Program/Project Management Systems Requirements 4.1 Resources Management 4.1.1 Financial Management 4.1.2 Life-Cycle Cost (LCC) Management and Accounting 4.1.3 Information Technology Management 4.2 Risk Management 4.2.1 Purpose 4.2.2 Requirements 4.3 Performance Management 4.3.1 Earned Value Management (EVM 4.3.2 Performance Assessment 4.3.3 Schedule Management 4.3.4 Work Breakdown Structure (WBS) 4.3.5 Program and Project Management Process Metrics 4.4 Acquisition Management 4.4.1 Acquisition 4.4.2 Identifying Requirements/Strategizing Implementation 4.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
10

NPG 7120.5A Table of Contents (contd)
4.5.2 Nuclear Launch Safety 4.5.3 Application of Lessons Learned 4.5.4 Program/Project Emergency Planning/Response 4.5.5 Environmental Management 4.6 Program/Project Management Development 4.6.1 Purpose 4.6.2 Requirements 4.6.3 PPMI Responsibilities Appendix A. References Available Via NODIS Appendix B. Definitions Appendix C. Acronyms Appendix D. Responsibilities for Program and Project Management Appendix E. Key Document Contents Appendix F. Independent Reviews List of Figures and Tables
11
PART I:
REQUIREMENTS ANALYSIS
12

Requirements Analysis
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 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 Requirements Validation System Verification From EIA 632
Requirements Definition
Solution Definition Transition To Use
Systems Analysis
End Products Validation
16

MIL SE Handbook
Input Requirements
Mission Objectives Mission Environments Mission Constraints Measures of Effectiveness
Functional Analysis
Synthesis
Acceptable Solution
Evaluation and Decision (Trade-off)
OR
Technology Selection Factors
Hardware Software Reliability Maintainability Personnel/Human Factors Survivability Security Safety Standardization Integrated Logistics Support EMC System Mass Properties Producibility Transportability Electronic Warfare Computer Resources
OR Will Alternatives Work?
Description of System Elements
17

NASA SE Handbook
Define / Identify Goals / Objectives and Constraints Perform Functional Analysis The following questions should be considered: Define Selection Rule
Define Plausible Alternatives
Have the goals / objectives and constraints been met?

I the tentative selection robust?
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
Is more analytical refinement needed to distinguish among alternatives? Have the subjective aspects of the problem been addressed?
Compute an estimate of system effectiveness, performance or technical attributes, and cost for each alternative Compute or estimate uncertainty ranges. Perform sensitivity analyses
Make a tentative selection (decision)
Is tentative selection acceptable?
Proceed to further resolution of system design, or to implementation 18
Analytical Portion of Trade Studies

Recognize Need or Opportunity
Principle of Successive 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 Analysis Requirements Validation Requirements Specifications Design Synthesis
Design Validation
Design Specifications Verification Analysis Verification Validation Verification Plans Baseline New Results Update Existing Baselines Configure
21
Trades Risks Issues

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 2 .3 .1 2 .3 .1 .1 2 .3 .1 .2 2 .3 .1 .3 DESCRIPTION Po i n t HGA S a n t e n n a a t TDRS Co m p u t e S/C t o TDRS L OS v e c t o r Co m p u t e r e q u i r e d g i m b a l a n g l e s Se n d c o m m a n d t o g i m b a l s
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 Console
Science Results
31

Data Flow Diagram Example

Commands Command Capture
Valid Cmds
TL Cmds
Command Timeline Executive
Cmd Status CC TM CE TM Telemetry Output Command Executive
TL Status TL Cmds Cmd Status
RT Cmds
CE TM CTE TM Other Elements
Other TM
32

Control Flow Diagram Example

Interrupts ISR Interrupt Requests
Real Time Executive
Resume Suspend
Task A
Status
Resume Suspend
Status
Resume Status Suspend

Task N
Task B
33

Input Requirements
Mission Objectives Mission Environments Mission Constraints Measures of Effectiveness
Flowchart Example
Functional Analysis Synthesis Acceptable Solution Evaluation and Decision (Trade-off)
OR
Technology Selection Factors
Hardware Software Reliability Maintainability Personnel/Human Factors Survivability Security Safety Standardization Integrated Logistics Support EMC System Mass Properties Produceability Transportability Electronic Warfare Computer Resources
OR Will Alternatives Work?
Description of System Elements
34

Understand User Requirements, Develop System Concept and Validation Plan Develop System Performance Specification and System Verification Plan Demonstrate and Validate System to User Validation Plan
Integrate System and Perform System Verification to Performance Specification
Expand Performance Specifications Into CI Design-to Specifications and Inspection Plan
Assemble CIs and Perform CI Verification to CI Design-to Specifications
Evolve Design-to Specifications into Build-to Documentation and Inspection Plan
Inspect to Build-to Documentation
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 "bandaid" 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

Azzolini

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

Azzolini

Uploaded by

Copyright:

Available Formats

Introduction to Systems Engineering Practices:

SEC jda: July, 2000

Essential Systems Engineering: For Each System:

Requirements Analysis Operations Analysis Design Analysis

Essential Systems Engineering:

REQUIREMENTS DEFINITION PROCESS REQUIREMENTS

2Product Acquisition 3Supplier Performance

14Acquirer Requirements 15Other Stakeholder Requirements 16System Technical Requirements

REQUIREMENTS VALIDATION PROCESS REQUIREMENTS

17Logical Solution Representations 18Physical Solution Representations 19Specified Requirements

SYSTEM VERIFICATION PROCESS REQUIREMENTS

TRANSITION TO USE PROCESS REQUIREMENTS

30Design Solution Verification 31End Product Verification 32Enabling Product Readiness

12Outcomes Management 13Information Dissemination

22Effectiveness Analysis 23Tradeoff Analysis 24Risk Analysis

33End Products Validation

Essential Systems Engineering:

System Requirements Analysis

Identification of Functional and Performance Requirements Allocation to Sub-elements

Essential Systems Engineering:

System Operations Analysis

Separation, and Deployment Checkout Observations

Partitioning of Functions Among Launch, Ground, and Flight Segments

Essential Systems Engineering:

System Design Analysis

and Synthesize Design

Essential Systems Engineering:

System Risk Analysis

Margins Schedule Risk

Essential Systems Engineering:

System Verification Analysis

Methods, Levels, Procedures, and BTE and GSE

Essential Systems Engineering:

to Requirements and Operations Concept Plans to Requirements Validation Testing

Essential Systems Engineering:

Essential Systems Engineering:

Essential Systems Engineering:

Essential Systems Engineering:

Introduction and Definitions

The Requirements Analysis Process

Essential Systems Engineering:

Essential Systems Engineering:

Essential Systems Engineering:

End Products Validation

Essential Systems Engineering:

Evaluation and Decision (Trade-off)

OR Will Alternatives Work?

Description of System Elements

Essential Systems Engineering:

Define Plausible Alternatives

Have the goals / objectives and constraints been met?

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

Make a tentative selection (decision)

Is tentative selection acceptable?

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

Analytical Portion of Trade Studies

Essential Systems Engineering:

Principle of Successive Refinement (Boehms Spiral Development Model)

Essential Systems Engineering:

At the end of each phase

Essential Systems Engineering:

Trades Risks Issues

Essential Systems Engineering: