The Importance of Requirements in the System Engineering and Integration (SE&I) Process

What do I need? What must be accomplished? ◦ This is the essence of a requirement ◦ Seems simple enough

Every personal buying decision ◦ A requirement exercise ◦ If you can’t clearly define what you need, it’s unlikely you’ll be satisfied with the resulting purchase

You’re asked to give a presentation ◦ You aren’t given the date, place, time, subject,

attendees, or intent ◦ What are your odds of success?

2

Consistency The only way to get what you want Enables Faster, Better, Cheaper (if it can happen at

all) The alternative has proved repeatedly to be ugly

80% of product defects are rooted in poor

requirements

3

Rework and “Gold Plating” ◦ Schedule delays ◦ Cost growth

Examples ◦ Y2K “bug” ◦ Waste Management Inc. ($100M) ◦ FAA Advanced Automation System ($2.5B) ◦ Boeing 747 – 767 aircraft 777 – success (~15% spent on requirements definition) ◦ NASA’s labor distribution and tracking system

4

Culture ◦ Fix it later ◦ Pressure from management

Corporate Management Myths ◦ Everyone can write requirements ◦ Everyone knows what this project is all about ◦ Nothing can be done about bad requirements

Customers ◦ May not understand their own needs ◦ Poor communications ◦ Requirement developers forced to make assumptions ◦ May describe solutions, not needs

5

Scope Product

Develop Operational Concepts

Identify Interfaces

Write Requirements

Capture Rationale

Level Requirements

Assess Verification

Format Requirements

Baseline Requirements

Requirements Definition Process

6

7

Where Do Requirements Fit In?

Define Requirements

Design

Manufacture

Verify

Operate

8

Define the Scope FIRST ◦ Scope = What is germane to the project? What is the Need? What are the Goals and Objectives? What are your assumptions?

Document them explicitly Validate – reject/modify those that cannot be validated

◦ State the Business Case ◦ Operations Concept How will the product be developed, tested, deployed, and used?

◦ What are the Boundaries and Constraints? Cost, schedules, expertise, ethics, politics

◦ Must communicate Scope clearly and review regularly ◦ No clear Scope? (International Space Station) Multiple restarts Wasted dollars

◦ No boundaries? Divergence

◦ Work done before Scope definition: largely wasted ◦ Scope definition must be COMMONLY UNDERSTOOD

9

Scenarios describing how a product will be: ◦ Used ◦ Manufactured ◦ Tested ◦ Installed ◦ Stored ◦ Decommissioned

Software = use cases Spacecraft = Ops Plan or Design Reference

Mission (DRM)

10

Why develop Ops Concepts? ◦ Addresses the two major classes of requirement errors: Missing requirements Conflicting requirements

◦ Relatively easy to generate ◦ Almost everyone can understand them ◦ Builds consensus among stakeholders ◦ Reduces requirement debates later on ◦ Illuminates user interfaces ◦ Customers, users, fabricators: “Is the product feasible?” ◦ Lays the foundation for future verification testing

11

A complex system is made up of subsystems ◦ System = Highest Level ◦ Write System Level requirements first

Subsystems ◦ Number of lower levels = f(System complexity) ◦ Can’t write subsystem requirements until the

System function is well understood This problem plagued CEV

12

13 13

Requirements Flowdown at NASA Mission

Objectives

Level I Mission Reqts

Programmatics • Cost • Schedule • Constraints

Defined System Functional

Requirements Environmental

And Other Design Requirements and

Guidelines

Institutional Constraints

Assumptions System

Performance Requirements

Subsystem A Functional and Performance Requirements

Subsystem X Functional and Performance Requirements

Allocated Reqts Derived Reqts

NASA Headquarters

Implementing NASA Center

Level II

Level III

Why worry about requirement levels? ◦ Keeps low level requirements out of high level

documents May constrain System design options May prevent achieving optimum design ◦ Facilitates tracking and traceability Are the higher level requirements implemented at the

lower levels? Are there lower level requirements not justified by

higher level requirements? Potential “Gold plating” Are there missing requirements at the higher level?

14

15 15

Requirement Levels

System

Design

Design Design

Simulations Prototypes Models

Hardware Software Test

Equipment

System requirements define what the system must do.

System design: how the System will work and defines its segments.

Segment requirements define what each segment must do.

Segment design: how each segment will work and defines its

subsystems.

