“Perishable Requirements”
Re-reading Agile Management for Software Engineering
I re-read it several times, and each time it sunk in deeper just how important this concept is: this alone proves the worth of an agile approach to project development. Requirements go stale.
Most obviously, they run the risk of becoming obselete as the team and client’s understanding of the project evolves; but, equally importantly, they suffer atrophy simply through lack of use.
Once captured and defined, a requirement has a half-life – the longer it gets left in the requirements document without being actively worked on, the poorer the knowledge of that requirement. Clearly, if the developer leaves, the team suffers massive impact in its understanding of the requirement. But, even if the developer stays, their understanding and knowledge of the requirement withers as they work on other things.
The reality is that a requirement can rarely be so fully captured that it doesn’t depend on an individual’s understanding and definition of it.
The solution to this problem?
Define a sub-set of requirements that can be worked on within a specific timeframe. Move from requirements capture and definition to solution implementation within the same timeframe. Work agilely.
* Eli Schragenheim & David J. Anderson, Prentice Hall, 2003 (ISBN: 0-13-142460-2)
