requirements phase planning
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 PresentationTRANSCRIPT
![Page 1: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/1.jpg)
8 September 2010
REQUIREMENTS PHASE
PLANNING
![Page 2: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/2.jpg)
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
![Page 3: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/3.jpg)
RequirementsDesignImplementationTestDeploymentMaintenance
Fundamental Steps
![Page 4: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/4.jpg)
ProcessPersonas and User Stories
Types and Use Cases
Requirements
![Page 5: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/5.jpg)
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
![Page 6: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/6.jpg)
User Stories and Personas
![Page 7: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/7.jpg)
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!
![Page 8: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/8.jpg)
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
![Page 9: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/9.jpg)
User Characterization Knowledge and experience Age and gender Physical handicaps Characteristics of tasks and jobs Psychological characteristics
![Page 10: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/10.jpg)
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
![Page 11: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/11.jpg)
User Stories
Comes from agile programming model
SHORT: fit on an index card
Learn them from the client
![Page 12: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/12.jpg)
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
![Page 13: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/13.jpg)
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?
![Page 14: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/14.jpg)
Use Cases and User Roles
![Page 15: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/15.jpg)
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
![Page 16: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/16.jpg)
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
![Page 17: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/17.jpg)
Requirements
![Page 18: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/18.jpg)
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)
![Page 19: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/19.jpg)
A requirement must be … Documented Expressed precisely Expressed as what, not how Prioritized
essential, desirable, optionalprimary, secondary, tertiary
Testable
![Page 20: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/20.jpg)
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.
![Page 21: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/21.jpg)
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
![Page 22: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/22.jpg)
Functional Spec
![Page 23: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/23.jpg)
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
![Page 24: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/24.jpg)
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
![Page 25: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/25.jpg)
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
![Page 26: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/26.jpg)
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
![Page 27: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/27.jpg)
Why a Spec? Allows you to communicate with your
client and users Easier to change than code Basis for schedule Record of design decisions
![Page 28: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/28.jpg)
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
![Page 29: Requirements phase planning](https://reader034.vdocument.in/reader034/viewer/2022051422/56816758550346895ddc14d9/html5/thumbnails/29.jpg)
What needs to be in the plan? All Deliverables Code Design Test Documentation Learning Presentation and demo prep Reviews