Writing Effective Use Cases [Paperback]

I must say that this book could make even someone new like me, being new to Use Cases, look good. The Table of Contents makes it easy to find an overall view of Use Case topics and the Index breaks it down in great detail. The book is described by the author as a book that is, "predominately aimed at industry professionals who read and study alone, and is therefore organized as a self-study guide." I like that.

If you are looking for a book for a class, such as the one I took, or just want to look good at work to describe a process, behavioral requirements, or software development, surely this book could help you too.

* How do I apply use cases to non-business software?
"Writing Effective Use Cases" includes 40 completed use cases related to a range of activities from Register Arrival of a Box to Apply a (System) Lock. That gave me a better feel for how use cases work than the usual Bank Customer Withdraws Cash or Online Customer Makes Puchase. As far as system software is concerned, Cockburn says:

"Occasionally I hear someone complain that it is hard to describe the requirements for a tape merge operation or a compiler with use cases. I wholeheartedly agree. Those are best described using algebraic or tabular forms."

* Can I go straight from use cases to design?
One of the misconceptions I had was that you could design directly from use cases. Cockburn goes to some trouble to explain that there is no one-to-one mapping between use cases and code, although use cases do make an excellent basis for test cases.

"The design doesn't cluster by use case. Blindly following the use case structure leads to functional decomposition designs (this is really of concern to object-oriented and component design teams.)"

* How do use cases relate to requirements?
The most valuable concept I obtained from "Writing Effective Use Cases" was that the primary value of use cases is to tease out the complete requirements, including how failures should be handled, from the potential customers of the system.

"[The use case] becomes a communication device between the different stakeholders on the project".

Recommended by the author:
Mastering the Requirements Process by Suzanne and James Robertson

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......