What Skills Are Needed to Produce Effective Use Cases?

 First and foremost, the person writing the use case must be a competent, if not excellent, writer. In our experience most organizations select a use case writer based on job title or availability at the moment. These are precisely the wrong criteria.

A job title does not correspond to a specific set of skills. Availability just means that a person needs to be given something to keep them busy. Assigning just anyone to write use cases to keep them busy and gainfully occupied will definitely keep them, and lots of others, busy ― invariably doing lots of rework.

A good writer is sensitive to the purpose of the document she is writing. A good writer always defines the target audience he is writing for, and tailors his presentation to that audience. A good writer limits herself to the accepted and proper structure, grammar, genre form, and perspective (i.e., point of view) for the type of document she is writing. Let’s cover these quickly.

The purpose of a use case is to describe the interactions between a user (the primary actor) and a named service (the use case name) provided by a software system.

A use case is written from the user’s point of view. A use case should describe the system behavior the user sees, and only that behavior that leads to achieving the user’s goal for using the software system at all. The point of view should never, ever be from the inside of the software system ― that point of view goes into the design specifications, not the use cases.

The form of the overall layout of a use case document is not rigid. You have quite a bit of flexibility with respect to the layout of the sentences, document headers, numbering schemes, and how internal references are implemented. But the structure of the sentences in the body of the use case always should be written in present tense, active voice, and the “doer” of the action in that sentence should be clearly stated.

Many people write use cases in future tense. This is especially common if the use case is for a system to be developed in the future. But present tense is preferable because it puts the reader in the moment of the action, as if the use case is happening right now, and the reader is an observer.

Present tense: The actor indicates the vehicle he wishes to reserve.

Future tense: The actor will indicate the vehicle he wishes to reserve.

Even in this simple example you should appreciate that present tense is more affirmative and confident, while future tense seems more tentative and provisional.

Voice is a function of sentence structure and grammar.

Active voice:  John kicks the ball.

Passive voice: The ball is kicked by John.

In active voice the subject (John) precedes the verb (kicks) and the object of the verb (the ball) receives the action of the kicking.

In passive voice the object receiving the action is placed at the beginning of the sentence, and the subject and doer of the kicking (John) is placed after the verb, which is always in a verb-participle form, and the subject is invariably in a prepositional phrase beginning with the preposition “by”.  Sometimes the subject is left out completely in passive voice, as in

Passive voice (no subject): The ball is kicked.

Many people in the business world strangely believe that passive voice is the way “good” business documents should be written. Many years ago I asked technical writing expert Ted Brusaw[1] about this, and his response was immediate and unequivocal: “Passive voice writing is just bad writing.” Active voice is simply clearer, easier to understand, and the reader does not have to do the mental rearranging of the sentence that passive voice requires.

A good use case writer not only writes well, but limits himself in what he expresses in the use case. A well-written essential use case (a Cockburn sea-level use case) does not discuss

• User interface (UI) controls or widgets
• UI navigation such as screen-to-screen flows
• Data formats or field rules
• Database schema structure
• Internal algorithms
• Software design elements

Then why do so many use cases contain these elements? My experience leads me to conclude that many use cases include these technological elements because the use case writer

• Does not understand who the primary audience is for a use case (too many think the primary audience is themselves, or the entire development organization)
• Does not understand the purpose of a use case, which is to focus on what a software system does to satisfy a user’s needs ― not to be a catch-all document for any and every piece of technical information on a project.

All of the technical elements above are needed, but in the various design specifications (UI design specs, data design specs, etc.) and not in the use case.

The use case is not a replacement for any of your other technical artifacts. The use case adds a new perspective to your system specification, a user-centered (i.e., behavioral) perspective.

Some design activities, e.g., algorithmic design or design of very low-level tasks such as data formatting and field validation, or functions such as getDate&Time( ), will be marginally dependent on the behavior expressed in a use case. But, in general, the use case is an input to all of the later design, programming and test activities in a project.

But, there is a warning that I must end with. You may be an excellent writer. You may be a master of tense and voice. You may be scrupulous in not allowing technology to pollute your descriptions. But even if all this is true, if you do not write your use case to represent how the user’s goals are achieved, you will not be able to obtain your user’s consensus that “yes, this is the behavior I want to see when I request this service”.

Always focus on how your system satisfies the needs of your users. If you do that, they will be more willing to be active participants on your project, and you will have many fewer episodes where your users or customers tell you, “but that is not what I need”.