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  “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?”  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.
The Lean Approach
The lean approach has a slightly different viewpoint. In an attention grabbing presentation by Mary Poppendieck of Lean Software Development fame , she made the point that you make more money by increasing your ratio of outputs to inputs, and a key way to improve your productivity is just to do less work! Provide only what the customer will pay for. A quote from Jim Johnson of the Standish Group: users typically use only 25% of the system - 65% of features are rarely or never used ( see Martin Fowler's write-up of XP2002 ).
Where do all these extra features come from?
- we ask the customer what they want
- we reward them for thinking of everything ("scope")
- we penalise them for adding features later ("scope creep")
So we effectively train them to go for a humungous, all singing all dancing set of requirements up front! This reinforces requirements as a key differentiating practice.
For some alternative ideas she recommends Minimum Marketable Feature Set (Mark Denne & Jane Cleland-Huang, Software by Numbers; Low-Risk, High Return Development , Prentice Hall, 2004).
The Power of Scenarios
Just a quick mention for a very powerful technique – that of writing scenarios to tease out requirements and desired functionality. If you pitch these correctly they can provide an excellent way of communicating the needs of the users. For some examples, see Joel Spolsky’s examples . The related technique that has sprung to the fore is use cases as describe about by Alistair Cockburn  in his two books and other related papers.
So let’s get a little more practical and look at some of the details of managing requirements. From an SCM point of view this means treating them as configuration items and then implementing the classic processes of: identification, change control, status accounting and configuration audit.
To date, the most widely used requirements management tool is Microsoft Word (followed closely by Excel)! The huge advantage is the extreme flexibility of these documents as a format for capturing and recording requirements. Word is very convenient and efficient for producing documents (including the majority of these articles!) and its universal availability is another major factor.
The biggest problem with this is that Word documents are frequently managed badly as configuration items. Problems include:
- Version identification and control for baselines – which version is valid for which release?
- Binary format makes comparisons difficult and thus tracking changes between versions of the documents difficult
The recent announcements