1. Requirements Engineering from a Standards Perspective
INCOSE Hampton Roads Area Chapter
Requirements Management and Analysis Seminar
November 4-5, 2008
John O. Clark
Chief Engineer, CSEP
Northrop Grumman Corporation

2. Copyright Acknowledgement
All EIA, IEEE, ANSI, and ISO/IEC copyrighted material has been removed from this version in order to comply with the copyright owner’s requirements. Refer to the figures in the standards.

3. Content Introduction Want is Requirements Management?
Purpose
SE Standards
In-Seat Warm-up Exercise
Key Terms
What is Systems Engineering?
What is a Requirement?
Want is Requirements Management?
What is the Requirements Engineering Process?
MIL-STD-499B, EIA/IS
IEEE
ANSI/EIA
ISO/IEC , IEEE Std
ISO/IEC TR 19760
ISO/IEC , IEEE Std
Appendix – Acronyms
This is the order of the presentation. Tell them why we go in this order and how long it takes. Tell them a little something about each part.

4. Purpose
Introduce the systems engineering standards which include the requirements engineering processes
Emphasize the requirements engineering processes from a “standards” perspective
“Stand on the standards," as opposed to relying solely on other sources such as instructions, procedures, guides, textbooks, education, training, and even experience in performing requirements engineering functions
Develop an appreciation for the different views of the requirements engineering process based on how each of the standards presents this view, thereby getting a more complete view
Show the relationships between systems requirements engineering and software requirements engineering based on these standards
Elaborate more on the purpose of the tutorial. The objectives were covered but now you need to appeal to their “feelings” as opposed to their intellect.
The goals of this tutorial are to:
1) describe the systems engineering and software engineering standards heritage, processes, and products;
2) show the relationships between processes, products, and people based on these standards; and
3) encourage and challenge the participants to read, understand, select, tailor, and apply these standards, i.e., "stand on the standards," as opposed to relying solely on other sources such as instructions, procedures, guides, textbooks, education, training, and experience.  Individuals may have an understanding of portions of systems and software engineering based on these other sources.  Standards, developed by subject matter experts and approved by nationally recognized standards organizations, provide a more complete and common understanding.

5. SE Standards IEEE 1220 EIA 632 EIA/IS 632 ISO/IEC 15288
Sheard and Lake
Scope and Detail of the SE Standards
Level of Detail
Breadth of Scope
IEEE 1220
EIA 632
EIA/IS 632
ISO/IEC 15288
Provided with the permission of Sarah Sheard from Sheard, Sarah A., Software Productivity Consortium (SPC), and
Lake, Jerome G., Systems Management international (SMi), Systems Engineering Standards and Models Compared, July 1998.
As is to be expected, SE standards have a different level of detail and scope.
The new international SE standard, ISO/IEC 15288, which does not even recognize the term ”SE”, takes the broadest scope approach, adds first the emphasis on Acquirer-Supplier agreement and then adds all the other enterprise processes that must be in place to develop and support the systems for their entire life cycle. However, is the least level of detail (i.e, is the most abstract), is intended for international commerce between countries, but has been adopted as an IEEE standard..
The older time-tested US standards, such as EIA/IS-632, EIA-632, and IEEE 1220, have the most detail and least breadth of scope of the SE standards, as they try to provide information on how to do systems engineering, and mostly confine themselves to engineering (plus some project management). EIA/IS-632 and IEEE 1220 were based on MIL-STD-499B which was never issued by the US DoD in favor of “standards reform” and “industry best practice.” EIA-632 changed radically from EIA/IS These three are preferred by the US DoD. Of these, many in the US DoD still favor EIA/IS-632 because it was based on MIL-STD-499B and retains the DoD flavor. Some in DoD (primarily the Navy) use a combination of EIA/IS-632 and EIA The Air Force Space and Missile Command initially published a draft MIL-STD-499C, but it later was issued as a technical report because the DoD did not accept it. IEEE 1220 is the most detailed, has remained mostly unchanged from its beginning, is used by DoD, was adopted as an ISO/IEC standard, and is being aligned with and the international software standard: ISO/IEC 11

