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 softwares 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.
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

• Websters
• 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
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 youre going
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 were done?

9
There are many kinds of Requirements

• Customers Requirements
• Customer (as opposed to user) wants or need
• Designers 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?
• Wheres the users pain?
• What customers problem are you attempting to
  solve?
• Dont build solutions and then go looking for
  problems they might solve

13
Problem and Context

• There are two fundamentally different kinds of
  requirements
• Your customers 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 Whats 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.
16
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 systemall 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.

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
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.
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 havent solved the
  problem
• Distinguishing
• You want to push these ones as far as possible
  during design
• Blue Sky
• Figure the odds! I mean, well do some
  tradeoffs.

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 its
  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 vary in importance its 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.

28
Opinion 2
If we dont 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 toolsthose 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.

29
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 customers 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.

30
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.

31
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)

32
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 its
  the designers who are going to construct the
  system based on their understanding of the
  requirements, and no one elses.
• Its crucial that the designers model the
  requirements, where the best understanding is
  forged.
• Designers frequently believe that they havent
  signed up to participate in requirements modeling
• Customers should NOT own the requirements.

33
Opinion 7
Requirements dont change our understanding of
them changes.

• Genuine requirements dont 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.

34
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
  dont like than what they do - so having
  something the customer can criticize can really
  help define what she does want

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.