Activity: Review Business Use-Case Model

Recommended Review Meetings

Normally, you should divide the review into the following meetings:

• A review of the entire business use-case model.
• A review of the business use cases (for each use case), along with their diagrams. If the model is large, break this review into several meetings, possibly one per business use-case package.

Even if you can review everything at the same meeting, you probably won't get approval of your conclusions the first time. Be prepared to carry out new reviews for each new version of the business use-case model. It is important to involve employees, domain experts, as well as members of the business-engineering team in the review, to make sure the model describes the business properly.

Checkpoints are included in the following sections.

Checkpoints for the Business Use-Case Model

• Do the use cases conform to the business you want them to describe?
• Have all the use cases been found? The use cases should together perform all activities within the business.
• Are all activities within the business included in at least one use case?
• Is there a balance between the number and the size of the use cases?
• Is each use case unique? If not, consider merging it with a similar use case.
• Do the diagrams appear to be well-structured?
• Are the diagrams so large and complex that they should be broken down into several smaller diagrams?

Checkpoints for Business Actors

• Have all actors been found?
• Does each (human) actor express a role, not a person? Try to name at least two people that can act as the actor.
• Does each actor model something outside the business?
• Is each actor involved with at least one use case? If not, remove it.
• Does each actor represent one role? If not, you should probably split the actor into several actors, each expressing a different role.
• Does each actor have an explanatory name and description that is understandable to people outside the business-engineering team?

Checkpoints for Business Use Cases

• Is its name and brief description clear and easy to understand, even to people outside the business-engineering team?
• Is each business use case complete from an outside (actor’s) perspective?
• Is each business use case involved with at least one actor?
• Is each supporting use case involved with at least one actor? If not, it has to be initiated by an internal event, and does not have to interact with an actor to perform its activities.

For abstract business use cases, you may add:

• Is the business use case substantial enough to be an abstract business use case on its own?
• Does it contain logically related activities?
• Is there a reason for the business use case to exist?

Checkpoints for Business Use-Case Reports

• Is the use-case workflow clear and understandable?
• Is the wording informal enough to be understood by people outside the project team?
• Does it describe the workflow, and not just the purpose of the use case?
• Does it describe the workflow from a external viewpoint?
• Does the use case perform only activities inside the business?
• Are all possible activities that belong to the use case described?
• Are only actors that interact with the use case mentioned?
• Are only activities that belong to the use case described?
• Does it mention only use cases with which it is connected?
• Does it clearly indicate when the order of activities is not fixed?
• Is the workflow well-structured?
• Are the start and end of the workflow clearly described?
• Is each extends-relationship described clearly so that it is obvious how and when the use case is inserted?

Checkpoints for Supplementary Business Specifications

• Are all supplementary business definitions listed in the document general, in the sense that none of them should pertain to one single business use case, business worker, or business entity?
• Are all relevant business rules listed or referred to?
• If the business rules are not in the document, are the references correct and easily accessible for project members?

Checkpoints for the Glossary

• Does each term have a clear and concise definition?
• Is each glossary term included somewhere in the descriptions of the business use cases? If not, it may imply that a business use case is missing or that the existing business use cases are not complete. It is more likely, though, that the term is not included because it is not needed. In that case, you should remove it.
• Are terms used consistently in the brief descriptions of business actors and business use cases?
• Does a term represent the same thing in all business use cases?