Requirements Definition, Analysis, and
Management from an
INCOSE SE Handbook V3.1
Perspective
INCOSE Hampton Roads Area (HRA) Chapter
Requirements Management and Analysis Seminar
John O. Clark, CSEP
HRA Director of Education and Training
© 2008 International Council on Systems Engineering
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
1
INCOSE Copyright Notice
Copyright (c) 2008 by INCOSE, subject to the following restrictions:
Author Use. Authors have full rights to use their contributions in a totally unfettered way.
Abstraction is permitted with credit to the source.
INCOSE Use. Permission to reproduce and use this document or parts thereof by
members of INCOSE and to prepare derivative works from this document for INCOSE use
is granted, with attribution to INCOSE and the original author(s) where practical, provided
this copyright notice is included with all reproductions and derivative works.
External Use. This document may be shared or distributed to non-INCOSE third parties.
Requests for permission to reproduce this document in whole are granted, provided it is
not altered in any way. Requests for permission to prepare derivative works of this
document for external and/or commercial use will be denied unless covered by other
formal agreements with INCOSE. Copying, scanning, retyping, or any other form of
reproduction of the content of whole pages or source documents is prohibited except as
approved by the INCOSE Central Office, 2150 N.107th St., Suite 205, Seattle, WA 981339009.
Electronic Version Use. Any electronic version of this document is to be used for
personal use only and is not to be placed on a non-INCOSE sponsored server for general
use. Any additional use of these materials must have written approval from INCOSE
Central.
Permissions. INCOSE has granted permission to member companies of the INCOSE
Corporate Advisory Board to post and use this document internally, subject to the
external use restriction.
Technical Data. This technical data was prepared by the Hampton Roads Area (HRA)
Chapter of INCOSE. It was extracted by the HRA Chapter from the SE Handbook V3.1
Tutorial which is an INCOSE Technical Product. Future releases are subject to change by
the HRA Chapter. Forward comments to john.clark@incose.org.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
2
Contents
Section 1 - Scope (excerpts)
Section 4.2 - Stakeholder Requirements Definition
Process
Section 4.3 - Requirements Analysis Process
Section 7.2 - Requirements Management
Appendix I - Requirements Definition Process
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
3
Section 1
Scope
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
4
1.1 Purpose
• To define the discipline and practice of
Requirements Definition, Analysis, and
Management for student and practicing
professional alike
• To provide an authoritative reference to
understand these disciplines in terms of content
and practice
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
5
1.3 Contents, Chapters 4-6
ENTERPRISE
PROCESSES
(Chapter 6)
PROJECT PROCESSES
(Chapter 5)
Enterprise Environment
Enterprise
Environment
Management
Management
Investment
Investment
Management
Management
Resource
Resource
Resource
Resource
Management
Management
Management
Management
Quality
Quality
Quality
Quality
Management
Management
Management
Management
AGREEMENT
PROCESSES
(Chapter 6)
Acquisition
Acquisition
Supply
Supply
Risk
Management
Decision-making
- Making
Decision
System
SystemLife
LifeCycle
Cycle
Processes
Processes
Management
Management
Control
Control
Assessment
Assessment
Planning
Planning
Risk Management
Process
Guidelines
Configuration
Configuration
Management
Management
Information
Information
Management
Management
TECHNICAL PROCESSES
(Chapter 4)
Stakeholder
Stakeholder
Requirements
Requirements
Definition
Definition
Requirements
Requirements
Analysis
Analysis
Implementation
Implementation
Verification
Verification
Architectural
Design
Architectural Design
Integration
Integration
Transition
Transition
Validation
Validation
Maintenance
Maintenance
Operation
Operation
Disposal
Disposal
Figure 1-1 System Life Cycle Processes Overview per ISO/IEC 15288
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
6
1.4 Format, Chapters 4-6
• Purpose
• Description
• Inputs – this section discusses all inputs, including Controls and Enablers
• Outputs
• Process Activities
• Common approaches and tips – endnotes contain additional readings
Controls
Directives
Constraints
Inputs
-Data
-Material
Activities
Activities
A Aprocess
set
processisisananintegrated
integrated
setofof
activities
activities
that
that
transforms
transforms
inputs
inputs
into
into
desired outputs.
Outputs
- Processed data
-Products and services
Enablers
Resources (infrastructure, including workforce)
Tools and technologies
Figure 1-2 Sample Context Diagram for Process
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
7
Section 4
Technical Processes
November 4-5, 2008
Subject to the restrictions on Copyright Page
8 CSEP
8
4.2 Stakeholder Requirements
Definition Process
Controls
- Agreements
- Project procedures & processes
Activities
Inputs
- Stakeholders’ needs
- Project Constraints
- Identify legitimate stakeholders
- Elicit requirements
- Define constraints
- Build scenarios and concept documents
- Resolve requirements problems
- Confirm and record requirements
- Establish and maintain traceability
Outputs
-System
Systemsolution
solution
constraints
- constraints
- Requirements
Traceability
- Verification
Matrix
& Traceability
Validation
- Matrix
criteria
Validation
Concept documents
- criteria
- Concept documents
Enablers
- Enterprise Infrastructure
- Enterprise Policies, Processes, & Standards
Figure 4-2 Context Diagram for Stakeholder Requirements Definition Process
November 4-5, 2008
Subject to the restrictions on Copyright Page
9 CSEP
9
4.2 Stakeholder Requirements
Definition Process
PURPOSE: Elicit, negotiate, document, and maintain stakeholders’ requirements for the
system-of-interest within a defined environment.
DESCRIPTION: Governs the system’s development
INPUTS: Include the description of users’ needs or services that the system will provide,
cost, schedule, and solution constraints, terms and conditions of the agreement, and
industry specifications and standards.
OUTPUTS: Consist of formally documented and approved stakeholder requirements that
will govern the project, including: required system capabilities, functions and/or services;
quality standards; cost and schedule constraints; concept of operations; and concept of
support.
TIPS: Know your concept documents and what they contain: The following are instances
of concept documentation: • Concept of Production • Concept of Deployment • Concept of
Operations • Concept of Support. • Concept of Disposal.
Use scenarios to define the concept documents.
Once established, the stakeholders’ requirements are placed under configuration control.
Establish open communications between systems engineers and stakeholders.
Avoid designing a final solution.
Capture source and rationale for each requirement.
November 4-5, 2008
Subject to the restrictions on Copyright Page
10 CSEP
10
4.3 Requirements Analysis Process
Controls
- Natural and societal laws
- Project procedures & processes
Inputs
- Stakeholder requirements
- System Solution Constraints
- Requirements Verification
& Traceability Matrix (RVTM)
Activities
- Define functional boundary
- Define performance requirements
- Identify architectural constraints
- Define non-functional requirements
- Maintain traceability and baseline integrity
Outputs
- Functional and nonfunctional Requirements
- Performance Requirements
- Architectural constraints
- Verification strategy
and criteria
- Updated RVTM
Enablers
- Enterprise Infrastructure
- Enterprise Policies, Processes, & Standards
Figure 4-3 Context Diagram for Requirements Analysis Process
November 4-5, 2008
Subject to the restrictions on Copyright Page
11 CSEP
11
4.3 Requirements Analysis Process
PURPOSE: Review, assess, prioritize, and balance all stakeholder and derived
requirements (including constraints); and to transform those requirements into a
functional and technical view of a system description capable of meeting the
stakeholders’ needs.
DESCRIPTION: An interim process: the output of the process must be compared for
traceability and consistency with the Stakeholder Requirements, before being used
to drive the Architectural Design Process, without introducing implementation biases.
INPUTS: The primary input is the baseline documented during the Stakeholder
Requirements Definition Process.
OUTPUTS: A technical description of characteristics the future system must have in
order to meet Stakeholder Requirements – not a specific solution – which will be
evolved in subsequent development processes.
TIPS: Integrated Product Teams • Use failure modes, effects, and criticality analysis
(FMECA) or hazard analysis to identify the critical system level requirements. • Use
specially designed requirements management tools • Begin from the very beginning
to maintain requirements traceability. • Avoid deriving requirements that are not
consistent with other requirements or constraints. • Create templates for constructing
requirements statements.
November 4-5, 2008
Subject to the restrictions on Copyright Page
12 CSEP
12
Section 7.0
Enabling Systems
Engineering Process
Activities
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
13
Enabling Systems Engineering Process
Activities
• From a sampling of the literature in Systems
Engineering from 1962 to the present, a
common set of process activities emerges.
• This is the same set as that identified by a joint
project between The American Institute of
Aeronautics and Astronautics (AIAA) and
INCOSE in which they are referred to as
“enabling” processes.
• The enabling processes are Decision
Management, Requirements Management, and
Risk and Opportunity Management.
• When tailoring a project, most of these activities
will be essential to every system life cycle.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
14
7.2 Requirements Management
7.2.1 Elicit and Capture Requirements
7.2.2 Systems Modeling Language (SysML)
7.2.3 Concept of Operations
7.2.4 Define systems capabilities and performance
objectives
7.2.5 Technical Performance Measures
7.2.6 Define other non-functional requirements
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
15
7.2.1 Elicit and Capture Requirements
• Requirements management is the collection, analysis,
and validation of requirements
• Four major elements:
– elicit and capture requirements,
– generate a concept of operations,
– define system capabilities and performance objectives,
– define non-functional requirements
• The reason:
understand the needs of the stakeholders well enough
to support the architecture design process.
• Biggest challenges:
– Identification of the set of stakeholders
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
16
7.2.1 Elicit and Capture Requirements (cont)
Users
(& stakeholders)
Systems in operational
environment
System-of-interest
Society
Operators
Enabling systems
Stakeholders
Production system
Maintenance system
Figure 7-3 Requirements elicitation captures the needs of
stakeholders, operators, and users across systems boundaries
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
17
7.2.2 Systems Modeling Language (SysML)
• SysML
– Model complex systems
– Provide standard representations
• Requirements Diagram
• Behavior Diagrams
–
–
–
–
–
Use case diagram
Activity diagram
Sequence diagram
State machine diagram
Timing diagram
• System Structure Diagrams
– Block definition diagrams
– Internal block
• Parametric Diagram
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
18
7.2.2 Systems Modeling Language (SysML)
(cont)
SysML Diagram
Structure
Diagram
Block Definition
Diagram*
Parametric
Diagram
Internal Block
Diagram*
Requirement
Diagram
Behavior
Diagram
Activity
Diagram
Timing
Diagram
Sequence
Diagram
Use Case
Diagram
State Machine
Diagram
Figure 7-4 SysML Diagram Types
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
19
7.2.3 Concept of Operations
• Capturing the understanding of stakeholder
needs in a series of concept documents,
– implementation-free
–defining what is needed
–behavioral characteristics
• Starting point for building up the concept is
–To begin by identifying outputs generated
by external systems
–These single threads of behavior eventually cover
every aspect of operational performance.
–Aggregation of these single threads of behavior
represents a dynamic statement of what the system
is required to do.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
20
7.2.3 Concept of Operations (cont)
Objectives:
a. Operational needs are clearly understood and the
rationale is incorporated into the design decision
database.
b. To provide traceability between operational needs and
the captured source requirements.
c. To establish a basis for requirements to support the
system over its life, such
d. To establish a basis for test planning, system-level test
requirements
e. To generate operational analysis models to test the
validity interfaces
f. To provide the basis for computation of system capacity,
g. To validate requirements to discover implicit
requirements
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
21
7.2.4 Define Systems Capabilities and
Performance Objectives
• The concepts of production, deployment, operations, and
support serve as an foundation for discerning the required
capabilities and the relevant performance objectives of the
system.
• Together with identified system constraints, these will drive
the architecture design activities.
• Simulation
– should contain sufficient functional
elements that the interactions can be properly assessed.
– purpose is to establish measurable parameters for the
functional requirements.
– provides the necessary guidance to the designers on the size
and capability required of their equipment.
•
As a result of this activity, a number of performance requirements will be identified.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
22
7.2.4 Define Systems Capabilities and
Performance Objectives (cont)
•
Parameters will be used as an integral part of the
verification process in establishing the capability of the
equipment (and the system) to satisfy user needs.
Interdisciplinary team
•
–
Audit the requirements
•
–
•
Assess that the requirements are verifiable
Uncertainty associated with a requirement,
–
–
•
may help ensure the clarity, completeness and consistency of the set.
identified as needing further attention,
monitoring as part of the project risk management.
Resolution of uncertainty should be assigned as a
responsibility to an individual, and progress and eventual
resolution recorded in the decision database.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
23
7.2.5 Technical Performance Measures
Technical Performance Measures (TPM)
–
–
–
–
objective performance requirements,
evaluated at decision gate reviews,
used to assess the risk position of the project.
provide visibility into important project technical
parameter
– enable effective management enhancing the likelihood of
achieving the technical objectives of the project
• The Systems Engineering Plan (SEP) should define
the approach to TPM.
• Periodic recording of the status of each TPM
• Measured values that fall outside an established
tolerance band will alert management to take
corrective action.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
24
7.2.5 Technical Performance Measures (cont)
Specified “Not to Exceed” Value
100%
90
Action Team to Bring Back into
Spec
Demonstrated
Variance
Predicted Variance
Planned
Value Profile
Current
Estimate
X
80
X
70
X
X
X
X
X
X
X
X
Achievement
to Date
X
Demonstrated
Values
Estimated
Value
Proposal
Allocated
Value
Gate
Calculated
Value
Gate
Measured
Value
Test
Figure 7-5 TPM Monitoring
November 4-5, 2008
Subject to the restrictions on Copyright Page
Delivery
© CSM, Used with permission
CSEP
25
7.2.6 Define Other Non-functional
Requirements
• The concept documents will also suggest
requirements that are not directly related to the
primary capability provided by the system-of-interest.
• The Øresund Bridge case illustrated the
avoidance of negative environmental impact by
establishing constraints on the construction
practices.
• Addressing non-functional requirements from the
Earliest stages is a good way to ensure that they
are not forgotten and that they are satisfied.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
26
Sample Question Section 7.2, Requirements Management
• Which two of the following are SysML
Diagram types? (Choose two)
A. Timing Diagram
B. Activity Diagram
C. Context Diagram
D. Component Diagram
E. SV-1 View
This question IS NOT from the INCOSE Certification Exam. The format and content are similar (based on
SEH V3.1), however it was created by INCOSE HRA, and is used with permission.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
27
Appendix I
Requirements Definition
Process
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
28
Contents
• I.1 Capturing Source Requirements
• I.2 Concept of Operations Definitions
• I.3 Define/Refine Functional/Performance
Requirements
• I.4 Requirements Allocation and Traceability
• I.5 Development of Specification Tree and
Specifications
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
29
Scope and Objectives
•
•
•
Scope: This appendix elaborates and provides
“how-to” information on requirements
identification, capture, analysis, and
management
Requirements are the foundation of the project
Objectives:
1.
2.
Identify and express verifiable requirements that state user
needs in appropriate terms to guide system concept
development
Provide an understanding of the interaction between various
functions and to obtain a balanced set of requirements based
on user objectives
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
30
Sources of Requirements
Figure I-1
Exte rnal E nvironme nt
• LAWS & REGULATIONS • LEGAL LIABILITIES • SOCIAL RESPONSIBILITIES • TECHNOLOGY BASE
• LABOR POOL • COMPETING PRODUCTS • STANDARDS & SPECIFICATIONS • PUBLIC CULTURE
Enterprise Environment
• POLICIES & PROCEDURES • STANDARDS & SPECIFI CATIONS
• GUIDELINES • DOMAIN TECHNOLOGIES • LOCAL CULTURE
Project Environment
Enterprise Support
• DIRE CTIVES & PRO CE DURES • PLANS • TOOLS • P ROJECT REVIEWS • METRICS
Process Groups for
Engineering Systems
Project Support
• Proje ct Management
• Agreement Support
•
•
•
•
•
Acquisition & Supply
Technical Mana gement
System Design
Product Realization
Technical Evalu ation
Project A
Project B
Project C
November 4-5, 2008
Subject to the restrictions on Copyright Page
•
•
•
•
•
•
•
Investment De cision s
E xterna l A greements
Infrastru cture Sup port
Resour ce Manage me nt
P rocess Managemen t
P roduction
Field S upport
CSEP
31
I.1 Capturing Source Requirements
• Extract, clarify and prioritize all of the
written directives embodied in the source
documents relevant to the particular phase
of procurement activity
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
32
I.1 Capturing Source Requirements
(cont)
• Examples of typical inputs include (but not limited to):
– New or updated customer needs, requirements, and objectives in
terms of missions, measures of effectiveness, technical
performance, utilization environments, and constraints
– Technology base data including identification of key technologies,
performance, maturity, cost, and risk
– The outputs from the preceding acquisition phase
– Requirements from contractually cited documents for the system
and its configuration items
– Technical objectives
– Records of meeting and conversation with the customer
• Source Requirements from the above are only a
portion of the total system requirements
– Breakdown broad requirements statements will reveal need for
additional clarification
– Concept of operation definition function may reveal need for
additional clarification
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
33
I.1 Capturing Source Requirements
(cont)
• Develop a database of baseline system requirements
traceable to the source needs and requirements
• Requirements are refined as part of the Systems
Engineering Process
• Requirements include:
–
–
–
–
–
–
–
–
Project Requirements
Mission Requirements
Customer Specified Constraints
Interface, environment, and non-functional requirements
Unclear issues discovered in the Requirement Analysis process
An audit trail -Issues to Resolution
Verification Methods required by the customer
Traceability to source documents
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
34
I.1 Capturing Source Requirements
(cont)
• To be successful at gathering
requirements:
– Empower a system analysis team
– Assign experienced Systems Engineers
– Assign experienced team members from
cross functional areas
– Use a mature database tool, train the team
– Produce output products, agree on the format
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
35
I.1.1 Initializing the Database
The decision database is first populated with source
documents
Recommended Activities:
1. Analyze the highest priority source document, decompose and
extract the requirements, place these requirements in the database
–
–
Each paragraph in the source document is entered as a separate
requirement object. Record object information to trace back to the
identity of the: source document, identity, paragraph title, and sentence
number.
Continue to analyze source documents and place requirements in the
database
2. Analyze the content of each parent requirement object from above:
–
Does the parent object contain any information on requirements? If
yes, go next, if no, go to if not:
 Unambiguous,
 Non-conflicting with other requirements,
 Unique to a single system function, architectural component,
