Presentation is loading. Please wait.

Presentation is loading. Please wait.

Why Written Requirements?  Unambiguous  Defines goals  Cost of finding a requirements bug later can be 100 times more expensive.

Similar presentations


Presentation on theme: "Why Written Requirements?  Unambiguous  Defines goals  Cost of finding a requirements bug later can be 100 times more expensive."— Presentation transcript:

1

2 Why Written Requirements?  Unambiguous  Defines goals  Cost of finding a requirements bug later can be 100 times more expensive

3 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

4 From Client to Plan user stories and personasuse cases and user typesrequirementsfunctional specuser manual and plan

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

6 Our Requirements Process Personas and User StoriesUser Types and Use CasesRequirements

7 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

8

9 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

10 User Characterization  Knowledge and experience  Age and gender  Physical handicaps  Characteristics of tasks and jobs  Psychological characteristics

11

12 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

13 Persona excerpt (hotel reservation)

14 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

15 Fundamental Benefit  Makes it easier to reason about the person and predict how they might behave

16

17 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

18 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

19

20 User Types: Broad, easily described  Typically self-explanatory  Never more than a sentence or phrase  Casual user, new user, experienced user

21

22 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

23 Documenting Use Cases  UML diagrams  Simple text description

24 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

25 Use Case Extensions  Dotted lines: show dependencies between procedures Includes (subroutine) Extends (variation)

26 Example of Use Case (customer name)

27 Use Case Usage  determining features (requirements)  basis for communicating with clients  generating test cases

28 Documenting Use Cases  We will use simple text description  Examples from prior years Butterfly Lab Foreign Language Resource Center


Download ppt "Why Written Requirements?  Unambiguous  Defines goals  Cost of finding a requirements bug later can be 100 times more expensive."

Similar presentations


Ads by Google