In Chapter 1 of Alistair Cockburn’s “Writing Effective Use Cases,” which I have to believe is the book most often recommended when someone is seeking to learn about use cases, we are first presented with a few questions, the second of which really captures the tone of the tome, and frames what I’d like to discuss today:
“Why do different project teams need different writing styles?”
First and foremost, when I read questions like this, I hear all the upper-management types I’ve dealt with in the past whine the same question: “Ok. First you convinced us that we need to document requirements, and now you’re telling us that there’s going to be some work (a.k.a., money) to determine the style that’s right for our team?” This is, of course, a cup-half-empty perspective on the idea. After all, going through a process that would result in your organization achieving greater communication and efficiency isn’t a bad thing. Documentation alone is a hard sell, especially when budgets are tight (or “in this economy,” which I believe has recently replaced “in bed” as the most popular fortune cookie ender). And you can’t use hollow, stock phrases like “all successful projects start with g…
In Chapter 1 of Alistair Cockburn’s “Writing Effective Use Cases,” which I have to believe is the book most often recommended when someone is seeking to learn about use cases, we are first presented with a few questions, the second of which really captures the tone of the tome, and frames what I’d like to discuss today:
“Why do different project teams need different writing styles?”
First and foremost, when I read questions like this, I hear all the upper-management types I’ve dealt with in the past whine the same question: “Ok. First you convinced us that we need to document requirements, and now you’re telling us that there’s going to be some work (a.k.a., money) to determine the style that’s right for our team?” This is, of course, a cup-half-empty perspective on the idea. After all, going through a process that would result in your organization achieving greater communication and efficiency isn’t a bad thing. Documentation alone is a hard sell, especially when budgets are tight (or “in this economy,” which I believe has recently replaced “in bed” as the most popular fortune cookie ender). And you can’t use hollow, stock phrases like “all successful projects start with good requirements.” All the people holding the purse strings hear when you give them that stuff is akin to the teacher from Charlie Brown. So it’s important, as analysts, that we have a pointed reply, something beyond “We’re just going to use the force.”
Step 1 – Identify the Levels.
Thank goodness, Cockburn points out the three levels of detail in writing use cases, which is good, because management likes short lists. If you tried to say “there are ten levels of detail we can use to write use cases,” this would cause wincing and grimacing.
I’m not saying that it’s possible to explain the effectiveness of use cases to that guy. However, what comprises the three levels is as equally important as the fact that there are three. The “brief” use case is the short, one- or two-sentence statement that can fit in a table or spreadsheet. The “casual” use case can be a few summary paragraphs, and the “fully dressed” use case is the most thorough approach.
Step 2 – Identify which to use.
So now that we have presented our short list of methods from a reputable source, we will no doubt need to respond the next obvious question, “Which style do we use?” It doesn’t hurt anyone to take all the Use Cases identified and compose the “brief” style. Obviously this gives you a nice, informative list of work items to which you can append priority, frequency of use, or other tidbits. Whether the brief use case is a candidate for a more verbose explanation via the “casual” style can come down to a couple questions:
1. Have we done this before?
2. Is this a core piece of the project? Either from
a. a development/complexity perspective or
b. the client/customer perspective
If functionality has been developed on similar projects, obviously a very minimal amount of discussion is required to reproduce the same in the new project, so going beyond the basic is probably not warranted. What immediately trumps this for me is if either the development team or certainly the customer has any concern or gives the use case any weight. The “casual” style is both perfect in name and intent. The word “casual” plays down any notion that you’re going to go into some deep analysis that requires time and money, and yet you give the use case the treatment it deserves to create the communication baseline.
Last, but certainly not least, the “fully-dressed” use case. I like to think of these as “black tie” use cases.
Here, we’re really thorough and detailed and maybe even looking for a degree of polish, as we would if dressing to go to the ballet or a dinner party. This method is called for if both the client and development team consider the functionality to be core to the product. Even if the functionality has been developed before on a previous project, if it is core to the new product, a full treatment is required because the core usefulness of the feature is directly tied to the client brand. If I can’t take money out of the ATM machine, the bank name suffers. In addition, fully dressing the core functions allows the uniqueness of the particular client/customer to come to the surface. It works like salt and pepper work to enhance natural flavors. Just like with ATMs, each bank has a different flavor on the same function based, at least in part, on their branding which leaves you with the ability to favor one over the other. So, functionality that represents a point of market competition, and thus a major business objective, must be fully dressed. I also use a metric to govern whether the use case needs the full treatment, such as if three or more questions arise from any stakeholder.
So that’s a two-step procedure for selling the idea of using use case analysis for projects to those in power. Two steps! Golly jeepers that’s easy! Here’s the kicker: the discovery process happens whether realized or not. Project teams, in order to achieve their highest degree of efficiency and productivity, require a discovery process to find the methods of requirements documentation that work best. This can either be recognized or not. It’s a matter of unconscious incompetency or conscious incompetency, not knowing what you don’t know, and knowing what you don’t know. Those companies that proactively engage in the process become successful, productive, and fun places to work. Those same companies have either established analysts or analyst consultants as key contributors. These people can also effectively throttle the amount of requirements practices exposed to a particular team. The result is you either have companies who understand the complexities before the project at an appropriate level, or are reflecting on them in the same – albeit more excruciating – detail as they close their doors forever.
