Requirements Driven Development: A Stream-Based WBS Approach


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.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.