Just Enough To Be Dangerous
It’s Monday morning and you’ve had a great weekend with the family. On Friday afternoon your boss told you that you would lead the use case effort for your new client, the national travel agency, “Wings over the World”. Now you’re having your first phone conversation with Karen, Wing’s Chief Information Officer, since doing your original presentation.
You: “I just got the news on Friday that we’re going ahead with this. Can you tell me what you have done since my presentation three weeks ago?”
Karen: “Well, I was really impressed with your explanation of how use cases will help us out on this project. We’ve always had a lot of problems gathering our functional requirements and this sounds like just the ticket for us. I wanted to get my people started quickly, so I brought in an instructor for a couple of days to teach a use case course. All I can say is, people are really excited by this. Anyway, the instructor gave them a great template that covers everything you can think of in a use case, from soup to nuts. I’ve got everyone on the team now working on the use cases and they’re just turning these things out a mile a minute.”
Once again you hear that familiar “sproing” sound of red flags popping up. Templates are wonderful you think, but can they ever be misused and abused. After a short pause, Karen confirms they are having problems.
Karen: “I have a big favor to ask you. I know you’re not scheduled to be here until next week but is it possible that you could come sooner?”
More “sproings”.
Karen: The way you explained the use cases, and the way our course instructor explained them, we thought they would be easy to write. But, obviously we’re doing something wrong because we’re running into some problems. We’re really anxious to get you in here to help us out.”
You: “What kind of problems?”
Karen: “Well you know it’s no secret that we’ve had methodology problems on past projects.
There are a lot of cowboys here. Anyway, Ahmed, our architect on this project is really insistent that we do things right this time, and that means we go by the book and follow the use case template that our instructor gave us. Well, people are having all kinds of problems filling in the pre-conditions, post conditions, triggers, goal statements and all that. While most of us are really happy to be trying out these use cases, some of the old hands are getting a bit frustrated. I was
You don’t know whether to laugh or cry. But right now you know that last thing you want to do is sound condescending.
You: “It’s a bit early in the process to be writing detailed use cases; we should just try to get the big picture first, then refine the use cases.”
Karen: “Well, Ahmed said we needed detailed specs, otherwise there was just too much that would be left to the programmers. But I think I have to agree with you on this one, because Ralph and Sitra got into a big fight last week.”
You: “A fight? Over what? I thought they worked well together.”
Karen: “Not really a fight, more of a programmer’s territorial dispute. Ralph is our billing expert and Sitra is our RAPIER expert. Ralph wrote a billing use case that overlaps and in some situations contradicts Sitra’s use case for the RAPIER interface. Both of them have spent about two solid weeks writing their use cases and neither wants to throw their work away.”
You: “What about the agent reps, what do they think about all this so far?”
Karen: “I’m a little bit worried about their buy in to this project because all they’ve done is complain. They’ve always complained that our specs are too complex or that they can’t find what they’re looking for. Well, all right, we’re trying to go the distance for them by writing use cases and they’re still complaining. Not only that, but some of travel agent’s reps are even refusing to show up for our JAD sessions and reviews. They keep saying there are too many reviews and that they’ve got better things to do than correct our spelling.”
You: “If I can swing it I’ll try to hop tonight’s Redeye and be there tomorrow and we can sort this out.”
Karen: “I really appreciate your dedication. I knew there was a reason we selected you. Oh, and one last thing…”
You: “What is it?”
Karen: “Well, when do we know we’re done? Ahmed is really insisting that we go by the book, and Ralph is really getting impatient and saying we should just get on with the job.”
After you hang up, you immediately call travel and have them book your tickets for tonight’s Redeye. You decide you better get there now and get this project back on track before these guys dig themselves any deeper into the hole they have started.
Wouldn’t it be wonderful if there was one well-defined process for writing use cases? Then we could all learn the one universal methodology and know that everyone else clearly understands our ideas. Unfortunately, writing good use cases is highly personalized; everyone has their own
needs. After all, it is these differences that give a business their competitive advantage. What is good for one group is not necessarily good for another.
While there is no one-size-fits-all process for creating use cases, we have captured common elements of good processes in the process patterns. It is important to note that these patterns do not constitute a process, i.e. they don’t follow one after the other. Rather, they make statements that are true about the process. For example, TwoTierReview(76) describes inner reviews followed by an outer review. This pattern will be found in organizations using slightly different processes for writing their use cases.
An effective process creates use cases in a BreadthBeforeDepth(63) manner, identifying potential use cases before describing them, adding details in a controlled manner and achieving a SpiralDevelopment(66) of the use case set. One of the biggest mistakes that people make while developing use cases is writing them sequentially. They start developing one use case, taking whatever time they need to write it, and don’t start on the next one until the first one is finished. This approach has two drawbacks: 1) it is easy to get bogged down on difficult use cases at the expense of the remaining ones; and 2) facts uncovered during the development of later use cases often necessitate a rewrite of the earlier ones, wasting the original effort.
Different groups within a development organization should have the freedom to choose the format and level of detail for their use cases that best meets their needs, instead of being required to use some “official” style. An effective process allows the writers to choose from MultipleForms(83), and determine the appropriate level of detail. The group should use the same format for all the use cases in the same project to avoid confusion, but it is their decision to make, based on the project’s complexity and the audience’s need.
One of the most difficult questions involving use case development is when to stop. The effective team knows when it is QuittingTime(71). Rather than getting bogged down in long arguments about cosmetic issues, they allow a certain amount of WritersLicense(80), recognizing that trying to enforce identical writing habits on everyone doesn’t add economic value to the endeavor.
Reviews are a better way of identifying errors and inadequacies, however, a traditional review process can often be ineffective for use cases because they can require a large, diverse group of reviewers with competing needs. To get around this problem, TwoTierReview(76) describes how to stage reviews, in which those closest to the use cases review their correctness and completeness before turning them over to the larger group to review from a system standpoint.
1.1 BreadthBeforeDepth(63)
Blasting crew going into ore vein with horizontal drill. Mahoning pit, Hibbing, Minnesota.