Checkpoints:  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.
• 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 extend-relationship described clearly so that it is obvious how and when the use case is inserted?

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?

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process