Appendix A. Use Case Development Review Checklist

The checklist in this appendix summarizes the key guidelines for developing use case models presented in body of the book. The checklist is based on the authors’ experiences, the experiences of other veteran use case modelers, and other experts in the field. A project, organization, or customer can/should add to or customize the checklist for their specific needs.

Getting Started

• A set of use case modeling standards and templates has been selected or created. Appropriate tools are identified and purchased.

• The use case modeling process is determined in the context of the overall development process.

• If use case modeling experience is low or not uniform (members of the team have done use case modeling in different ways), education or mentoring needs have been identified and scheduled.

• All of the stakeholders of the system have been identified.

Scoping the System

• The system boundary is clear. Stakeholders understand what hardware/software resides inside and outside the system.

• A concept of operation/system concept/vision document has been created to outline the scope of the system.

• The business need for the system is clear (possibly defined in a business case).

Identifying Actors

• All external entities that interact with the system (primary and secondary actors) have been identified. Consider the external systems (for example, legacy systems, sensors, and so on) as well as the human users and system administrators.

• All actors are entities outside the system.

• Each actor is an abstraction of a specific role.

• Each actor is the most specific delineation of the role possible. No broadly defined, “single” catch-all actor, such as “person” or “computer,” interacts with all use cases.

• Appropriate abstract actors have been identified when multiple actors share common behavior.

• All actors derive observable value from/provide observable value to the system.

• Each actor’s role in the overall business environment is well understood or has been documented.

• Each actor’s needs from the system are well understood or have been documented.

Identifying Use Cases

• The set of use cases covers all the requirements of the system. Consider both breadth and depth of requirements coverage.

• The name of each use case is a verb–noun phrase stated from the perspective of the actor. The verb is in the second person imperative tense, denoting an action that the actor should perform. (Remember that a use case is an event, not a process or information flow.)

• The name of the use case reflects the actor’s goal in interacting with the system. Test this goal to ensure that the system provides observable value.

Writing Use Cases (General)

• The names of the actors are consistent with the actor glossary.

• The terminology of the description is consistent with the system glossary.

• The use case descriptions can be understood by all of the stakeholders (customers, management, developers, and so on) who will read them. Adequate context is included.

• Each use case is complete; it provides the necessary behaviors and interactions to satisfy the actor’s goals.

• All observable value required by the interacting actors and described in the use case is consistent with the name of the use case.

• The use case provides a description from the actor’s perspective. It fully captures the actor’s expectations from this interaction.

• The use case is not a scenario. It describes all of the paths that may occur en route when attempting to achieve the goal specified by its name.

• The use case is initiated by a business event. Users can identify the use case by name or description as a situation they encounter or a task they need to accomplish when playing the role of one of the actors of the system.

• The use case contains only the functionality that is to be captured in the system; i.e., the system boundary is well-defined. Any context material outside the system but that supports functionality of the system is clearly indicated.

• All actors associated with the use case are entitled to all the functionality described in the use case.

• There are no gaps in the system functionality between use cases; that is, each use case completes its area (like a piece of a puzzle). If a gap is found, determine whether a new use case needed or if the functionality is missing from a use case description.

• The granularity, approach, and style used to write the use case description are consistent with the other use cases (use of prose, step, state, system interaction, and system goal approaches).

• The use case descriptions are compliant with the standards of the company, customer, and/or project.

• The use case contains the “right” amount of information to achieve its task.

• The source of the use case has been documented, if appropriate.

• If ambiguity exists, the project has an approach for dealing with the ambiguity.

• All assumptions about the use case have been documented. Consider assumptions made about the use case’s scope, expectations about information available via secondary actors, and development issues surrounding the use case, such as the level of effort needed to develop the use case, time frames, and so on.

• If preconditions and postconditions are used (e.g., not used in conceptual use cases), they are documented at a level of abstraction and with a vocabulary that users can understand. They apply to the state of the system, not the outside environment. They are written in a way that allows them to be verifiable and testable. They are written in the present tense.

• Alternative flows indicate the triggers that cause deviations from the normal course. If an alternative flow does not remerge with the normal flow, the results of how it differs from the normal flow are stated. If it does remerge, document the point at which it remerges.

• Extend relationships are truly extended behavior and not alternative flows.

• Significant common behavior has been factored out into a common use case linked by the “include” relationship.

Diagramming Use Cases

• The use case diagram is consistent with the conventions of the UML, some superset of the UML, or other well-defined modeling language.

• Multiple use case diagrams have been considered/used on a system of any size to partition the functionality. For example, some diagrams may be used to show the relationship between the actors and the system; others may show the base use cases and their extend, include, and generalization relationships. One diagram may be used to show the priorities of use cases based on architectural significance; another may be utilized to indicate the iteration in which a use case will be scheduled to have its functionality designed/developed/tested/documented.

• A system boundary in the diagram delineates the functionality inside and outside the system.

• All use cases are associated with an actor or are related to another use case (via include, extend, and generalization relationships).

• The use cases in a given package are consistent with a single theme or idea captured in the package name.

• The diagram is not spaghetti or a mass of relationships. Actors are not too broadly defined and no incorrect (or subroutine) level of use case modeling has been used. (Consider “layering” your use case model, as you would an architecture, so that dependencies between use cases are one-way.)

• The priority mechanism (if used) is documented. Priorities can be described using techniques such as a straight numerical ranking or the grouping of use cases into categories (high, medium, and low). Priorities are probably needed if incremental or iterative development of the system is planned.

Organizing the Use Case Model

• The use cases are organized in an appropriate manner (e.g., by functional area, by dependency stream, or by actor) making them comprehensible to the stakeholders.