1 the engineering design of systems: models and methods chapter 6 – requirements and defining the...

1

The Engineering Design of Systems: Models and Methods

Chapter 6 – Requirements and Defining the Design Problem

MG587 Systems Engineering

Let’s review….• Overall goal is to specify and ultimately build a large,

complex system.

• Use a ‘systems approach’ to develop documentation and a ‘model’ for the system.

• Start with stakeholder input.

• The systems model has many sections that describe as much as we can about the system – written, visual, and graphical.

• The process followed is key to a successful outcome.

• Linkages between sections/components is key to a successful outcome.

2

Key topics for this week

1. Review of how we get to originating requirements.2. All about requirements

– Different types– Where they come from– How to write them

3. The rules, regs, and connections between operational concept, ESD (External Systems Diagram), objectives hierarchy, and requirements.

4. A detailed look at the elevator case study5. Examples –

– ATM System– Lawnmower

3

Two concepts for “Requirements”

4

1. ‘Originating or Stakeholder Requirements’ – collection of information, scenarios, sketches, prose to describe what a system should do.

2. ‘Requirements’ – the written statements that describe inputs, outputs, and other aspects of system performance.

3. In either case, goal is to collect and describe stakeholder wants/needs, system vision, mission, constraints, and performance objectives. Build the

Right System

5

Levels of Requirements

Mission Requirements

Originating Requirements

System Requirements

Component Requirements

CI Requirements

Derived Requirements

Figure 6.1

Stakeholder Requirements

CI’s are “Configuration Items”

6

Originating/Stakeholder Requirements Development

OperationalConcept

Stakeholders

Life-CyclePhase

ObjectivesHierarchy

Stakeholders

OriginatingRequirements

Life-CyclePhase

ExternalSystemsDiagramInputs &

Outputs

Inputs &Outputs

CompleteInputs &Outputs

Objectives

Validation &AcceptanceTest Scenarios

Figure 6.11


7

The Big Picture – Redux

OperationalConcept

Stakeholders

Life-CyclePhase

ObjectivesHierarchy

Stakeholders


Life-CyclePhase


Outputs

Inputs &Outputs


Objectives


FunctionalArchitecture

PhysicalArchitecture

OperationalArchitecture

StateTransitionDiagram

DerivedRequirementsand Flowdown

Risk Analysis and

Documentation

Interfaces


8

Life Cycle ORD (Originating Requirements Development)

Requirements must be developed for each phase of the system’s life cycle.

The life cycle phases used in this book are:1. Development (design and integration)2. Manufacturing or production3. Deployment4. Training5. Operations, maintenance, and support6. Refinement7. Retirement

These seven functions should be applied to each stakeholder group and phase of the system’s life cycle. Note that some of these phases may not be relevant for some systems. Most of the discussion from here on out will focus on the operations, maintenance, and support phase.

10

The Importance of Requirements

Is this also a problem for Agile?

Heck yes! The first iteration(s) mostly get risk out.

They don’t “produce” much of anything!

11

Where do requirements come from ?Pragmatic Principle 1 [DeFoe, 1993]

Know the Problem, the Customer, and the Consumer

1. Become the “customer/consumer advocate/surrogate” throughout the development and fielding of the solution.

2. Begin with a validated customer (buyer) need - the problem.3. State the problem in solution-independent terms.4. Know the customer’s (or buyer’s) mission or business objectives.5. Don’t assume that the original statement of the problem is necessarily the best, or even the right one.6. When confronted with the customer’s need, consider what smaller objective(s) is/are key to satisfying

the need, and from what larger purpose or mission the need drives; that is, find at the beginning the right level of problem to solve.

7. Determine customer priorities (performance, cost, schedule, risk, etc.).8. Probe the customer for new product ideas, product problem/shortfalls, identification of problem fixes.9. Work with the customer to identify the consumer (user) groups that will be affected by the system.10. Use a systematic method for identifying the needs and solution preferences of each customer group.11. Don’t depend on written specifications and statements of work. Face-to-face sessions with the different

customer/consumer groups are necessary.12. State as much of each need in quantified terms as possible. However, important needs for which no

accurate or quantified measure exists still must be explicitly addressed.13. Clarify each need by identifying the power and limitations of current and projected technology relative

to the customer’s larger purpose, the environment, and ways of doing business.

12

Roles & Responsibilities in Requirements Generation

Who has the right to have an operational requirement?

Any individual/organization with an operational need involved in the development (design and qualification), production, deployment, training, operation, maintenance, support, refinement, decommissioning of and payment for the system.

What does one call a requirer?

