1

System Engineer’s Toolbox

1

Compliance Automation, Inc.

INCOSE: NM Enchantment ChapterBy

Cheryl HillAugust 12, 2009

2

Objectives

2

To provide three tools to help you:

• Elicit requirements• Get all the requirements• Communicate better with customers

and developers• Reduce rework due to requirement

defects

333

SCOPE

Requirement Check List

Rationale

4

Toolkit 1: Scope

Scope is an iterative process Drivers and

Constraints

Operational Concepts

InterfacesSchedule

Need

Authority and Responsibility

Assumptions

Risk

Scope isan iterative

process

Goals and objectives

Business Caseor Mission

Budget

5

Why Scope?Effect Of Requirements Definition Investment On Program Costs

20

80

60

40

160

140

120

100

200

180

5 10 15 20 25 30

OMV

GRO 78

GALL

TDRSS

CENHST

EUVE/EP

GOES I-M

ACT

MARS

MAG

SEASATUARS

DESMM

ERB 77

LAND 76

IRAS

TETH

STS LAND 78

GRO 82

ERB 80

VOYAGER

ULYSSES

PION/VENIUE

ISEE

COBE

HEA

Target Total Cost

Requirements Definition and Preliminary Design

Tar

get

Co

stA

ctu

al –

Tar

get

Co

st

Why are you running so fast when you don’t know where you are going?

German proverb

6

NEED

• NASA – vehicle to replace shuttle

NASA – make human access to space safer and cheaper

7

NEED

• IS– derived from a problem assessment– why we are doing something– a way to ensure we stay on track

• IS NOT– the product– subject to change

• MUST BE– in writing– available to all

8

Goals and Objectives

• Goals – define specific things to

accomplish to meet the need

• Objectives – define how we will know when we

get there

Transport crew to and from space station

Twice as safe as shuttle

9

Stakeholders

Engineering

Software

Logistics

Operations

Testing

Manufacturing

Maintenance

SystemEngineering

Customer

ReliabilityDevelopers

Security

Training

Safety

Quality

Procurement

10

External Interfaces

database

com

man

d

stat

uscommand & data

Your System

Test

Physical

Power

11

Operational Concepts

Maintenance

Development

Test and Verification

Transportation

Deployment

Installation

Integration

TransitionManufacturing Training

Logistics

Upgrades

Operations

Storage

Disposal

Life-cycle

12

Toolkit 2: Requirement Checklist

• Requirement wording• Ambiguities• Implementation• Operations

13

Good Requirements

• Needed• Verifiable• Attainable

– Technically– Cost– Schedule

Customer-Centered Products, p. 119

Mandatory Characteristics

14

Characteristics of Good Requirements

Improving Communications• One Thought• Concise• Simple• Stated Positively• Grammatically Correct• Can only be understood one

way

Customer-Centered Products, p. 119

15

What a requirement must state

Who

What

Connect

• WHO is responsible– The system– The software– The structure

• WHAT shall be done– operate at a power

level of … – acquire data from …– withstand loads up

to …

16

Use The Correct Terms

• Requirements are binding - Shall

• Facts or Declaration of Purpose - Will

• Goals are non-mandatory provisions - Should

• Don’t use must

17

Avoid Ambiguous Terms• etc.• Maximize• Sufficient • User-friendly• Robust• High speed

• Including, but not limited to• Minimize• Adequate• Easy• Ultra-low power• TBD

Customer-Centered Products, p. 162-4

• Indefinite pronouns - this

- these

- it

- and/or

- be able to/be capable of

• Accommodate • Support

18

• How: The aircraft shall have three engines (DC-3 initial requirements).

• What: The aircraft shall meet the operation requirements with a single engine out.

The magic of “why”

Implementation Versus Requirements

How: The System shall include flight performance instrumentation.

What: The System shall measure its flight performance.

What do you want to verify?

19

Operations Statements

Requirement• The operator shall have the capability to change

the given thread selection.

Rewrite• The system shall allow a change of thread

selection during operations.• The system shall provide a user interface for

thread selection changes.

20

Toolkit 3: Rationale

• What• How• Why

21

Rationale – defines

• Why a requirement is needed• What assumptions were made• What design effort drove the requirement• Information to help understand the

requirement• Source of any numbers

22

What NOT to Put in Rationale

• A rewrite of the requirement• Hidden requirements• Copy of another requirement’s rationale • Everything you know on the topic

23

Rationale Benefits

• Key to understanding• Reduce interpretation problems• Facilitate maintenance and

upgrades• Preserve corporate knowledge

24

Example

• Requirement: The truck shall have a height of no more than 14 feet.

• Rationale: Ninety-nine percent of all U.S. interstate highway overpasses have a 14-foot or greater clearance. (Assumption: The truck will be used primarily on U.S. interstate highways for long-haul, intercity freight in the U.S.)

25

SCOPE

Requirement Check List

Rationale

Your Tool Box