Requirements Driven Development: A Stream-Based WBS Approach

The driver for requirements typically falls into one of two categories: a specific contract/customer or a general marketing strategy. One of these things is going to drive your requirements. If you have a $1B NASA contract, you'll be focused on that, largely to the exclusion of any other product requirements. If you're trying to capture market share, you be focused on both innovative and me-too features. If you've got a new high-priced product, you're likely going to focus on one or two contracts to get credibility before addressing the issue of market share.

Customer Requirements vs. Product Requirements

So we have: Customer Requirements and Product Requirements. Sometimes we build something specifically for a customer and the two are the same - the CRD (Customer Requirements Document) becomes the PRD. The PRD, is an important document for the development team - it describes what it being built. If there is one or more CRD, traceability from the PRD back to the CRD is essential. The Customer must still be able to verify that all the requirements in the CRD have been met.

Before going any further, there are a couple of other things to keep in mind. First, some PRDs describe the first "release" of the product, with subsequent release PRDs to follow. In other cases, the PRD describes the product and the product team may address it across a series of development streams, each culminating in a significant release.

Second, the PRD is not the sole source of input to product definition. Change Requests (CRs) tend to filter in as well. CRs are typically customer centric. The customer request usually arises from having used the product (or a prototype of it).

2D Version Control of Requirements

Your Requirements Management Tool should provide adequate facilities to manage your Customer Requirements Tree. Each element of the tree should be under both version control and change control. The tree itself may be baselined and frozen often. It should support 2-dimensional version control, with release streams forming one dimension, and within each stream, revisions. So the requirements tree can evolve within each release stream and can also evolve across release streams. This allows us to compare baselines across streams for identifying new release requirements, as well as within a stream, for identifying changes to the requirements and "requirements creep" within a release cycle.

Parallel Phase Requirement Trees vs. Work Breakdown Structure of Activities

There are two camps on how to proceed from here. One recommends a parallel requirements tree, a Product Requirements Tree, managed in the same way as the Customer Requirements. Then the Product Requirements may spawn a third similar tree, a System (or Software) Requirements Tree.

I recommend taking the second approach and using a WBS for your Product Requirements. More specifically, a WBS (Work Breakdown Structure) is generated for the release stream and the Product Features which flow out of the Customer Requirements baseline populate the WBS. The Customer Requirements Tree is really a mechanism for negotiating with the Customer. With the Product Requirements, you really want to do a lot more. You're negotiating with your Product Manager, but you're also building the specification, identifying and assigning resources, establishing and refining your effort estimates, prioritizing implementation and identifying dependencies.

The product manager wants to take the customer requirements (i.e. specific customer requirements, market demands, customer requests - including internally generated ones) and propose a feature and functionality content for the product. The WBS tree will start out as a feature set and should grow into a full product requirements functional specification. The WBS should then continue to grow, based on this