CMPS 115 Requirements
Hats off to
Brian Lawrence of Coyote Valley Software
&
Drew Downs of Process Focus Incorporated
1
Why Bother with
Requirements?
• If you know your software’s requirements, you
can:
–
–
–
–
–
Set expectations
Establish a common understanding
Discover and test assumptions
Create a basis for risk management
Create a basis for system testing
A good set of requirements vastly improves the chances that
you will build the right software.
2
Why Bother with
Requirements? - 2
• Top two factors in failure of system
development contracts to meet schedule or
budget [SEI]
– Inadequate requirements specification
– Changes in requirements
• Top three causes of quality and delivery
problems [Standish Group]
– Lack of user input
– Incomplete requirements
– Changing requirements
3
Why Bother with
Requirements - 3
4
“Requirements” Defined
• Webster’s
– “Something that is required; a necessity.”
• From IEEE Standard 610.12-1990
– 1. A condition or capability needed by a user to solve a
problem or achieve an objective.
– 2. A condition or capability that must be met or possessed by
a system or system component to satisfy a contract,
standard, specification, or other formally imposed
documents.
– 3. A documented representation of a condition or capability
as in (1) or (2).
5
Exercises
• Someone asks you to provide,
either by purchasing it for them or
by building, a form of urban
transportation for their city. What
do you come up with?
• Mary had a little lamb
6
Consider a “Requirement” as:
“Anything that drives design choices.”
• This implies:
–
–
–
–
Requirements always exist, since you have design choices
Requirements are NOT the design choices themselves
Many possible drivers of design choices exist
Many people contribute requirements, not just customers,
and some may not be aware that they are doing so
– Requirements may or may not be documented, but they are
just as real either way
Requirements happen, whether you plan them or not - better to
admit it and know where you’re going
7
Purpose of All Requirements
is to answer the questions:
• Are we doing the right thing?
• What makes us think so?
• How do we know when we’re done?
8
There are many kinds of
Requirements
• Customer’s Requirements
– Customer (as opposed to user) wants or need
• Designer’s Requirements
– Ones brought by the system designers
• Accidental Requirements
– Arbitrary decisions made by the designers
• Genuine Requirements
– Ones users actually need and value
9
Many Levels of Requirements
Elicitation
Customer Requirements
System Architecture
System Requirements
System Design
System Requirements allocated to Software
Software Architecture
Software Requirements
10
Elements of a Requirements
Definition
• Purpose of the system
• Context of the system
• Problem description
11
Purpose
• Why are you bothering to build this
system at all?
• “Where’s the users’ pain?”
• What customer’s problem are you
attempting to solve?
– Don’t build solutions and then go looking for
problems they might solve
12
Problem and Context
• There are two fundamentally different kinds of
requirements
– Your customer’s design problem to be solved
– The context within which you are setting out to
solve that design problem
• Problem information and context information
are managed very differently
13
The Context
• Issues
– Questions about the context
• Assumptions
– Statements about the context (often answers to the
issues)
• Choices
– Assumptions which have been confirmed by an
authority
14
The Problem
• Answers the question “In what characteristic
ways are we going to do what for whom?”
• Comprises:
– Users - Roles that people take
– Attributes - Characteristics of the system
– Functions - Actions the system is to perform
• Formulate problem without reference to
technology
– Drive out technology by asking “What’s the essence of this?”
or “Why are we doing this?”
Managing the problem is about choosing what problem to solve, then
making sure that you solve that and no other problem.
15
Why “No Technology?”
By specifying in terms of technology, you are
defining the problem in terms of a solution.
3. Specifying in terms of a solution may preclude
discovering other, possibly better solutions. This is
particularly true for long-lived systems.
2. Specifying in terms of a solution removes the ability
to validate the system—all you can do is verify.
1. Specifying in terms of the problem rather than the
solution shifts the basis of the negotiation from a
positional negotiation to a principled negotiation.
16
Always Keep In Mind . . .
• The Problem is always embedded in the
Context
– Shifts in the context can and often do
dramatically redefine the problem
– Always ask
•
•
•
•
What problems does this system solve?
What problems does this system create?
What environment is this system likely to encounter?
What kind of precision is expected in this type of
product?
• What did the system do that this one replaces?
17
Users
“Any individual who could be affected in any way
by the system we are building”
• Described as roles - typically nouns
– Lawyers
– Honest people
• Favored Users
– Ones we are explicitly building something for
• Disfavored Users
– We put in something to explicitly prevent them from doing
something
• Ignored Users
– We are not putting anything in for these users
Overlooking an important user is usually a design catastrophe, which may
be difficult or even impossible to overcome.
18
Functions
• Actions the system must perform to be
satisfactory
–
–
–
–
Typically verbs or verb phrases
“The game should . . .”
“The game should display the current score.”
NOT: “The game should have a blue background.”
• Evident
– Everyone can see them - announcing the current floor on an
elevator
• Hidden
– As imperceptible as possible - movement in an elevator
– How about producing lamb chops?
19
Attributes
• My old dog and the new Sony Robodog have
most of the same functions - they differ in
attributes.
– The Robodog is dead. My dog is alive. Mostly.
• Attributes are the desired characteristic
dimensions of the solution
– Typically adjectives or adverbs
– Attribute: ease of use (ergonometric, flexible display, easy to
understand, foolproof), profitable (easy to sell, easy to
package, easy to manufacture.) Response time (fast, slow,
appropriate, consistent)
20
Types of Attributes
• Defining
– You must have these or you haven’t solved the problem
• Distinguishing
– You want to push these ones as far as possible during
design
• Blue Sky
– “Figure the odds! I mean, we’ll do some tradeoffs.”
Failing to understand which are defining and which are distinguishing
attributes is a critical and COSTLY requirements failure.
21
Constraints/Performance
• Constraints are measurable conditions placed
on attributes.
– Constraint for “ease of use” attribute: “This constraint is
defined in terms of the number of times an experienced
computer game player requires external assistance in
playing the game. To test whether the constraint has been
satisfied we will run the experiment using three students
from the lab. The average number of external information
requests must be less than three.”
– Constraint for “Response Time” attribute: the game will
respond to all mouse clicks on it’s board surface within 1
second of the click.”
• Constraints are the boundaries.
22
Why Classify Requirements
as Function, Attribute,
Constraint?
• Clarifies the requirements
• Finds missing requirements
• Identifies unnecessary or redundant
requirements
• Ensures that requirements are testable
23
Requirements Data Flow
Derived from QSM 4
24
Defects in Requirements
• Unclear or ambiguous
• Incorrect
• Missing
– These are hard to find!!!
• Not measurable or testable
• Stated as a design, not a need
• Cost of requirements defects:
– Up to 100x if not found until test
25
Opinions about Requirements
26
Opinion # 1
“Requirements vary in importance & it’s
essential to understand their relative value.”
• Requirements represent the interests of the
stakeholders of the system, including customers,
end-users, system designers, and others.
Requirements are nearly always in conflict.
• A critical aspect of a managing requirements is
making tradeoffs among them.
• The term “requirement” is actually a poor choice of
words.
27
Opinion # 2
“If we don’t meet customers’ expectations, we fail,
even if we meet all our requirements.”
• Many papers and books assume that the requirements may be
found in requirements specifications and tools—those are only
models of the requirements.
• Never confuse the map with the terrain!!!
• The real requirements exist in the minds of the stakeholders and they may not be documented.
• We construct models such as prototypes and requirements docs
to help define the real requirements in peoples’ minds.
28
Opinion # 3
“The process of negotiating requirements is
what results in
shared understanding of a product.”
• Frequently, requirements activities are characterized as
being limited to gathering, tracing, modeling, or analyzing
requirements, but not negotiating them.
• Negotiating is the process of taking what we think we
know about the customer’s needs and how they are
valued, offering potential fulfillments and feeding back the
outcome to our requirements.
• Informed negotiators are more effective than uninformed
negotiators.
29
Opinion # 4
“You can NEVER know all the
requirements, but you can reduce your
uncertainty a lot!.”
• Fuzziness scale
–
–
–
–
–
Unknown and unaware
Aware but unspoken
Spoken but not written
Written
Explicitly negotiated, documented, and signed off
• In every software project, some of the more fuzzy
requirements always exist, and they always will.
30
Opinion # 5
The creation of a requirements documents is an
effective communication process - but the
requirements document is probably not an
effective means of communication
• Most of the value in producing a model or
specification comes during its construction, not in its
application later.
• This is because most of the learning happens during
construction.
• Requirements specifications after the fact are mostly
boring.
– There are some notable exceptions (e.g. litigation)
31
Opinion # 6
The principle product of a requirements process is
shaping the minds of the designers and users, not
production of the specification
• Customers should certainly participate in
requirements definition, but remember that it’s the
designers who are going to construct the system
based on their understanding of the requirements,
and no one else’s.
• It’s crucial that the designers model the requirements,
where the best understanding is forged.
– Designers frequently believe that they haven’t signed up to
participate in requirements modeling
• Customers should NOT “own” the requirements.
32
Opinion # 7
Requirements don’t change; our
understanding of them changes.
• Genuine requirements don’t change all that fast, even
in volatile environments such as Web development.
• What does change is our perception of requirements,
as we find out which are actually the genuine
requirements, and which are not.
• That said, expect that your understanding *will*
change over time.
33
Opinion # 8
The more you know, the less you risk, so
even a sketchy requirements effort is better
than none.
• The point of developing requirements is reducing
uncertainty, not eliminating it.
• You can get pretty good requirements even where
there truly is considerable uncertainty.
• Frequently people find it easier to say what they don’t
like than what they do - so having something the
customer can criticize can really help define what she
*does* want
34
Bibliography
• Andriole, Stephen J., Managing System Requirements:
Methods, Tools, and Cases, McGraw-Hill, 1996.
• Weinberg, Gerald M., Quality Software Management, Volume 1,
Systems Thinking, Dorset House Publishing, 1992.
• Gause & Weinberg, Exploring Requirements, Quality Before
Design, Dorset House Publishing, 1989.
• Hooks, Ivy, “Writing Good Requirements”, Proceedings of the
Third International Symposium of the NCOSE, Volume 2, 1993
• Harwell, Richard, “What is a Requirement”, Proceedings of the
Third International Symposium of the NCOSE, Volume 2, 1993
• Kar, Pradip, “Characteristics of Good Requirements”, Presented
at the 1996 INCOSE Symposium.
• www.incose.org
• www.coyotevalley.com - Brian Lawrence
35