Critique Of Use Cases

We have begun writing UseCases, or ScenarioTextualDescriptions as our professor calls them in his PhD thesis. We're loosely mapping out UseCaseMaps. From this experience, I have made several conclusions.

(*) Actually, you can keep the source code and the use cases in phase but it requires more effort. In general, if you have n duplications of information, it will require n^2 as much work as if you had one copy of the information. [Consider the number of arcs in a fully connected directed graph with n nodes plus an overhead cost for maintaining each node = n(n-1)/2 * 2 + n = n^2 - n + n = n^2. ] -- SunirShah

That's a good critique of UseCases. It will be interesting to see if your view changes when you are on a different sort of project, with a different sort of customer. (UseCases solve problems that you aren't mentioning, as below)

Surprisingly, perhaps, not everyone understands what the system will actually do from UserStories written on index cards. UserStories, in their late 1999 XP incarnation, are more like what other people in the industry call "features" ("shalls" in military lingo). The problem with lists of features is that it not always clear what the system is busy doing. Programmers, of course, are (initially) happy with feature lists, because the work to be done is already broken down. Users, on the other hand, and executive sponsors, often aren't really sure what they are getting.

Those sentences beg an obvious reply from the XP community - that user stories a la XP are being well understood by the users. I think this is due to the fact that we have had extremely experienced programmers sitting with the users so far, and they are monitoring the conversation closely. With the examples of user stories floating around the net at the moment, and the coaching being offered online, I expect that to change.

The other saving grace for XP UserStories is their prioritization. The PlanningGame gives the customer a chance to ensure that a coherent set of features get implemented - a set that delivers value in combination. Historically, requirements documents suffer from unordered collections of features. That is what is driving people to write use cases, if they have been writing feature lists or "shall"s previously. They need to get a coherent picture of the system behavior, not just lots of little fragments.

-- AlistairCockburn

Your comments about duplicate maintenance are correct, but some amount of duplicate maintenance is inevitable. I'll move this conversation to RequirementsAndDesign. -- Alistair

Commonly, use cases are written in prosaic and linear text. However, reflection and abstraction are both available in natural language, and you can use them. Natural language is more expressive than Smalltalk. Certainly the tools don't support polymorphism, although natural language does. -- Alistair

