Requirements Driven Development: A Stream-Based WBS Approach

entire release.

Make sure that your functional specification is correct. If you need to do some exploratory work to eliminate specification risk, do it as part of the specification phase. When you come out of the specification phase, you should not have any significant risk remaining. Perhaps a few resource allocation issues to deal with, perhaps a backup strategy or two to cover still risky areas. But there should be no show stoppers.

Implementation

From the functional specification, testing, documentation and implementation may proceed in parallel. With respect to the WBS, this means creating 3 new kinds of activities. Test plans should be attached to testing activities, design documents should be attached to implementation activities, documentation strategies should be attached to the documentation activities. Ideally, each area will help the other. If something is too complex to document, perhaps a specification change can be proposed to simplify the operation. Test beds, and perhaps test cases may be made available for the developers to exercise their completed components. Developer-designed white-box test cases may be collected into a white-box test case suite.

These activities are all streamed to a particular release. They should be added to the tree in such a manner that clear traceability exists, either by hierarchical organization, or by explicit reference to the activities spawning them. Execution of the activities by the assignees yields the raw components for the initial release. A number of system integration, verification and configuration management activities should help to yield the actual release. The WBS captures all of these activities and shows them in a hierarchical manner.

The product test cases you develop to test the initial release should trace back to a WBS activity (i.e. a Product Requirement). Perhaps you'll have white box test cases which reference design activities. The change packages for the initial release that you use to create or change your code should reference a WBS activity. In any event, you should have full traceability from your change packages through to your requirements. Your test cases and changes should clearly belong to the stream for which they were performed. Your code branches, likewise, should belong to the stream for which they were created. If some of these artifacts remain unchanged in subsequent streams, they should be shared by those streams.

The requirements, test cases, documentation, code and perhaps other artifacts require 2-dimensional version control: stream and revision within each stream. The WBS does not require 2-D version control. It, by definition, is a single stream entity. It's defining the transformation operation to take your product from point zero to release 1. Then next one goes from release 1 to release 2, and so forth. Then you may have 2 more WBS structures to go to release 2.1 and to release 3 in parallel.

Your activities and changes all are targeted to a particular release development stream. If an activity does not get completed in one release, it should either be moved to another stream (and WBS) or split into the portion that is completed and the non-compliant portion, the latter going into another stream. Your changes may be applied to more than one stream. But in that case a separate change package should appear in each stream if there are any file revisions not shared between streams.

Your completed WBS is invaluable. Not only does it give you traceability and documentation. It also contains metrics such as what portions of the product development schedule were consumed by requirement specifications, design, test cases, CM, etc. If planned and actual information is maintained for each activity, you also get valuable feedback on