CSE 110 Software Engineering Inc.

Design Use Cases

A Design Use Case is a detailed description of a functionality that benefits the user of the application written from the user's and systems point of view. It is very similar to the Use Case artifact, but mentions the model/view/controller aspects of the project by specifying which files, API requests, calls, etc are being used in the Workflow.

    What feature or functionality of your application is and isn't a Design Use Case?
    A Design Use Case should be a complete idea for functionality that does something.
    A user would buy or use your application due the functionality described by the Design Use Case.
    • Displaying the home screen isn't a functionality described by a Design Use Case.
      • Such display isn't a benefit by itself.
      • Displaying the home screen could be a system step in the login Design Use Case.
    • Logging into the system is a functionality described by a Design Use Case. In another language the Design Use Case should have a one on one mapping to Use Case artifact.
      • Login provides benefit of securing information.

Instructions in Creating the Artifact

This instructions are inetended to give you a better scope of what a good Design Use Case could be like rather than a sole resource for the artifact of your project. You may need to tailor it and make several other changes to ensure it is a good fit for your use and project.

Title and Number: Using a few key words that fit the functionality to be described.
Description: High level overview of the capability provided.
Desired Outcome: User Goal achieved.
User Goal: High level achievement or purpose of the functionality provided. (What problem are we trying to solve?)
Dependent Design Use Cases: The list of Design Use Case numbers for functionality that must exist before the described functionality in current Design Use Case can be performed.
Priority: The importance of the functionality to the application.
Status: The condition of the functionality described.
Requirements: A cross reference listing of the portions of functionality the system must implement relating to this Design Use Case. These are often the "The system shall" statements in the Design Use Case steps.
Pre-conditions: The actions of the user or of the system that must have occurred in order for the functionality to be provided. Preconditions do not include steps in the Design Use Case Workflow.
Post-conditions: The changes to the system after the user or the system completes the Design Use Case Workflow.
Trigger: The catalyst or motivation causing the user to use the Design Use Case functionality. This does not involve steps in the using the system.
Workflow: The steps involved in using the system to provide the desired functionality. The steps are typically a series of steps listing an exchange of "The user shall..." or "signup.js shall ..." followed by "The system shall..." The steps can refer to steps in other design use cases. The starting point is after Pre-Conditions. Be sure to mention which MVC components/files are being used.
Alternate Workflow: The steps involved in alternate functionality and error processing.

Things to keep in mind

  • Eliminate vague words ("such as", "etc", "information"). Coding isn't vague.
  • Ideally, precondition starts at the Home Page or Dashboard

Examples of Design Use Cases