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)


©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


©2019 Caltech

The Systems Engineering V‐Model

Systems Engineering for Intelligent Transportation Systems, U.S. Department of Transportation


©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


©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


©2019 Caltech

Requirements Engineering is An Iterative Process

Requirements Analysis

Requirements Specification

Requirements Validation

Requirements Elicitation

RequirementsManagement


©2019 Caltech

Discussion: What Requirements Challenges Have You Experienced?


©2019 Caltech

Schedule

08:00 am Breakfast






12:00 pm Lunch



01:30 pm Adjourn


©2019 Caltech

Stakeholder Expectations Definition Process

NASA SE Handbook


©2019 Caltech

Systems Definition

Concept Definition

Concept Definition Drives System Definition

Business or MissionAnalysis

Stakeholder Needs &

Requirements

FunctionalArchitecture

Logical Architecture

Physical Architecture

SEBOK


©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


©2019 Caltech

Cycle of Stakeholder Needs

Cited in SEBoK. Permission granted by Singery'Com


©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


©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• …


©2019 Caltech

Schedule

08:00 am Breakfast






12:00 pm Lunch



01:30 pm Adjourn


©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


©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


©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


©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


©2019 Caltech

Functional Hierarchy Example

Note each function is in the form Active verb ‐ object


©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


©2019 Caltech

Schedule

08:00 am Breakfast






12:00 pm Lunch



01:30 pm Adjourn


©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!


©2019 Caltech

Verification and Validation (Incremental and End‐Item)

INCOSE Guide for Writing Requirements


©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?


©2019 Caltech

Cycle of Stakeholder Needs

Cited in SEBoK. Permission granted by Singery'Com


©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


©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)


©2019 Caltech

Schedule

08:00 am Breakfast






12:00 pm Lunch



01:30 pm Adjourn


©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


©2019 Caltech

Sample Specification: National Airspace System


©2019 Caltech

Modern Approaches Typically Capture Requirements in a Tool


©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>]


©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


©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



©2019 Caltech

Characteristics of Individual Requirement Statements


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


©2019 Caltech

Characteristics of Sets of 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)


©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


©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



AssemblyRequirements

Assembly Requirements

Assembly Requirements


©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


©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


©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


©2019 Caltech

Schedule

08:00 am Breakfast






12:00 pm Lunch



01:30 pm Adjourn


©2019 Caltech

Schedule

08:00 am Breakfast






12:00 pm Lunch



01:30 pm Adjourn


©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?)


©2019 Caltech

Verification and Validation are Performed Throughout the Lifecycle


©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


©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


©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.


©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


©2019 Caltech

Schedule

08:00 am Breakfast






12:00 pm Lunch



01:30 pm Adjourn


©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


©2019 Caltech

Traditional Systems Engineering

RequirementsSystems

Architecture

Stakeholder Needs

ImplementationBusiness Analysis

Detailed Design

Validation

Verification


©2019 Caltech

Model‐Based Approach

Ref: Vitech


©2019 Caltech

MBSE Domains

Ref: Vitech


©2019 Caltech

SysML Diagram Taxonomy


©2019 Caltech

No Magic MagicGrid (Refine/Derive/Satisfy)


©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


©2019 Caltech

Schedule

08:00 am Breakfast






12:00 pm Lunch



01:30 pm Adjourn

See http://ctme.caltech.edu for additional training


Documents

Requirements Management Tutorial