Informal Use Case Template

Free Microsoft Word 2003 template for creating informal use cases. This template is built as a form with guiding text and help text. Read how to use it and download it today.

Informal Use Cases

As part of our series on use cases, we included an article on informal use cases. Informal use cases are designed to provide as much information as possible without the overhead formal use cases. An informal use case template is much simpler than a formal use case template.

An informal use case includes a minimal set of header information for administrative purposes, and immediately gets to the meat of the use case – describing what the user (also known as the actor) does.

Informal Use Case Template

This free template (MS Word 2003 – 34K) can be downloaded from Tyner Blain right now. (zipped version 5K)

Above is a screen shot of the template as you see it when you first open it in MS Word. The template is created as a form that you can easily tab from field to field, without having to worry about messing up the formatting. When you want to create an informal use case, just double click on the template file (*.dot). This will create a new word document, Document1.doc. When you save the file, it will be a word document (and not a template).

If you want to modify the template to add header and footer information, for example, you have to open it differently. Open Microsoft Word, then open the template file. You’ll notice that the title bar will say “Informal Use Case.20070119.dot” instead of “Document1.doc.” That’s how you’ll know that you are editing the template. All future documents will include any changes you make to the template.

The template is locked, which allows you to quickly tab between the fields (the grey areas in the document) and input information without worrying about changing the formatting of the template. If you want to change the formatting for a single document, just unlock the document that is open. There’s an icon that looks like a little lock in the formatting tool bar. Or you can select Tools : Unprotect Document.

Note that if you unlock the document, the drop-down control for selecting the use case status will not be available. Just relock the document to re-enable the status drop-down control.

Using the Informal Use Case Template

1. Download the template file.
2. Double-click on the template file to create a new MS Word document.
3. Enter your data (field details explained below) into the fields.
4. Use the key to quickly navigate to the next field.
5. Save your document. We suggest a naming convention like “UC##.V#.Use Case Title.doc” or “UC##.YYYYMMDD.doc” if you don’t already have a naming convention. Substitute the use case ID and version number (or current date) into the filenames – this makes it easier to organize your files.
6. Repeat steps 2 through 5 for additional use cases.

There are descriptions in some of the fields (wherever there was room) to remind you what goes in each field. You can also hit F1 to see additional help about any field.

Informal Use Case Fields

The Header section of the template organizes the administrative information about the use case.

• Use Case ID – This is the unique identifier that you use to reference the use case from other artifacts that you create as part of developing your software product. In a structured requirements framework, use cases support goals and are supported by functional and non-functional requirements. You will use the use case ID to trace between the use case and the goals it enables. You will also trace between the use case and the functional and non-functional requirements that support it.
• Use Case Version – The version of the use case can be used to keep track of each draft or revision of the document – but it was intended for something more powerful. We discussed the notion of having evolutionary use cases – where each version of a use case represents an improvement over the previous version. Version 1.0 might be released for the primary actor, in a particular release. Version 2.0 could be released later, with support for secondary actors. You can track this as the following diagram shows:
• Status – Everyone uses status differently. A good reason to edit this template would be to change the available status options in the template to match what you normally use. The template has four simple status selections.
  1. Draft represents an incomplete document.
  2. Proposed represents a document that has been completed and is being reviewed.
  3. Approved represents a use case that has been approved by all parties.
  4. Rejected represents a use case that has been rejected.
• Release – Put the name or ID of the release into this field. This represents the release for which the use case is scheduled. We reccommend scheduling releases with complete use cases and not portions of use cases. You can use the versioning approach described above if needed to manage your delivery schedule.
• Author – That would be you. Enter the name of the person responsible for authoring the use case.

The Body section of the informal use case template includes the primary content of the use case.

• Title – The title, or name of the use case. This should be a simple sentence that describes the use case. If someone were to only read the title, she should have a good idea of what the use case represents. All your use cases should use a consistent naming convention, but the one you choose is a matter of style. You may want to use the subject – verb – object approach (“User Reviews Pending Orders”), or a verb – object approach (“Review Pending Orders”).
• Actors – The people who execute the use case are the actors. Not “Tim” and “Joan,” but rather “Office Clerk” and “Department Supervisor.” You may want to define an actor hierarchy for organizing the actors that are relevant to this product. If you do – the names in this section should match the ones in the hierarchy.
  
• Normal Flow – This is where the description of your use case goes. The goal here is to write just enough to clearly define the use case. The individuals on your team will have the biggest impact on what enough is for you. Most use cases involve some branching or decisions. The normal flow should not include these “if…then” constructs. The normal flow should include the most-common or most-valuable path through the use case.
• Alternate Flows – This is where those uncommon and lower-value paths are documented. Imagine a use case for processing invoices. The normal course would describe how pending invoices are handled. An alternative flow might handle how past-due invoices are handled. A second alternate flow could handle customers with credit-balances in their accounts.

Summary

The informal use case is a great tool for representing requirements without a lot of overhead. Using a template can help your team maintain consistency in documentation. If you don’t like our free template, create your own, but make sure you use one.

Some great additional reading is Alistair Cockburn’s Writing Effective Use Cases.
We added the ability to rate our articles, to help us know what people most want to read. Please let us know what you think of this article by rating it from 1 to 5 stars. And rate some of our other articles because this will help people who are new to Tyner Blain. If you’re reading this in the feed or in email, come on over to the website and rate a couple articles.

Thanks in advance!