INDEX

the evenings out here - Thoughts, rants and musings about absolutely everything except photography. Or cats.

Use Cases: Requirements in Context

in Technical Book Reviews , Friday, August 19, 2005

0321154983_xs.jpg "Use Cases: Requirements in Context", by Daryl Kulak and Eamonn Guiney, professes to present a radical approach to gathering and defining software requirements, employing only Use Cases. Whilst many other writers embrace Use Cases as an important part of a requirements engineering process, here the authors take it all the way, and claim that not only is there no other workable alternative, but that any dilution by including other methods, such as narrative based approaches, is unacceptable. They take no prisoners, stomping all over Alistair Cockburn's notion of Use Case hierarchies (which I've always found a bit clumsy, to be honest), and generally being irreverent about everything else. It is quite entertaining, and presents an interesting thesis. Unfortunately, it is also appallingly edited, inconsistent, not terribly well written, and lacking in detail at crucial points. For example in section 2.3.4, the text refers to a sample Use Case which has nothing to do with the scenario under discussion, nominally based on this Use Case. However, on the next page, the discussion abruptly switches to something which seems relevant to the Use Case, but is a total non-sequitur in the text. There are many such examples of bad editing throughout the book. A really serious snafu comes on page 85: "NOTE: In the first edition of this book, we advocated a tool called system context level use case ? we formally disavow this technique in this new edition". Rather a pity, because in Section 4.4, Deliverables, we're told that the Facade iteration is complete when, amongst other things, a system context use case is documented. Whoops! In section 5.2, we're told that system context use case diagram shows the big picture, and each package's diagram will contain the detail for each set of use cases. Try "Find and Replace" in your word processor, chaps. It can be a surprisingly useful tool. Another irritating habit found in several places is introducing an interesting sounding concept and then failing to explain it properly. For example, the idea that non-functional requirements can be captured as Use Case stereotypes is, well, interesting ? but just one single example might help to convince the more sceptical reader. Equally, the much heralded "hierarchy killer" tool remains a complete mystery to me. It could be an interesting idea, but the author's writing skills do not reach a level where the odd example or diagram would not help a bit. However, if you are interested in the sharp end of requirements engineering, I do recommend you read the book, with the proviso to not treat it as gospel. It is provocative, sometimes funny, quite often entertaining, but the various errors and inconsistencies are jarring and left me rather disappointed. I did not believe that Use Cases offer a 100% proof solution to requirements definition, and I still don't, but in at least 80% of situations they work well, and this book provides some very valuable insights into applying them effectively. Publisher: Addison Wesley Pub Date: July 25, 2003 ISBN: 0-321-15498-3