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.
Pros:
- 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.
Cons:
- 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
Some references
Here are some examples of use case templates in use in the real world
From process impact .
From Alistair Cockburn.
Very detailed explanation from Alistair Cockburn on how to develop a formal use case.
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
Why use use cases? from the Carnegie Quality blog
Brad Kuhn said,
December 20, 2005 at 2:39 pm · Edit
Tyner-
Nice series so far on Use Cases – a few comments:
– On the “cons†side firms should consider training costs as well. Not everyone is going to be comfortable writing and using Use Cases day one. Not that training is a big cost – just need to budget time to take care of it. Of course, Use Cases are no different than any other artifact of software development – and believe me, it’s a lot easier to teach someone to read a Use Case and get feedback from them than to read a functional spec.
– Maintenance is certainly a factor when collecting a lot of detail. And once you go into Design, you know things are going to change. One option is to use Use Cases to bootstrap the project – get everyone on the same page and get rolling into requirements, then drop them. Of course, you don’t get the benefit of using Use Cases in the future that way (e.g. Test Scripts, starting point for future projects/enhancements).
– I like the IMS link, never came across that one before. Interesting idea, though there’s not a lot there yet.
Scott Sehlhorst said,
December 21, 2005 at 12:28 am · Edit
I went back and forth on including training as a con for formal use cases. I’ve been trying not to list anything that’s true of all the use case models, and I started with the presumption that training was required to use any of them, so I didn’t break that out as a differentiator. I think the training needed to do use cases well is roughly the same cost, regardless of which format people use. Although it’s much easier to imagine a pointy-haired manager saying “What training cost? Just write a paragraph. You can write a paragraph, can’t you?†If you show said manager a template with 20 fields, “You’re gonna need to be trained to fill out that form†is more likely.
Thanks, Brad, and please let us know your thoughts on the other posts in the series as I get them out.
Scott
To my opinion, the argument of the Cons is not sound, as it suggests that documenting nothing is best, since it costs less, and we all know where that leads to …
Whether “more information†is better or worse depends on the information added.
Since use cases are meant to be used as a basis for design, test and user documentation, I always ask myself the questions:
– Does the designer need this information to make the design for the desired system?
– Does the tester need this information to verify that the desired system was built?
– Does the person making the user documentation need this information to document the desired system?
If all three need the information, I suggest you include the information in the Use Case (if this information applies to this Use Case only) or in Supplementary Requirements document. The latter can be indirect, as in “The System must adhere to the companies User Interface Guidelines (with reference to that document)â€.
If not all three parties need the information, include the information in other artifacts like Designs or Guidelines. (As Scott Ambler says: By referring to other artifacts, instead of embedding the information in your use cases, you reduce the chance that you’re writing Use Cases of Mass Destruction.)
A sample Use-Case specification is available at http://blogs.infosupport.com/harryn/archive/2006/01/04/3341.aspx.
It relates to the formal Use-Case specification written by Scott W. Ambler in Introduction to System Use Cases. Please feel free to compare the styles used by Scott and by me.
The template we use is originally written in Dutch, but I translated it for this discussion and upcoming discussions on my own blog.
Harry, thanks for the post.
On listing cost as a negative for formal use cases, what I should have said was “relative cost” as compared to informal or story/scenario style use cases. Because we have to go through the process of sorting out information into different buckets (alternates, exceptions, main course), that takes a little time – the documentation of alternate and exception courses also takes extra time, because we have to apply the effort to make sure that we aren’t specifying design. Thanks for your link – I’ve added the template you developed to the post as well.