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 personasuse cases and user typesrequirementsfunctional specuser manual and plan

Fundamental Steps StepDocumentation  Requirements  Design  Implementation  Test  Deployment  Maintenance  Functional Spec  Design Document  Code  Test Plan  User Documentation  Design Document

Our Requirements Process Personas and User StoriesUser Types and Use CasesRequirements

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 their goals  Determine the total user experience  How 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 Microsoft  Persona Power 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