Rules for Checking Use Cases

Type: Rules
Sources: Standard document rules by Tom Gilb, my own experience with use cases


If you do some sort of QA for use cases, there are a lot of possible defects to look out for. Here's what I found useful in a couple of my recent projects. I'm sure this checklist needs customization for your project. With slight alterations it should be possible to apply the rules to all kinds of requirement specifications.
Please note that the actual rules are written in boldface. The additional aspects noted shall make finding defects easier.

Summary of Rules

The rules are split into two destinct categories: craftsmanship and stakeholder-value. I check the craftsmanship rules first and make sure the use cases comply to them. ONLY THEN it is economic to let the stakeholders check the stakeholder-value rules.
Note: I like to use a 2-step QA approach to documents: make sure the document is written well first, then check if it has the right content. This way, the experts do not have to wade through dozens of presumably minor defects, like wrong links and bad sentance structure. Of course, this aims at improving the quality of what authors write in the first place.

Rules and Notes


Note: Testing against these rules make sure you have a well written document. It doesn't make sure these are the right use cases.

R1: Clear enough to test

  • There's only one action per step.
  • The sunny scenario is described as well as all exceptions and alternatives.
  • The use case is consistent with all kin use cases and other documents.
  • put all formal clarity criteria you like here. But make sure you aim at 'clear enough'.

R2: Unambiguous to the intended readership

  • The purpose of the use case is stated clearly.
  • Comments can be clearly identified as such.
  • Terms used are consistent with the business class model and the definitions given in the glossary of terms.
  • The short description is constent with preconditions, flow of events, and post conditions.

R3: Complete, compared to sources and kin documents

  • If there are open questions, they are clearly stated. 'use <fuzzy brackets>, or a special section witin the document.
  • If there are open questions, they cannot be answered as of now.
  • The knowledge contained in the document is consistent with all source documents.

R4: Relevant for the purpose of the document

  • All sources are listed.
  • There is a statement concerning the priority of the requirements in the document, relative to other requirements.
  • There's a clear statement of 'why?' this use case makes sense.
  • The document does not describe unnecessary design, but does describe a future state.


Note: These rules take a different standpoint. They reflect the opinion of a distinct stakeholder, our group of stakeholders. If these criteria do not hold, there's no point in starting a system development based on the requirements the use cases express.

R5: Valid from our point of view

  • The requirements in {process, business rules, definitions, relations to a business class model} reflect the subject matter, as we perceive them and take responsibility for them.
  • The document does not contain any requirements which are marginal or even irrelevant to our goals.

R6: Desirable for our business

  • Considering all the explicit and implicit requirements we have in mind, the document expresses our wishes for a new system.
  • If the requirements expressed in the document are made into a system, the system will take us closer to our goals, and close enough.

R7: Expressing our priorities

  • These are the things we consider as required to solve our problem.
  • Secondary, non-mandatory 'requirements' are stated as comments or design ideas only

R8: Manageable with our resources

  • We can handle this document and the set of all requirement documents in the coming years, in keeping them up to date and in finding relevant information.
  • We understand the statements of this document.

Costs, Savings

In one project we saved over 170.000 EUR just by ensuring minimal quality (well-crafted documents, rules R1- R4) in the use case documentation alone. The ROI was pretty constant, at 1:4 per document.


< Good quote, anybody? >

Related Pages

Where to go from here? Link other pages in bullet list.

rating: 0+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License