Home > Work > Use Case Style Issues

Use Case Style Issues

Some more notes, following a review of my team’s experience of writing a set of use cases during a recent round of development, focusing in some of the stylistic issues we encountered (as in writing style, rather than layout).

We found that converging on a consistent house style was surprisingly difficult. The following are some of the pitfalls we found we spent time trying to agree, or had to revise. I hope this may help as a pointer to others trying to hit upon a common use case style for the first time:

Active voice. Maintaining the active voice in steps (“the system displays a list of customers”, not the passive “a list of customers is displayed”) turned out to be surprisingly hard. As our use cases covered entirely back end processing and would take the repetitious form “system does x”, we decided a better approach was to write “the system does the following” then a set of numbered steps in command form (“determine this, update that”).

Alternative Flows. Our concern here was the layout: which way structures the flow most clearly? A purist’s approach would be to pull out all the alternative flows into separate sections, to leave the main flow showing just the standard scenario. Our developers much prefer a single nested flow of statements in the order they would write the program. We decided that where it was a simple if-then-else the alternative could go in the main flow, and where either the alternative path contained multiple steps or it omitted several steps in the main flow we should define a formal Alternative Flow.

Trigger, preconditions and initial step. We found a clear and consistent definition of these three took some effort to understand. Preconditions are statements that the use case can assume are true and need not test explicitly again – but we struggled to work backwards to identify them in a consistent way. Related to this, we spent a lot of time trying to agree how to handle the call from the previous use case. It’s not a precondition (although some of the team thought it was as it sets the data up in a particular way) but is it a trigger or the first step of the main flow? This is particularly true if the call could come from multiple places. I’m not sure we quite got it right. In practice triggers and the first step overlap

Business Rules. Our use case documents contained business rules, which purists would say shouldn’t be here. We write these as functional statements that can be tested, defining the detail behind the simple statements outlined in the main flow steps. We defined all data with reference to the Logical Data Model. We allowed pseudocode in rules if that was the best way to describe it. We also decided that there should always be a statement for each step, to make sure it was tested, even if it effectively duplicated the step text without adding much to it. On review some statements were deemed not to be strictly functional, but if they contained useful background information were rewritten as preconditions or assumptions or inserted as notes.

In deciding how to resolve these issues, we kept our audience in mind – in our case the Use Cases are being written primarily for developers and testers. That has influenced how we have chosen to phrase things – e.g. the use of pseudocode in rules, or referring to all data items via the Logica Data Model, neither of which might be appropriate for a non-technical audience. On another project, we might make a very different set of decisions.

Some other views

Categories: Work Tags: ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: