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.