One of the BEST ways to guarantee project failure is to develop a comprehensive requirements document early in your software development project. A 2001 study by M. Thomas in the U.K. of 1,027 projects showed that scope management related to attempting waterfall practices — including detailed, up-front
requirements — was cited as the No. 1 cause of failure in 82 per cent of projects that flopped.
At the XP 2002 conference in Sardinia Italy, Jim Johnson of the Standish Group said its Chaos report showed that when requirements are specified early in the lifecycle, 80 per cent of the functionality will not be taken advantage of by users. He reported that 45 per cent of features are never used, 19 per cent are rarely used, and 16 per cent are sometimes used.
There are two reasons why this happens. First, when project stakeholders are told they need to get all of their requirements down on paper early in the project, they desperately try to define as many potential requirements (things they might need, but really aren’t sure about right now) as they can. They know if they don’t define these “”requirements”” now that it will be too hard to get them added later due to the change management/prevention process that will be put in place once the requirements document is baselined. Second, things change between when the requirements are defined and when the software is actually delivered. The only way to effectively manage change is to accept that it will happen and then find ways to easily do so.
Agilists still identify requirements early in the project lifecycle. The difference is they know enough not to go into significant detail. We still need to identify the high-level scope of your efforts, gather sufficient information for initial estimating and scheduling and build a consensus among our stakeholders and within our development team as to what the requirements imply. This initial modelling effort should take no more than a few days (for a large project).
We identify the details in a just-in-time manner throughout our projects. During each development iteration, we model storm, code, test, build and potentially deploy your software. Model storming sessions are typically performed in an impromptu fashion by small groups of people, typically a development subteam working on a requirement with one or more project stakeholders providing input. The goal is to model just enough at that point to get the requirement implemented — we know we can do the exact same thing again for the next requirement.
Our project stakeholders must be actively involved with our project teams. This happens because we create inclusive models. Tools such as whiteboards or paper are employed. There is a wide variety of simple modeling techniques, essential-use cases, paper-based user interface prototypes and free-form sketches described in detail at www.agilemodeling.com/artifacts/.
If defining and then “”freezing”” requirements leads to project failure, or at best, to systems that are overbuilt, isn’t it time to rethink your approach?
Scott Ambler is an independent consultant specializing in object-oriented development. His latest book is The Object Primer 3rd Edition: Agile Model Driven Development with UML2. www.ambysoft.com
