Show Menu

Use Cases - Defining Requirements Cheat Sheet by

Systems Analysis Defining Requirements
class     models     systems     analysis     defining     requirements     interviewing     domain

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

Download the Use Cases - Defining Requirements Cheat Sheet

2 Pages
//media.cheatography.com/storage/thumb/nataliemoore_use-cases-defining-requirements.750.jpg

PDF (recommended)

Alternative Downloads

Share This Cheat Sheet!

 

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