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 that the next version of MS Office will default to XML formats sounds interesting in that it should make version control much easier.