This is the classic use case as described by someone who talks about Software Engineering. All of the training classes (other than Agile classes) that I’ve been to teach formal use case development as a component in a system of requirements management. Here’s an introductory article on how to read a formal use case.
- Detailed information about use cases, making it easy to estimate the cost of implementation.
- Thorough coverage of the use cases is influenced by the use of a template.
- Easy for readers to absorb. The structure of the document makes scanning easy, and also helps targeted lookups when a reader needs a specific piece of information.
- Consistency with other use cases is much easier to assure when using a template.
- Expensive to maintain. Mapping a “use case” to the template requires some effort. Since formal use cases contain more (explicit) information than other use cases, there is more content to document, validate and modify. More content equals more cost (of maintenance).
The formal, or classic use case, is a tool used to gather structured information about how users will use the software. Formal use cases are gathered in a template, which structures the information. While this structure can vary from company to company, or even project to project, there are a few common and critical sections to the structure. The two main benefits of having the structure are that it helps with thoroughness (much harder to leave a field blank than it is to forget about it), and it helps with scanning by readers of the document.
Some common elements in a use case template:
- Actor – The person or people who will perform the steps of this use case.
- Preconditions – A description of the relevant and non-trivial state(s) of the system prior to the use case starting.
- Normal course – A description of the use case itself. This description can either be in narrative form, or a numbered list (1..N) of specific user steps. When a use case (such as “User approves/rejects customer requests”) has more than one way that a user can accomplish the needed steps, the most common way is shown here – only a single path is shown.
- Alternate courses – Descriptions of alternatives to, or deviations from the normal course. For example, the most common course might be to view the oldest unaddressed customer requests. An alternate course may be to view the unaddressed requests from the largest customers.
- Exception courses – Descriptions of what the user will experience when something goes wrong.
- Post-conditions – Description of the affected portions of the state of the system after the use case has completed.
- Frequency of use – An estimate of how often a particular use case will be exercised.
- Assumptions – Any assumptions that are implicit in the definition of the use case.
The formal use case can be considered as a contract, in that if the preconditions are met prior to initiating the use case, the post-conditions will be met after its completion. This contract provides a great framework for defining the functional requirements required to support the use case. Rodolfo Ruiz posts a good approach and insights on pre and post-conditions in Some thoughts on use cases.
Quick links to posts in this series
- Use Case Series: Introduction
- Use Case Series: Formal Use Case
- Use Case Series: Informal Use Case
- Use Case Series: UML 2.0 Use Case Diagrams
Here are some examples of use case templates in use in the real world
From process impact .
A detailed document from the HL7 Working group on how to approach the process of writing formal use cases.
From Harry Nieboer.
Related blog post