Customer or stakeholder.

Who must respond to the requirer(s) having a requirement and how?

System’s requirements team, a collection of stakeholders and systems engineers. Response is acceptance, request for clarification, or rejection.

By what criteria does the systems requirements team respond?

This team establishes the external systems diagram and fundamental objectives hierarchy of the system, and then determines if the requirement fits within the scope of the system’s boundary and fundamental objective.

13

Roles & Responsibilities in Requirements Generation, Cont.

How does one know that the requirement is "right"?

There is no right or wrong, only acceptable or unacceptable at this time. Over time, some of the system’s originating requirements will change.

How are these requirements conveyed to the people who get involved once a requirer has enunciated a requirement?

The system’s requirements team documents the collection of originating requirements. This Originating Requirements Document (ORD) is distributed to the stakeholders and systems engineers. Included in this document is a discussion of the operational concept of the system and the external systems and context associated with the system, that is, how each stakeholder expects to interact with the system. By reviewing the originating requirements document each stakeholder can see how the requirement suggested fits into the envisioned operation of the system, and can judge whether this vision makes sense from her/his perspective.

14

How To Talk To Stakeholders(Sound familiar?)

• Ulrich and Eppinger guidelines– Start with Usage Scenarios (Use Cases)– Ask ‘context free’ questions (what not how)– Ask to observe them during “stressful”

periods– Give them drafts to modify– Give them prototypes or choices (eye

doctor)– Work with them in groups

SE Design

From Ulrich and Epppinger’s Product Design and Development.

16

Requirements Categories

Input

Output

Functions

ExternalInterfaces

Input/Output

Technology

"ilities"

Cost

Schedule

Technology &System-Wide

CostTrade-offs

PerformanceTrade-offs

Cost-PerformanceTrade-off

Trade Off

Data for allqualification

VerificationPlan

ValidationPlan

AcceptancePlan

System Qualification

Requirement Partitionby Life Cycle Phase

ObjectivesHierarchy

Thresholds & Goals

TradeSpace

Figure 6.4

17

Requirements Categories

Buede Textbook

1. Input/Output2. Technology and

System Wide3. Trade Offs4. Qualification

Raytheon1. Performance2. Environmental3. Interface4. Design

Constraints

18

Requirements Categories for an Medical Device – FDA Related

3.0 Requirements– 3.1 Physical– 3.2 Human Factors– 3.3 Electrical

• 3.3.1 Power• 3.3.2 Interfaces

– 3.4 User Interface– 3.5 Functional– 3.6 Product Performance– 3.7 Diagnostic and

Calibration– 3.8 Environmental

– 3.9 Safety– 3.10 Manufacturing– 3.11 Serviceability– 3.12 Reliability– 3.13 Quality– 3.14 Cost– 3.15 Labeling– 3.16 User

Documentation– 3.17 Regulatory– 3.18 Shipping– 3.19 Accessories

19


Document

1.0 System Overview2.0 Applicable Documents3.0 Requirements

3.1 Development Phase (Programmatic) Requirements3.1.1 Input/Output Requirements for Development...3.1.4 Qualification Requirement for Development

3.2 Manufacturing Phase Requirements...

3.3 Deployment Phase Requirements...

3.4 Training Phase (if present) Requirements...

3.5 Operational Phase Requirements3.5.1 Input/Output Requirements for Operations

3.5.1.1 Input Requirements for Operations3.5.1.2 Output Requirements for Operations3.5.1.3 External Interface Requirements for Operations3.5.1.4 Functional Requirements for Operations

3.5.2 System-wide/Technology Requirements for Operations3.5.3 Trade-off Requirement for Operations3.5.4 Qualification Requirement for Operations

3.6 System Improvement/Upgrade Phase Requirements...

3.7 Retirement Phase Requirements...

3.8 Overall Trade-Off RequirementAppendix A. Operational Concepts by PhaseAppendix B. External System Diagrams by Phase

Figure 6.5

(StakeholderRequirements)

20

Exemplary Requirement Dimensions

Input or Output performance • Presence of an Input or Output• Quality of an output

– Accuracy (or precision) – Correctness (or confidence, error rate) – Security (or perishability, survivability)

• Quantity of an output– Intensity, size, or distance– Number per unit time (throughput, velocity)– Coverage (area or volume served by outputs)

• Timing of outputs– Response time (timeliness, time to create an output)– Update frequency– Availability

Table 6.2

Part of a Scenario

21


• Undesired or unexpected inputs– Unexpected or undesired inputs and

appropriate response– Bounds on expected inputs and appropriate

response

Table 6.2

22