performance measurement index, or system constraint?
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
36
I.1.1 Initializing the Database (cont)
•
•
•
 If not, determine a strategy for decomposing the parent
requirement object into separate but related pieces with the
objective of meeting these criteria.
Record information in the database to provide vertical traceability from
the parent requirement object to the child requirement object. Assign a
Project Unique Identifier (PUID).
Repeat the procedure with the child requirement objects, creating and
recording traceability to grandchild, great grandchild, etc. Stop when the
objective has been achieved (leaf node requirements).
As the requirement are flowed down, this will eventually end at a
configuration item (CI).
– A CI is a hardware , software or composite item at any level in the system
hierarchy
– CI has four common characteristics
•
•
•
•
Defined functionality
Replaceable as an entity
Unique specification
Formal control of form, fit, function
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
37
I.1.2 Generation of the System
Requirement Document (SRD)
• The output of this function will be a baseline set of
complete, accurate non-ambiguous system requirements
recorded in the decision database, accessible to all parties
• Non-ambiguous requirements must be broken down into
constituent parts in a traceable hierarchy such that each
individual requirement is:
• Clear, unique, consistent, stand-alone and
verifiable
• Traceable to an identified source requirement
• Not redundant, not in conflict with any other known
requirement
• Not biased by any particular implementation
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
38
I.1.2 Generation of the SRD (cont)
• Note that these objectives may not be
achievable using source requirements.
Requirements analysis is required to
resolve potential conflicts and
redundancies, and to further decompose
requirements so that each applies only to
a single system function
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
39
I.1.2 Generation of the SRD (cont)
Recommended Activities
1.
2.
Generate a “snapshot” report of clarified system
requirements. Clarified requirements may be
grouped as functional, performance, constraining,
and non functional for easy access by the team
databases
Generate draft SRD. This is highest level document
to be created by the project to represent the
customer/user requirements. The SRD should be
generalized to fit the range of real-world situations.
Use of an automated database will greatly facilitate
this effort, but is not explicitly required
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
40
I.2 Concept of Operations Definitions
• A Concept of Operation (ConOps) document is produced
early in the requirements definitions process to describe
what the system will do (not how it will do it) and why
(rationale)
• The ConOps should also define any critical, top-level
performance requirements or objectives stated either
qualitatively or quantitatively and system rationale
• The ConOps should contain a preliminary functional flow
block diagram of the system with only the top-level
functional “threads” specified
• At this time, no attempt is made to define a complete
operational concept or to allocate functions to hardware or
software elements
• This ConOps is essentially a functional concept definition
and rationale from the user and customer perspective
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
41
I.2 Concept of Operations Definitions
(cont)
• ConOps objective is to communicate with
the end user of the system during the early
specification stages to assure the
operational needs are clearly understood
and incorporated into the design decision
database for later inclusion in the system
and segment specifications.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
42
I.2 Concept of Operations (cont)
Recommended Activities
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Start with the source requirements statements. Deduce statements
describing high-level mission-oriented system objectives
Review system objectives with end users and operational personnel
Define and model operational boundaries
For each model, generate a context diagram to represent the model
boundary.
Identify all of the possible types of inputs and output events that can
occur between the system and its interactive external system
If the inputs/outputs are affected by the environment between the system
and external system show timing difference between input and output.
Record system interfaces between the system and the environment or
external system.
Develop an FFBD
Add functional timing from performance requirements, simulate the
FFBD. Review results with operators.
Develop timelines to supplement source requirements.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
43
I.3 Define/Derive/Refine Functional &
Performance Requirements
• Functional/Performance requirements
definition/derivation/refinement covers the total
system over its life cycle including support
requirements
• Functional/Performance requirements need to
be formally documented, quantified,
performance-based that define the functions and
interfaces and characterize the system by
performance requirements that can be flowed
down to hardware and software designers
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
44
I.3 Define/Derive/Refine Functional &
Performance Requirements (cont)
Figure I-2
CAPTURE
SOURCE
REQUIREMENTS
SRD/TRD
OR
SORD
SOW
(CDRL,WBS,
MIL-STD, DID,
COMPLIANCE
DOCUMENTS)
REQUIREMENTS
ANALYSIS
ESTABLISH
MEASURABLES
FUNCTIONAL
ANALYSIS &
MODELING
SIMULATION
COTS,
NDI,
FACILITIES
SYSTEM
ARCHITECTURE
IMPACTS
DESIGN DECISION DATABASE
ENGR
MEMOS
ALLOCATED
& DERIVED
REQM’T
REQM'TS
TRACEABILITY
MATRIX
REQUIREMENTS
DATABASE
SPEC
TREE
LOWER
LEVEL
SPECS
EXAMINE
ADVERSE
CONSEQUENCES
TRADES
OPERATIONS
CONCEPT
DESIGN
CONSTRAINTS
DRAFT
SPECIFICATION
REVIEW
& AUDIT
BASELINE
DESIGN
IDENTIFY
TBD/TBR &
PRIORITIZE
REQUIREMENTS
PERFORMANCE
EVALUATION
RELEASED
SPECS
& ICDs
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
45
I.3 Define/Derive/Refine Functional &
Performance Requirements (cont)
1. Starting point is the source requirements
•
Establish constraints on the system: cost, schedule, use of
COTS, facilities, operational interface, operational
environment
2. The mission should be examined and characterized
in measurable requirement categories: Quantity,
Quality, Coverage, Timeliness, and Availability
•
Expand the analysis include supporting areas to obtain total
system requirements
3. Use detailed functional analysis to extract new
functional requirements specifically those required to
support the mission
•
Quality Function Deployment (QFD) is a technique,
particularly where the “voice of the customer” is not clear.
See figure I-3
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
46
I.3 Define/Derive/Refine Functional &
Performance Requirements (cont)
Quality Function Deployment (QFD); House of Quality
Figure I-3
REQUIREMENTS
CORRELATION
MATRIX
X
++
XX
FEATURES
WHAT ?
- -
HOW ?
RELATIONSHIP
MATRIX
VOICE OF THE CUSTOMER
• BLANK ROW = UNMET REQT.
• BLANK COL. = UNNEEDED
FEATURE
HOW MUCH ?
BEST
BENCHMARK
WORST
• A PLANNING TOOL FOR TRANSLATING CUSTOMER REQUIREMENTS INTO SPECIFICATIONS
• DEPLOYS THE "VOICE OF THE CUSTOMER"
• A FAST, SYSTEMATIC WAY TO DERIVE & FLOW DOWN REQUIREMENTS TO DESIGN, PARTS,
MANUFACTURING, AND PRODUCTION
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
47
I.3 Define/Derive/Refine Functional &
Performance Requirements (cont)
4. For larger systems develop a high-level system simulation
evolved from the system architecture
5. Examine any adverse consequences of incorporating
requirements- risk, cost, technology ready for production,
schedule realism
6. Trade studies should be performed to determine appropriate
requirements and balance performance with cost
7. Incorporate revised and derived requirements and
parameters into decision database
8. Prepare specifications:
•
•
•
Enter document into formal release system
Maintain under configuration control
Any further changes will require configuration control board approval.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
48
I.3 Define/Derive/Refine Functional &
Performance Requirements (cont)
• The following questions should be considered for
every requirement:
• Clear? Convey what is to be done to the next level of development.
• A proper requirement? A requirement is a demand on the
designer. Is the requirement at the proper level?
• Necessary? Only necessary requirements should be written
• Consistent with product standards?
• Achievable? Design should assess requirement achievability.
• Traceable? Do all requirements trace to higher level specification.
• Verifiable? Can the requirement be verified by: test, demonstration,
analysis or inspection?
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
49
I.3 Define/Derive/Refine Functional &
Performance Requirements (cont)
Requirements – Verb Tense in specifications
• Shall - Preferred – demands on the designer
• Will - Identify future happening, conveys
information-not to be interpreted as a requirement
• Must - Shall is preferable to the word “must”
• Other forms - “to-be”, “is to be” – “should” are not to
be used in specifications
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
50
I.4 Requirement Allocation and
Traceability
•
Traceability not an end goal in and of itself, but is a tool
to use to:
1.
2.
3.
•
•
Improve integrity and accuracy of all requirements, from the
system down to the component
Allows tracking of the requirements development and allocation
and generating overall metrics, and
Support easier maintenance and change implementation of the
system in the future.
Derived requirements must be documented and their
justification given.
Traceability should be maintained throughout all levels of
documentation; bidirectional traceability is top-down and
to validation and verification plan and procedures for
specifications.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
51
I.4 Requirement Allocation and
Traceability (cont)
•
Recommended Activities
1.
2.
3.
4.
5.
6.
Use a requirement traceability tool that augments the
requirements database
Each requirement must be traceable using a Project Unique
Identifier (PUID)
Identify the functions and sub functions for which each area is
responsible, and the top level system requirement associated
with those functions.
Requirement flow down includes deriving new requirements
which often involve a change in parameters as appropriate to
the level in the hierarchy .
Audit the specification as they are produced to verify that the
allocation process is correct and complete.
Generate the Requirements Traceability Matrix (RTM) from
the database.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
52
I.5 Development of Specification Tree
and Specifications
Recommended Activities:
1. Derive the Spec Tree from the system
architecture configuration
2. For each specification in the Spec Tree, create
an outline using standard specification
template and define the configuration item
3. Craft requirements for each specification,
fulfilling all flow down and accommodating
derived and reflected requirements emerging
from the definitions of each configuration item
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
53
I.5 Development of Specification Tree
and Specifications (cont)
System
Element
CSCI
IS
CSCI
IS
HWCI
Hardware Configuration Item
CSCI
Computer Software Configuration Item
IS
Interface Specification
Element
Element
HWCI
HWCI
HWCI
HWCI
HWCI
CSCI
IS
HWCI
Figure I-4 Example Project Specification Tree:
also known as Product Breakdown Structure (PBS)
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
54
I.6 Requirement and Design Loops
•
Design is the process of defining, selecting, and
describing solutions to requirements in terms of
products and processes. A design describes the
solution (conceptual, preliminary or detailed) to
the requirements of the system.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
55
I.6 Requirement and Design Loops
(cont)
• Recommended Activities-the following steps describe the
Systems Engineering activities in achieving Requirements
and Design feedback loops.
1. Determine how SE process is tailored for different levels of the project.
2. Audit the system requirements. Audits occur at various levels, from
peer reviews against requirements in specifications, to design reviews,
both informal and formal.
3. Iterate between system (hardware and software), design, and
manufacturing functions.
4. Audit the design and manufacturing process. To insure compliance
with requirement.
5. System Engineering ensures that all elements of the Systems
Engineering process are executed.
6. Interface with specialty engineering groups and subcontractors to
ensure common understanding across disciplines.
7. Update models as better data becomes available.
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
56
Sample Question
Which three of the following is true? (Choose
three)
A. The requirements are the foundation of the
project.
B. Design is “what” has to be done.
C. Traceability is an audit to ensure that customer
requirements are reflected in the design.
D. Context diagram helps define interfaces.
E. All of the above
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
57
Sample Question
Which three of the following is true? (Choose
three)
X
A. The requirements are the foundation of the
project.
B. Design is “what” has to be done.
X
C. Traceability is an audit to ensure that
customer requirements are reflected in the
design.
X
D. Context diagram helps define interfaces.
E. All of the above
November 4-5, 2008
Subject to the restrictions on Copyright Page
CSEP
58