Requirements Driven Development: A Stream-Based WBS Approach

[article]
Summary:
Requirements are a must have. Or should have. Maybe a want. OK, maybe not really requirements. When it comes down to it, you need to understand why you're building what you're building in sufficient detail so that you will know if what you built does the job. You also need full traceability to show that you have met the requirements. Developers work to a set of requirements, but these are not the same as the product requirements, which are again different from the customers' requirements. And what about ad hoc requests? Where do they fit in?

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 versus Product Requirements
So we have customer requirements and product requirements. Sometimes we build something specifically for a customer and the two are the same. This is called the customer requirements document (CRD) and it becomes  becomes the PRD. The PRD is an important document for the development team, as 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.

Pages

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 farah@neuma.com

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

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

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09