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