8 September 2010

REQUIREMENTS PHASE

PLANNING

Announcements GIT Class:

Friday 3-5 SN 115 (Peter Parente) Information for Project Links Page Hot Topics

Teams and Dates Coming Soon Meetings This Week

Need to Reschedule Friday Morning

RequirementsDesignImplementationTestDeploymentMaintenance

Fundamental Steps

ProcessPersonas and User Stories

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

User Stories and Personas

Talking to the client Active listening

Restate what you hearNOT “I hear you”

How to extract informationAsk them to “tell stories”Focus on the interface: that’s what the user

seesStart the design process with the customerDraw pictures!

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 groupUser groups are based on unique characteristicsEach persona represents a unique set of goals for

design Personas help direct the design

Will cover later

User Stories

Comes from agile programming model

SHORT: fit on an index card

Learn them from the client

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

Using UIs with the Client User: what will they expect?

Function: is anything missing?

Menu design: what’s the natural order?

Types of controls: what’s the natural mechanism?

Use Cases and User Roles

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 roles and use cases User activities, decisions, and objects involved

In terms of user types: classifications that the system recognizes

Documenting Use Cases UML diagrams are often used

Requires toolsWill discuss later, not use for now

We will use simple text description Examples from prior years

Butterfly LabForeign Language Resource Center

Requirements

Types of Requirements Functional : services needed Usability : how easy it is to do it Performance: speed, capacity, memory Reliability and availability: failure rates Error handling: how to handle Interface: user and program Constraints: systems and tolerances (Inverse: what it won’t do)

A requirement must be … Documented Expressed precisely Expressed as what, not how Prioritized

essential, desirable, optionalprimary, secondary, tertiary

Testable

The set of requirements must be… Consistent

Three requirements:○ Only basic food staples will be carried○ Everyone will carry water○ Basic food staples are flour, butter, salt, and milk

CompleteThe function tells whether 3 numbers produce an equilateral, isosceles, or scalene triangle.

Requirement Level Two phases

Requirements written at customer levelDeveloper will convert in order to do design

Once agreement exists with customer, developer “translates” them into his language

ExampleCustomer: User must never lose more than 10

minutes of workDeveloper: Autosaving is required

Functional Spec

Expectations of Software Engineering

1. Predetermine quantitative quality goals2. Accumulate data for use in later projects3. Keep all work visible4. Design, program and test only against

requirements5. Measure and achieve quality goals

Watts Humphrey

Keeping Work Visible: Documentation What will be implemented

Customer: contract, requirements, “glossy”User: manuals

How it will be implementedProject plan

The code The test plan What people will do How you will manage code and documents

Documentation Principles Need to reflect changes

Not just change, but CAPTURE changeVersion control

Need to keep all documents synchronizedOnly say it once

Danger of shared ownership: If many own, no one owns

Practical consideration: Responsibility vs. authority

What is a Functional Spec?

Defines what the functionality will be NOT how it will be implemented

Describes features of the software productproduct's behavior as seen by external

observer Contains

technical info and data needed for design

Why a Spec? Allows you to communicate with your

client and users Easier to change than code Basis for schedule Record of design decisions

What’s in a Functional Spec? Overview Use cases (scenarios) Interfaces: anything the USER sees or

uses As much as you know

Note: your functional spec should go through multiple iterations

What needs to be in the plan? All Deliverables Code Design Test Documentation Learning Presentation and demo prep Reviews