Upload
ofira
View
25
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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. Fundamental Steps. Requirements Design - PowerPoint PPT Presentation
Citation preview
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