Requirements-Based Development: A Software Configuration Management View


If you store documents in your repository with the code this makes it easier to track them and do things like branch different versions for a release. Doing this manually with no SCM tool support can be a bit of an overhead, but several SCM tools have Office plug-ins which make this fairly easy (and Office itself is WebDAV compliant which can help with other tools). It is possible to compare versions of Word documents using built in comparison facilities (we don’t recommend using the built in versioning though). Manual merging is often surprisingly easy if you have a couple of windows open with differences highlighted in each and some judicious copy and pasting gets the job done.

Of course the specialist requirements tools claim to solve a lot of these problem, although usually at a not insignificant cost. In our January crystal ball gazing column [7] we referred briefly to some of the advances we expect to see in requirements tools: they typically have wonderful facilities for attaching and viewing meta-data and links and taking a container-based view of collections of items, while lacking considerably in areas of branching and merging and baselining when it comes to having to support multiple projects/variants/sites. The Source Code version control tools have the opposite problem. We expect to see considerable improvement in this area, and unified repositories potentially offer big advantages. We have written before [8] about the use of story cards within agile methods such as XP, and our recommendation to balance the use of physical cards with appropriate electronic backup.

Task-Based Development (TBD)
This implies that changes to software should be associated with specific tasks—this enables traceability. If you take this approach to its logical conclusion and mandate that no change can take place without an associated task you run the risk of people working around the problem. They associate a change with any old convenient task, and the traceability becomes much less useful. Especially for agile development you need to allow for activities such as refactoring. The benefit of this is not immediate, and yet if it isn’t done regularly (mercilessly in some circles!), cruft builds up which slows the whole tempo of development. How do you know when enough refactoring has been done—that is usually a judgment call, and should be left to your developers, especially the senior ones—after all, why else do you employ them?! Done well, TBD provides a huge amount of benefit for very little overhead.

Automate, Automate, Automate!
However, we have seen any number of organizations where the actual linking of the changes checked in to the requirements involves various manual steps—copying and pasting from one application to another, or retyping information. Little steps, and some frequent slips—what seems a small overhead can mount up very quickly. Even if your tool doesn’t directly support this, some judicious scripting works wonders.

One of the authors had a recent experience reviewing a team of over 100 developers. They had some review processes in place which required them to package up diffs of changes and get them reviewed. Someone had written a simple script to help automate part of this process. The script did diffs of all checked out files, not just the ones specific to that task. This required manual editing of the output file before attaching to an email. By adding 3 characters to the script we solved that problem saving a few minutes a day each for 100+ people—mounts up, doesn’t it! For ideas and the whole ethos behind automation, see the work of the Pragmatic Programmers.

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!