Oct
12
Cockburn vs. Bittner & Spence
October 12, 2005 |
As far as I can tell, the two most common notations for writing use cases are the ones promoted by Alistair Cockburn and by Kurt Bittner and Ian Spence.
The key difference between them is the management of alternate flows.
Cockburn lumps all the alternates together in a single section. The first step in the alternate flow is given a number based on where it diverges from the main flow. All the steps are then listed in sequence, and the final step specifies at which step in the basic flow the alternate flow resumes.
Bittner & Spence require that you add names extension points to the main flow. The alternate flows are also named and begin at one of these extension points. In general, once the alternate flow is completed you resume at the extension point.
I’ve used both for about a year, and how you write the use case actually does alter how you think about the flows.
I find Cockburn’s notation easier on developers, because it is closer to pseudocode. It also seems to be better for spotting error conditions that might occur during the execution of the use case and for understanding possible interactions between alternate flows, because you think about the alternates as a whole. On the other hand, it is a lot harder to read and non-technical stakeholders find it confusing. Changes to the basic flow or alternate flows cause ripple effects on the numbering of everything else, and since autonumbering is hard in most tools, it’s easy for accidental errors to be introduced in complex use cases.
Bittner and Spence’s notation is a lot easier to read. It also makes the concept of an extension point a lot clearer, and makes it much easier to write use cases for later releases that extend previously developed use cases. It’s easier to mark a named subflow as out of scope for a particular release and get a handle on the complexity of a use case. On the other hand, error conditions and problems in various scenarios have an easier time being overlooked or mishandled.
For what it’s worth, I use Bittner and Spence’s notation these days–the improvements in readability and comprehension seem to be worth it. But for a processing heavy system, I might consider going back to Cockburn.
Comments
What I'm Reading- Agile Requirements Information Model (4) – Subset For Agile Programs (a): Features and Feature BacklogScaling Software Agility
- The Great Implication of Context-Driven MethodologyJames Bach's Blog
- User stories versus Use CasesBusiness Analyst Blog
- Can Use Cases Possibly be Agile?Agile Product Owner (.com)
- A little bit of levity for the holidays from iRiseThe iRise Blog
- The end of reposiphilia?The Forrester Blog For Technology Product Management & Marketing Professionals
- IT ethics and the recessionIT Project Failures
- Risk Assessment ModelingEDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology
- Test Requirements, Don't Test CodeHerding Cats
- Enterprise architecture is optionalBizRules Blog