Skip to content
Software Architecture Guide

Use Case Completeness Check

Explanation

Section titled “Explanation”

A use case describes how a user reaches a goal with a system (see Use Case). A completeness check asks whether the set of use cases is good enough to build from.

The simple test. The set is complete when users, the sponsor and other stakeholders cannot think of any more use cases. This is easy to apply, but it depends on what people happen to remember.

Three ways a set can fail. The set can have too few use cases. It can have too many, for example wishful thinking far beyond what the project needs. Or it can contain the wrong ones.

Why a measure helps. Without a measure, judging completeness is subjective and error-prone. One suggestion is to check the set against non-functional requirements and against domain concepts.

Check goal levels. Goals come in different sizes. Levels run from very high summary, through summary, user goal and subfunction, down to too low. The preferred level is user goal, also called “sea level”. Mark each use case with its level so readers do not get confused (see Use Case Goal Level).

Check extensions. An extension is a condition that leads to different interactions than the main success scenario. List each extension separately.

Do not rush. Users often name use cases they had not thought of before. Give elaboration time, and expect the list to grow.

Scope by release. Formal capture of use cases happens later, in increments. This fits scoping release by release (see Iterative and Incremental Development).

Example

Section titled “Example”

A team plans an online library system. Users, the sponsor and the stakeholders list their goals: “Borrow a book”, “Return a book”, “Pay a fine”. Nobody can name more, so the simple test passes.

A reviewer then checks levels. “Run the library” is a summary goal. “Check book availability” is a subfunction. Each use case carries its level. The reviewer also checks that each use case lists its extensions, such as a book that is already borrowed. Later, a user mentions “Reserve a book”. The team adds it and notes which release will include it.

Trade-offs

Section titled “Trade-offs”

The simple test is cheap, but it is subjective and can miss use cases. Checking against non-functional requirements and domain concepts takes more effort, but gives a firmer measure. Taking more time to elaborate finds more use cases, but delays formal capture.

Checks

Section titled “Checks”
  • Each use case is marked with its goal level.
  • Extensions are listed separately for each use case.
  • The use case set was checked against non-functional requirements and domain concepts, not only by asking stakeholders.
  • The use case set contains no wishful thinking beyond project needs.
Section titled “Related”

Sources

Section titled “Sources”