Use Case Modeling Guidelines

Introduction

Over the last decade, use cases have become the most popular de facto standard technique for performing software requirements analysis and specification of operational (a.k.a., functional) requirements within the object community. However, use case modeling also has numerous well-known problems (see [1], [2], [3], [4], [5], and [6] in Sources below). It is inherently more functional than object-oriented, leading to a significant chasm and paradigm shift between requirements engineering and OO modeling. Putting the use case approach into practice also often illuminates problems that are not addressed in books and most articles on use cases, and different requirements engineers typically perform use case modeling differently.

These webpages provides a hierarchically organized set of detailed guidelines for use case modeling. These guidelines were collected from numerous real projects during the last decade.

Guidelines

General Guidelines:

• Provide Training
• Functional Requirements Only
• Document in Requirements Specification
• Use Standard Terminology
• Use Technical Writers
• Validate Requirements
• Avoid Use Case Driven Design
• Verify Architecture and Design
• Use an Iterative, Incremental, Parallel Development Cycle
• Schedule Later Builds by Use Cases and Paths
• Use a Standard Modeling Language
• Choose Appropriate Tools

Actor Guidelines:

• Identify the Boundary
• Summarize the Context
• Initially Focus on Human Actors
• Initially Focus on Client Actors
• Document all Relevant Actors
• Actors Should be Cohesive
• Identify External Stereotypes
• Organize by Externals
• Identify Roles, Not People or Job Descriptions
• Properly Name Actors
• Define the Actors
• Document Responsibilities
• Document State Behavior
• No Requirements on Actors
• Identify Required Actor Expertise
• Specify Required Interfaces

Use Case Guidelines:

• Make Use Cases Functionally Cohesive
• Use Essential Use Cases
• Do Not Specify Security Mechanisms
• Properly Name Use Cases
• Specify Use Case Requirements
• Create Use Case Diagrams
• Provide a Business Context
• Annotate Business Rules
• Provide a Business Justification

Use Case Path Guidelines:

• Only Specify Basis Paths
• Specify Paths Individually
• Properly Name Paths
• Specify Path Requirements
• Document Relevant Assertions
• Document the Interactions
• Capture Exceptions
• Categorize the Paths
• Factor Out Common Interactions
• Document the Logic
• Create Sequence Diagrams
• Some Interactions are Requirements
• Specify Complex Internal Algorithms
• Standardize Interaction Formats

Sources

1. Donald G. Firesmith, “Use Cases: The Pros and Cons,” in Wisdom of the Gurus: A Vision for Object Technology, Charles F. Bowman, ed., SIGS Books Inc., New York, New York, 1996, pp. 171-180.
2. Alistair Cockburn, “Structuring Use Cases with Goals,” Journal of Object-Oriented Programming, SIGS Publications, Sep-Oct 1997 and Nov-Dec 1997.
3. Alistair Cockburn, Writing Effective Use Cases, Addison Wesley, Boston, Massachusettes, 2001.
4. Tim Korson, “The Misuse of Use Cases,” Object Magazine, 8(3), SIGS Publications, 1998, pp. 18-20.
5. Susan Lilly, “Use Case Pitfalls: Top 10 Problems from Real Projects,” in the Proceedings of TOOLS USA’1999.
6. Rebecca Wirfs-Brock, Writing Use Cases, Scenarios, and Conversations, Wirfs-Brock Associates, 15 May 2000.