Guidelines for Use Case Analysis

GUIDELINES FOR USE CASE ANALYSIS
	Yes	No	N/A	Remarks
Notation Have you used interaction diagrams to provide more rigorous descriptions of critical areas? While both the script and diagram notations are theoretically equivalent, in practice interaction diagrams (which are frequently annotated with structured text or pseudocode) tend to be more rigorous. This is especially true when the interaction diagrams are constructed using an OO CASE tool.
Organization Have you organized use cases so that the system can be analyzed in increments and the use cases can be managed? Large development projects with many use cases should consider hierarchical organizational schemes to manage their complexity. (Compare the application of subsystem and module decomposition for large object systems.)
Prioritization Have you prioritized the use cases according to their importance in relation to the system requirement? Complete basic courses first, alternative courses as time permits.
Efficiency Have you applied the 80/20 rule? After defining approximately 80 percent of the basic courses and some of the more interesting alternate courses, validate them using prototypes and designs. Use what is learned from prototypes and design to complete the remaining 20 percent of the use cases required. Do not feel compelled to complete every alternative course, and don’t feel that you need to both script and diagram every basic course. (Usually one technique is sufficient.) Avoid analysis paralysis.
Design Creep Have you reviewed the use cases to ensure they are focused on requirements (i.e., what) not design (i.e., how)? Use cases should focus on specifying requirements, and avoid making design decisions.
Testing Support Have you defined use cases so that they can be used to drive system testing, as well as analysis and design? Addressing this additional concern will improve the rigor of the use cases and facilitate system verification and validation.