9 of 9 people found the following review helpful:
3.0 out of 5 stars
Interesting but flawed, 19 Aug 2005
This book 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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
6 of 6 people found the following review helpful:
5.0 out of 5 stars
Great for introducing use-cases into your work-flow, 26 July 2001
This review is from: Use Cases: Requirements in Context (Paperback)
I have read two books on Use Cases - these being Alistair Cockburns 'Writing Effective Use Cases', and this book. Both are brilliant.
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
6 of 6 people found the following review helpful:
5.0 out of 5 stars
Excellent reference book full of ideas and working practices, 8 Aug 2000
By A Customer
This review is from: Use Cases: Requirements in Context (Paperback)
I actually enjoyed reading this book and I liked the authors boldness in declaring requirement lists, DFD and ERD diagrams well and truly out-of-date in the requirements capture process, before going on to describe where in the UML process Use Cases can be used, and how they define the requirements clearly. This book is not just about Use Cases but about capturing requirements as well, and I think it does it without leaving anything out.
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No