Requirements Document
Work Breakdown Structure
Schedule
Date 1-Oct-08 8-Oct-08 15-Oct-08 22-Oct-08 29-Oct-08 5-Nov-08 12-Nov-08 19-Nov-08 26-Nov-08 3-Dec-08 Tooic work breakdown/features breakdown agile methods acceptance criteria testing - unit, tdd, Student Presentations Student Presentations Student Presentations Demos Thanksgiving Break Code review requirements doc feature breakdown design review Student Presentations Student Presentations Student Presentations Demos Thanksgiving Break code review Assignment
10-Dec-08
last day of instruction
Requirements Document
DDJ Quick-kill Project Management
Problem Statement
Project background Stakeholders End-users
Vision and Scope
Vision statement List of features List of features that will NOT be developed
Problem Statement
Project background
summary of the problem that the project solves. a brief history of the problem an explanation of how the organization justified the decision to build software to address it why the problem exists the organization's history with this problem any previous projects that were undertaken to try to address it the way that the decision to begin this project was reached
Problem Statement
Stakeholders list of stakeholders
Individuals within the client organization that have a vested interest in the outcome Name, title or role
Users
Name, title or role OR the end users are individuals with an interest in
Vision and Scope
Vision statement
A description of the goal of the software How does it fulfill the needs of the client or users?
Vision and Scope
List of features List of features or functionality that will NOT be developed concise list of exactly what will and won't be built
WBS
What is it? Why do we need it? Are we going to get graded on this?
What is it?
In software development, this is a feature breakdown structure. Feature-by-feature catalog and description A comprehensive classification of project scope, not an exhaustive list of work
Why do we need it?
To document agreement with client To provide a define the scope of the project clearly for the team and the client Aids in planning
Estimation Assigning responsibility
It is considered poor practice to develop a schedule without first designing a WBS
Are we going to be graded on this?
Yes The way you are graded is pass/fail on this section. If you turn in documents without this they will be returned to you for revision.
WBS (wikipedia)
100% Rule Planned outcomes, not planned actions Mutually exclusive elements
100% Rule
Represents all of the work defined by project Includes all deliverables Applies to all levels of the hierarchy
Planned outcome, not planned actions
(Unless an action is a deliverable)
Mutually Exclusive Elements
When breaking down the tasks, it is important that nothing appears on the WPS more than once
WBS
User interface Business logic Database
WBS
User interface
User Log-in page Account summary page Pay bills
Combine database table data for summary Generate data for presentation
Business logic
Database
Table design Query design
WBS Numbering
1.0 User interface
1.1 User Log-in page 1.2 Account summary page 1.3 Pay bills
2.1 Combine database table data for summary 2.2 Generate data for presentation 2.3 Record transactions 2.4 User verification 3.1 Table design 3.2 Query design
2.0 Business logic
3.0 Database
Granularity
How far do you continue this process?
Too fine = Micromanagement Too course = too difficult to manage
Cant estimate time to completion Cant keep track of how complete it is Cant turn in interim results because they are not defined
Granularity
If a task is not a direct deliverable then it is too fine A task should:
Be definable as an OUTCOME Have a duration no more than a week
Granularity
Progressive elaboration
Allows details to be progressively
A word on duration
A task may only take 10 hours to complete Theoretically, that can be done by the end of the week If the person assigned this task is out of town, sick or gets hit by a bus you have a problem
Estimating
If you can not estimate time to completion, break the task down further If you can not AGREE on the time to completion, list the assumptions of those in disagreement
Schedule
Each OUTCOME must be listed A date of completion must accompany each outcome Responsibility for each outcome must be assigned All expected outcomes must be listed
