A staple agile practice is that of unit test frameworks. The ability to re-run thousands of tests allows key practices such as refactoring to take place safely with vastly reduced risk. Unit tests provides a project development heart beat of ongoing progress, and frequently improved (simplified) code—code that is easily testable is usually easier to understand than code that isn’t. Quite a bit of work has been going in to acceptance test frameworks which are a little more difficult. Simple table driven specifications of tests such as those used in Fitnesse, can not only provide security but also help refine requirements since they provide a language to talk to the end user in that can be much more precise about the meaning of requirements. There are many challenges, particularly in the areas of GUI testing, but this is a very valuable practice to investigate.
Applying Agile Principles to Requirements
A good requirements process doesn’t happen by magic, and certainly isn’t produced just by tools. It requires hard graft and intelligence, both in the discovering of requirements and in their management and integration into the whole development process. Some principles which are helpful:
- DRY (Don’t Repeat Yourself)—how many times is information copied backwards and forward between systems and applications? How can you minimise this, or automate it?
- YAGNI (You Aren’t Gonna Need It)—evolutionary development and prioritizing of requirements for the upcoming delivery, postponing all sorts of details about other require
- Test First Development—get feedback on your requirements by working on acceptance test frameworks
A good requirements process is fundamental to software—heading a few steps in the right direction is usually better than zooming off ever so efficiently in totally the wrong direction! Being bad at discovering requirements is a quick way to failure. Of course even with excellent requirements you still have to develop the appropriate software. There may not be a magic bullet, but you can evolve from smooth bore muskets to sniper rifles through applying good software engineering and agile principles, and of course sound SCM practices too!
References and Additional Resources
 Software Engineering Body of Knowledge, www.swebok.org
 Requirements Engineering Maturity in the CMMI, Dennis Linscomb, Crosstalk
 Requirements and Change, Richard Brooksby, http://www.ravenbrook.com/doc/2003/02/24/requirements-and-change/
 Is Design Dead? Martin Fowler, http://martinfowler.com/articles/designDead.html
 “MDA: Revenge of the Modelers or UML Utopia?,” by Dave Thomas, http://martinfowler.com/ieeeSoftware/mda-thomas.pdf
 Lean Programming; by Mary Poppendieck; Software Development Magazine, May-June 2001 (Vol. 9, No. 5 and 6—see full article at http://www.poppendieck.com/lean.htm)
 Future of Agile CM, CM Journal, Jan 2005 (Vol 4. No. 1) by Brad Appleton, Robert Cowham and Steve Berczuk
 The Agile Difference for SCM, CM Journal, Oct 2004 (Vol 3. No. 10) by Brad Appleton, Robert Cowham and Steve Berczuk
 User Interface Design for Programmers by By Joel Spolsky, http://www.joelonsoftware.com/uibook/chapters/fog0000000065.html
 Writing Effective Use Cases, by Alistair Cockburn, http://alistair.cockburn.us/usecases/usecases.html