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

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!