Table 6.2

Interface requirements• Required format of an input or output as

defined by the interface• Timing constraint associated with an

interface• Physical form or fit of an interface

23


Quality Attribute (‘-Ility’) issues:• Usability• Weight of the system• Form (volume) and fit (dimensions) of the system• Survivability of the system• Availability, reliability, maintainability of the

system • Supportability of the system• Safety of the system• Security• Trainability of the system• Testability of the system• Extensibility (expected changes/growth potential)

of the systemTable 6.2 Customer Needs – Engineering Specifications

24


Costs for various life-cycle phases

• Affordability (or operating and maintenance cost) of the system

• Development cost• Production cost (manufacturability) of

the system• Deployment and training costs of the

system• Decommissioning cost of the system

Table 6.2

25


Schedule for various life-cycle phases

• Development period• Manufacturing time for each unit• Training time to reach proficiency by

category of user• Deployment period• Durability (or operational life) of the

system

Table 6.2

26

Characteristics of Sound Requirements

Individual Requirement Attributes 1. Unambiguous – every requirement has only one interpretation 2. Understandable – the interpretation of each requirement is clear 3. Correct – a requirement the system is in fact required to do 4. Concise – no unnecessary information is included in the requirement 5. Traced – each requirement is traced to some document or statement of the stakeholders 6. Traceable – each derived requirement must be traceable to an originating requirement via some unique name or number 7. Design independent – each requirement does not specify a particular solution or a portion of a particular solution 8. Verifiable – a finite, cost-effective process has been defined to check that the requirement has been attained

Table 6.3

27

Characteristics of Sound Requirements

Attributes of the Set of Requirements 9. Unique – requirement(s) is (are) not overlapping or redundant with other requirements 10. Complete –

(a) everything the system is required to do throughout the system’s life cycle is included,

(b) responses to all possible (realizable) inputs throughout the system’s life cycle are defined,

(c) the document is defined clearly and self-contained, and (d) there are no to be defined (TBD) or to be reviewed (TBR)

statements; completeness is a desired property but cannot be proven.

11. Consistent – (a) internal, no two subsets of requirements conflict and (b) external, no subset of requirements conflicts with external

documents from which the requirements are traced 12. Comparable – the relative necessity of the requirements is included 13. Modifiable – changes to the requirements can be made easily, consistently (free of redundancy) and completely 14. Attainable – solutions exist within performance, cost and schedule constraints

Table 6.3

Together, “Unique” and “Complete” will “partition” the requirements space, into chunks of functionality that suggest how the solution might look. Partitioning below is available from http://www.lockersnmore.com/toilet-partitions-phenolic.php.

http://www.lockersnmore.com/toilet-partitions-phenolic.php

http://www.lockersnmore.com/toilet-partitions-phenolic.php

28

Writing Requirements

• Terminology– “Shall” to indicate the limiting nature of a requirement

(*)– Statements of fact use “will”– Goals use “should”

• Requirements statement shall include – A subject (the relevant life-cycle system)– The word ‘shall’– A relation statement (e.g., less than or equal to)– The minimum acceptable threshold with units

• Avoid – compound predicates– negative predicates– ambiguous descriptors

29

Examples of Requirements• The development system shall receive inputs from

stakeholders. (Input requirement)• The manufacturing system shall have a scrap rate of x

%. (Output requirement)• The deployment system shall accept boxes of x ft3.

(Input requirement)• The training system shall complete training in x hours.

(Output requirement)• The operational system shall have an operational life of

x years. (System wide schedule requirement).• The refinement system shall accept new technology for

the central processing unit. (Input requirement)• The retirement system shall cost less than $x. (System

wide cost requirement)

The fun part is we get to take a legalistic approach………

30

‘Writing Good Requirements’

• Proper GrammarThe system shall stop the flow of liquid hydrogen in 0.5 seconds or less. The liquid stopping time is measured from the time the control signal for stopping is received until the flow through reaches zero.

• Avoid Compound PredicatesThe system shall fit ..., weigh ..., cost ... (this causes traceability problems).

• Avoid Negative PredicatesThe system shall not ... (attempt to turn this into a positive statement of what the system shall do).

• Avoid Ambiguous Terms– Verbs: “optimize,” “maximize,” and “minimize” – Adjectives: “adaptable,” “adequate,” “easy,” “flexible,”

“rapid,” “robust,” “sufficient,” “supportable,” and “user-friendly”

SE Design

31

40 meters

32

When to Stop Seeking Requirements

• As late as possible– Requirements evolve over time as the world changes– Emergent requirements are new, undiscovered,

