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

About the author

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.