6. In-Seat Warm-up Exercise
JOC
Instructions: Answer the following questions on your own without looking at the materials:
What is a requirement?
Want is requirements analysis?
What is requirements management?
What is requirements engineering?
What is the requirements engineering process?
Time: 5 minutes
Instructor Notes
Ask students to document their answers to the questions above without looking ahead at the materials.
Tell them that throughout this module we will be providing them with the answers.
Ask them to see how close they were as we go along.

7. Key Terms
JOC
Capability: A group of related requirements raised to a higher level of abstraction. Synonyms include function, subject, object, or other term useful for presenting the requirements.
Requirement: A condition for acceptance of the system.
Functional Requirement: What?
Performance Requirement: How well?
Configuration Item (CI): Any item designated for Configuration Mgmt.
Preliminary Design: High-Level Design, one level below (inside) the CI.
Detailed Design: Low-Level Design, lowest level of the CI.
Validation: Right system?
Verification: System right?
Verification Methods: Analysis (including modeling and simulation), Demonstration, Test, and Inspection.
Use Case: A scenario-driven functional thread through the system.
Decompose: Parse or separate.
Derive: Deduce (e.g., if a=b+c then c=a-b, or I’ll know it when I see it).
Synthesis: Design. Translate requirements (problems) into solutions.
Architecture: Design or structure.

8. What is Systems Engineering?
Key Terms and Relationships
JOC
Capabilities
Operational Requirements Document (ORD)
Initial Capabilities Document (ICD)
Capabilities Development Document (CDD)
Mission Needs Statement (MNS)
Operational Concept Document (OCD)
System Threat Assessment Report (STAR)
Requirements
System Requirements Document (SRD)
System Specification (SS) (MIL-STD-961E)
System/Subsystem Specification (SSS)
Software Requirements Specification (SRS)
System/Subsystem Design Description (SSDD)
System Specification (SS) (MIL-STD-961E)
Software Design Description (SDD)
Functions
Components
(SSDD/SS/SDD)
Capability: “Verb Noun” Example: Transport personnel safely over land.
Requirement: “Noun shall verb.”
Example: The car shall stop within 100 feet at 50 mph, weigh less than 3000 lbs, and be green.
Functional (what) Performance (how well) Physical, Design, or Constraint
Function: “Verb Noun,” “Verb-ing,” or “Verb.” Examples: Stop Car, Stopping, or Stop.
Component: “Noun.” Example: Brake.
Capability: “Verb Noun” Example: Transport personnel safely over land.
Requirement: “Noun shall verb.”
Example: The car shall stop within 100 feet at 50 mph, weigh less than 3000 lbs, and be green.
Functional (what) Performance (how well) Physical, Design, or Constraint
Function: “Verb Noun,” “Verb-ing,” or “Verb.” Examples: Stop Car, Stopping, or Stop.
Capability: “Verb Noun” Example: Transport personnel safely over land.
Capability: “Verb Noun” Example: Transport personnel safely over land.
Requirement: “Noun shall verb.”
Example: The car shall stop within 100 feet at 50 mph, weigh less than 3000 lbs, and be green.
Functional (what) Performance (how well) Physical, Design, or Constraint

9. What is a Requirement? (cont)
INCOSE SE HDBK
Functional Thread Analysis / Use Cases
Requirements Specifications and Test Procedures can be written using Use Cases.
Provided with the permission of INCOSE from INCOSE SE Handbook, Version 2a. Copyright 2002, 2004 by INCOSE.