often critical

• Standish Group (1996) – Requirement related difficulties were responsible for

34 to 44 percent of project failures– $81B in ‘95 and $100B in ‘96 were spent on

cancelled IT products

SE Design

So, it’s a slippery slope…

• Systems engineer knows the customer better than the developers

• His/her role is to translate what the customer really wants into something the developers can understand

• Every aspect of that role is critical!

33

Here’s your development team executing from the requirements, in a perfectly syncrhonized interpretation! From http://www.youcanski.com/en/.

http://www.youcanski.com/en/

34

Let’s take a detailed look at the elevator case study

There really are multiple ways to move people up and down. See this video of a continuous, vertical elevator, at http://www.youtube.com/watch?v=Zx3MHm9WjBE.

http://www.youtube.com/watch?v=Zx3MHm9WjBE



35

Operational Concept

• Vision

• Mission

Requirements

• Usage Scenarios

Defines Justification for and Use of the System

Earth

MoonDirect: Earth-Moon-Earth

Earth

MoonEarth Orbit: Earth-Earth orbit-Moon-Earth

Earth

MoonLunar Orbit: Earth-Lunar orbit-Moon-Lunar Orbit-Earth

Kennedy “Put a man on the moon and bring him back safely by the end of the decade”

Figure 6.6

36

Usage Scenarios

Passenger (includingmobility, visually &hearing challenged) Elevator

Up Service Request

Feedback that request was received

Feedback that car is on the way

Entry Opportunity

Floor Request

Feedback that request was received

Feedback that door is closing

Feedback about floor where stopped

Feedback that door is opening

Exit Opportunity

Feedback that door is opening

Passengers (including mobility, visually, and hearing challenged) request up service, receive feedback that their request was accepted, receive input that the elevator car is approaching and then that an entry opportunity is available, enter elevator car, request floor, receive feedback that their request was accepted, receive feedback that door is closing, receive feedback about what floor at which elevator is stopping, receive feedback that an exit opportunity is available, and exit elevator with no physical impediments.

Figure 6.7Input/Output Trace,Sequence Diagram

Collections of Scenarios become ‘Features’

37

External Systems Diagram

• Composite of all scenarios• Shows

– System and External Systems– Flow of Items

• From external systems to system• From system to external systems• From context to system

– Trace Through All Scenarios, I/O Traces

Defines Boundary of the System

38

Elevator External Systems Diagram USED AT: CONTEXT:

NODE: TITLE: NUMBER:

AUTHOR:PROJECT:

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:REV:

WORKING

DRAFT

RECOMMENDED

PUBLICATION

READER DATE

P.

ProvideElevatorServices

A-0

PassengerCharacteristics

Electric Power& EmergencyCommunication Response

Service, Tests& Repairs

Request forEmergencySupport &EmerencyMessage

Request forFloor & Exit Support

Request forElevator Service &Entry support

BuildingRegulations

StructuralSupport,Alarm Signals& BuildingEnvironment

ModifiedElevatorConfiguration& ExpectedUsage Patterns

PassengerEnvironment

Acknowledgmentthat Request WasRecieved & StatusInformation

Diagnostic &Status Messages

Elevator EntryOpportunity

Elevator ExitOpportunity

EmergencySupport

RequestElevatorServices

A-11

UseElevatorServices

A-12

MaintainElevator

OperationsA-13

ProvideStructuralSupport

A-14

Passengers' Needs

EmergencyMessages

EmergencyCommunication

PassengersElevator System Maintenance Personnel Building

PassengersNeedingElevatorServices

Passengersin ElevatorSystem

RepairParts

External Systems Diagram for Operational Phase

ElevatorEntry/ExitOpportunity

MaintenanceQuality Standards

None

1

xElevator Case StudyDennis Buede

George Mason Univ.

05/24/99

A-1

Figure 6.8

39

External Systems Diagram• Special Rules

1. All of the outputs of the system’s function (the elevator in this case) have to go to at least one of the external systems’ functions on the page and cannot exit the diagram

2. Each of the external systems must receive at least one output of our system; otherwise, the system should be part of the context

3. Must be able to ‘trace out’ the operating scenarios (I/O traces) on the diagram

40

Objectives Hierarchy

• The ‘objectives hierarchy’ of a system are the goals/objectives that are important to the stakeholders in a ‘value’ sense – pay more for higher performance or other benefit.

Schedule / Cost / Performance

Cost vs. Performance

• How I value cost and performance – along with constraints that exist - determine whether I buy (or build) a:

– Ferrari– Rolls Royce– Ford Mustang– Honda Civic

