Agile or Analytic?
Book Reviews: Cohn vs Lavi & Kudish

Every now and again a pair of books comes 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 engineering and systems communities have continued to do their own thing, tutting politely at the behaviour of the young bolsheviks outside torching 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. Isn't 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 Chapter 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 don't 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 won't 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, Chapter 12 of Cohn also attacks traditional IEEE 830-style requirements as

"tedious, error-prone, and very time-consuming"

"quite frankly, boring to read",

Lavi and Kudish have been working on and with their method since 1980, initially in the aerospace industry but with a substantial backing in research. That both David Harel (inventor of the State Chart) and Mike Mannion (a pioneer of software engineering for product lines) liked the book enough to write cover blurbs was a futher clue that the contents would prove more appealing than the noun-heavy, acronym-laden title.

Lavi and Kudish cover a lot of ground. They begin quite traditionally with a context diagram, scope, and 'determination of the system's boundaries'. They make a data dictionary and a top-level specification. Then they examine modes and states, events, transitions, conditions and time -- in an event-driven world like aerospace, this makes sense; indeed, one of the few books that deals thoroughly with events, Bill Wiley's Essential System Requirements, comes from the same domain. But Lavi & Kudish go much further.

Their method is to step iteratively (Cohn and Beck have no monopoly on that front) through identifying the externally-observable ("E-level", black-box) system capabilities -- such as one might record in user stories: they use operational scenarios, among other things; modelling the processes underlying those capabilities; and then going inside the box to model "S-level" or white-box system behaviour, and successively decomposing into subsystems that can be built (or purchased, or subcontracted) separately. To do that they describe methods of decomposition, including objects; they analyse the system's internal information flows and subsystem capabilities; they identify internal system modes and processes; and they describe the transition to design.

As if all that wasn't enough, they also examine the stakeholders' requirements process -- like Cohn, they pay proper attention to the needs of different kinds of stakeholder, but quite unlike Cohn they know all about contractual and non-contractual situations, which they discuss in detail. They also consider what model-driven requirements allocation and derivation (expansion) mean in practice. Like Cohn they know that requirements must drive design by insisting on verification, and though their language differs greatly, they know that a specification is only as good as its acceptance criteria. They end with a short chapter on requirements management, covering traceability and configuration management perhaps rather briefly. The value of the book is greatly enhanced by the presence of no less than five detailed case studies for exercises. An appendix summarizes the proposed notation; there is a detailed glossary.

One might sum up the difference between these two books by saying that where Cohn is surprisingly well-read and reflective for such a young approach, Lavi & Kudish are surprisingly modern and agile for something so traditional. Both are excellent books - rich in detail, well thought out, closely argued, well illustrated, reflective and practical. That the approaches they advocate are so different says something about the state of software engineering today. Partly that reflects the different types of system that they have in mind: Cohn is in the main envisaging software that consults a database over the web, while Lavi & Kudish discuss military aircraft among many other (fully-worked) examples. Clearly the latter require decomposition of system requirements into subsystem specifications, so a hierarchical architecture is necessary, and documentation cannot be avoided. Perhaps Cohn does not address this issue head-on, given the domain in which he works: how far can agility be applied when a design and interfaces have to be agreed and shared among many subcontractors? Few things are less agile than contractual boundaries.

Both these books are immediately useful in industry, and can be warmly recommended. Students will also find them excellent companions -- both are well-organized and indexed, both have good bibliographies, and both (surprisingly) provide exercises.

© Ian Alexander 2005

You may also like: