Show Menu
Cheatography

Use Cases - Defining Requirements Cheat Sheet by

Systems Analysis Defining Requirements

Labelled use case automation boundary

Use Cases

Define requir­ements activity
Lists steps defining intera­ctions between a role (aka UML "­act­or") and a system, to achieve a goal. The actor can be a human, an external system, or time.
Bene­fits
Short summary of what the system will offer.
Provides a project planning skeleton, to be used to build initial priori­ties, estimates, team allocation and timing.
Provides everyone with an agreement as to what the system will/won't do.
Provides context for requir­ements
Helps in invest­igating small details which could cause big problems.
Answers often detailed / tricky / ignored business questions: “What are we supposed to do in this case?”
Shows that the invest­igators have thought through every user’s needs, every user system goal, every business variant involved.
Limits
not good for non-in­ter­action based requir­ements
Clarity depends on the skill of the writer(s).
Sometimes use cases are complex to write and to understand
No fully standard defini­tions of use cases

Use case names

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

User goal technique (Use case method)

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

Event Decomp­osition

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

Develop a use case diagram

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
 

CRUD - Create, Read or Report, Update and Delete

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

CRUD

UML - Unified Modeling Language

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
                           

Help Us Go Positive!

We offset our carbon usage with Ecologi. Click the link below to help us!

We offset our carbon footprint via Ecologi
 

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          System Design Cheat Sheet

          More Cheat Sheets by NatalieMoore