41

42


• ‘Objective’ : Key performance parameter– Minimum acceptable threshold

• Level below which entire system is unacceptable• Often defined too tightly

– Desired performance level• Often bounded by technology constraints

• Hierarchy integrates all objectives• Weighted Trade Offs

Defines Performance Space for Design Solution

43

Elevator Objectives Hierarchy

(from text)

M onth ly O perating C os ts$1,500 - $1,000, W t = 0.1

A verage W ait (R outine)35 - 27 sec , W t = 0 .3

A verage W ait (P riority)35 - 30 sec , W t = 0 .35

A verage T rans it T im e90 - 60 sec , W t = 0 .35

T im e in S ys temO bjec tives , W t = 0.35

M ax'm A cceleration1.5 - 1 .25 m /s2, W t = 0 .3

M ax'm A ccel'n C hange2 - 1 .5 m /s3, W t = 0.5

F loor Leveling E rror0.7 - 0 .3 cm ., W t = 0.2

R ide Q ualityO bjec tives , W t = 0.30

O perational M T B F1 - 1 .5 yrs , W t = 0 .5

O perational M T T R8 - 4 hrs , W t = 0 .5

A vailab ilityO bjec tives , W t = 0.35

O perational P erform anceO bjec tives , W t = 0.9

O perationalO bjec tives

Figure 6.9

44

Objective Hierarchy and Trade Space

How big is the solution set for the design ?

Larger area, looser

constraints, easier to find a

solution

Smaller area, tighter

constraints, harder to find a

solution

Four categories of requirements

45

1. Input/Output• Input• Output• Functional• Interface

2. Technology and System-wide3. Trade Offs4. Qualification

Where does each category come from ??

46

Defining Input/Output Requirements

• The external systems diagram is the primary tool • The systems engineering team must examine each

input, control, and output in detail to discover every requirement associated with each of these items – Every input, control and output should have at least one

requirement– There should be at least one “performance” requirement

for each major system output• Interface constraints address the physical aspects

of the interface to which the system has to connect to obtain the inputs and disseminate the outputs

• The functional requirements should be the two to six functions that partition the system function

47

Exemplary Input/Output Requirements

• The elevator shall receive “calls” from all floors of the building. (Input requirement)

• The elevator shall indicate to a prospective passenger that he/she has successfully called the elevator. (Output requirement)

• The elevator shall use a standard phone line from the building for emergency calls. (External interface requirement)

48

System-wide & Technology Requirements

• Technology requirements are the ones that engineers would prefer not to have because they really do constrain the engineering creativity and should result from the other requirements if they are justifiable

• Table 6.2 provides a list of common suitability issues • A cost requirement deals with payment of money during

the appropriate life-cycle phase for the system in question to be useful

• A schedule requirement deals with a timing issue for the relevant system for the phase of life cycle in question

• There should be a “performance” requirement for – The major suitability issues– The major cost issue– The major schedule issue

49

Usability Testing• Obtaining samples of users • Elicit their reactions about their needs & desires as they interact

with prototypes• Learnability

– Time to master a defined efficiency level, e.g., 50 words per minute– Time to master a defined skill, e.g., cut and paste

• Efficiency – Time for a frequent user to complete a defined task– Rate of producing a defined set of products for a frequent user

• Memorability – Time for a casual user to complete a defined task– Time for a casual user to achieve previously achieved rate of production

• Error rate

– Number of errors of a specific type in a given period for a given task• Satisfaction

– Stress level associated with use– Fun level associated with use

Some customer wants/requests are imprecise and unclear

[Macauley, 1996]. [Macauley, 1996].

How do we translate ‘easy to use’ into engineering specifications ?

Customer wants, needs, and requestsImprecise and unclear

Technical Specifications

How do we translate ‘I want a blue system’ into engineering specifications ?

House of Quality

51

Bicycle Fork Example1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Need

Me

tric

Att

en

ua

tion

fro

m d

rop

ou

t to

ha

nd

leb

ar

at

10

hz

Sp

ring

pre

-loa

d

Ma

xim

um

va

lue

fro

m t

he

Mo

nst

er

Min

imu

m d

esc

en

t tim

e o

n t

est

tra

ck

Da

mp

ing

co

eff

icie

nt

ad

just

me

nt

ran

ge

Ma

xim

um

tra

vel (

26

in w

he

el)

Ra

ke o

ffse

t

La

tera

l stif

fne

ss a

t th

e t

ip

Tota

l ma

ss

La

tera

l stif

fne

ss a

t b

rake

piv

ots

He

ad

set

size

s

Ste

