Use cases – how to ensure the perfect use case (almost)

use case checklist It sometimes seems that use case modeling is more art than science (like much of the tricky bits of business analysis, see Use cases – an Introduction for the basics). There are many different viewpoints on what makes a good use case. Some of those viewpoints are undoubtedly wrong, some of them are just different! There is room for variations in personal preferences in style and application of use case modelling without them being wrong. Within your organisation, you will have developed or will need to develop a house style which is likely to be supported by a template (here’s one I created earlier!). You will also need to ensure a consistent level of quality. I have been working on a checklist recently to support peer reviews and have adapted it so you can use it as a starting point. I have broken it into three sections:


This covers a variety of things such as:

  • completion of all aspects of use case
  • record of all open issues
  • numbering of use case


This covers the actual content and includes:

  • covers a single goal (all use cases must deliver a result of observable value)
  • considers all possible alternate flows
  • language and terminology is consistent with other use cases

Content (for more detailed use case)

I have found that use cases are used at the initial stages of a project and evolve or are created anew as the project progresses into design. The use cases that are used to support design will be more detailed and will have ancillary supporting documentation (such as data dictionaries, screen specifications or mockups). This section provides guidance for use cases that are used as part of design as opposed to requirements use cases.

Project specific

This section is deliberately left blank! Each project will have concerns and areas of interest that are specific to that project only. However, these concerns are likely to be very important so it is critical that you spend time considering what should appear on your check list that is particular to your project. They are likely to be items that need to be considered throughout the problem domain. For example, in a regulatory application, you may want to ensure that the regulations have been considered for every area of functionality in the system. When you have developed your own version of this checklist, you should use it as part of a peer review process. The peer review is a formal process where agreed documents are submitted for review by an agreed set of stakeholders or interested parties. Typically, there is a preparation before the review when stakeholders prepare their feedback for discussion during the review proper. This check list should be used to assist the stakeholders in preparation for the review. use case checklist Let me know your thoughts on this checklist. If you have developed your own or develop your own in the future, please let me know so I can share them with the readers of this blog.

About Alex Papworth

8 Responses to “Use cases – how to ensure the perfect use case (almost)”

Read below or add a comment...

  1. Rose Broadbear says:

    Again the spell check on your replies.

  2. Firstly, thanks for the checklist and the template.

    On the checklist:
    Why do all our documents start with a document history? I open a use case document because I want to understand the system functionality, not who has been working on this document, and when. (I’ve got a little rant on this subject here section 2.2.2.)
    Language and terminology – should also be defined in the project glossary.
    Screens would be in a use case storyboard, I do not want to have to change my use case if the screen changes.
    The data model would come after the use case as a result of use case realization.
    I would also add, impacting supplementary requirements and performance timings. (More on this in section 2.1.3 of the above link.)

    On the template:
    Document History – enough said.
    Alternate paths – I’m not sure if it is important, but I tend to distinguish between alternate flows and extension flows.
    Postconditions – I call out the expected postcondition and list others as alternate postconditions.
    Somewhere the actors need to be identified, either in a use case diagram or in the text.
    Where are the supplementary requirements specified – is there an accompanying supplementary specification?

    I describe a textual and graphical style for specifying use cases at
    It is a large document, so I will briefly summarize that I am used to writing steps numbered sequentially, each one of the form and .
    I like to keep the basic workflow ‘happy’, so I do not consider what can go wrong in this sequence of steps.
    Instead, once I have a happy path documented I will consider all of the alternative paths and call them out from the step from which they occur. For example, Alternate Path Cancel Operation – ‘At step 5, the user cancels the operation and the use case returns to step 4’.

    Hope this is useful,


    • Alex P says:

      Hi Leslie

      my thoughts:

      Document history – can be critical. If the organisation is more relaxed and not focussed on change control, you can do without it. I haven’t found many organisations that are like this. Maybe it would be better at the end to minimise distraction.

      Agreed that screens should NOT be referenced in a use case. However, it is useful to have a separate document (e.g. spreadsheet) that ties the screens back to the use case (when you need to get to that level of detail).

      Data model – in my experience, you produce a business data model when it is useful and/or necessary. This tends to be after a first draft of use cases. After this you can jump between the two as your understanding in a use case increases your understanding of the business object model. Not sure if you’re referring to a more system/design oriented data model?

      I agree with most of your other points on the checklist although some are more personal preference rather than right or wrong. I would tend to show the actors in a use case diagram only to avoid duplication and the inevitable failure to keep the two documents aligned.

      Regarding Supplementary specifications, I agree you can include them in the use case or in separate document. Either way, there should be something in the use case check list referring to the type of material that this contains.
      For example, system response times, availability. Abnything that is particular to the use case should be contained here. Anything that applies to all use cases should appear in a separate document.

      I like your article although it would be helpful if it was broken down a little.


  3. Alex P says:


    thanks for yuor comment and sorry to be so slow in replying.
    Your suggestion sounds very much like the way I approach use cases.

    In answer to styles, first off I would say there are many standards and I’m probably only familiar with a subset.

    Personally, I prefer a simple, structured textual approach which reads as a simple series of steps. I’ve seen a format involving splitting the presentation in two columns with ‘The actor selects…’ on the left hand side and ‘The system checks …’ on the righthand side. This seemed to be a good example (imho) of trying to be more sophisticated but losing simplicity with no particular value added.

    I like this and think it works. I think other approaches can work as long as there is general consensus from the ultimate customers (i.e. the business stakeholders, testers, developers etc).
    Your and my opinion doesn’t matter too much – the real test is whether the customers like the approach


  4. aco says:


    I would be interested to view your template “by a template (here’s one I created earlier!). ” but the link seems to jump to the checklist instead?


    • Alex P says:

      Alison, Ted

      sorry for the cockup. It should work fine now.

      Please let me know your thoughts on either the checklist or the template


  5. Ted Husted says:

    The link to “(here’s one I created earlier!)” points to the checklist, rather than the use case template.


  6. DougGtheBA says:

    Hey Alex:

    I’ve used something very similar to this….so similar, in fact, that it’s not worth giving you a sample. One difference of note is that I like to indicate the trigger locations for Alt/Exc paths. For instance:

    The Basic Step might show:
    The user does this.

    …and below where the Alt Path is written up, it would show:

    A1: The user does something else (title of the Alt Path)

    I’ve found that this little extra reference siginifcantly helps users in the reading/review process.

    I’d also like to hear from you on what the different acceptable formats for writing use cases are. We have both tabular and paragraph formats, but I’d like to know what the standards and other methods are out there.

    Thanks again


Leave A Comment...