Use case style means handbags at 30 paces
Style is all that matters
In February, I wrote a Reg Developer article which caused some consternation. The article's message distils down to: Don't write vague use cases, write concrete, specific use cases that leave nothing to the imagination instead. Controversial stuff.
It turns out, I believe, that use case style hides a miasma of strong feelings and conflicting opinions far in excess of anything seen in the programming world.
Programmers have it easy: curly brace positioning, level of commenting, variable naming style etc. The Great Napoleonic Curly Brace Positioning War of 1803 was a schoolyard tussle compared with the political infighting that goes on around how to write use cases.
There are some elements of use case style that can seem important, but which ultimately don't make a shred of difference (except to slow the project down while everyone bickers) - like whether to structure your use case in the "narrative paragraphs" or "numbered list of steps" styles, or whether to link your use cases using "includes", "extends", or "invokes" stereotypes.
But there are some elements that really do matter, because they affect the ease with which the developers will be able to interpret your specification. Here are a few of them:
Active versus passive voice: Here's a passively worded description: "The capability is provided for users to log in, using a password-protected authorisation scheme." And here it is in active voice: "The user enters her username and password, and then clicks the Login button. The system looks up the user profile using the username and checks the password. The system then logs in the user."
If you write your use cases in active voice, you'll find that you write less ambiguously, and you'll prevent your reader from falling asleep face-first in her double chocolate chip muffin, which she'll thank you for.
Functional versus behavioural descriptions: Use cases are behavioural requirements specs, each one describing a user's interaction with the system. Mixing in functional requirements ("The system shall be capable of detecting intruders by their typing speed") is a common malpractice. Of course, functional requirements do have their place, but that place isn't in your use case descriptions.
How many 'rainy day' scenarios is enough? Ten. Three. One hundred. Of course, there is no magic number. The correct number of rainy day scenarios is simply when you've brainstormed and quizzed the end-users and can't think of any other variations or ways in which the 'sunny day' scenario could go wrong.
Comprehensive versus Minimal Templates: What else can we add to our template? Preconditions, post-conditions, scope, minimal guarantees, level, context of use... The list of fun and entertaining subheadings to add to your template is endless. But keep in mind that the more "blanks" you add that need to be filled in for each use case, the longer each use case will take to write; and, the less bang for your buck you'll get out of them.
Whether to reference domain classes by name: By domain classes I mean names for real-world or problem domain objects referenced in the project, e.g. trade, ledger. Some analysts feel that even this level of detail is too concrete for a use case.
Whether to reference UI elements (screen/page names, buttons etc.): This particular piece of religious touch paper is the catalyst for much of the disagreement about the purpose of use cases; so I'll return to this subject in my next article.
With some style elements, most people will agree wholeheartedly that there's a right and a wrong way to write them. Just no one can really agree on what's right and what's wrong. Check back in a couple of weeks... ®
Matt Stephens is the co-author, with Doug Rosenberg, of Use Case Driven Object Modeling with UML: Theory and Practice.
Sponsored: IBM FlashSystem V9000 product guide