ert

ub

e le

ng

th

Wh

ee

l siz

es

Ma

xim

um

tire

wid

th

Tim

e t

o a

sse

mb

le t

o f

ram

e

Fe

nd

er

com

pa

tibili

ty

Inst

ills

prid

e

Un

it m

an

ufa

ctu

ring

co

st

Tim

e in

sp

ray

cha

mb

er

w/o

wa

ter

en

try

Cyc

les

in m

ud

ch

am

be

r w

/o c

on

tam

ina

tion

Tim

e t

o d

isa

sse

mb

le/a

sse

mb

le f

or

ma

inte

na

nce

Sp

eci

al t

oo

ls r

eq

uire

d f

or

ma

inte

na

nce

UV

te

st d

ura

tion

to

de

gra

de

ru

bb

er

pa

rts

Mo

nst

er

cycl

es

to f

ailu

re

Jap

an

In

du

stria

l Sta

nd

ard

s te

st

Be

nd

ing

str

en

gth

(fr

on

tal l

oa

din

g)

1 reduces vibration to the hands.• • •2 allows easy traversal of slow, difficult terrain. •3 enables high speed descents on bumpy trails.• • •4 allows sensitivity adjustment. •5 preserves the steering characteristics of the bike. • •6 remains rigid during hard cornering. • •7 is lightweight. •8 provides stiff mounting points for the brakes. •9 fits a wide variety of bikes, wheels, and tires. • • • •

10 is easy to install. •11 works with fenders. •12 instills pride. •13 is affordable for an amateur enthusiast. •14 is not contaminated by water. •15 is not contaminated by grunge. •16 can be easily accessed for maintenance. •17 allows easy replacement of worn parts. • •18 can be maintained with readily available tools. •19 lasts a long time. • •20 is safe in a crash. • •

52

Trade-off Requirements

• Incorporates value judgments within and across stakeholders

• Sample many stakeholders• Bill payer ultimately responsible for

integration across stakeholders• See chapter 13 for details – value functions

53

Elevator Objectives Hierarchy

(from Case)

Figure 6.9

The elevator system shall have an average passenger transit time in the elevator car of

no larger than 90 seconds. The design goal is 60 seconds.

The elevator system shall have an average wait for service (time interval

between elevators) of less than 35 seconds. The design goal is 27 seconds.

M on th ly O p era tin g C os ts$ 1 ,5 0 0 - $ 1 ,0 0 0 , W t = 0 .1

A verag e W a it3 5 - 2 7 sec , W t = 0 .5

A verag e Tran s it T im e9 0 - 6 0 sec , W t = 0 .5

T im e in S ys temO b jec tives , W t = 0 .5

M a in ten an ce A c tion s5 0 -8 0 % in 1 h ou r, W t = 0 .2

O p era tion a l M TB F1 - 1 .5 yrs , W t = 0 .5

O p era tion a l M TTR8 - 4 h rs , W t = 0 .5

A va ilab ilityO b jec tives , W t = 0 .3

O p era tion a l P erfo rm an ceO b jec tives , W t = 0 .9

O p era tion a lO b jec tives

The system shall achieved the highest weighted score combining the

weighted performance and cost as shown in the objectives hierarchy.

The relative weights of the cost and performance requirements are 0.1

and 0.9, respectively.

How do we construct the Objectives Hierarchy ??

With the Requirements !!

54

Wasson Trade Space Example

55

Wasson Trade Space Example

56

Objectives Hierarchy and Trade Space

Larger area, looser

constraints, easier to find a

solution

Smaller area, tighter

constraints, harder to find a

solution

How big is the solution set for the design ??There may be no solution !!

57

Qualification Requirements

• Observance: how the measurements for every input/output and system-wide requirement will be obtained, that is - test, analysis and simulation, inspection, or demonstration

• Verification plan: how the qualification data will be used to determine that the real system conforms to the design that was developed

• Validation plan: how the qualification data will be used to determine that the real system complies with the originating requirements

• Acceptance plan: how the qualification data will be used to determine that the real system is acceptable to the stakeholders

58

Originating Requirements Development

OperationalConcept

Stakeholders

Life-CyclePhase

ObjectivesHierarchy

Stakeholders


Life-CyclePhase


Outputs

Inputs &Outputs


Objectives


Figure 6.11

59

Requirements Management

1. Identification, derivation, allocation & control of requirements,

2. In a consistent, traceable, correlatable, verifiable manner,

3. Of all the system functions, attributes, interfaces, and verification methods,

4. That a system must meet.

60

TraceabilityRe

mot

e Do

or

Unloc

