Use Cases: Requirements in Context (Paperback)

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.

I think this book is well written and well laid out, gradually pulling the reader into greater and greater detail, and concentrating on the subject. I like the style and presentation. The relationship between requirements and use cases is fully explored in a very readable way, though I thought that the business rules may have deserved a little more explanation, but that is not really what the book is all about. It also defines a series of documents (or templates) that may be used to hold all the information that should be gathered during this process and not just concentrate on Use Case analysis. It also provides the reader with some good tips. I do believe that in practice the facade and filled steps in the use case development will actually be performed all in one go due to time and other limitations, though as the author says, everyone should try and spend time on the early stages.

The appendices provide two examples of Use Case Analysis and move from the early to the complete stage showing each step and indicating how the complete picture is built up.

The only problems I have with this book (and they are very minor) is that some use cases and diagrams are duplicated throughout the book and serve only as examples, which could save some space, especially when the ones concerned are fairly basic. Also the differences between Use Case descriptions in the appendices are not very clear, you have to keep flicking between pages to compare the facade, filled and complete use cases to see if they have changed. It would be better to outline the changed parts in bold or italics.

This book was purchased for our software group - I thought it was good enough to have on my own shelf as well.

This book will be useful to those who are trying to fit Use Case modelling into their working practices. It tells you about how you can iteritively progress your use cases from sketchy ideas to refined and correct requirements.

It also describes where other related issues such as business rules and risks fit into the picture.