Feeds

Vague and ambiguous use cases

How abstract should your specs be?

Internet Security Threat Report 2014

Column Programmers are often frustrated when well-meaning managers or architects attempt to introduce some OOAD [note that the process in my link isn't necessarily the same as the Iconix process Matt alludes to - Ed] into their projects.

Often the reason for this frustration is subtle, and has nothing to do with OOAD as such - it's that they've been given vague and ambiguous requirements to design from. And the reason for so much ambiguity is that so many of the books and gurus out there preach "abstract, essential, technology-free, and implementation-independent" as the right way to write use cases.

Representation of Vague and Ambiguous Use Cases

To illustrate...

Which of these two use case scenarios would you prefer to create a design from?

  1. The clerk enters basic loss information specific to the claim line. The system confirms that there are no existing, possibly competing claims and assigns a claim number. The clerk confirms they are finished; the system saves and triggers acknowledgement to be sent to the agent.
  2. The system displays the Basic Loss Information Page, with a form to enter basic loss information specific to the claim line. The clerk fills out the form then clicks the "Add" button. The system queries the claims database to confirm that there are no existing, possibly competing claims. The system then assigns an ID to the claim and displays the confirmation page. The clerk clicks the "Confirm" button, and the system saves the claim, then triggers acknowledgement to be sent to the agent.

(For brevity's sake, I'm omitting the all-important "rainy day scenarios"; such as what the system should do if an existing, competing claim is discovered).

Example 1 is excerpted, and slightly mangled to fit into the context of this article, from a longer use case description in Alistair Cockburn's Writing Effective Use Cases. Example 2 is my attempt at rewriting the first one to be less vague and ambiguous.

Example 1 is an "essential", abstract, technology-free and implementation-independent use case description. In fact, it's closer to a business process description as it has a lot to say about the details of a business transaction but very little (nothing, in fact) about precisely how the user and the system will interact. In other words, it's entirely divorced from the technical or UI details.

By contrast, Example 2 is more of a detailed usage description: a low-level scenario. So to an extent, we're talking "horses for courses" - different styles for different purposes.

But if you're defining the business and purely the business (as in Example 1) - to be brutally honest you probably don't want to do this with use cases - you'd do better to write business process descriptions, which tend to be broader in scope (one use case is typically a "discrete packet of functionality", i.e. quite fine-grained).

But having defined your business processes, there's a mighty leap to get from there to an architecture and detailed design. This is where Example 2 comes in, a set of use case scenario descriptions with concrete, tangible and specific statements of required system behaviour that programmers can deal with efficiently.

As you've probably gathered, my own preference is for the second example, because it's far more explicit. So instead of showing a page/screen/unspecified UI component with information about basic loss information, the system is displaying a Basic Loss Information Page. It gives the developers a specific name to refer to.

To illustrate this, in the second example I've bolded the terms that would end up as domain objects, actors or pages/screens, which then get used in the detailed design. In doing so, I noted that Basic Loss Information could be an entity class, or even be a set of attributes on a Claim entity class. This all helps to tighten up your behavioural spec, and it's a tangible benefit of tying your use cases to your objects.

By writing your use cases using a concrete, unambiguous style, you end up with a rigorous specification of how the user and the system will interact (with an additional, higher-level description of the business processes, if the project calls for it). From a behavioural spec of this sort, it's then much easier to design and create a comprehensive set of unit tests, and to create realistic estimates.

(The diagram at the top of this article appears in the Preface to my latest snappily titled blockbuster co-authored with Doug Rosenberg, Use Case Driven Object Modeling with UML: Theory and Practice, which walks you through the OOAD process I've alluded to in this article). ®

Choosing a cloud hosting partner with confidence

More from The Register

next story
Netscape Navigator - the browser that started it all - turns 20
It was 20 years ago today, Marc Andreeesen taught the band to play
Sway: Microsoft's new Office app doesn't have an Undo function
Content aggregation, meet the workplace ... oh
Sign off my IT project or I’ll PHONE your MUM
Honestly, it’s a piece of piss
Return of the Jedi – Apache reclaims web server crown
.london, .hamburg and .公司 - that's .com in Chinese - storm the web server charts
NetWare sales revive in China thanks to that man Snowden
If it ain't Microsoft, it's in fashion behind the Great Firewall
Chrome 38's new HTML tag support makes fatties FIT and SKINNIER
First browser to protect networks' bandwith using official spec
Admins! Never mind POODLE, there're NEW OpenSSL bugs to splat
Four new patches for open-source crypto libraries
prev story

Whitepapers

Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Why cloud backup?
Combining the latest advancements in disk-based backup with secure, integrated, cloud technologies offer organizations fast and assured recovery of their critical enterprise data.
Win a year’s supply of chocolate
There is no techie angle to this competition so we're not going to pretend there is, but everyone loves chocolate so who cares.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Intelligent flash storage arrays
Tegile Intelligent Storage Arrays with IntelliFlash helps IT boost storage utilization and effciency while delivering unmatched storage savings and performance.