The Engineering
Design of Systems:
Models and Methods
Buede Chapter 6 –
Requirements and Defining the
Design Problem
And a little bit of Wasson Ch 52
MG587 Systems Engineering
1
Let’s review….
• Overall goal is to specify and ultimately build a large, complex
system.
– Missions to Mars being an example.
– Or, maybe, redesigning Verizon’s network.
– Too big to expect our favorite, Agile methods to work well, all by
themselves.
• So, we 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.
Your HW for this week – 2A and 2B (project).
–
2.
How’s all this is different from Agile, and why.
–
3.
6.
7.
Different types
Where they come from
How to write them
The rules, regs, and connections between operational concept, ESD
(External Systems Diagram), objectives hierarchy, and requirements.
A detailed look at the elevator case study
Examples –
–
–
–
8.
The ones from the customer
All about requirements
–
–
–
5.
The SEI article you read, week 2 (see schedule).
Review of how we get to originating requirements.
–
4.
Alternative ways to represent stuff, vs IDEF0.
ATM System (homework)
Lawnmower (a little discussion in class)
Airbus “fly by wire” (separate slide set)
Ulrich & Eppinger’s view of assessing customer needs.
–
What’s the terminology & process in the rest of engineering?
3
Your HW for this week
• Feel free to show and tell directly.
– Let’s do 2A first, then 2B (your project).
– How did you choose the ways to represent the
ATM?
• Next week – the project assignment is to
do the same thing for your project.
• HW 3 is to do some requirements – convert
to Agile.
4
Alternative ways to show stuff,
from IDEF0
• How about vs the External Systems
Diagram and their sequence diagrams?
– Suggest that we have a “Domain Model” that
does a lot of what the ESD does.
– And our System Sequence Diagrams are very
similar.
5
Typical Software “Domain Model”
This one’s for a health insurance plan…
6
Typical “System Sequence Diagram”
As it says, this one’s for a sales transaction.
7
Another, with more “swim lanes”
Basic course of action for a whole “Enroll in Seminar” use case.
8
How this differs from Agile
• The SEI article on SE and Agile…
• Buede’s view
– Careful analysis
– Organization
– Weighing tradeoffs (gets into defining design)
• Wasson’s view (see slides 63 - 66)
– It’s all about tradeoffs!
• Ulrich & Eppinger’s view (2nd slide set)
– We’ll look at specific examples, and try to turn
them into user stories!
9
The SEI article…
• “Agile Software Teams: How they Engage with
Systems Engineering on Department of Defense
Acquisition Programs”
• SE has an important product side and service side.
• Possible ways to handle differences:
– Agile software engineering teams interacting with
traditional systems engineering teams operating on that
traditional systems engineering V model
– systems engineers acting as Agile team members
– systems engineering teams actually applying Agile
methods to their own work and systems engineering
functions
10
The SEI article, cntd
• A whole list of successes and challenges.
– E.g., pilot programs to figure out what works.
– Stakeholder involvement is important.
– Coming to agreement about evolving
requirements
• Tonight’s topic!
– Aligning the program roadmap with agile
increments.
• It will all require SE’s to understand Agile
better.
11
Buede, Ch 6:
Two concepts for “Requirements”
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
12
Typical of SE –
Two Levels of Requirements
Mission Requirements
Originating
Requirements
Stakeholder
Requirements
System
Requirements
Component
Requirements
Derived
Requirements
CI
Requirements
CI’s are “Configuration Items”
Figure 6.1
13
Originating/Stakeholder
Requirements Development
Li
fe
Ph -Cy
as cle
e
Inputs &
Outputs
External
Systems
Diagram
Operational
Concept
St
ak
eh
o
ld
er
s
Validation &
Acceptance
Test Scenarios
Inputs &
Outputs
Objectives
Hierarchy
St
ak
eh
o
Figure 6.11
Complete
Inputs &
Outputs
ld
Li
fe
Ph -Cy
as cle
e
Originating
Stakeholder
Requirements
Requirements
Objectives
er
s
14
The Big Picture – Redux
Li
fe
Ph -Cy
as cle
e
Inputs &
Outputs
External
Systems
Diagram
Operational
Concept
St
ak
eh
o
ld
er
s
Complete
Inputs &
Outputs
Validation &
Acceptance
Test Scenarios
Inputs &
Outputs
St
Objectives
Hierarchy
ak
eh
o
ld
er
s
Functional
Architecture
Operational
Architecture
Li
fe
Ph -Cy
as cle
e
Originating
Stakeholder
Requirements
Requirements
Objectives
Derived
Requirements
and Flowdown
Physical
Architecture
State
Transition
Diagram
Interfaces
Risk Analysis
and
Documentation
15
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 production
3. Deployment
4. Training
5. Operations, maintenance, and support
6. Refinement
7. 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.
16
17
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!
18
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.
Pragmatic Principles 2 and 3 are on slides 81 and 83!
19
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?
By what criteria does
the systems
requirements team
respond?
System’s requirements team, a collection of stakeholders and
systems engineers. Response is acceptance, request for
clarification, or rejection.
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.
20
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.
21
SE Design
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
From Ulrich and Epppinger’s Product Design and Development.
22
Requirements Categories
Requirement Partition
by Life Cycle Phase
Input/Output
Technology &
System-Wide
Trade Off
System
Qualification
Input
Technology
Cost
Trade-offs
Data for all
qualification
Output
"ilities"
Performance
Trade-offs
Verification
Plan
Functions
Cost
Cost-Performance
Trade-off
Validation
Plan
External
Interfaces
Schedule
Acceptance
Plan
Thresholds & Goals
Objectives
Hierarchy
Figure 6.4
Trade
Space
24
Requirements Categories
Buede Textbook
Raytheon
1. Input/Output
2. Technology and
System Wide
3. Trade Offs
4. Qualification
1.
2.
3.
4.
Performance
Environmental
Interface
Design Constraints
25
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
26
Stakeholder
Requirements
Document
(Stakeholder
Requirements)
Figure 6.5
1.0 System Overview
2.0 Applicable Documents
3.0 Requirements
3.1 Development Phase (Programmatic) Requirements
3.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 Requirements
3.5.1 Input/Output Requirements for Operations
3.5.1.1 Input Requirements for Operations
3.5.1.2 Output Requirements for Operations
3.5.1.3 External Interface Requirements for Operations
3.5.1.4 Functional Requirements for Operations
3.5.2 System-wide/Technology Requirements for Operations
3.5.3 Trade-off Requirement for Operations
3.5.4 Qualification Requirement for Operations
3.6 System Improvement/Upgrade Phase Requirements
...
3.7 Retirement Phase Requirements
...
3.8 Overall Trade-Off Requirement
Appendix A. Operational Concepts by Phase
Appendix B. External System Diagrams by Phase
27
Exemplary Requirement Dimensions
Input or Output performance
• Presence of an Input or Output
• Quality of an output
Part of a Scenario
–
–
–
Accuracy (or precision)
Correctness (or confidence, error rate)
Security (or perishability, survivability)
–
–
–
Intensity, size, or distance
Number per unit time (throughput, velocity)
Coverage (area or volume served by outputs)
–
–
–
Response time (timeliness, time to create an output)
Update frequency
Availability
• Quantity of an output
• Timing of outputs
Table 6.2
28
Exemplary Requirement Dimensions
• Undesired or unexpected inputs
– Unexpected or undesired inputs and
appropriate response
– Bounds on expected inputs and appropriate
response
Table 6.2
29
Exemplary Requirement Dimensions
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
Table 6.2
30
Exemplary Requirement Dimensions
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 system
Table 6.2
Customer Needs – Engineering Specifications
31
Exemplary Requirement Dimensions
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
32
Exemplary Requirement Dimensions
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
33
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
34
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.
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/toiletpartitions-phenolic.php.
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
35
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
36
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………
37
SE Design
‘Writing Good Requirements’
• Proper Grammar
The 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 Predicates
The system shall fit ..., weigh ..., cost ... (this causes traceability problems).
• Avoid Negative Predicates
The 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 “userfriendly”
38
40 meters
39
SE Design
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
40
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!
Here’s your development team executing
from the requirements, in a perfectly
syncrhonized interpretation! From
http://www.youcanski.com/en/.
41
Elevator case study
Let’s take a detailed look at the
elevator case study
Matt saw this last week!
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=Zx3MHm9Wj
BE.
42
Elevator case study
Operational Concept
Direct: Earth-Moon-Earth
• Vision
Moon
Earth Orbit: EarthEarth orbit-Moon-Earth
Moon
Earth
• Mission Requirements
Earth
Lunar Orbit: EarthLunar orbit-MoonLunar Orbit-Earth
• Usage Scenarios
Earth
Kennedy “Put a man on the moon and bring him back
Otis “Put a man on the top floor by the end of a
safely
by the end of the decade”
minute”
Defines Justification for and Use of the System
Figure 6.6
43
Moon
Elevator case study
Usage Scenarios
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.7
Collections of Scenarios
become ‘Features’
Passenger (including
mobility, visually &
hearing challenged)
Elevator
Up Service Request
Feedback that request was received
Feedback that car is on the way
Feedback that door is opening
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
Input/Output Trace,
Sequence Diagram
44
Elevator case study
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
Context
External Systems
System
are impacted by “System”
impacts, but not impacted by, “System”
Defines Boundary of the System
45
Elevator case study
Elevator External Systems Diagram
USED AT:
George Mason
Univ.
AUTHOR: Dennis Buede
PROJECT: Elevator Case Study
DATE: 05/24/99
REV:
x
NOTES: 1 2 3 4 5 6 7 8 9 10
Passengers' Needs
Elevator Entry
Opportunity
Request for
Elevator
Service &
Entry support
Request
Elevator
Services
A-11
Passenger
Environment
Use
Elevator
Services
A-12
Elevator Exit
Opportunity
Emergency
Support
Elevator
Entry/Exit
Opportunity
Passenger
Characteristics
Building
Regulations
Structural
Support,
Alarm Signals
& Building
Environment
ModifiedElevator
Configuration
& Expected
Usage Patterns
Diagnostic &
Status Messages
Provide
Elevator
Services
A-0
Maintain
Elevator
Operations
Repair
Parts
A-13
Passengers
Needing
Elevator
Services
None
Acknowledgment
that Request Was
Recieved & Status
Information
Request for
Floor &
Exit Support
Request for
Emergency
Support &
Emerency
Message
DATE CONTEXT:
WORKING
READER
DRAFT
RECOMMENDED
PUBLICATION
Maintenance
Quality Standards
Emergency
Communication
Provide
Structural
Support
Passengers
in Elevator
System
Service, Tests
& Repairs
Passengers
NODE:
Figure 6.8
A-1
Elevator System
TITLE: External Systems Diagram for Operational Phase
Maintenance Personnel
Emergency
Messages
A-14
Building
NUMBER:
Electric Power
& Emergency
Communication
Response
P. 1
46
Elevator case study
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
47
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
48
Cost vs. Performance
• How I value cost and performance – along
with constraints that exist - determine
whether I buy (or build) a:
–
–
–
–
Ferrari 458 Italia coupe
Rolls Royce Ghost
Ford Mustang
Honda Civic
Interesting questions:
Which one is least expensive?
Which one has the best
maintenance record?
49
Objectives Hierarchy - cntd
• ‘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
50
Elevator
Objectives
Hierarchy
Operational
Objectives
Monthly Operating Costs
$1,500 - $1,000, Wt = 0.1
(from text)
Elevator case study
Operational Performance
Objectives, Wt = 0.9
Time in System
Objectives, Wt = 0.35
Average Wait (Routine)
35 - 27 sec, Wt = 0.3
Average Wait (Priority)
35 - 30 sec, Wt = 0.35
Average Transit Time
90 - 60 sec, Wt = 0.35
I love this figure!
Why don’t we do this in software?
Ride Quality
Objectives, Wt = 0.30
Max'm Acceleration
1.5 - 1.25 m/s2, Wt = 0.3
Max'm Accel'n Change
2 - 1.5 m/s3, Wt = 0.5
Floor Leveling Error
0.7 - 0.3 cm., Wt = 0.2
Availability
Objectives, Wt = 0.35
Operational MTBF
1 - 1.5 yrs, Wt = 0.5
Operational MTTR
8 - 4 hrs, Wt = 0.5
Figure 6.9
51
Objective 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 ?
52
Four categories of requirements
1. Input/Output
•
•
•
•
Input
Output
Functional
Interface
2. Technology and System-wide
3. Trade Offs
4. Qualification
Where does each category come from ??
53
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
54
Elevator case study
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)
55
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
56
Usability Testing
•
•
•
Obtaining samples of users
Elicit their reactions about their needs & desires as they interact
with prototypes
Learnability
•
Efficiency
•
Memorability
•
Error rate
•
Satisfaction
– Time to master a defined efficiency level, e.g., 50 words per minute
– Time to master a defined skill, e.g., cut and paste
– Time for a frequent user to complete a defined task
– Rate of producing a defined set of products for a frequent user
– Time for a casual user to complete a defined task
– Time for a casual user to achieve previously achieved rate of production
– Number of errors of a specific type in a given period for a given task
– Stress level associated with use
– Fun level associated with use
57
For a lot more on usability…
• Check your interaction design book, from
CSSE571:
58
Some customer wants/requests are
imprecise and unclear
How to clarify!
Technical Specifications
Customer wants, needs, and requests
Imprecise and unclear
[Macauley, 1996].
House of Quality
How do we translate ‘easy to use’ into engineering specifications ?
How do we translate ‘I want a blue system’ into engineering specifications
?
•
Bending strength (frontal loading)
•
Japan Industrial Standards test
Special tools required for maintenance
Time to disassemble/assemble for maintenance
Cycles in mud chamber w/o contamination
Time in spray chamber w/o water entry
•
Unit manufacturing cost
•
Instills pride
•
Fender compatibility
•
Monster cycles to failure
•
UV test duration to degrade rubber parts
•
Time to assemble to frame
•
Maximum tire width
•
Wheel sizes
•
Steertube length
•
Headset sizes
•
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Lateral stiffness at brake pivots
•
8
Total mass
•
7
Lateral stiffness at the tip
•
6
Rake offset
•
5
Maximum travel (26in wheel)
Spring pre-load
Need
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.
4
Damping coefficient adjustment range
3
Minimum descent time on test track
2
Maximum value from the Monster
1
Attenuation from dropout to handlebar at 10hz
Metric
Bicycle Fork Example
•
•
•
•
•
•
•
•
•
•
•
60 •
•
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
61
Elevator Objectives Hierarchy
(from Case)
How do we construct the
Objectives Hierarchy ??
Operational
Objectives
Monthly Operating Costs
$1,500 - $1,000, Wt = 0.1
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.
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.
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.
Figure 6.9
Elevator case study
With the Requirements !!
Operational Performance
Objectives, Wt = 0.9
Time in System
Objectives, Wt = 0.5
Average Wait
35 - 27 sec, Wt = 0.5
Average Transit Time
90 - 60 sec, Wt = 0.5
Maintenance Actions
50-80% in 1 hour, Wt = 0.2
Availability
Objectives, Wt = 0.3
Operational MTBF
1 - 1.5 yrs, Wt = 0.5
Operational MTTR
8 - 4 hrs, Wt = 0.5
62
Wasson Trade Space Example
63
Wasson Trade Space Example - cntd
64
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 !!
65
Wasson’s whole trade study process
66
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
67
Originating Requirements
Development
Li
fe
Ph -Cy
as cle
e
Inputs &
Outputs
External
Systems
Diagram
Operational
Concept
St
ak
eh
o
ld
er
s
Validation &
Acceptance
Test Scenarios
Inputs &
Outputs
Objectives
Hierarchy
St
ak
eh
o
Figure 6.11
Complete
Inputs &
Outputs
ld
Li
fe
Ph -Cy
as cle
e
Originating
Requirements
Objectives
er
s
68
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.
69
Elevator case study
Fitting it Together
Requirement Partition
by Life Cycle Phase
Input/Output
Technology &
System-Wide
Trade Off
System
Qualification
Input
Technology
Cost
Trade-offs
Data for all
qualification
Output
"ilities"
Performance
Trade-offs
Verification
Plan
Functions
Cost
Cost-Performance
Trade-off
Validation
Plan
External
Interfaces
Schedule
Acceptance
Plan
Thresholds & Goals
Recall the Elevator
example… (slide
55)
Objectives
Hierarchy
Trade
Space
70
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.
71
Examples
HW 3 Exercise
ATM Sample Requirements
1. What’s important?
2. What types of requirements?
3. What additional ones are needed from the
ESD (External Systems Diagram), or whatever
you used for HW 2A?
See separate file with ATM requirements!
72
Examples
Class Exercise?
OnStar Case
• What are key requirements, from the
scenarios and ESD.
See separate file with OnStar Case study!
73
Examples
OnStar ESD
USED AT:
George Mason
University
AUTHOR: SYST 520 Student
PROJECT: Cadillac On-Star System
x
DATE: 08/15/00
REV:
NOTES: 1 2 3 4 5 6 7 8 9 10
Request for directions,
Location to go to,
Request to record directions,
Request to play directions,
Lights and horn off,
Car jacking
Request for location,
Audio directions, Instructions
for lights and horn, Instructions to
unlock car, Attempt to reach driver,
Test results for cellular phone,
Test results for conversation,
Test results for tracking signal
Use
On-Star
A-11
Car lost,
Car locked
Perform
Control
Center
Operations
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Test instructions
for unlock feature
User
NODE:
A-1
None
User Feedback
Control
Center
feedback
Signal to activate
lights and horn,
Signal to
unlock car,
Signal to
deactivate
lights and horn,
Test signal to
unlock car
Maintainer
feedback
Provide
OnStar
Capability
Test results
for unlock
signal
A-0
Perform
Car
Functions
User request for directions,
Request for audio directions,
Accident location, No user
response, Car stolen,
Notice of car jacking,
Tracking signal, Phone
link, Test of phone link,
Request for control center
link test
DATE CONTEXT:
Cadillac Policies
and Procedures
A-12
Where to?,
Audio replay
of directions,
Call for accident
READER
Test of cellular
phone,
Adjustments for
cellular phone,
Control center
link test,
Adjustments for
tracking signal,
Adjustments for
conversation,
Adjustments for
unlock feature
A-13
Air bag signal,
Security system
signal, Power
Control
Center
Maintain
On-Star
System
On-Star
System
TITLE: Cadillac On-Star System Operational Phase External System
A-14
Flashing
horn and
lights
Test diagnostics - phone,
Test diag. - tracking signal,
Test diag. - conversation
Car
Request test
of unlock
feature
NUMBER:
Maintainer
P. 1
74
Examples
Traceability
x
x
x
x
x
x 1.2
1.3
x 2.2
x 2.3
x 1.10
x 2.1
x 2.13
x 3.2
x 3.3
The OnStar system shall accept verbal communication from the user.
The OnStar system shall accept notification of the user being locked out.
The OnStar system shall request assistance from local emergency services.
The OnStar system shall provide the location of the user's vehicle
The OnStar system shall accept a request for assistance from the user.
The OnStar system shall provide verbal communication with the user.
The OnStar system shall communicate with the user's friend or family member.
The OnStar system shall communicate with the phone system
The OnStar system shall provide verbal information to the user.
Traceability – backward and forward
Analysis and
Simulation
Demonstration
Instrumented Test
Equipment
Qualification
Accident Assist
Remote Door
Unlock
User Case
x
x
x
x
x
x
x
x
x
75
Examples
Class Exercise?
(See sub-directory for this week)
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!
76
Requirements – other SE views
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.”
77
Originating Requirements Development
AUTHOR: Dennis Buede
PROJECT: Engineering Design of a System
USED AT:
GMU Systems
Engineering
Program
DATE: 05/24/99
REV:
NOTES: 1 2 3 4 5 6 7 8 9 10
x
WORKING
DRAFT
RECOMMENDED
PUBLICATION
DATE CONTEXT:
READER
Inputs of Stakeholders
Stakeholders'
Uses
Stakeholders'
Objectives
Stakeholders'
Jurisdiction
Stakeholders'
Constraints
Approval or
Disapproval
Qualification
Constraints
Requirements
Issues
Develop
Operational
Concept
Design
Changes
A1111
Engineers'
Requirements
Issues
System
Boundary
Define
System
Boundary
with an
External
Systems
System-level
Operational
Concept
Qualification
System Issues
Objectives
Hierarchy
Define
Qualification
System
Requirements
A1112
Develop
System
Objectives
System
Hierarchy Boundary &
Proven Requirements
Infeasibility
Develop,
Analyze and
Refine
Requirements
NODE:
Figure 6.3
A111
Ensure
Requirements
Feasibility
A1114
Operational Architecture
Changes to Requirements
Originating & System
Requirements
TITLE:
Stakeholders'
Requirements
Issues
A1116
A1113 Objectives
Hierarchy
Lower
Layer
Changes to
Requirements
Originating & System
Requirements,
Objectives Hierarchy,
Boundary & Qualification
System Requirements
Qualification
System
Requirements
Define System-Level Design Problem
Obtain
Approval of
Requirements
Documentation
Originating
& System
Requirements
A1117
A1115
Proven Requirements
Feasibility
NUMBER:
P. 6
78
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 performance
b. Program criteria: cost, schedule, quality, risk
c. 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.
81
House of Quality
Technical Specifications
Customer wants, needs, and requests
Imprecise and unclear
[Macauley, 1996].
How do we translate ‘easy to use’ or ‘blue’ into engineering specifications ?
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.
83
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
84
The Next Moon Mission
Examples
Unmanned 2008, Manned 2020
‘Apollo’ looking
86
Examples
The Next Moon Mission
87 looking
‘Space Shuttle’
Examples
The Next Moon Mission
The Apollo Concept
88
So, what SE requirements tools
could you use?
• In addition to Agile things we do now?
• Which ones could be translated into our
terms?
89