Every now and again a pair of books come on to the market offering interestingly contrasting perspectives on the same area. Since Kent Beck’s dramatic Extreme Programming burst onstage in 2000, there has been a stream of books from the object-oriented software community on the theme of first ‘extreme’ and now ‘agile’ development approaches. These have argued, sometimes roughly and forcefully, that the traditional software development life cycle was too cumbersome and often ineffective. Meanwhile, the more traditional requirements of engineering and systems communities have continued to do their own thing, tutting politely at the behaviour of the young bolsheviks torching outside their institutions. Cohn’s readable book offers a practical introduction to the use of brief scenarios in the form of Kent Beck’s user stories. A user story is just what it says on the tin: it is a short, informal description of how some class of user could interact with and benefit from the proposed software. Is not that exactly what Ivar Jacobson meant to do with his use cases? Sssh! Of course, both scenarios and use cases now have (a range of) different meanings. Cohn is careful to distinguish user stories from these in Chap. 12, ‘What Stories Are Not’. Something that is particularly welcome is recognition that there are many kinds of user; Cohn suggests brainstorming possible kinds, perhaps an odd choice of technique here, but much better than just assuming that all users are rather like programmers. And that is not all; Cohn shows in a practical way with examples and advice how to use stories to drive software development, so the book in fact covers all the early part of the life cycle, and even strays into XP to show how the whole cycle works. But instead of shouting in the streets, Cohn ventures inside the requirements literature, and reflects in a fresh and practical way on what is good and not so good in the tradition. First to go is vague talk of ‘‘elicitation’’ or ‘‘capture’’ (several well-known books are criticised at this point): requirements do not run about by themselves, nor are they waiting fully formed inside people’s heads just to be elicited. The Robertsons’ ‘‘trawling’’ is however taken up with enthusiasm: you would not catch all the requirements in one trawl, so the process is inevitably iterative—which chimes well with the agile theme. We may argue that we knew it was iterative already, but far too many projects were not; and it is really welcome to see the Agile community engaging with the ongoing debate. However, Chap. 12 of Cohn also attacks traditional IEEE 830-style requirements as
Read full abstract