Vague and ambiguous use cases revisited

Join Camp Gritty


Oh no, not again: the industry's gone and divided into two camps. In Camp Purity, there's the group insisting that use cases must be abstract and free of any specific technology or UI feature. Simply heavenly! Useless, but heavenly.

Then in Camp Gritty, there's the group politely whispering that use cases work better when they're concrete, specific and tuned into the design. I'm firmly in Camp Gritty (but as you can see from the responses to this linked article, many people aren't).

head shot of Matt Stephens smiling

Matt Stephens.

Of course, it's horses for courses really. The term "use case" has evolved to mean more than one type of specification, and – crucially – is applied at varying stages in the development lifecycle. So use case advice only makes sense if you first establish exactly which type of use case you're talking about, and at what stage it should be applied – oh, and who's actually involved in writing the use cases and the "document ping-pong" that follows while the details are ironed out.

According to the Camp Puritans, "the user clicks the Submit button on the Details page" is an unforgivably evil statement, because it imposes the concept of buttons and clicking on the final UI – and the final UI may not use buttons (not if Steve Jobs is involved in the design, at any rate). Worse, the example implies a web-based system, and surely you want to keep those use cases pure, because the eventual system may not be web-based at all.

If the use cases comprised your first written specification for the system (which they probably shouldn't), then it would make sense to omit the technical details: after all, you're defining the "what" and the "why", not the "how". But it's more likely that the project's first written specification of any weight will be a functional spec: "The system shall allow humanoid entities to update customer details." This is an important document, but handing it directly to the programmers/designers is likely to result in much guesswork, and an eventual system that is almost, but not quite, entirely unlike the customer's own vision of the finished article. ("What we demand is a total absence of solid facts.")

This is where use cases really come into their own - pinning down the specifics. Not to use them in this way would be a terrible shame, as they're so good at it. And if you combine use cases with robustness analysis and a domain model to bridge the gap between analysis and design, then there's little room left for ambiguity and guesswork.

So, who writes the use cases? Usually a non-technical person who spends a lot of time talking to the customers and end-users. But use case writing works best as a collaborative and iterative process. The first-draft text won't be the last. Robustness analysis (aka preliminary design, aka use case realisation, which definitely involves the developers) may result in a virtual rewrite of the use case text; not necessarily changing the scope, but wringing out ambiguity and making sure that the behavioural scenarios are written in the context of the domain model, from which the eventual class design will flow.

Use cases are also useful as a user experience description, exploring the user's path through the UI to complete specific tasks. While a "pure" use case that doesn't pin down the UI might seem like a good thing (rather like several layers of separation in a multi-tiered design), in practice it isn't really much use.

So... at some point in the project you'll need to hunker down and start committing to technical/architectural decisions, so why not make it the use case stage? Join Camp Gritty, you know it makes sense.

Matt Stephens is the co-author, with Doug Rosenberg, of Use Case Driven Object Modeling with UML: Theory and Practice.


Other stories you might like

  • Returning to the Moon on the European Service Module
    Moving to series production and dealing with the US, where things are done slightly differently

    Interview NASA has set late August as the launch window for its much-delayed Artemis I rocket. Already perched atop the booster is the first flight-ready European Service Module (ESM). Five more are in the pipeline.

    Airbus industrial manager Siân Cleaver, whom The Register met at the Goodwood Festival of Speed's Future Lab, has the task of managing the assembly of the spacecraft, which will provide propulsion, power, water, oxygen and nitrogen for the Orion capsule.

    Looking for all the world like an evolution of the European Space Agency's (ESA) International Space Station (ISS) ATV freighter, the ESM is not pressurized and measures approximately 4 meters in length, including the Orbital Maneuvering System Engine (OMSE), which protrudes from the base.

    Continue reading
  • Running DOS on 64-bit Windows and Linux: Just because you can
    DOS isn't dead. You can still run it and its apps, even now

    FOSS Fest There are still ways to run DOS apps under 64-bit Windows and Linux, and a lot of free apps to choose from.

    One of the differences between the Microsoft and Apple approaches to maintaining widely used OSes is that Apple is quite aggressive about removing backwards compatibility, while Microsoft tries hard to keep it.

    One of the few times Microsoft removed a whole compatibility layer from Windows was with the launch of 64-bit Windows, which went mainstream with Vista in 2007. 64-bit editions of Windows can't run 16-bit apps, whether they're for DOS or Windows.

    Continue reading
  • China's blockchain boosters slam crypto as Ponzi scheme
    Communists reckon Bill Gates and Warren Buffet got it right

    Executives at China's Blockchain-based Service Network (BSN) – a state-backed initiative aimed at driving the commercial adoption of blockchain technology – labelled cryptocurrency "the biggest Ponzi scheme in human history" in state-sponsored media on Sunday.

    "The author of this article believes that virtual currency is becoming the largest Ponzi scheme in human history, and in order to maintain this scam, the currency circle has tried to put on various cloaks for it," wrote Shan Zhiguang and He Yifan in the People's Daily.

    He Yifan is the CEO of startup Red Date Technology – a founding member and architect behind BSN – where he serves as executive director. Co-author Zhiguang Shan is chair of the BSN Development Alliance.

    Continue reading

Biting the hand that feeds IT © 1998–2022