Use case
In software engineering, a use case (pronounced yoos-case) is a technique for capturing the potential requirements of a new system or software change. Each Use Case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use Cases typically avoid technical jargon, preferring instead the language of the end user, or domain expert. Use Cases are often co-authored by software developers and end users.
Scope and goals of a Use Case
Each use case focuses on describing how to achieve a single business goal or task. From a traditional software engineering perspective a use case describes just one feature of the system. For most software projects this means that multiple, perhaps dozens, of use cases are needed to fully specify the new system. The degree of formality of a particular software project may influence the level of detail required in each use case. It is generally accepted that each use case be short enough to implement by one software developer in one release.
A use case should:
- Describe a business task to serve a business goal
- Have no implementation specific language
- Be at the appropriate level of detail
Use Cases diagrams
Many people are introduced to Use Cases via UML, which defines a graphical notation for representing Use Cases. UML does not define standards for the written format to describe Use Cases, and thus many people have the misapprehension that the graphical notation defines the nature of a use case; however, the graphical notation can only give the simplest overview of a Use Case or set of Use Cases.
Use Case templates
There are various formats, or templates for use case documents. There is no agreed template for documenting use cases. There are a number of competing schemes and individuals are encouraged to use templates that work for them or the project they are on. Standardisation for each project is more important than the detail of a specific template. However, there is general agreement about the core sections.
Typical sections include:
- Use Case Name
- Iteration
- Summary
- Preconditions
- Basic course of events
- Alternative paths
- Triggers
- Postconditions
- Related business rules
- Notes
- Author
- Date
Use Case Name
The use case name provides a unique identifier for the Use Case. It should be written in the verb/noun format.
Iteration
Often an interation section is needed to inform the reader the stage a use case has reached. The initial use case developed for business analysis and scoping may well be very different to evolved version of that use case when the software is being developed. Older versions of the use case may still be current documents, because they are may valuable to different user groups.
Summary
The summary section is used to capture the essence of the scenario before the main body is complete. It provides a quick overview which is intended to save the reader from having to read the full contents of a use case to understand what it is about.
Preconditions
A preconditions section is used to convey any conditions that must be true when a user initiates a use case. They are not however the triggers that initiate a use case.
Basic course of events
At a minimum, each use case should convey a primary scenario, or the typical course of events. The main basic course of events is often conveyed as a set of steps, for example:
- The system prompts the user to logon.
- The user enters his name and password.
- The system verifies the logon information.
...and so on.
Alternate paths
Use cases may contain secondary paths, or alternate scenarios which are variations on the main theme. Exceptions, or what happens when things go wrong, may also be described, either within the alternative paths section or in a section on their own.
Triggers
Triggers describe the starting condition(s) which cause a use case to be initiated.
Postconditions
The post-conditions section summarizes the state of affairs after the scenario is complete.
Related business rules
Business rules are written or unwritten rules that determine how an organisation conducts its business with regard to a use case. Business rules are a special kind of assumption.
Notes
There is often a notes section to capture important information that does not seem to fit any section within the use case template.
Author
The author section is traditionally listed at the bottom, because it is not considered to be essential information.
Date
This section should list when this version of the use case was created. It should also list and date any versions of the use case from an earlier stage in the development which are still current documents.
Other Parts of a Use Case
Different templates often have additional sections, e.g. assumptions, exceptions, recommendations, technical requirements. There may also have industry specific sections.
Benefits of Use Cases
Use cases are a newer, more agile format for capturing software requirements. They are often contrasted to large, monolithic documents that attempt but fail to completely convey all possible requirements before construction of a new system begins.
Use cases have a number of advantages:
- Use cases have proved to easily understandable by business users, and so have proved an excellent bridge between software developers and end users.
- Use cases are useful for scoping. Use cases make it is easy to take a staged delivery approach to projects. They can be relatively easily added and removed from a software project as priorities change.
- Use cases are traceable.
- Use cases can also serve as the basis for the estimating, scheduling, and validating effort.
- Use cases discourage premature design
- Use cases don't use a special language.
- Use cases allow us to tell stories. It is very easy to describe a use case in a concrete way by turning it into a story or scenario.
- Use cases are reusable within a project. The use case can evolve at each iteration from a method of capturing requirements, to development guidelines to programmers, to a test case and finally into user documentation.
Problems with Use Cases
Use cases are not without their difficulties:
- Use cases may be excellent for capturing the functional requirements of a system, but they are not so suited to easily capturing the non-functional requirements.
- Use cases templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s)
- Use cases are not as easy to understand as proponents suggest. There is a learning curve involved in learning to interpret them correctly for end users and programmers alike.