Writing Effective Use Cases
by Alistair Cockburn

List Price: $54.99
Our Price: $26.87
You Save: $28.12 (51%)
Availability: Usually ships in 1-2 business days
Buy Used: from $12.50 (click here)
Category: Book
See more book details and other editions

Book Summary Information

• Agile Software Development: The Cooperative Game (2nd Edition)
• User Stories Applied: For Agile Software Development
• The Software Project Manager's Bridge to Agility

Book Reviews of Writing Effective Use Cases

Book Review: Cockburn's approach naive
Summary: 2 Stars

Cockburn's approach to business use-cases is centred on an actor wanting to achieve a goal rather than a business event/response focus. Although business events are stated as triggers to a use-case, I am not happy with this, as a business event occurrence needs to cause the instantiation of an actor to handle the event. If BPR is part of the programme, the actor may not yet be known, as the determination of actors may be deferred until design, which is possible with the business event/response paradigm.

Cockburn partitions use case scenarios into those which `succeed', i.e. the actor achieves the goal, and those that `fail', i.e. the goal is not achieved due to violation of a rule. I do not agree with this view; a use case `fails' if it puts the business into an undefined state, which must never happen.

The content of the example use cases made no explicit mention of business objects, i.e. the static data-centric viewpoint was completely missing. As a result, I found the use cases to be too imprecise and largely untestable. In order to be precise and unambiguous, business use cases must be written in terms of a static business object model, supplemented with statecharts for business objects with complex lifecycles.

On page 164 Cockburn states that ` business rules do not fit well into the use case narrative'. I totally disagree : business use cases are the dynamic process view, and this is exactly where business rules must be, in their context of application. Business rules are often candidate variation points in a design, but for the designer to make intelligent decisions about them, their context of application to transactions must be clearly defined.

Cockburn's recommended format for use cases is numbered paragraphs detailing the main `success' scenario, with extensions for other scenarios. He does not recommend if..then..else statements, as he believes this leads to the document being difficult to read. If ... statements have basically been transmuted into extension paragraphs, but this will quickly degenerate into the `Fragmentary' type of process specification, which is hard work for designers and test analysts.

The section on stakeholders in use cases is focussed on business interests, whereas the focus should be on designers and test analysts as being the primary audience. As a result, the sections on QA and testing are woefully inadequate.

Much is made of `readability'; in my experience, the reason requirements documents do not get read is because they do not directly tell the the reader what he/she wants to know. Cockburn's method is more compact than the `Wuthering Heights' and `Fragmentary styles', but ultimately still falls into this trap.

Overall, I found this approach naïve, there being no evidence of any real analysis or modelling. This is reinforced by the reading list being very short for a technical book and not containing a single `serious' requirements engineering reference. I also believe Cockburn's approach is dangerous, in that it could lead to a totally false sense of security in the hands of inexperienced practitioners with a low level of knowledge of real requirements engineering.

Although the format is an improvement over the `Wuthering Heights' and `Fragmentary' styles of functional requirements specification, the example use cases are at `Concept of Operations' level, and are not sufficient for process requirements specification. If I were an acceptance test analyst given this content from which to identify test cases, I would know that I would have a lot of work to do; and yes, in my opinion there is a better way......

Summary of Writing Effective Use Cases

The focus of this text is on use cases that are written, as opposed to modeled in UML. This book may change your mind about the advantages of writing step-by-step descriptions of the way users (or actors) interact with systems. Besides being an exceptionally clear writer, the author has plenty to say about what works and what doesn't when it comes to creating use cases. There are several standout bits of expertise on display here, including excellent techniques for finding the right "scope" for use cases. (The book uses a color scheme in which blue indicates a sea-level use case that's just right, while higher-level use cases are white, and overly detailed ones are indigo. Cockburn also provides notational symbols to document these levels of detail within a design.)

This book contains numerous tips on the writing style for use cases and plenty of practical advice for managing projects that require a large number of use cases. One particular strength lies in the numerous actual use cases (many with impressive detail) that are borrowed from real-world projects, and demonstrate both good and bad practices. Even though the author expresses a preference for the format of use cases, he presents a variety of styles, including UML graphical versions. The explanation of how use cases fit into the rest of the software engineering process is especially good. The book concludes with several dozen concrete tips for writing better use cases.

Software engineering books often get bogged down in theory. Not so in Writing Effective Use Cases, a slender volume with a practical focus, a concise presentation style, and something truly valuable to say. This book will benefit most anyone who designs software for a living. --Richard Dragan

Topics covered:

Introduction to use cases Requirements Usage narratives Actors and goals Stakeholders Graphical models for use cases Scope for use cases (enterprise-level through nuts-and-bolts use cases) Primary and supporting actors Goal levels: user goals, summary level, and subfunctions Preconditions, triggers, and guarantees Main success scenarios Extensions for describing failures

Formats for use cases (including fully dressed one- and two-column formats) Use case templates for five common project types Managing use cases for large projects CRUD use cases Business-process modeling Missing requirements Moving from use cases to user-interface design Test cases eXtreme Programming (XP) and use cases Sample problem use cases Tips for writing use cases Use cases and UML diagrams

Object-Oriented Design Books

• Subjects > Computers & Technology > Programming > Software Design, Testing & Engineering > Object-Oriented Design
• Software