k

Accid

ent A

ssist

Instr

umen

ted

Test

Equip

men

t

Dem

onstr

ation

Analy

sis a

nd

Sim

ulatio

n

x x 1.2 The OnStar system shall accept verbal communication from the user. xx 1.3 The OnStar system shall accept notification of the user being locked out. x

x 2.2 The OnStar system shall request assistance from local emergency services. xx 2.3 The OnStar system shall provide the location of the user's vehicle xx 1.10 The OnStar system shall accept a request for assistance from the user. x

x x 2.1 The OnStar system shall provide verbal communication with the user. xx 2.13 The OnStar system shall communicate with the user's friend or family member. x

x x 3.2 The OnStar system shall communicate with the phone system xx x 3.3 The OnStar system shall provide verbal information to the user. x

User Case Qualification

Traceability – backward and forward

61

Fitting it Together

Input

Output

Functions

ExternalInterfaces

Input/Output

Technology

"ilities"

Cost

Schedule

Technology &System-Wide

CostTrade-offs

PerformanceTrade-offs

Cost-PerformanceTrade-off

Trade Off

Data for allqualification

VerificationPlan

ValidationPlan

AcceptancePlan

System Qualification

Requirement Partitionby Life Cycle Phase

ObjectivesHierarchy

Thresholds & Goals

TradeSpaceLet’s look at the

Elevator example

Doing this well

• Detail oriented

• Consider all possibilities

• Everything ties together

• Think about how it will be interpreted by others

• An elegance about the structure, connections, graphical representations, and overall visual appeal.

62

63

Class Exercise

ATM Sample Requirements1. Edit for correct grammar and statement.

2. Identify type.

3. What additional ones are needed from the ESD (External Systems Diagram)?

See separate file with ATM requirements!

64

Class Exercise

OnStar Case• Create requirements from the scenarios

and ESD.

See separate file with OnStar Case study!

65

OnStar ESD USED AT: CONTEXT:


AUTHOR:PROJECT:

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:REV:

WORKING

DRAFT

RECOMMENDED

PUBLICATION

READER DATE

P.

Provide OnStar

Capability

A-0

Cadillac On-Star System Operational Phase External System

On-StarSystem

User ControlCenter

UseOn-Star

A-11

PerformControl Center

Operations

A-12

Request for directions, Location to go to,Request to record directions,Request to play directions,Lights and horn off,Car jacking

User request for directions,Request for audio directions,Accident location, No userresponse, Car stolen,Notice of car jacking,Tracking signal, Phonelink, Test of phone link,Request for control centerlink test

Request for location,Audio directions, Instructionsfor lights and horn, Instructions tounlock car, Attempt to reach driver,Test results for cellular phone, Test results for conversation,Test results for tracking signal

Where to?, Audio replayof directions,Call for accident

Car

PerformCar

FunctionsA-13

Signal to activatelights and horn,Signal to unlock car,Signal todeactivatelights and horn,Test signal tounlock car

Maintainer

MaintainOn-StarSystem

A-14

Test of cellularphone, Adjustments for cellular phone,Control centerlink test,Adjustments for tracking signal,Adjustments for conversation,Adjustments forunlock feature

Test diagnostics - phone,Test diag. - tracking signal,Test diag. - conversation

Flashinghorn andlights

Air bag signal,Security systemsignal, Power

Cadillac Policiesand Procedures

User Feedback

Test resultsfor unlocksignal

Car lost,Car locked Maintainer

feedback

ControlCenterfeedback

Request testof unlockfeature

Test instructionsfor unlock feature

None

1

xCadillac On-Star SystemSYST 520 Student

George Mason University

08/15/00

A-1

66

Class Exercise?

Lawnmower – Here We Mow Again - Case• Review the operating scenarios –

comments ?– Enough, too many, right ones ?– Functional vs. physical descriptions ?– Inputs/outputs are nouns ?

• Does the ESD follow from the scenarios ?• Review the requirements – comments ?.

See separate directory with Lawnmore requirements!

Extra Information

67

68

Requirements

MIL-STD 499B [Military Standard, 1993]: identifies the accomplishment levels needed to achieve specific objectives. Chambers and Manos [1992]: the attributes of the final design that must be a part of any acceptable solution to the design problem. Davis [1993]: a user need or necessary feature, function, or attribute of a system that can be sensed from a position external to that system. Grady [1993]: an essential attribute for a system or an element of a system, coupled by a relation statement with value and units information for the attribute. Harwell et al. [1993]: “If it mandates that something must be accomplished, transformed, produced, or provided, it is a requirement - period.”

