Download - CMPS 115 - Requirements
1
CMPS 115 - Requirements
Hats off to Brian Lawrence of Coyote Valley Software
&Drew Downs of Process Focus
Incorporated
2
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.
A good set of requirements vastly improves the chances that you will build the right software.
3
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
4
Why Bother with Requirements - 3
5
“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).
6
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
7
Consider a “Requirement” as:
• 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
Requirements happen, whether you plan them or not - better to admit it and know where you’re
going
“Anything that drives design choices.”
8
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?
9
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
10
Many Levels of Requirements
Elicitation
Customer Requirements
System Architecture
System Requirements
System Design
System Requirements allocated to Software
Software Architecture
Software Requirements
11
Elements of a Requirements Definition
• Purpose of the system
• Context of the system
• Problem description
12
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
13
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
14
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
15
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.
Managing the problem is about choosing what problem to solve, then making sure that you solve that and no other
problem.
16
Why “No Technology?”
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.
By specifying in terms of technology, you are defining the problem in terms of a solution.
17
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?
18
Users
• 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
“Any individual who could be affected in any way by the system we are building”
Overlooking an important user is usually a design catastrophe, which may be difficult or even impossible to
overcome.
Overlooking an important user is usually a design catastrophe, which may be difficult or even impossible to
overcome.
19
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?
20
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)
21
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.
Failing to understand which are defining and which are distinguishing attributes is a critical and COSTLY
requirements failure.
22
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.
23
Why Classify Requirements as Function,
Attribute, Constraint?• Clarifies the requirements• Finds missing requirements• Identifies unnecessary or redundant
requirements• Ensures that requirements are testable
24
Requirements Data Flow
Derived from QSM 4
25
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
26
Opinions about Requirements
27
Opinion # 1
• 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.
“Requirements vary in importance & it’s essential to understand their
relative value.”
28
Opinion # 2
• 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.
“If we don’t meet customers’ expectations, we fail, even if we meet all
our requirements.”
29
Opinion # 3
• 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.
“The process of negotiating requirements is what results in
shared understanding of a product.”
30
Opinion # 4
• 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.
“You can NEVER know all the requirements, but you can reduce
your uncertainty a lot!.”
31
Opinion # 5
• 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)
The creation of a requirements documents is an effective
communication process - but the requirements document is probably
not an effective means of communication
32
Opinion # 6
• 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.
The principle product of a requirements process is shaping the minds of the designers and users, not
production of the specification
33
Opinion # 7
• 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.
Requirements don’t change; our understanding of them changes.
34
Opinion # 8
• 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
The more you know, the less you risk, so even a sketchy
requirements effort is better than none.
35
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
• Again, this presentation was based on work by and with Brian Lawrence and Drew Downs.