Use Case it!

Use Case Name
Scope
Level
Primary Actor
Stakeholders and Interests
Preconditions
Postconditions
Main Success Scenario
Extensions
Special Requirements
Technology and Data Variations List
Frequency of Occurence
Miscellaneous

Use Case IT!

Use Cases helps you better understand how users and other actors interact with your website/game/app. Each use case describes a list of actions an actor needs to follow to satisfy a specific goal.

Make use cases for each distinct functionality in your product.
Describe for example how an user signs into the system and where the system redirects the user after successful login, or how an user can place an order and what the system needs to do, if ordered item is out of stock.

Tap on the beside each field to see a detailed description of each field and what content it shall contain.

Also checkout out burnflow.com - my new week-based Project Management Tool.

Check out my new week-based Project Management Tool

Available on Android, iOS and Web - burnflow.com

Help keep this tool alive!


What is this Use Case for?

Examples:
Webshop Mobile App, SOCIAL News Feed, etc.

User Goal or Subfunction?

user-goal: Use Cases describing scenarios for the Primary Actor to complete
for fulfilling a specific goal, e.g. Sending Friend Request.

subfunction: Use Cases describing substeps that support a User Goal.
These Use Cases are primarily created to factor out common
steps used by multiple Use Cases, e.g. signing into the system.

Actor performing the scenario of the Use Case to satisfy a goal.

Examples: System Admin, Client, Employee, etc.

Information about who this Use Case concerns and
their desires.

Examples:

  • Customer: Wants information of their current order.
    Wants fast support. Wants to be able to add
    new items to the cart without effort.
  • System Admin: Wants easily visible orders by customers.
    Want to be able to checkout items from warehouse
    with minimal effort.

State what must be true before the scenario can begin.

Example:

  • User must be signed into the system.
  • User must have permission to access this system.

State what must be true, if the scenario is
to be considered successfully completed.

Example:

  • Friend request sent by mail.
  • Chat Group created.

Main steps considered as the typical path for a successful scenario
that satisfies the desires of all stakeholders.

Example:

  1. User enters login information
  2. User clicks 'login'
  3. System validates provided information
  4. System shows success message
  5. System redirects to dashboard

Alternate paths goes here. These paths can both lead to success or failure.

Example:

3a. Entered login information doesn't match:

  1. System shows error message indicating that login information is wrong.
  2. System clears password field
  3. User re-enters login information
  4. User clicks Enter

Non-functional requirements goes here. Qualities like performance,
reliability and usability, and design constraints that is required or
considered to be mandatory.

Examples:

  • Language localization on all text.
  • Text on screen must be visible from 1 meter.
  • Game must run smoothly on minimum 2GB RAM.
  • All progress must be saved on the Cloud.

Hardware, Software or Data formats that must be supported.
Typically technical constraints requested by stakeholders.

Examples:

  • Barcode entered by scanner or by keyboard.
  • Invoices gets saved in PDF format.

How often is this Use Case expected to happen?

E.g. 100 times every month. Continuous. Once every year.

State any other information important for the the Use Case,
but doesn't fit any other field. E.g Open Issues:

  • Should users be able to see their friend's item orders.
  • Blacklist user after 3 failed login attempts?
  • Recovering passwords.