10. What is Requirements Management?
Technical Baselines, Documents, and Reviews
JOC
Baselines
Documents
Reviews
Performance
ORD / TLR
A/O
SRD / SS / SSS
External IRS
Requirements R
Functional
SRD / SS / SSS F
SSDD, SRS, HRS,
Internal IRS
Allocated PD
HDD (Drawings)
SDD, DBDD, IDD
Developmental CD
Software
Hardware
FCA/V
PCA
Physical/Product
A/O – Alternative/Operational
CD – Critical Design
DBDD – Data Base Design Description
F – Functional
FCA – Functional Configuration Audit
HDD – Hardware Design Description
HRS- Hardware Requirements Specification
IDD – Interface Design Description
IRS – Interface Requirements Specification
ORD – Operational Requirements Document
PCA – Physical Configuration Audit
PD – Preliminary Design
TLR – Top Level Requirements
R – Requirements
SDD – Software Design Description
SRD – System Requirements Document
SS – System Specification
SSS – System/Subsystem Specification
SRS – Software Requirements Specification
SSDD – System/Subsystem Design Specification
V – Verification

11. LOWEST CONFIGURATION ITEM
What is Requirements Management? (cont)
Technical Baselines, Documents, and Reviews for a System
J. Clark A R F PD I CD TR TC
FCA VR
PCA
Review Types:
FULL MENU
Document Types:
ORD/
ICD
S/SS
IRS
S/SS
IRS
S/SDD
SDD
HDD
IDD
DBDD
SDD
HDD
IDD
DBDD
T Plan
T Proc
T Rpt
Rpt
Rpt
Rpt
SYSTEM
LEVEL
System Requirements
Baseline
System
requirements
allocated to
Subsystems
ASR
SRR
SFR
SPDR
SCDR
STRR
STCR
SVR
SPCA
ORD/
ICD SS
IRS
SDD
T Plan
T Proc
T Rpt
FCA Rpt
PCA Rpt
Rqmts,
Functions,
& Prelim
Design
Flow Down:
Detailed
Design,
Verification
& Validation
Roll Up:
ISR
SUBSYSTEM
LEVEL
System Allocated Baseline =
Subsystem Requirements Baseline
Subsystem
requirements
allocated to
Lowest Configuration
Items (LCIs)
SubRR
SubFR
SubPDR
SubCDR
SubTRR
SubTCR
SubFCA
SubPCA
SubS
IRS
SubDD
T Plan
T Proc
T Rpt
FCA Rpt
PCA Rpt
ISubR
Rqmts,
Functions,
& Prelim
Design
Flow Down:
Detailed
Design,
Verification
& Validation
Roll Up:
LOWEST CONFIGURATION ITEM
LEVEL
Subsystem Allocated Baseline =
LCI Requirements Baseline
(e.g., Software Requirements Baseline)
SWRR
SWFR
SWPDR
SWCDR
SWTRR
SWTCR
SWFCA
SWPCA
SWRS
IRS
SWDD
IDD
DBDD
T Plan
T Proc
T Rpt
FCA Rpt
PCA Rpt

12. What is the Requirements Engineering Process?
MIL-STD-499B, EIA/IS Systems Engineering
IEEE IEEE Standard for Application and Management of the Systems Engineering Process
ANSI/EIA Processes for Engineering a System
ISO/IEC , IEEE Std Systems and Software Engineering – System Life Cycle Processes
ISO/IEC , IEEE Std Systems and Software Engineering – Software Life Cycle Processes
ISO/IEC TR Systems Engineering – A guide for the Application of ISO/IEC (System Life Cycle Processes)

