© Colin Potts A-1

Introduction to Customer Requirements

Colin Potts

Georgia Tech

© Colin Potts A-2

What this course is about

Approaches to defining, managing and analyzing requirements for software-intensive information systems and products

© Colin Potts A-3

Who this course is for

Roles» IS or software

developers

» IS or software project management

» Product conception, marketing or contract experts

Activities» How to define» How to reach

agreement» What questions to

ask» How to document

thoroughly» How to model» How to manage

© Colin Potts A-4

Why the subject is important

Misunderstood requirements lead to poor-quality products» Misunderstood requirements are very

expensive to correct» If not corrected, misunderstood

requirements can doom a product Requirements are underemphasized in

engineering and business education

© Colin Potts A-5

Course objectives

Introduce a representative selection of techniques to understand and manage requirements

Afterward, you should be able to:» Apply these techniques in practice» Choose the right ones for your organization

and integrate them into a coherent process» Know how to find out more

© Colin Potts A-7

What are requirements?

Properties of a planned system or product that are desired by its customer» What kinds of properties?

– Functional / quality requirements

» What is the scope of the system?– System / environment; software / process

» Are requirements absolute? What if they conflict?– Requirements / preferences

» Who are the customers? What if they disagree?– Stakeholders / viewpoints. Trade-offs / negotiation

© Colin Potts A-8

“Is” and “Ought” statements

“Is” statements» What is the case (true or false)» “Standard office hours are between 8am and

6pm” “Ought” statements

» What is desired (worthwhile or not)» “The MSS shall select the earliest schedulable

time for the meeting within standard office hours”

© Colin Potts A-9

A graphical “statement”

Is this “statement” about what is the case or what is required?» Does it describe the

way things are in the host organization (a library) or a new policy that the system should enforce?

Book

Library patron

borrows

(0,1)

(0,6)

© Colin Potts A-10

Requirements-related activities

Requirements definition» Discovering and recording requirements

Requirements management» Keeping track of dependencies among

requirements & design decisions Requirements analysis and validation

» Checking for consistency, desirability and feasibility

© Colin Potts A-11

Requirements management and process

maturity

1: Initial

2: Repeatable

3: Defined

4: Managed

5: Optimizing

Key practices:- requirements management- project planning- project tracking & oversight- subcontract mgt.- quality assurance- configuration management

SEI CMMlevels

© Colin Potts A-12

CMM Requirements Management: key

practices

Goals» Software reqts. are baselined» Reqts. are honored

Commitment» Organizational policy exists for

managing reqts. Abilities

» Responsibility for managing reqts.

» Reqts. are documented» Resources are available for

reqts. mgt.» Staff are trained in reqts-related

responsibilities

Activities» Review reqts. before

incorporation» Base product on reqts.» Review & incorporate changes

Measurements» Keep track of reqts. mgt.

activities Verifications

» Sr. mgt. periodically reviews reqts. mgt. procedures

» Project mgt. regularly reviews reqts. mgt. procedures

» SQA reviews & audits process & products

© Colin Potts A-13

Requirements and system fitness

Well-understood requirements

Poorly understood requirements

© Colin Potts A-14

Requirements and the system lifecycle

“What” vs. “How”

Requirements, prototypes and system evolution

Reqts. DesignProductSpec.Vague

ideas

(“What”) (“How”)

Vagueideas

Devt. (incl.prototyping)

Product

Firmerideas

© Colin Potts A-15

Customer relationships

Contractual In-house Market-based

Cus

tom

er

Dev

elop

er

Cus

tom

er

Dev

elop

er

solicitn.

proposal

detailedreqts.

systemsystem/service

....(muchlater)

reqts.

requestfor help

Dev

elop

er

Pro

xyC

usto

mer

Act

ual

Mar

ket

productidea

product/service

© Colin Potts A-16

Engineering and human-oriented approaches

Requirements occur at boundary between the human and the engineered» “Soft” and “hard” / “Wet” and “dry”

Human-oriented issues» Understanding the system’s context, reaching

consensus, tracking issues, etc.

Engineering-oriented issues» Documentation quality, modeling, feasibility

analysis, etc.

© Colin Potts A-17

Requirements: How to find out more

General texts» Davis: Software Requirements» Macaulay: Requirements Engineering» Wieringa: Requirements Engineering

Readings» Jirotka & Goguen, Reqts. Engineering» Thayer & Dorfman, IEEE Tutorial (2 vols)