Use Case Template
Filed Under UML, Template, Document, Process, Development, Software | Posted on October 28, 2007
There is no standard template for documenting detailed 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. Of course, there are many Use Case Templates that are available on the internet, so here’s a listing:
Formal Use Case Template, Simple Use Case Template, Link3, Basic Use Case Template, Informal Use Case Template
Some common and core sections of a Use Case template are:
* Use case name: A use case name provides a unique identifier for the use case. Goal-driven use case analysis will name use cases according to the actor’s goals, thus ensuring use cases are strongly user centric.
* Version: Often a version section is needed to inform the reader of the stage a use case has reached.
* Summary: A summary section is used to capture the essence of a use case 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 the use case is about.
* Actors: An actor is someone or something outside the system that either acts on the system – a primary actor – or is acted on by the system – a secondary actor. Actors represent the different roles that something outside has in its relationship with the system whose functional requirements are being specified.
* Preconditions: A preconditions section defines all the conditions that must be true (i.e., describes the state of the system) for the trigger (see below) to meaningfully cause the initiation of the use case. That is, if the system is not in the state described in the preconditions, the behavior of the use case is indeterminate.
* Triggers: A triggers section describes the event that causes the use case to be initiated. This event can be external, temporal or internal. If the trigger is not a simple true “event” (e.g., the customer presses a button), but instead “when a set of conditions are met”, there will need to be a triggering process that continually (or periodically) runs to test whether the “trigger conditions” are met: the “triggering event” is a signal from the trigger process that the conditions are now met.
* Basic course of events: At a minimum, each use case should convey a primary scenario, or typical course of events, also called “basic flow” or “happy flow”. The main basic course of events is often conveyed as a set of usually numbered steps.
* Alternative paths: Use cases may contain secondary paths or alternative 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 of their own. Alternative paths make use of the numbering of the basic course of events to show at which point they differ from the basic scenario, and, if appropriate, where they rejoin.
* Postconditions: The post-conditions section describes what the change in state of the system will be after the use case completes. Post-conditions are guaranteed to be true when the use case ends.
* Business rules: Business rules are written (or unwritten) rules or policies that determine how an organization conducts its business with regard to a use case. Business rules are a special kind of requirement. Business rules may be specific to a use case or apply across all the use cases, or across the entire business.
* Notes: Experience has shown that however well-designed a use case template is, the analyst will have some important information that does not fit under a specific heading. Therefore all good templates include a section (eg “Notes to Developers”) that allows less-structured information to be recorded.
* Author and date: This section should list when a version of the use case was created and who documented it. It should also list and date any versions of the use case from an earlier stage in the development which are still current documents.
Leave a Reply