13. MIL-STD-499B and EIA/IS-632 (cont)
John Clark Amplified Version
JOC
Systems Analysis
Requirements Trade Studies and Assessments
Effectiveness Analysis, etc.
Functional Trade Studies and
Physical Design Trade Studies
Assessments
and Assessments
Effectiveness Analysis, etc.
Effectiveness Analysis, etc.
Physical Design & Allocation
Define Subsystems and Components
Allocate Functions and Sub functions to
Subsystems and Components
Define Subsystem & Component Rqmts
Define Subsystem & Component Interfaces
Establish Allocated Baseline
Define Physical Architecture
Develop Physical Flow Block Diagrams
Establish Physical/Product Baseline
Requirements Analysis
Define Requirements
Define Interfaces
Decompose and Derive Requirements
Define Constraints & Conditions
Define Requirements Architecture
Establish Requirements Baseline
Functional Analysis & Allocation
Define Functions
Allocate Requirements to Functions
Define Functional Interfaces
Decompose Functions to Sub functions
Allocate Decomposed and Derived
Requirements to Sub functions
Define Functional Architecture
Develop Functional Flow Block Diagrams
Establish Functional Baseline
Requirements Architecture
Functional Architecture
Physical Architecture
I/F
Sys
I/F
F11
F12
F21 F2 F1
Sys
I/F
F22 C1 C2 C3
Sub2
Sub1
Sys
I/F R1
I/F R2
R11
I/F
R22
R21
I/F
R22
Requirements Loop
Design Loop
Verification Loop
Control
Risk Management
Configuration & Data Management
Interface Management
Performance-Based Progress Measurement:
- SEMS/IMP & SEDS/IMS
- TPMs & Metrics
SOW, Deliverables
WBS, SBS, PBS
Work & Planning Packages
- Technical Reviews
Earned Value

14. Summary Introduction Want is Requirements Management?
Purpose
SE Standards
In-Seat Warm-up Exercise
Key Terms
What is Systems Engineering?
What is a Requirement?
Want is Requirements Management?
What is the Requirements Engineering Process?
MIL-STD-499B, EIA/IS
IEEE
ANSI/EIA
ISO/IEC , IEEE Std
ISO/IEC TR 19760
ISO/IEC , IEEE Std
Appendix – Acronyms
This is the order of the presentation. Tell them why we go in this order and how long it takes. Tell them a little something about each part.

15. THE END! For More Information Contact: John O. Clark
Northrop Grumman Mission Systems
Command and Control Systems Division
Warfare Systems Engineering Department
468 Viking Drive
Virginia Beach, VA USA
(757)

16. Acronyms Acronym Description A Alternative Acq Acquisition ACWP
Actual Cost of Work Performed AD
Architectural Design
ANSI
American National Standards Institute
AoA
Analysis of Alternatives AP
Assessment Process
ASR
Alternative System Review
AT&L
Analysis, Technology and Logistics
ATM
Automatic Teller Machine
BCWP
Budgeted Cost of Work Performed
BCWS
Budgeted Cost of Work Scheduled C
Component CD
Critical Design
Concept Decision
CDD
Capability Development Document
CDR
Critical Design Review
CDRL
Contract Data Requirements List CI
Configuration Item CM
Configuration Management Plan
CMMI
Capability Maturity Model Integrated CP
Control Process
CPD
Capability Production Document
CSCI
Computer Software Configuration Item CV
Cost Variance
CWBS
Contract Work Breakdown Structure
DAB
Defense Acquisition Board
DBDD
Data Base Design Description
DID
Data Item Description
Dis
Disposal DM
Decision Making
DMP
Data Management Plan
DMU
Defense Management University
DOD-STD
Department of Defense Standard
DOTMLPF
Doctrine, Organization, Training, Material,
Leadership, Personnel, Facilities
DSMC
Defense Systems Management College
EEM
Enterprise Environment Management
EIA
Electronic Industries Association

17. Acronyms (cont) HSIP Human Systems Integration Plan HW Hardware HWCI
Hardware Configuration Item I
Implementation
I&TP
Integration and Test Plan
ICD
Initial Capabilities Document
IDD
Interface Design Specification
IEC
International Electrotechnical Commission
IEEE
Institute of Electrical and Electronic Engineers
ILSP
Integrated Logistics Support Plan IM
Information Management,
Investment Management
IMP
Integrated Master Plan
IMS
Integrated Master Schedule
INCOSE
International Council on Systems Engineering
Int
Integration
IOC
Initial Operational Capability
IOT&E
Initial Operational Test and Evaluation IP
Implementation Process
IRS
Interface Requirements Specification
EPVP
End Products Validation Process
EVM
Earned Value Management F
Function, Functional
Final
FAB
Final Allocated Baseline
FCA
Functional Configuration Audit
FFB
Final Functional Baseline
FFBD
Functional Flow Block Diagram
FFD
Functional Flow Diagram
FOC
Full On Capability
FOS
Family of Systems
FPB
Final Product Baseline
FRB
Final Requirements Baseline
FRP
Full Rate Production FW
Firmware
HDBK
Handbook
HDD
Hardware Design Description
HDP
Hardware Development Plan HS
Hardware Specification

