Use Cases: What They Are, Examples, How to Write Them, & More
Developing an initial set of functional requirements during the Requirements Gathering phase should provide a good understanding of the intended behavior of the system. However, one shortcoming of this list of requirements is that it’s static and doesn’t adapt to the different business processes that need to be supported by new features.
What is a Use Case? Use Cases Defined
So what is a use case? A use case is a description of the different ways that a user can interact with an application or product. They define the various external entities that exist outside the system, as well as the specific interactions they have with the system. This can come in the form of success scenarios, alternate paths, and more. Use cases can also be formatted in a text-based medium like a list/table, or a visual medium like a diagram.
What is the Purpose of a Use Case? Benefits & Importance
The major benefits that use cases provide are in the planning stage of development. Steps like requirements gathering, defining scope, and roadmap creation are all improved through the clarity that these use cases bring. They also allow the team to identify the best possible outcome scenario, accurately depicting the intended design and use of the system. When it comes to less-than-ideal use cases, the brainstorming of these alternative possible outcomes helps developers identify potential problems before they happen.
How to Write a Use Case
Writing a use case can be started with three basic steps or questions:
- Who is going to use the product?
- What will it be used for?
- How are they going to use it?
These questions form the basis of any successful use case, and should be used as an initial framework when writing your own. Beyond that, use cases can be as high-level or detailed as they need to be for the audience and system. The key to an effective and helpful use case is to carefully consider the flow of events for a typical user, and use those to form the use case.
What to Include in a Use Case
As you’re writing your use case, there are several components that should typically be included. These range from the identifier of the use case to who’s involved and alternative scenarios:
- Use case number: Assigning a number to each use case helps organize your records and can be sorted in chronological order or by other criteria depending on how the developers decide to label them.
- Use case name, description, and goal: Giving a clear and concise name, description, and goal to each use case also helps organize documentation while preventing scope creep.
- Actor: This is someone or something that performs a behavior or action (can be a person or an object). If we take an e-commerce site as an example, actors might include buyers, credit card companies, shipping companies, and more.
- Primary actor: This is someone or something whose goals are fulfilled by the system in question, and while they don’t always start the use case, it’s fairly common for them to do so.
- Stakeholders: Anyone with interests in the functionality and success of the system are called stakeholders, and are often indirectly involved (not users, but those that benefit from how the system functions).
- Pre-conditions: The statements about what needs to happen before the use case starts.
- Triggers: Used to start a use case, triggers are events that initiate the first steps of a scenario.
- Post-conditions: The statements about the possible states that the system can be in after the use case ends.
- Basic flow: Also called the main success scenario, this is a use case path that works perfectly and as intended with no exceptions (this is often used as a base to create alternative paths).
- Alternative path (or flow): A variation of the main success scenario, these usually show what happens when there’s an error or unexpected event in a use case.
Use Case Examples
Example 1: Quiz Instant Feedback
- Description: An educational technology company wants to develop a feature that allows students to take quizzes and receive instant feedback
- Primary actor: Students
- Goals: Take a quiz, view quiz results
- Stakeholders: Educational technology company, students, educators, school administration, investors
- Pre-conditions: Student must be logged in, student must have access to the quiz
- Post-conditions: Student can take the quiz and receive instant feedback on their performance
- Basic flow:
- Student logs into the educational technology platform and selects the option to take a quiz
- System presents the student with the quiz questions
- Student answers the questions and submits the quiz
- System evaluates the student's answers and provides instant feedback on their performance
- System records the quiz results and makes them available for the student, educator, and administration to view
- Student views the feedback and can review their answers if they desire
- Alternate path:
- Student logs into the educational technology platform and selects the option to view previous quiz results
- System presents the student with a list of previous quizzes they have taken, along with their results
- Student selects a previous quiz to view
- System displays the student's answers and the correct answers for each question
- Student reviews their answers and receives feedback on their performance
Example 2: Social Media Live Streaming Feature
- Description: A social media company wants to develop a feature that allows users to live stream to their followers
- Primary Actor: Social media users
- Goals: Start a live stream, end a live stream, view live stream
- Stakeholders: Social media company, social media users, followers, advertisers, investors
- Pre-conditions: The user must have a stable internet connection
- Post-conditions: The user's followers can view the live stream, user can end the live stream at any time
- Basic flow:
- User logs into the social media platform and selects the option to start a live stream
- System accesses the user's camera and microphone and displays a preview of the live stream to the user
- User starts the live stream, which is broadcast to their followers in real time
- Followers can view the live stream, engage with the user through comments or other interactions, and can share the live stream to their own followers
- User ends the livestream
- Alternate path:
- User logs into the social media platform and selects the option to schedule a live stream
- System prompts the user to enter the date, time, and title of the scheduled live stream.
- System sends a notification to the user's followers, letting them know when the scheduled live stream is starting
- At the scheduled time, the user starts the live stream, which is broadcast to their followers in real-time
- Followers can view the live stream, engage with the user through comments or other interactions, and can share the live stream with their own followers
- User ends the livestream
Types of Use Case
Use cases can be described either at an abstract level (known as a business use case) or at an implementation-specific level (known as a system use case):
- Business Use Case: Also known as an "Abstract-Level Use Case", these are written in a technology-agnostic manner, simply referring to the high-level business process being described (e.g. "book return") and the various external actors that take part in the process (e.g. "borrower", "librarian", etc.). The business use case will define the sequence of actions that the business needs to perform to give a meaningful, observable result to the external entity.
- System Use Case: Also known as an "Implementation Use Case", these have a more granular level of detail than the business use case and refer to specific processes that will be carried out by different parts of the system. For example, a system use case might be "return book when overdue". It would then describe the interactions of the various actors and the system to carry out the end-to-end process.
Typically, you will start by defining the high-level business use cases. As the system requirements get defined, they will be drilled down into one or more lower-level system use cases.
Use Cases vs. User Stories
One related artifact is the "business scenario" or user story. These are similar to use cases in terms of what they seek to accomplish — a description of how the system will carry out a specified business process to fulfill the stated requirements. However, unlike a use case (which is a step-by-step enumeration of the tasks carried out during a process), a scenario is much more free-form.
A user story is typically a narrative "short story" that describes the tasks that the users carry out, what information they see, and how they interact with the system. User stories have become more popular with the rise of Agile Methodologies that emphasize customer collaboration, user interaction, and simplicity.
Use Case Diagrams
In addition to use cases and user stories, diagrams can be used to more clearly illustrate the set of use cases that are provided by the functionality in a system. These contain both the actors that will be using the system and the discrete use cases (or goals) that the users will be carrying out.
These diagrams are typically represented in the UML modeling language, though other forms do exist. They help the business analyst convey the relationships between the actors and their business goals and how the design of the system needs to support their different objectives with integrated business processes.
Scenarios and Process Flows
While UML use-case diagrams depict the different actors and goals, you can also use process flow diagrams to display the steps that will take place in each process:
In the simplest form, it can be a linear flow from start to finish. In more complex use cases, you may have multiple branches and decision points. In this case, it would become a fully-fledged flowchart.
Relationship to Functional and System Requirements
Use cases are often used as a means of discovering and representing functional and system requirements because they define the interactions and tasks necessary for carrying out specific business objectives. However, they are typically not the best way to define non-functional requirements such as technical requirements or system qualities. A requirements traceability matrix is used to ensure completeness — namely that all functional requirements are covered by at least one business use case, and that all system requirements are covered by at least one system use case.
Relationship to Test Cases
Typically, you’ll need to ensure that there is complete requirements test coverage for a successful quality assurance program. Use cases provide a good starting point for the design of test cases that will be used to test that the system meets the specified requirements.
Once the requirements engineering activities have been completed and the business analysts are happy with the requirements definition, the team can create test cases based on the system use cases. This usually involves adding more detailed pre-conditions and post-conditions and writing different test case "variants" of the same use case to cover different scenarios.
The Best Way to Manage Your Use Cases
SpiraTeam manages your project's requirements, use cases, tests, tasks, source code, and issues in one integrated environment, with full traceability throughout the product development lifecycle.
- It is a complete requirements management solution that provides multiple views of requirements, including a document, hierarchical, grid, mind map, and agile Kanban board view.
- With SpiraPlan, you can plan your product’s work with its integrated project, product, and quality management system.
- You can also connect your requirements to your other product artifacts for end-to-end traceability, as well as linking requirements to your test cases, issues, tasks, defects, builds, and source code.
How do I Get Started?
To learn more about SpiraTeam and how it can be used to improve your requirements and use case management: