Requirements Driven Development: A Stream-Based WBS Approach

specification, to identify all of the activities that need to be performed to bring this specification to an end product.

We want to track project activities of various types: Requirements Specifications (RS) , Design (and Implementation) activities, Documentation activities, Testing activities, Configuration Management activities, Project Management activities, etc. Just as the RS activities start out as a bunch of Product Requirements which later evolve into specifications, similarly, Design and Implementation activities start out as a set of System (or Software) Requirements. This happens after careful analysis of the set of specifications drawn up in the previous phase. These Design activities grow into the design specifications ideally attached directly to the Design activities, and clearly traceable to the RS activities. The Design activities are a different type of activity, but still very much a part of the same WBS. The goal of the WBS is to transform the product from ground zero to the first release or from one release to the next.

The Product Manager Role

We want to address the entire product, but at the same time, we want to start by focusing on the first release. How do we do this? Here's what I would do if I were product manager:

• Identify the product requirements as line items - we'll call them RS Activities.
• Identify the key objectives/deliverables for each of the activities, and split/merge requirements if necessary.
• Prioritize each of the activities (e.g. high/medium/low or must/should/could)
• Do a rough (e.g. High/Medium/Low) budget (i.e. cost or effort sizing) for each of them to help identify the expected scope.
• Review the entire tree with respect to your targets, budget, timelines, processes, resources and select those RS Activities which will or might be part of the initial release.
• Organize all of these RS Activities into a Functional Tree for the initial release.

This tree is the basis for your initial release negotiations. Your goal is to take this Release Contents and refine it. Some activities will stay in the Release Contents. Some will move into the next release WBS. Some will be split into current and next release activities. But in the end, you have a proposed Release Contents functional tree.

Project Management

The next step is for the project manager to assign each activity to the manager responsible for producing the functional specification for that RS activity. The manager and staff should be able to do an accurate sizing on the activity (+/- 50% assuming a reasonable number of activities) and should be able to identify dependencies between activities where applicable.

At this point, the project manager can roll up the estimates and identify more clearly the total effort to achieve the initial release. Required release dates and available resources/budget will dictate whether or not you need to chop things from the Release Contents. This is a negotiation that will be done primarily between the Product Manager and the Project Manager. If you're serving primarily one or two customers, they would be involved as well. The negotiated Release Contents document forms your Product Requirements for your initial release.

Functional Spec - Contract and Driver

At this point in time, each activity is fleshed into a functional specification by the assigned resource. Reviewers are assigned to each activity and reviews are tracked against each specification, perhaps as an appendix or in a parallel data field. A final round of sizing is performed and a more accurate effort estimate results. This is the first and most important phase of the development. Ideally, the functional specifications may be attached directly to each activity. The entire tree gives a functional specification for the