18. Acronyms (cont) P Preliminary P3I Pre-Planned Product Improvement PA
Process Area
PAB
Preliminary Allocated baseline
PAP
Product Assurance Plan
PBS
Product Breakdown Structure
PCA
Physical Configuration Audit PD
Preliminary Design
PDR
Preliminary Design Review
PEO
Project Executive Officer
PFB
Preliminary Functional Baseline
PIN
Personal Identification Number
PMP
Program Management Plan PP
Project Planning
PPB
Preliminary Product Baseline
PRB
Preliminary Requirements Baseline
PROC
Process
PWBS
Program Work Breakdown Structure QM
Quality Management
ISO
International Organization for Standardization
ISR
Interim System Review
JOC
John O. Clark
JROC
Joint Requirements Oversight Council
LRIP
Limited Rate Initial Production
MIL-STD
Military Standard MO
Manual Operation MS
Milestone MT
Maintenance N2
N x N
NAVAIR
Naval Air Systems Command
NAVSEA
Naval Sea Systems Command
NSS
National Security Systems
OBS
Organizational Breakdown Structure
OCD
Operational Concepts Document Op
Operation
ORD
Operational Requirements Document
OSD
Office of the Secretary of Defense
OSJTF
Open Systems Joint Task Force

19. Acronyms (cont) SOS System of Systems SOW Statement of Work SPCA
System Physical Configuration Audit
SPDR
System Preliminary Design Review SR
Stakeholder Requirements
SRD
System Requirements Document
SRR
System Requirements Review
SRS
Software Requirements Specification SS
System Specification
Software Specification
SSCDR
Subsystem Critical Design Review
SSDD
System/Subsystem Design Description
SSFR
Subsystem Functional Review
SSPDR
Subsystem Preliminary Design Review
SSR
Software Specification Review
SSRR
Subsystem Requirements Review
SSS
System/Subsystem Specification
STCR
System Test Completion Review
STRR
System Test Readiness Review R
Requirement RA
Requirements Analysis
RDP
Requirements Definition Process
RESM
Resource Management
RM&AP
Reliability, Maintainability and Availability Plan
RMP
Risk Management Plan S
System
SAP
Systems Analysis Process
SBS
System Breakdown Structure
SCDR
System Critical Design Review
SDD
Software Design Description
SDP
Software Development Plan
Solution Definition Process SE
Systems Engineering
SEDS
Systems Engineering Detailed Schedule
SEMP
Systems Engineering Master Plan
SEMS
Systems Engineering Master Schedule
SFR
System Functional Review
SLCM
System Life Cycle Management Process

20. Acronyms (cont) TLR Top Level Requirements TP Training Plan
Transition to Use Process
TPM
Technical Performance Measurement TR
Test Readiness
TRM
Technical Review Manual
Trn
Training
TSC
Theater Surface Combatants U
Updated
USD
Under Secretary of Defense
Val
Validation
Ver
Verification
WBS
Work Breakdown Structure
Sup
Supply SV
System Verification
Schedule Variance
SVP
System Verification Process
SVR
System Verification Review SW
Software
SWCDR
Software Critical Design Review
SWFCA
Software Functional Configuration Audit
SWFR
Software Functional Review
SWPCA
Software Physical Configuration Audit
SWPDR
Software Preliminary Design Review
SWRR
Software Requirements Review
SWTCR
Software Test Completion Review
SWTRR
Software Te3st Readiness Review
T Pln
Test Plan
T Proc
Test Procedures
T Rpt
Test Report TC
Test Completion
TEMP
Test and Evaluation Management Plan