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

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:

General

This covers a variety of things such as:

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

Content

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. 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.