69

Originating Requirements Development

USED AT: CONTEXT:


AUTHOR:PROJECT:

NOTES: 1 2 3 4 5 6 7 8 9 10

DATE:REV:

WORKING

DRAFT

RECOMMENDED

PUBLICATION

READER DATE

P.

Originating & System Requirements,

Objectives Hierarchy, Boundary & Qualification

System Requirements

System-level Operational

Concept Design Changes

LowerLayerChanges toRequire-ments

Develop Operational

ConceptA1111

Define System

Boundary with an External Systems

A1112

Develop, Analyze and

Refine Requirements

A1114

Obtain Approval of

Requirements Documentation

A1117

RequirementsIssues

Originating & SystemRequirements

SystemBoundary

Define Qualification

System Requirements

A1116

QualificationSystemRequirements

Develop System


A1113

ObjectivesHierarchy

System Boundary & ObjectivesHierarchy

Stakeholders'Constraints

Stakeholders'Objectives

Ensure Requirements

FeasibilityA1115

Proven RequirementsFeasibility

Proven RequirementsInfeasibility

Qualification System Issues

Inputs of Stakeholders

Originating & System

Requirements

Approval orDisapprovalQualification

ConstraintsStakeholders'Uses

Stakeholders'Jurisdiction

Operational ArchitectureChanges to Requirements

Engineers'RequirementsIssues

Stakeholders'RequirementsIssues

6

x

Engineering Design of a SystemDennis Buede

GMU Systems Engineering

Program

05/24/99

Define System-Level Design ProblemA111

Figure 6.3

72

Pragmatic Principle 2 [DeFoe, 1993]

Use Effectiveness Criteria Based on Needs to Make System Decisions 1. Select criteria that have demonstrable links to customer/consumer needs

and system requirements.a. Operational criteria: mission success, technical performanceb. Program criteria: cost, schedule, quality, riskc. Integrated Logistic Support (ILS) criteria: failure rate, maintainability, serviceability

2. Maintain a “need-based” balance among the often-conflicting criteria.3. Select criteria that are measurable (objective and quantifiable) and express

them in well-known, easily understood units. However, important criteria for which no measure seems to exist, still must be explicitly addressed.

4. Use trade offs to show the customer the performance, cost, schedule, and risk impacts of requirements and solutions variations.

5. Whenever possible, use simulation and experimental design to perform trade offs as methods that rely heavily on “engineering judgment” rating scales are more subject to bias and error.

6. Have the customer make all value judgments in trade offs.7. Allow the customer to modify requirements and participate in developing

the solution based on the trade offs.

House of Quality

[Macauley, 1996]. [Macauley, 1996].

How do we translate ‘easy to use’ or ‘blue’ into engineering specifications ?

Customer wants, needs, and requestsImprecise and unclear

Technical Specifications

74

Pragmatic Principle 3 [DeFoe, 1993]

Establish and Manage Requirements 1. Identify and distinguish between specified (fundamental or essential), allocated, implied

and derived requirements.2. Carry analysis and synthesis to at least one level broader and deeper than seems

necessary before settling on requirements and solutions at any given level. (Top down is a better recording technique than it is an analysis or synthesis technique.)

3. Write rationale for each requirement. The attempt to write rationale for a “requirement” often uncovers the real requirement.

4. Ensure the customer and consumer understand and accept all the requirements.5. Explicitly identify and control all the external interfaces the system will have - signal,

data, power, mechanical, parasitic, and the like. Do the same for all the internal interfaces created by the solution.

6. Negotiate interfaces with affected engineering staff on both sides of each interface and get written agreement by the two parties before the customer approves the interface documentation.

7. Document all requirements interpretations in writing. Don’t count on verbal agreements to stand the test of time.

8. Plan for the inevitable need to correct and change requirements as insight into the need and the “best” solution grows during development.

9. Be careful of new fundamental requirements coming in after the program is underway. They invariably have a larger impact than is obvious.

10. Maintain requirements traceability.

75

Modeling/Prototyping• A physical model of the system that

– Ignores certain aspects of the system – Glosses over other aspects– Is fairly representative of a third segment of aspects

of the system

• Throwaway prototypes developed for – Educating the users about the possibilities– Extracting requirements from the users based upon

their needs

• Evolutionary prototypes – Built for these educational and requirements

development purposes as well– Will eventually be turned into a working version of

the system

77

The Next Moon Mission Unmanned 2008, Manned 2020

‘Apollo’ looking

78

The Next Moon Mission

‘Space Shuttle’ looking

79

The Next Moon Mission

The Apollo Concept