Why Written Requirements?

Unambiguous

Defines goals

Cost of finding a requirements bug later can
be 100 times more expensive
Mars Climate Orbiter (Dec 98)


Intended to orbit Mars
Supposed to provide
output in newton
seconds


Instead crashed into it
Instead provided in
pound-force seconds
Minimum
distance:
80 km
From Client to Plan
user stories and personas
use cases and user types
requirements
functional spec
user manual and plan
Fundamental Steps
Step






Requirements
Design
Implementation
Test
Deployment
Maintenance
Documentation






Functional Spec
Design Document
Code
Test Plan
User Documentation
Design Document
Our Requirements Process
Personas and User Stories
User Types and Use Cases
Requirements
Our Requirements Phase

What does the client want to do?
 User stories – his (or her) terms
 Use cases – your terms

Extract the essence: requirements
 Requirements document as a tool
 This product should …

Translate to a system: functional spec
Understanding Users
Identify
the user groups
Understand
Determine
How
their goals
the total user experience
users perform their tasks now

Task and goal descriptions, importance ranking,
strategies, measures, and targets

Stories and scenarios describing how they currently
perform their tasks
User Characterization





Knowledge and experience
Age and gender
Physical handicaps
Characteristics of tasks and jobs
Psychological characteristics
Personas


A description of a fictitious user representing a distinct
user group
 User groups are based on unique characteristics
 Each persona represents a unique set of goals for
design
Personas drive User-Centered Design (UCD)
 Data-based personas


Microsoft
Persona Power
Persona excerpt (hotel reservation)
Purported Benefits of Personas
Establishes users’ goals and needs
 Provides manageable set of users
 Reduces gathering of user requirements
 Focuses on what users will use
 Prioritizes design efforts
 Resolves disagreements over design
decisions
 Reduces usability tests

Fundamental Benefit

Makes it easier to reason about the
person and predict how they might
behave
User Stories

From the USER’s perspective
Capture what the user is trying to do

Different stories may trigger same function
BUT different concerns, sequences, constraints

Examples
 Same user planning a trip for business or pleasure
 Or buying an item for himself or as a gift
Why User Stories

From the USER’s perspective
Capture what the user is trying to do

Different stories may trigger same function
BUT different concerns, sequences, constraints

Examples
 Same user planning a trip for business or pleasure
 Or buying an item for himself or as a gift

Comes from agile programming model
 SHORT: fit on an index card
 Learn them from the client
User Types:
Broad, easily described
Typically self-explanatory
 Never more than a sentence or phrase
 Casual user, new user, experienced
user

Generalizing to Use Cases
A statement
of the functionality users
expect and need, organized by functional
units
Different from user stories because they
are from the software’s perspective
Functional units are any natural division
 Relationships between user types and use
cases
 User activities, decisions, and objects
involved

In
terms of user types: classifications that
the system recognizes
Documenting Use Cases
UML diagrams
 Simple text description

Use Case Diagram
Defines the outside view
 Elements

 Actors (stick figures): anything outside the system
that interacts with it
 Use cases (ovals): procedures by which the actor
interacts with the system
 Solid lines: indicate how actors interact
Use Case Extensions
 Dotted
lines: show dependencies
between procedures
 Includes (subroutine)
 Extends (variation)
Example of Use Case
(customer name)
Use Case Usage
determining features (requirements)
 basis for communicating with clients
 generating test cases

Documenting Use Cases
We will use simple text description
 Examples from prior years

 Butterfly Lab
 Foreign Language Resource Center