Alistair, I think that XP substitutes continuous communication for the structure that use cases impose. Sunir, you can do quite a bit of abstraction with use cases. For instance, UML provides <<uses>> and <<extends>> as mechanisms for abstracting use case text. DanRawsthorne likes to model use cases using class diagrams partly because he considers use cases to be objects. (I'm more into using tables now - I realized that extensive use case diagrams were the developer in me coming out, and weren't particularly interesting to the users... DanRawsthorne) I personally like to group them by roles if I have a lot of them (in practice I usually don't). You can do an OO decomposition of roles by treating them as classes. I think of use cases as the procedural part of an OO model of an organization just as I think of method bodies as the procedural part of an OO model of a program.

The key issue is communication. The less face to face communication you have the more paper communication you need. The less of a shared culture you have the more formality you need. For me being aware of XP makes me aware of the trade off. The best possible communication happens face to face between people who have a well established relationship. Things like highly structured use cases and detailed paper models serve to make communication possible between people who are separated by geography and personal relationships. The challenge isn't in determining which is better, it's in understanding how much of which tools to use and when. -- PhilGoodwin

This is going to get esoteric, but here goes.

Consider a system to be a volume in a discrete space. A discrete space is built out of indivisible quantized partitions, like pixels on your screen. It's discrete because your computer is. It's that Turing guy again..

If you consider that, then each feature, or UserStory, is like a point inside this volume. A UseCase is like a path through the volume. A diagram is like a surface inside this volume.

All actual changes happen at the point level. Many paths and surfaces go through any given point. To keep your static copies of these paths and surfaces (specific UseCases and diagrams) accurate, you have to update each element of this possibly large set. However, there is only the one point and the one volume, so there aren't many copies of these that need to be updated (probably approaching zero).

Naturally, if that one point is the root of a large coupling graph, there will be many changes to be made anyway. But still many paths and surfaces intersect each and every point in that graph, and those will need to be updated as well.

On the other hand, if you reduce the entire system to a set of unordered points, you've lost information on how those points are connected to each other. Thus, you need higher order slices of the overall volume (which we presume is too large to be understood) to provide insight. Hence, UseCases and diagrams.

What's ironic is that the paths and surfaces are usually too complex to be understood as well, so we "abstract" them to simpler paths and surfaces. That is, we remove information and provide an approximation. The conclusion here is that AllAbstractionsLie.

Anyway, since most systems are dynamic, especially during development, the cost of having all this spaghetti tied to each point is very large. After all, the UseCases and diagram act as opposing forces to change, thus requiring the plucky programmer to expend more energy (and more cost) to change a given point. It's friction.

The obvious solution is to not hand generate the higher order slices, but to have them derived from the volume itself.

-- SunirShah

By the way, while you may think that UseCases are generated by the users of the system before it is completed, I doubt that. I believe engineers almost always write UseCases. Engineers certainly write ScenarioTextualDescriptions because they were designed to model a real-time system in English, something Joe Q. Public really isn't cut out to do. (Why did he hire us, then?)

Engineers being what they are, they immediately start solving the problems in their heads. This gets reflected in the actual UseCases and STDs. BigDesignUpFront, even if it's subconscious. -- ss

Good observation, Sunir! -- Alistair

There's this big assumption that diagrams, use cases and the like must be kept in synch with the code, and if they aren't they become completely useless. XP says to write them if you need them and then throw them away. I prefer to keep them around but not up to date. Sometimes I'll annotate a drawing that I'm particularly fond of and occasionally I'll redraw something that's really changed a lot if I think I'll benefit from the exercise or if I have a thought that I want to be able to remind myself of in the future. Whether you decide to throw them away or stash them away as cherished memories you don't have to be slowed down by them unless you choose to try to keep them up to date.

All those lines and planes are most interesting because of the points where they intersect. It's worth plotting them just to get that information.

When programmers write use cases they do it by asking the other stakeholders how the system should work. They're decomposed into scenarios because that's actually how people think -- in stories. The people best qualified to write this stuff are actual writers. Of course they have to be gifted enough to produce a single document that satisfies two different audiences: Customers so that they can be sure that what's going to be built is actually what they want; and engineers so that they can understand what's being asked for. There are actually people who build their entire careers out of being Analysts. Gathering and presenting this data is basically all they do.

Use cases and other requirements documents are really just documentation of a problem that's already been solved. People who want software want it to fill a role in the solution of some problem that they have. If they know what they want the software to do then they know how they want their original problem to be solved. Understanding that original problem can go a very long way towards the production of usable, flexible software.

-- PhilGoodwin

Just to clarify my own thoughts, I'm not entirely bent against UseCases. I'm bent against any process that attempts to keep six versions of the system in perfect synchronicity. That's at least nine times the work! (*) And if humans aren't perfect, it's asymptotically infinitely more work.

From what I've seen, UseCases are very clever because they do maximize our innate instinct for narrative. (**) They do make for interesting needs-driven design processes too. They give you the components and the messages almost ForFree. Very cool.

But if you drive down from UseCases, you need to keep non-formal traceability in place. Traceability to maintain consistency, non-formal because you don't have a compiler to check consistency for you. If you don't want traceability overhead, I suppose AcceptanceTests do the same thing in this respect as UseCases, but they can only be written by a programmer. You win some, you lose some, eh.

Anyway, I agree with Phil, who is wiser than I for sure. On the other hand, I'm learning differently right now, hence my confusion. No strong argument posited.

(*) There are always at least two versions of the system: the RequirementsAndDesign. So, (6/2) squared = 9.

(**) On our team, as programmers, we had a very hard time writing the narratives because we don't write a program (and consequently think) in sequential order. We tend to grow them almost organically, one concept at a time. Hence, we're taking the micro-iterative approach I mentioned. -- SunirShah

The micro-iterative approach failed. We are now reverse engineering the use cases from the system. It's not something I'm proud of. -- ss

Sunir, as a field methodologist, I want to toss in two things:

(1) Welcome to the real world (the real world of methodology, that is :-)

(2) What's wrong with reverse engineering the use cases from the system? (that may or may not be a rhetorical question, depending on what you want to do with it).

Taking (2) first, if your team understood what they were supposed to build simply by talking to each other, and built what they were supposed to build, then there is nothing wrong at all, at the first level of critique. Your sentence carries an implication that there is a "right" way, which consists of writing documents in a particular order, and which leads to "goodness". Suppose that either there isn't a "right" way, or that the right way doesn't involve writing documents in a particular order. (It's for sure that writing documents doesn't lead to "goodness".) As a field methodologist, I spend some portion of my life purging people from their sense of guilt about not writing documents in a particular order (as here :-).

If, as I suspect, your team didn't communicate well enough to understand what they were supposed to build, then it is the team communications that need to be addressed. The symptom is that they didn't get together to write the use cases - that isn't the cause.

In your situation, students with lots of other courses and vacations and parties on their minds, one could view the use cases as a social mechanism used to bring the people together to discuss (and capture before people forget again). Then your sentence above would mean, "I'm not proud that we weren't able to get the people together, and so here we are, piecing together a written story about whatever we managed to construct."

Taking (1), that's all pretty normal. Usually what gets built isn't quite what was intended. Other times, what got built was OK, and the process was really OK, if ungainly. It's the latter that I search for, and that motivates parts of XP. My main awakening in methodology is that (A) the process, as written, is probably wrong, (B) people won't do what they're told to do, (C) people don't really do on a project what they tell you they do (they embellish). Relate those to your most recent experience?

-- AlistairCockburn

Well, we do have a strong sense of our requirements in the form of story cards. Since we don't have much time, we're not going overboard with anything. The stories for this "iteration" weren't ordered very well but I think that's because what XP considers "iteration" is way too long. I'm not bright enough to hold more than five things in my head. And even though my teammates probably could hold more, I suspect that they couldn't effectively order all 12 cards for this iteration either because obviously we didn't. At least we've nailed down what we're going to do this iteration, even if we couldn't commit personally to the cards (if I need login, and you have login, I'm stuck...).

Hmmm.. I'm not sure why I'm not proud we don't have any use cases. We have requirements. I suppose I said that out of guilt that we were reverse engineering the requirements. But, as you pointed out, we have 'em.

And, no, our communication isn't very good. It's maybe workable but not as good as if we were all dedicated to the task naturally. We also have six people which is two more than the course usually allows and two more than there is work to hand around. Thus, there are overlapping responsibilities and consequent contentions that only good communication can overcome.

-- SunirShah

P.S. Ok, I'm off to the labs. I swear. (ugh)

I've just had a very interesting experience with Use Cases. I was asked to quote on a system and given a draft requirements document. Having Alistair's Use Case blank lying around (Thanks Alistair!) I decided the quickest way to get a handle on it was to fill in Use Cases. In the end, I made out 21 (far too many!) very sparse UC's, but doing so really clarified what they wanted, and especially what the holes in the requirement were. If I get the job (the final spec comes out next week) I'll be consolidating them (probably from scratch) into 10 -12 with far more detail. But yes - they enabled me to get a job which I thought would take 2 days done in one. -- SimonSmith

So I'm immediately interested in what you would have done that would have taken 2 days, and how scribbling use cases helped you do that faster, and how you estimated work effort from them. I'll also lay a side bet that your use cases are at "too-low" a level (and a side bet on the side bet that having them at too low a level for general requirements was useful for estimating). -- Alistair

I'll second both the interest and the bets. -- RaitisGrinbergs

Having now used UseCases for testing, I really find them useless. Only the path along the (small set of) use cases we are testing come close to functioning. As soon as you go off into the weeds, the product fails. Since following use cases leads one into a false sense of "system coverage" because they are used to define the system, people are not testing the product adequately and bugs are slipping by. Thus, use cases are creating negative work. -- SunirShah

Very cute, Sunir... since UCs create negative progress (I think you meant to say), then you are on the hook to name something would have have merely created zero progress. I.e., name an alternative. What might you otherwise have done that could even have been useful? This is the interesting question. -- AlistairCockburn

For what its worth, I don't think anyone in the test methodology community would suggest that use case driven testing is anything more than an adjunct to other more comprehensive test methods. Unfortunately, it is now becoming common practice much to the detriment of the software being tested. -- HowardFear

I'd like to take issue with Sunir's n-squared thing. If you have lots of representations of the same thing, then you have to update all of them when any of them changes; but the total number of changes, not the number of changes to each representation, is constant. So you lose a factor of n, not a factor of n^2.

(Actually, it's quite likely that having more representations does mean that the number of changes goes up: the more paperwork you have - abstract as well as concrete -- the more temptation there is to fiddle with it...) -- GarethMcCaughan

Yes, but on each of the n representations, there are upto n references to the other representations. Perhaps I should've used Big O notation, but the idea is that the representations aren't independent of each other. -- SunirShah

But you are altering the (n-1) to reflect the original change to just one representation. If your representations are so entangled that each fix requires a complete refactor of every other representation, *including* the one that originated the change, then your representations are really messed up. But even so, in my experience having a linear increase in the amount of work required is bad enough as is. [And of course we haven't addressed what happens when the representations themselves include internal references. Ack.] -- RaitisGrinbergs

I found this description which views use cases as drivers of design, rather than a artifacts of the design, as fundamentally the statements of the users, to be implemented by the designers. In reality, can production of the code follow such a scheme?

Use case driven" means writing the user manual first, then writing the code. This practice reinforces the fundamental notion that a system must conform to the needs of the users, instead of your users conforming to the system.

I think this argument may be a little misleading. There is no clear divide between the system conforming to the users and the users conforming to the system; both are necessary. The appropriate balance is dependent upon a number of factors and the weight and precedence of these factors varies over time. The only way to find this balance point is through iteration and successive approximation. The true question is whether it is more efficient to do this iteration through use cases, text, or operational software.

Use Cases aren't about the Developers in an XP project anyway. They are about the Customer Team. The Customer Team uses use cases in two ways:

At least, that's the way I see it. Now, in a situation where we have the One Team containing analysts (customers), testers, and developers, the generation of the use cases requires its own kind of story (many of them, possibly). Unfolding the use cases to generate developer stories is another kind of story. -- DanRawsthorne

Even use-case introduced in object-oriented world, but no body ever say that use case is object oriented. use case only teach us how to describe system behaviour in natural language but consistent and more formal. -- ImanLHakim

To my knowledge Ivar Jacobson says that use cases is object oriented. I think that your opinion about use cases would shift to being positive about them, if you read the fantastic book by Ivar Jacobson and Pan-wei ng, Aspect oriented programming with use cases, 2005. That book has rocked my world.

EditText of this page (last edited November 21, 2014) or FindPage with title or text search