1

BTS330

Requirements Gathering Review

What are requirements? It depends who you ask… Requirements try to describe the

whole system you are creating. You need to decide on a definition

with all project stakeholders…your requirements document will be based on that definition.

What are requirements? Intersection of interests of

stakeholders: Customers (acquire the software) Users Analysts, developers, testers Legal staff And so on…

Why requirements? Foundation for the software

system Define them well terrific product,

happy customers/stakeholders Define them poorly disaster

Levels of Requirements Business

Organizationvision/scope User use cases Functional software specs (not

BTS330)

Levels of Requirements Nonfunctional

Business rules Quality attributes External interfaces Constraints And so on…

Requirements Development Cycle

Elicitation Analysis

Specification

Validation

Clarify

Correct and close gaps

Rewrite

Re-evaluate

Text, p. 59

Development and Management Manage Requirements

Define baseline—SCOPE Manage changes (**NOT EASY) Manage project activity Manage project plan

Why are there problems? Detailed requirements are

difficult!!! “…no other part of the work so

cripples the resulting system if they’re wrong. No other part is more difficult to rectify later.” (text, p. 15)

Cost of Correcting Requirements

Requirements

Design Code Test Operation

20

40

60

80

100

120

Relative Cost

Source: Text, p. 17

Common Problems Insufficient user involvement Scope creep Ambiguous requirements “Paper Napkin” syndrome Overlooked users Inaccurate planning (bad

promises)

The Pain Curve

Pain

Time

GoodRequirements

PoorRequirements

Collaborating with Customers/Stakeholders Take responsibility for ensuring

understanding Be respectful Give honest/correct information

The Sign-off Myth Signing off requirements

is NOT a weapon but a milestone establishes a baseline provides the basis for change

management

Process (Iterative!)1. Define Vision/Scope2. Identify users/stakeholders: classes, reps,

decision makers 3. Select elicitation techniques4. Identify, prioritize and develop use cases

Some modeling here (e.g. user interfaces)

Includes business rules …and so on

Hearing Requirements Use domain vocabulary, not

“techtalk” Provide glossary to explain terms

across project participants Discussing possibilities IS NOT a

commitment Stakeholdersfocus and prioritize

“blue sky” wish

Hearing Requirements Ask the right questions

Open ended “Describe…” “Explain…

Task/Job Descriptions “What tasks…”

Suggestions, Exceptions “What else could…” “What things annoy you…”

Categorizing What You Hear Vision/Scope Document

Business requirements Use Case Document

Use cases/scenarios User needs to <do something>

Business rules Must conform to/comply with some

policy/formula

Categorizing What You Hear Software Specification

Functional requirements Quality attributes External Interface Requirements Constraints

Getting It All Get enough detail to eliminate

fuzziness All users? Full Coverage?

E.g. “life of an order” Diagrams/Charts

When are you done? Hearing “nothing new” Hearing only things outside of

scope or release Hearing low priority

Use Cases A very rough description:

You describe what the users need to do (how they use the system)

Each of these major system “usages” is a use case

Help in understanding the requirements of the system

Use Cases “A sequence of interactions

between a system and an external actor”

Accomplishes a “useful” goal; something “of value”

Use cases encompass all system functionality (sort of).

Actor A person, software system,

department, role, device…etc…. outside of the system that interacts with the system

ActorUse Case

Use Case Diagram

Register Customer

Rent Video

Bank

Clerk

Return Video

ActorAssociation System Boundary

Use Case

Documenting Requirements in BTS330 Requirements Document as per a

given template (posted to the bts330 site)