Subsystem requirements define what each subsystem must do.

Design

Allocation ◦ Identify the subsystems that will satisfy

System requirements ◦ Subsystem requirements must be

traceable to a “parent” requirement at the System level (or the next highest level) ◦ Orphans: lower level requirements not

justified by a higher level requirement

16

17

Allocation of Requirements

Reqt #33

Reqt #671

Reqt #366

Design

System Specification

Hardware Software Test

Equipment

Space Shuttle ◦ Development: 1970 – 1981 ◦ Service: 30 years

Max Faget had a vision ◦ We will build America’s next spacecraft ◦ Launch like a rocket, land like an airplane ◦ Reusable ◦ Low G-levels (3 Gs max) ◦ “Shuttle” back and forth to LEO Carry satellites Resupply Space Station Retrieve and service satellites

◦ Will have a crew of x, weigh y, and land at speeds < z ◦ Faget tasked a small team to flesh out his vision

Was the lack of ‘pervasive’ technology beneficial? ◦ Requirements were hand written ◦ Typed by secretaries (who served multiple engineers) ◦ Were reviewed up the line by a knowledgeable person

18

Took 25 years to complete ◦ Not all due to requirements issues ◦ Politics played a significant part

Two major restarts ◦ $500M overrun resulting in contractor change ◦ Political redirection to include international partners Primarily directed toward saving Russia Ended up saving the Space Station

Requirements written by a large team ◦ Shuttle lessons were consciously ignored ◦ Requirements integration a nightmare

Even Station users were invited to write requirements No experienced leader No well defined scope (vision) – open ended Ultimately, the Prime Contractor wrote the requirements

for NASA’s approval

19

20

Program Structure at NASA

ANTARES Project

ARES Project

ORION Project

Level III

Level II

X

X

X

A good requirement clearly states a verifiable and attainable need ◦ Need – someone has to deem it to be necessary ◦ Verifiable – by analysis, test, or demonstration ◦ Attainable – budget, technical, schedule ◦ Clear – cannot be misunderstood

Use standard requirement terminology ◦ Shall => Requirements ◦ Will => Statements of Fact ◦ Should => Goals

Shall is a powerful word ◦ Identifies requirements that must be verified ◦ Every Shall is contractually binding

21

Bad assumptions Specifying implementation instead of

requirements Describing operations instead of writing

requirements Using incorrect or ambiguous terms * Bad grammar or poor sentence structure Unverifiable requirements Using unverifiable words * Omitting requirements Over specifying requirements

22

Ambiguous words ◦ support ◦ et cetera (etc.) ◦ but not limited to ◦ and/or

Unverifiable words ◦ flexible small ◦ adequate large ◦ user-friendly easy ◦ appropriate quickly ◦ fast light-weight

23

Requirement # Document Paragraph Shall Statement Verification Success

Criteria Verification

Method Performing

Organization Result

xy.01 A401022012.08

2.1.3.1 In succession, for each axis, GN&C system shall command translation jets on for two secionds. S/C shall then coast for two seconds. GN&C shall then command Vs/c = 0 cm/s ± 0.1 cm/s.

S/C translates parallel to the active axis and final velocity is within the specified range.

Analysis and simualtion

GN&C TPS xx1

xy.02 A401022012.08

2.1.3.2 In succession about each axis, GN&C system shall rotate s/c 180 degrees (± 2 degrees) from its current orientation and hold that position for 30 seconds ± 0.05 degrees.

S/C rotates to the correct angle and is able to maintain its attitude within the specified range.

Analysis and simulation

GN&C TPS xx2

24

What Managers Say ◦ Adjust schedule ◦ Ambitious ◦ Aggressive ◦ Challenge ◦ Exciting ◦ Historical ◦ Learning experience ◦ Less than candid ◦ Opportunity ◦ New opportunity ◦ Project transfer ◦ Pessimistic ◦ Resource constrained ◦ Scenario ◦ Strong personality ◦ Strongly encouraged ◦ We

What Engineers Hear ◦ Slip Schedule ◦ Unlikely ◦ Very unlikely ◦ Dirty job that no one wants ◦ Frightening ◦ No one remembers why ◦ Mistake ◦ Boldface lie ◦ Problem ◦ Surprise ◦ Start project over again ◦ Most likely to occur ◦ Not getting done ◦ Fairy tale ◦ Obnoxious ◦ Ordered on pain of death ◦ You

25