Download - Requirements Management Tutorial
©2019 Caltech
Requirements Management TutorialINCOSE‐SD – 1 November 2019
Rick Hefner, Caltech ([email protected])
Nov 2019 INCOSE‐SD Requirements Tutorial1
©2019 Caltech
Background
Requirements are one of the most critical aspects of modern systems development and also one of the least understood
This tutorial will present a comprehensive overview of industry best practices for requirements development, covering elicitation, analysis, validation, specification, allocation, and verification
An introduction to model‐based techniques for developing requirements will also be provided
Attendees will leave with a thorough understanding of techniques and tools for handling common requirements challenges
Material is taken from Caltech professional training (http://ctme.caltech.edu)
Nov 2019 INCOSE‐SD Requirements Tutorial2
©2019 Caltech
Schedule
08:00 am Breakfast
08:15 am Introduction to Requirements Development
08:45 am Requirements Elicitation
09:30 am Requirements Analysis
10:30 am Requirements Validation
11:00 pm Requirements Specification and Allocation
12:00 pm Lunch
12:15 pm Requirements Verification
01:00 pm MBSE Approaches to Requirements
01:30 pm Adjourn
Nov 2019 INCOSE‐SD Requirements Tutorial3
©2019 Caltech
The Systems Engineering V‐Model
Systems Engineering for Intelligent Transportation Systems, U.S. Department of Transportation
Nov 2019 INCOSE‐SD Requirements Tutorial4
©2019 Caltech
Key SE Representations and Their Purpose
Ensure requirements are clear,complete, consistent
ConOps/OpsCon(behavior diagrams)
Functional architecture
Design Structure Matrix (functional)
Understand the problem context
Mission statement
Table of stakeholders and their needs
Context diagram
System boundary diagram
Nov 2019 INCOSE‐SD Requirements Tutorial5
©2019 Caltech
A Systems Thinking (Systems Engineering) Perspective to Defining Stakeholder Needs and Requirements
Systems thinkers believe it is critical to spend more time up‐front to thoroughly understand the customer’s context, problem, constraints, etc. – not just start designing!
This time is made‐up in later phases
Nov 2019 INCOSE‐SD Requirements Tutorial6
©2019 Caltech
Requirements Engineering is An Iterative Process
Requirements Analysis
Requirements Specification
Requirements Validation
Requirements Elicitation
RequirementsManagement
Nov 2019 INCOSE‐SD Requirements Tutorial7
©2019 Caltech
Discussion: What Requirements Challenges Have You Experienced?
Nov 2019 INCOSE‐SD Requirements Tutorial8
©2019 Caltech
Schedule
08:00 am Breakfast
08:15 am Introduction to Requirements Development
08:45 am Requirements Elicitation
09:30 am Requirements Analysis
10:30 am Requirements Validation
11:00 pm Requirements Specification and Allocation
12:00 pm Lunch
12:15 pm Requirements Verification
01:00 pm MBSE Approaches to Requirements
01:30 pm Adjourn
Nov 2019 INCOSE‐SD Requirements Tutorial9
©2019 Caltech
Stakeholder Expectations Definition Process
NASA SE Handbook
Nov 2019 INCOSE‐SD Requirements Tutorial10
©2019 Caltech
Systems Definition
Concept Definition
Concept Definition Drives System Definition
Business or MissionAnalysis
Stakeholder Needs &
Requirements
FunctionalArchitecture
Logical Architecture
Physical Architecture
SEBOK
Nov 2019 INCOSE‐SD Requirements Tutorial11
©2019 Caltech
Business or Mission Analysis
Understand a mission/market problem or opportunity• Review the enterprise mission, vision, and concept of operations
• Define the mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without focusing on a solution
Examine and evaluate the solution space• Identify the main stakeholders (customers, users, administrations, regulations, etc.)
• Identify high level operational modes or states, or potential use cases
• Identify candidate solutions that span the potential solution space
Nov 2019 INCOSE‐SD Requirements Tutorial12
©2019 Caltech
Cycle of Stakeholder Needs
Cited in SEBoK. Permission granted by Singery'Com
Nov 2019 INCOSE‐SD Requirements Tutorial13
©2019 Caltech
Methods for Collecting Stakeholder Needs and Requirements
Context diagram
Concept of operations
Review of technical documentation
Review of problem reports, warranty returns, test problems
Brainstorming or problem‐solving sessions
Interviews
Surveys/questionnaires
Market analysis
Reverse engineering
Simulations
Prototyping
Benchmarking
Nov 2019 INCOSE‐SD Requirements Tutorial14
©2019 Caltech
Stakeholder Requirements
Stakeholder needs and requirements represent the views of the users, acquirers, customers, and other stakeholders as they relate to the problem (or opportunity)• Form the basis of system requirements activities
• Form the basis of system validation and stakeholder acceptance
The solution is only conceptual (“black‐box”) at this point• We want to explore all the requirements before finalizing a design
Stakeholder Needs
Customer • Low cost• ...
Operator • Easy to use• …
Manufacturing • Easy to manufacture• …
Nov 2019 INCOSE‐SD Requirements Tutorial15
©2019 Caltech
Schedule
08:00 am Breakfast
08:15 am Introduction to Requirements Development
08:45 am Requirements Elicitation
09:30 am Requirements Analysis
10:30 am Requirements Validation
11:00 pm Requirements Specification and Allocation
12:00 pm Lunch
12:15 pm Requirements Verification
01:00 pm MBSE Approaches to Requirements
01:30 pm Adjourn
Nov 2019 INCOSE‐SD Requirements Tutorial16
©2019 Caltech
Product Requirement Types in Industry
Functional
•What must the system do?
Performance
• How well must it be done?
Design Constraints
•What design characteristics must be followed or achieved?
• Typically set by a higher authority for business reasons
Quality Attributes
• How will the users determine the quality of the system, given the other requirements?
• Usability, maintainability, etc.
• Specification must include agreement on how it will be measured
Nov 2019 INCOSE‐SD Requirements Tutorial17
©2019 Caltech
Requirements Analysis (or Functional Analysis)
The systematic process of identifying, describing, and relating the functions a system should perform to fulfill its goals and objectives• Identifies and links system functions, trade studies, interface characteristics, and rationales to requirements
• Based on the ConOps for the system of interest
Three key steps in performing functional analysis are:1. Translate top‐level requirements into functions that should be
performed to accomplish the requirements
2. Decompose and allocate the functions to lower levels of the product breakdown structure
3. Identify and describe functional and subsystem interfaces
NASA SE Handbook, Section 4.3.1.2.2
Nov 2019 INCOSE‐SD Requirements Tutorial18
©2019 Caltech
Functional Decomposition
Stated in the form<the system> shall <active verb> <object><qualifiers>
Functional decomposition organizes functions, subfunctions, etc., in a functional hierarchy (functional architecture)
System = home
Provide Access & Mobility
Provide Space
Provide Living Space
Provide Vehicle Storage
Provide Storage
Provide Object Storage
Provide Food& Drink
Provide Nourishment
Provide Waste Disposal
Provide Physical Security
Provide Protection
Provide Physical Protection
Provide Sleeping
Provide Personal Cleaning
Provide Seating
Provide Comfort
Provide Climate
Provide VideoEntertainment
Provide Audio Entertainment
Provide Computing Entertainment
Provide Telephony
Provide Human Habitat
Provide Communications & Entertainment
Nov 2019 INCOSE‐SD Requirements Tutorial19
©2019 Caltech
Sample Functional Analysis Methodologies
Functional architecture• Use to describe top‐down definition of system functions
Functional flow block diagram• Used to show the sequence of all functions to be accomplished by a system
Design Structure Matrix (DSM)• Used to develop functional or physical interfaces
By iterating among the different
representations, the list of
functions can be checked for completeness and consistency
Nov 2019 INCOSE‐SD Requirements Tutorial20
©2019 Caltech
Functional Hierarchy Example
Note each function is in the form Active verb ‐ object
Nov 2019 INCOSE‐SD Requirements Tutorial21
©2019 Caltech
Exercise
Develop the 1st level functional hierarchy for an autonomous taxi
When complete, construct a 2nd level hierarchy for one of the top‐level functions
Small group
Nov 2019 INCOSE‐SD Requirements Tutorial22
©2019 Caltech
Schedule
08:00 am Breakfast
08:15 am Introduction to Requirements Development
08:45 am Requirements Elicitation
09:30 am Requirements Analysis
10:30 am Requirements Validation
11:00 pm Requirements Specification and Allocation
12:00 pm Lunch
12:15 pm Requirements Verification
01:00 pm MBSE Approaches to Requirements
01:30 pm Adjourn
Nov 2019 INCOSE‐SD Requirements Tutorial23
©2019 Caltech
Verification and Validation
Verification – proving the specified requirements have been met (Did we build the system right?)
Validation – determining to what extent the user needs have been met (Did we build the right system?)
These definitions reflect the industry consensus – some texts (and organizations) use these terms differently/backwards!
Nov 2019 INCOSE‐SD Requirements Tutorial24
©2019 Caltech
Verification and Validation (Incremental and End‐Item)
INCOSE Guide for Writing Requirements
Nov 2019 INCOSE‐SD Requirements Tutorial25
©2019 Caltech
Requirements Validation (My Definition)
Determining the extent to which the requirements reflect user needs
The goal of requirements validation is to seek out and correct problems before resources are committed to implementing the requirements – addresses specific requirements and the requirements collection as a whole
Do they meet the stakeholders’ intentions?
Do they capture the agreement and understandings between developer and acquirer about what to build, in a manner that ensures a common understanding across the project team and among the stakeholders?
Do they strike a reasonable balance among cost, schedule, and risk?
Nov 2019 INCOSE‐SD Requirements Tutorial26
©2019 Caltech
Cycle of Stakeholder Needs
Cited in SEBoK. Permission granted by Singery'Com
Nov 2019 INCOSE‐SD Requirements Tutorial27
©2019 Caltech
Common Requirements Problems
Including design and implementation decisions along with the requirements statements
Requirements that express an exact solution or design
Requirements that state requirements on lower‐level components
Subjective (unverifiable) requirements
Undocumented assumptions
Poorly written, i.e., requirements are not:• Clear – means the same to the requirement provider and designer
• Complete ‐ includes all information necessary to understand the customer’s need, no missing requirements
• Consistent – all conflicts with other requirements resolved
Nov 2019 INCOSE‐SD Requirements Tutorial28
©2019 Caltech
Requirement Validation Activities
Conduct requirements reviews to validate that requirements are correct, unambiguous, complete, consistent, ranked for importance, verifiable (testable), modifiable, and traceable
Use prototyping to demonstrate assumptions and confirm mutual interpretations
Validate the concept of operations developed during analysis
Plan how each requirement will be verified (establish acceptance tests)
Nov 2019 INCOSE‐SD Requirements Tutorial29
©2019 Caltech
Schedule
08:00 am Breakfast
08:15 am Introduction to Requirements Development
08:45 am Requirements Elicitation
09:30 am Requirements Analysis
10:30 am Requirements Validation
11:00 pm Requirements Specification and Allocation
12:00 pm Lunch
12:15 pm Requirements Verification
01:00 pm MBSE Approaches to Requirements
01:30 pm Adjourn
Nov 2019 INCOSE‐SD Requirements Tutorial30
©2019 Caltech
What is a Specification?
A document that completely defines the constraints and the functional and performance requirements for a specific element and the criteria for determining whether those requirements are met
Records the bilateral agreement resulting from the negotiations between giver and receiver
Specification often refers to a documented set of requirements (although the term is often used in different ways)
Scope/Quality/Performance
Time/Schedule Cost/Resources
Triple Constraint
Nov 2019 INCOSE‐SD Requirements Tutorial31
©2019 Caltech
Sample Specification: National Airspace System
Nov 2019 INCOSE‐SD Requirements Tutorial32
©2019 Caltech
Modern Approaches Typically Capture Requirements in a Tool
Nov 2019 INCOSE‐SD Requirements Tutorial33
©2019 Caltech
Requirement Syntax
<requiree> is typically the system‐of‐interest
The optional <qualifier> may identify when/where/how the requirement applies (e.g., “when the vehicle is stopped”)
One requirement per sentence, straightforward language
“Shall”, not “will” or “must” (convention)
“Shall not” is permissible
“Should” or “may” indicate preferences, but are not binding
No design choices unless absolutely necessary
<requiree> shall <active verb> <object> [<qualifier>]
Nov 2019 INCOSE‐SD Requirements Tutorial34
©2019 Caltech
Discussion – Reviewing RequirementsU. S. Army Signal Corps Specification No. 486 dated Dec 23, 1907
Are these requirements stated clearly in proper syntax?
1. The flying machine shall be quickly and easily assembled and taken apart and packed for transportation in army wagons
2. The flying machine shall be assembled and put into operating condition in about one hour
3. The flying machine shall carry two persons having a combined weight of about 350 pounds, also sufficient fuel for a flight of 125 miles
4. The flying machine shall have a speed of forty miles per hour in still air
5. The flying machine shall be provided with some device to permit a safe descent in case of an accident to the propelling machinery
6. The flying machine shall be sufficiently simple in construction and operation to permit an intelligent man to become proficient in its use within a reasonable length of time
Nov 2019 INCOSE‐SD Requirements Tutorial35
©2019 Caltech
Characteristics of Good Requirements
Individual Requirements
C1‐ Necessary
C2 – Appropriate
C3 – Unambiguous
C4 – Complete
C5 – Singular
C6 – Feasible
C7 – Verifiable
C8 – Correct
C9 ‐ Conforming
Sets of Requirements
C10 – Complete
C11 – Consistent
C12 – Feasible
C13 – Comprehensible
C14 – Able to Be Validated
INCOSE Guide for Writing Requirements
Nov 2019 INCOSE‐SD Requirements Tutorial36
©2019 Caltech
Characteristics of Individual Requirement Statements
INCOSE Guide for Writing Requirements
C1 – NECESSARY An essential capability, characteristic, constraint, or quality factorC2 – APPROPRIATE The specific intent and amount of detail of the requirement is
appropriate to the level (level of abstraction) of the entity to which it refers
C3 – UNAMBIGUOUS Stated in such a way that it can be interpreted in only one way
C4 – COMPLETE Sufficiently describes the necessary capability, characteristic, constraint, or quality factor to meet the entity need without needing other information to understand the requirement
C5 – SINGULAR States a single capability, characteristic, constraint, or quality factor
C6 – FEASIBLE Can be realized within entity constraints (e.g., cost, schedule, technical, legal, ethical, regulatory) with acceptable risk
C7 – VERIFIABLE Structured and worded such that its realization can be proven (verified) to the customer’s satisfaction at the level the requirement exists
C8 – CORRECT An accurate representation of the entity need from which it was transformed
C9 ‐ CONFORMING Conforms to an approved standard pattern and style for writing requirements
Nov 2019 INCOSE‐SD Requirements Tutorial37
©2019 Caltech
Characteristics of Sets of Requirements
INCOSE Guide for Writing Requirements
C10 – COMPLETE Stands alone such that it sufficiently describes the necessary capabilities, characteristics, constraints, interfaces, standards, regulations, and/or quality factors to meet the entity needs without needing other information
C11 – CONSISTENT Contains individual requirements that are unique, do not conflict with or overlap with other requirements in the set, and the units and measurement systems they use are homogeneous – the language used within the set of requirements is consistent (i.e., the same word is used throughout the set to mean the same thing)
C12 – FEASIBLE Can be realized within entity constraints (e.g., cost, schedule, technical, legal, ethical, regulatory) with acceptable risk
C13 – COMPREHENSIBLE Clear as to what is expected by the entity and its relation to the system of which it is a part
C14 – ABLE TO BE VALIDATED
Able to be proven the requirement set will lead to the achievement of the entity needs within the constraints (such as cost, schedule, technical, legal and regulatory compliance)
Nov 2019 INCOSE‐SD Requirements Tutorial38
©2019 Caltech
Exercise – Good Requirements
Select a requirement below and determine which characteristics it violates and re‐write it properly
1. The flying machine shall be quickly and easily assembled and taken apart and packed for transportation in army wagons
2. The flying machine shall be assembled and put into operating condition in about one hour
3. The flying machine shall carry two persons having a combined weight of about 350 pounds, also sufficient fuel for a flight of 125 miles
4. The flying machine shall have a speed of forty miles per hour in still air
5. The flying machine shall be provided with some device to permit a safe descent in case of an accident to the propelling machinery
6. The flying machine shall be sufficiently simple in construction and operation to permit an intelligent man to become proficient in its use within a reasonable length of time
Nov 2019 INCOSE‐SD Requirements Tutorial39
©2019 Caltech
Requirements Allocation and Traceability
Allocation is the process by which requirements defined at one level (system, segment, element, etc.) are assigned to the parts of the physical architecture at the next lower level (segment, element, subsystem, etc.)
Traceability is the ability to trace (via linkage) a lower level requirement back to its source requirement; bottom to top
System
Assembly
Subsystem SubsystemSubsystem
AssemblyAssembly
System Requirements
Subsystem Requirements
Subsystem Requirements
Subsystem Requirements
AssemblyRequirements
Assembly Requirements
Assembly Requirements
Nov 2019 INCOSE‐SD Requirements Tutorial40
©2019 Caltech
Requirements Allocation
Requirements are decomposed in a hierarchical structure
High‐level requirements are decomposed and allocated to the design elements – if each element can meet its allocated requirements, the top‐level system will meet its requirements
The process is repeated, as requirements are further decomposed and allocated among the elements and sub‐elements
NASA Systems Engineering Handbook
Nov 2019 INCOSE‐SD Requirements Tutorial41
©2019 Caltech
Industry Example of Requirements Allocation
Telescope shall be pointed to AAA degrees accuracy
Spacecraft shall be maintained in a stable orientation to BBB degrees
Pointing commands sent shall be accurate to CCC degrees
Spacecraft orientation shall be known to DDD degrees
The science axis shall be calibrated to EEE degrees accuracy
Gyro to Star Tracker alignment shall be calibrated to FFF degrees
Attitude estimation algorithms shall be accurate to GGG degrees
Nov 2019 INCOSE‐SD Requirements Tutorial42
©2019 Caltech
Requirements Traceability Matrix(Multi‐Dimensional Matrix)
After traceability is established at this level of the logical system hierarchy, the process is repeated at lower levels
Once we reach the level at which physical design will occur, a similar process can be used for the physical architecture
System
Subsystem 2 Subsystem 3Subsystem 1
x
x
x x
Nov 2019 INCOSE‐SD Requirements Tutorial43
©2019 Caltech
Schedule
08:00 am Breakfast
08:15 am Introduction to Requirements Development
08:45 am Requirements Elicitation
09:30 am Requirements Analysis
10:30 am Requirements Validation
11:00 pm Requirements Specification and Allocation
12:00 pm Lunch
12:15 pm Requirements Verification
01:00 pm MBSE Approaches to Requirements
01:30 pm Adjourn
Nov 2019 INCOSE‐SD Requirements Tutorial44
©2019 Caltech
Schedule
08:00 am Breakfast
08:15 am Introduction to Requirements Development
08:45 am Requirements Elicitation
09:30 am Requirements Analysis
10:30 am Requirements Validation
11:00 pm Requirements Specification and Allocation
12:00 pm Lunch
12:15 pm Requirements Verification
01:00 pm MBSE Approaches to Requirements
01:30 pm Adjourn
Nov 2019 INCOSE‐SD Requirements Tutorial45
©2019 Caltech
Verification and Validation
Verification – proving the specified requirements have been met (Did we build the system right?)
Validation – determining to what extent the user needs have been met (Did we build the right system?)
Nov 2019 INCOSE‐SD Requirements Tutorial46
©2019 Caltech
Verification and Validation are Performed Throughout the Lifecycle
Nov 2019 INCOSE‐SD Requirements Tutorial47
©2019 Caltech
Verification Approaches
The goal of Verification is to ensure the system meets its specified requirements
To be cost‐effective, verification is performed throughout the lifecycle to ensure errors do not propagate through the system
Selecting which work products to verify, and how to verify is a strategy question
User needs
Peer review
System architecture
Subsystemdesign
Component design
Component construction
Subsystem assembly
System specification
Subsystemrequirements
Component requirements
Unit test
System assembly
System test
Nov 2019 INCOSE‐SD Requirements Tutorial48
©2019 Caltech
Requirements Types and Typical Verification Methods
FunctionalWhat must the system do?
DemonstrationUse of system, subsystem, or component operation to show that a requirement can be achieved
PerformanceHow well must it be done?
TestUse of system, subsystem, or component operation to obtain detailed data to verify performance or to provide sufficient information to verify performance through further analysis
Design ConstraintsWhat design characteristics must be followed or achieved?
InspectionVisual examination
Quality AttributesHow will the users determine the quality of the system, given the other requirements?
AnalysisUse of mathematical modeling and analytical techniques to predict the compliance of a design to its requirements based on calculated data or data derived from lower level component or subsystem testing
Nov 2019 INCOSE‐SD Requirements Tutorial49
©2019 Caltech
Example – Verification of a Passenger Auto
Requirement Verification
Functional:The auto shall be capable of travelling in reverse.
Demonstration:A demo where you simply show the auto can travel in reverse.
Performance:The auto shall be capable accelerating from a stop to 60mph in 10 seconds.
Test:The auto’s acceleration is measured with a stopwatch.
Design Constraint:The auto shall use Firestone tires.
Inspection:Observe the tires used on the car.
Quality Attribute:The auto shall be highly reliable.> Overall reliability of the auto shall be .999 as measured by standard XXX.
Analysis:A model is built according to standard XXX, calibrated to physical measurements, and used to compute an overall reliabilitynumber.
Nov 2019 INCOSE‐SD Requirements Tutorial50
©2019 Caltech
Verification Cross‐Reference Matrix (VCRM)
A matrix delineating the verification method and level for each requirement
A – System, B – Subsystem, C Component
1 – Inspection, 2 – Analysis, 3 – Demonstration, 4 – Test
Nov 2019 INCOSE‐SD Requirements Tutorial51
©2019 Caltech
Schedule
08:00 am Breakfast
08:15 am Introduction to Requirements Development
08:45 am Requirements Elicitation
09:30 am Requirements Analysis
10:30 am Requirements Validation
11:00 pm Requirements Specification and Allocation
12:00 pm Lunch
12:15 pm Requirements Verification
01:00 pm MBSE Approaches to Requirements
01:30 pm Adjourn
Nov 2019 INCOSE‐SD Requirements Tutorial52
©2019 Caltech
Model‐Based Systems Engineering (MBSE)
The formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.
‐ INCOSE SE Vision 2020 (INCOSE‐TP‐2004‐004‐02), Sept 2007
Nov 2019 INCOSE‐SD Requirements Tutorial53
©2019 Caltech
Traditional Systems Engineering
RequirementsSystems
Architecture
Stakeholder Needs
ImplementationBusiness Analysis
Detailed Design
Validation
Verification
Nov 2019 INCOSE‐SD Requirements Tutorial54
©2019 Caltech
Model‐Based Approach
Ref: Vitech
Nov 2019 INCOSE‐SD Requirements Tutorial55
©2019 Caltech
MBSE Domains
Ref: Vitech
Nov 2019 INCOSE‐SD Requirements Tutorial56
©2019 Caltech
SysML Diagram Taxonomy
Nov 2019 INCOSE‐SD Requirements Tutorial57
©2019 Caltech
No Magic MagicGrid (Refine/Derive/Satisfy)
Nov 2019 INCOSE‐SD Requirements Tutorial58
©2019 Caltech
Requirements Diagram
Used to display text‐based requirements, the relationships between requirements, and the relationships between requirements and other model elements
Trace ‐ A modification to the supplier element (↑) may result in the need to modify the client element (tail end)
Derive – Client requirement is derived from the supplier requirement
Refine – Client element is more concrete (i.e., less abstract) than the supplier element
Satisfy – Client requirement is fulfilled by the supplier element
Verify – Client requirement is verified by the supplier test case
Nov 2019 INCOSE‐SD Requirements Tutorial59
©2019 Caltech
Schedule
08:00 am Breakfast
08:15 am Introduction to Requirements Development
08:45 am Requirements Elicitation
09:30 am Requirements Analysis
10:30 am Requirements Validation
11:00 pm Requirements Specification and Allocation
12:00 pm Lunch
12:15 pm Requirements Verification
01:00 pm MBSE Approaches to Requirements
01:30 pm Adjourn
See http://ctme.caltech.edu for additional training
Nov 2019 INCOSE‐SD Requirements Tutorial60