Embed Size (px)
Citation preview
REQUIREMENTS PHASEUSER STORIES
USE CASES
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 Documentation
Requirements Design Implementation Test Deployment Maintenance
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) termsUse cases – your terms
Extract the essence: requirementsRequirements document as a toolThis product should …
Translate to a system: functional spec
Users
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
Personas A description of a fictitious user representing a distinct
user groupUser groups are based on unique characteristicsEach 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
User Stories
From the USER’s perspectiveCapture what the user is trying to do
Different stories may trigger same functionBUT different concerns, sequences, constraints
ExamplesSame user planning a trip for business or pleasureOr 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 pleasureOr buying an item for himself or as a gift
Comes from agile programming modelSHORT: fit on an index cardLearn them from the client
User Types
User Types: Broad, easily described
Typically self-explanatory Never more than a sentence or phrase Casual user, new user, experienced
user
Use Cases
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 proceduresIncludes (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 LabForeign Language Resource Center
