Requirements-Based Development: A Software Configuration Management View

It seems so obvious that we should develop systems based on requirements, and yet it turns out to be rather hard to do and thus many organizations are doing it very badly. From a software configuration management standpoint, we could perhaps leave the whole process of requirements engineering to one side and focus on the management of requirements and thus the aspects of change control and traceability. That would perhaps be unduly ducking the issue, and, of course, we can’t resist giving an opinion anyway!

For definitions and descriptions of the process of gathering requirements, you can do a lot worse than use SWEBOK as a starter [1]. Requirements can be split into: functional, non-functional (interface, quality and other “ilities,” performance, safety), derived, behavioral and operational. Dennis Linscomb [2] makes some interesting recommendations as to how the requirements aspect of CMMI might be improved to reflect a level of maturity in requirements.

So first a quick review followed by an agile SCM slant on things and some suggestions for improvement.

Big Bang (Waterfall) Developments
What came to be known as the waterfall approach presented a vision of a set of requirements all specified upfront which could be verified, signed off and then implemented with an ecstatic set of users at the end of it. This turned out to be a siren call which resulted in the shipwreck of many, many projects over the years. It is very hard to specify requirements, since often no one knows precisely what they want, and in any case the requirements are almost certain to have changed by the time they are implemented. Interestingly, there are situations where a rather accurate requirements definition is available—for example re-engineering or re-developing an existing system. In such cases the requirements process can be to point at the existing system and “replicate that,” even down to the level of replicating existing mistakes.

Waterfall Successes
Of course not all waterfall projects were failures. One of the authors well remembers a 7 figure fixed price development project where the requirements specification mixed one liners that implied whole subsystems and months of effort and in other parts spent pages on specific details of how certain screens should look (that turned out not to be needed at all). The fact that the project was a success was down to some excellent people being involved on all sides, and also that while we didn’t quite ignore the spec, we did rather rewrite it. The project was likely to have been even more successful if done in a more evolutionary manner since the implications of various (some relatively minor) decisions did not fully manifest themselves until it was much too expensive to change them.

Evolutionary Development
This approach has been around for a long time, based on the idea that the faster you can deliver something, the more feedback you get and the more likely you are to get something useful. Richard Brooksby, in “Changing How You Change” [3] discusses the process of developing software to add value to your company, e.g. by understanding what is valuable to customers and solving their problems. He nicely summarises Tom Gilb’s work in this area. Richard came up with the wonderful image of seemingly random changes in the software that often occur—very much like the apparently random (Brownian) motion of small dust particles in a gas. Have you ever seen new release of software come out with apparently pointless features and changes? The sign of a company that doesn’t know which features are valuable, or that doesn’t know how to ensure that they are the ones that get delivered.

The Agile Approach
For Agile methods, the evolutionary approach is fundamental—without it there is no agility! It provides closer conformance between delivered features and actual needs, and shorter lead time for new features. As Martin Fowler writes [4] “The power of shipped, running code is enormous. It focuses customer attention, grows credibility, and is a massive source of learning.” This last point is interesting: we referred last month to Phil Armour’s book The Laws of Software Process, where he maintains that software is not a "product" in the usual production-oriented sense of the word, but that software is really a medium for capturing executable knowledge. There has been a school of thought that accurate requirements could lead to detailed modeling and then on to a full system implementation with most of the process automated. Dave Thomas in “MDA: Revenge of the Modelers or UML Utopia?” [5] writes: executable specification is an oxymoron—if the specification were truly executable, it would actually be “the thing.” Otherwise, it would merely model “the thing,” which is by definition partial and incomplete.


About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at or visit and follow his blog at

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at,  and a former section editor for The C++ Report. You can read Brad's blog at

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

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!