Use Cases - Defining Requirements Cheat Sheet

Name a use case with a verb-noun phrase that states the actor's goal. Action, Name.

1. Identify all potential users for a system
2. (Optional) Classify users by functional role (shipping, marketing, sales) and operat­ional level (opera­tional, manage­ment, executive)
3. Interview each user and determine what goals they have when using the system
4. Make a prelim­inary list of use cases for each type of user
5. Look for duplicates and incons­ist­encies across users
6. Identify when multiple users need the same use case
7. Review completed list with users and other stakeh­olders for validation

This approach looks for all events that would lead to the inform­ation system being used. Each event typically leads to a use case. Simplify events to ones that have a clearly defined start and end, and achieve a clear business purpose. These are: Elementary Business Processes (EBPs) = use cases.
Keeps attention on the macro scale purpose of the system, not internal details

Events can be:
- External – caused by an actor
- Temporal – done at fixed time intervals
- State – triggered by an internal condition, e.g. low inventory

Steps:
a. Identify relevant external events
b. For each, name a use case
c. Identify relevant temporal events
d. For each, name a use case and define when it occurs
e. Identify relevant state events
f. For each, name a use case
g. Omit trivial use cases (like log in), but keep system controls

1. ID all stakeh­olders who need a use case diagram.
2. Determine what each stakeh­older or user needs to review in a use case diagram. Could be subsystem, user focused, for use cases with the includes relati­onship, and for use cases that are of interest to specific stakeh­olders.
3. For each potential commun­ication need select the use cases and actors to show and draw the use case diagram.
4.Care­fully name each use case diagram and then note how and when the diagram should be used to review use cases with stakeh­olders and users

1. ID all data entities or domain classes involved
2. For each verify a use case has been created that creates a new instance, updates existing instances reads or reports values of instances and deletes (archives) an instance
3. If a needed use case has been overlooked add a new one and ID stakeh­olders
4. With integrated apps make clear app respon­sible for adding and maintain data and which merely uses the data

1. Genera­l-p­urpose modeling language in the field of software engine­ering, which is designed to provide a standard way to visualize the design of a system.
2. UML has been evolving since the second half of the 1990s and has its roots in the object­-or­iented methods developed in the late 1980s and early 1990s.

Why
Visualise through an assortment of types of diagrams: Activi­ties, Components and how they interact with other software, How system will run, How entities interact with others, external user interface

What
UML diagrams include (part of unit): Component, Activity, Sequence, Class, Use case*, Commun­ication