Blog

A use case can be formally defined as a list of steps defining interactions between a role and a system, to achieve a goal. However, if you haven’t written one yourself, you have at least heard the term somewhere. But exactly how useful are they when developing a product or defining a system process?  Without having the proper understanding of use cases and the purpose of writing one, writing an effective case to elicit functional requirements can be pretty…useless.

Use cases can mainly be viewed as writing a story, so there is no real standardized format for writing them, making it difficult to determine which kind of case best suits the goal you are trying to describe.  According to Alistair Cockburn however, use cases can be written as a casual case or a fully dressed case.

Casual cases consist of a few paragraphs describing the goals using a Title (the goal), Primary Actor (stakeholder), Scope, Level (goal level), and the story (the body of the use case describing the goal).  More story-like than a fully dressed use case, casual cases should capture the back and forth flow of information and activity between the user and the system, ending with the achievement of the stated goal.

required-reading.gif

Fully dressed use cases are longer cases, showing more detail and are more structured than casual cases.  This type of use case includes the following details:

• Title
• Primary Actor
• Goal in Context
• Scope
• Level
• Stakeholders and Interests
• Precondition
• Minimal Guarantees
• Success Guarantees
• Trigger
• Main Success Scenario
• Extensions
• Technology & Data Variations List
• Related Information

Regardless of the type of case you are writing, it is important to define the interactions between external actors and the system to accomplish a goal.  Actors can be a person, a company, an organization, or a system and are oft working on behalf of someone else.

Once you have an understanding of the different types of use cases, you can ensure each case's usefulness by learning the limitations.   Use cases are not intended to capture non-functional requirements such as performance, timing, or mathematical requirements.  They are complex to write and the clarity oftentimes, depends on the skill of the writer since there are no standard definitions on how to write cases.  Unfortunately, regardless of its usefulness, organizations will still avoid writing them, suggesting ways to develop products without them.

required-reading4-296x300_0.png

Reference: “The Software Requirements Memory Jogger”, Ellen Gottesdiener.  “Writing Effective Use Cases”, Alistair Cockburn.