Embedded Software
Prof. Philip Koopman
Requirements
"In spite of appearances, people seldom know what
they want until you give them what they ask for. "
– Donald Gause and Gerald Weinberg,
Are Your Lights On? © 2021 Philip Koopman 1
YOU ARE HERE
© 2021 Philip Koopman 2
Requirements Overview
Anti-Patterns:
Requirements aren’t written down
2005:
Requirements incomplete, imprecise
$170M
FBI Virtual Case
“Be like last version, except…”
File project
terminated
Requirements
Requirements issues:
Requirements faults can defeat a
Requirements not defined when
design before it is even built
development contract signed
Describe what system does
“We will know it when we see it”
– Also what it’s not supposed to do
Repeated requirements changes
Precise, testable language
Scope creep (new requirements
– Each requirement traces to system test
added) of 80%
© 2021 Philip Koopman 3
Characteristics of Good Requirements
Precise and minimally constrained
Describes what system should do, not how it does it
Uses “shall” to require an action; “should” to state a goal
If possible has a numeric target instead of qualitative term
– Has tolerance (e.g., 500 msec +/- 10%, “less than X”)
Traceable & testable
Each requirement has a unique label (e.g., “R-7.3”)
Each requirement cleanly traces to an acceptance test
U1 R1 T1
Requirement satisfaction has a feasible yes/no test
U2 R2 T2
Supported within context of system
U3 R3 T3
Supported by rationale or commentary U4 R4 T4
Uses consistent terminology U5 R5 T5
Any conflicting requirements resolved or prioritized
© 2021 Philip Koopman 4
Problematic Requirements
Untraceable (no label)
System shall shut down when E-STOP is activated.
Untestable
R-1.1: System shall never crash
Imprecise
R-1.7: The system provides quick feedback to the user.
No measurement tolerance
R-2.3: LED shall flash with a period of 500 msec
Overly complex
R-7.3: Pressing the red button shall activate Widget X, while
pressing the blue button should cause LED Z to blink instead
of LED Y illuminating steadily, which would be accomplished via the yellow button.
Describes implementation
R-8.3: Pressing button W shall cause two 16-bit integer values to be added, then …
© 2021 Philip Koopman 5
Requirements Ambiguity
A requirements engineer gets a text message:
“On the way home, please pick up one carton of milk.
And if they have eggs, get six.”
The requirements engineer comes home with:
6 cartons of milk and no eggs.
Spouse: “Why did you buy six cartons of milk?!”
Requirements Engineer: “They had eggs.”
Adapted from: www.ganssle.com/jokes.htm. © 2021 Philip Koopman 6
Extra-Functional Requirements
Emergent properties (things hard to attribute to one component)
Performance, real-time deadlines
Security, Safety, Dependability in general
Size, Weight and Power consumption (“SWaP”)
– Often handled with an allocation budget across components
Forbidden behaviors (“shall not do X”)
– Often in context of safety requirements
– “Safety function” is a way to ensure a negative
behavior, but some behaviors are emergent
Design constraints
Must meet a particular set of standards
Must use a particular technology
System cost, project deadline, project staffing https://goo.gl/hT3nDU
© 2021 Philip Koopman 7
Product vs. Engineering Requirements
Product level requirements:
what the product does
Example:
“PR6. The clock shall support a user-settable audible alarm.”
Gives a feature list of what the product actually does
Can be the interface between marketing and engineering
Detailed functional/engineering requirements:
how the product actually works
Example: “R5. Time set buttons shall change the alarm set time.”
Embedded systems often have detailed requirements tied to operational modes
– “R5. In Alarm Set Mode the time set buttons shall change the alarm set time.”
– “R6. Pressing the “+” time set button shall increase time value by one minute per button
press according to the current set mode.”
© 2021 Philip Koopman 8
Requirements Approaches
Text document with list of requirements
Works best if domain experts already know reqts.
Over time, this can converge to OK reqts.
UML Use Cases
Different activities performed by actors
Requirements are scenarios attached
to each use case
Agile User Stories
Each story describes a system interaction
Functional decomposition
Start with primary system functions
Make more and more detailed lists of sub-
functions (creates a “functional architecture”)
Prototyping to elicit requirements
Customers know it when they see it
Sometimes a paper mock-up is enough
UML Use Case Diagram
© 2021 Philip Koopman 9
Requirements Templates (EARS)
Easy Approach to Requirements Syntax (Mavin et al.) e.g.: https://bit.ly/2CQSF37
[While/Where <precondition>] [when/if <trigger> then]
<system> shall <response>
Ubiquitous: The touch screen shall have a response time of less than 250 msec.
State-driven: WHILE an external speaker is connected, the internal speaker shall mute.
Event-driven: WHEN a card is inserted, the card reader shall verify credentials.
Optional feature: WHERE a convertible roof is installed, a park/roof motion interlock
function shall be provided.
Unwanted: IF an invalid value is entered THEN an error message shall be displayed.
Complex: combinations of the above
Requirements issues to avoid:
Ambiguous, vague, complex, omitted, duplicated, wordy, implementation, untestable
© 2021 Philip Koopman 10
Example Software Requirements
https://goo.gl/qct5tL © 2021 Philip Koopman 11
Best Practices for Requirements
Six C-terms for Good Requirements
Clear, Concise, Correct,
Coherent, Complete and Confirmable
Also:
Deal with extra-functional issues
Relate requirements to design flow
– Associate with user stories or use cases
– Trace to corresponding test
Requirements pitfalls https://goo.gl/6H3dxi
Avoid unnecessary details and implementation
If it’s missing from requirements, it won’t get done
If it’s not testable, you won’t know if it got done © 2021 Philip Koopman 12
https://xkcd.com/2021/
