Use Cases and Scenarios: Their Importance, How to Write Them, & More
Once you have developed an initial set of functional requirements during the Requirements Gathering phase you will have a good understanding of the intended behavior of the system. This includes what functionality is desired, what constraints are imposed, and what business objectives will be satisfied. However, one shortcoming of a traditional 'laundry-list' of requirements is that they are static and don't adapt to the different business processes that need to be supported by one feature.
For example, in a fictitious online library system, the functionality for managing returns would need to handle the separate situations where a borrower returns a book early and when they return it late. Although the same functionality is involved, they are different situations and the system would need to handle the separate conditions in each use case.
What is a Use Case?
A use case is a definition of a specific business objective that the system needs to accomplish. They do this by describing the various external actors (or entities) that exist outside of the system, together with the specific interactions they have with the system to accomplish the business objective.
Why Are They Important?
The major benefits that come with the creation of use cases are in the planning stage of development. Factors such as requirements gathering, defining scope, and roadmap creation are all improved through these use cases. They also allow the team to determine 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
Thankfully, writing a use case can be broken down into three basic steps or questions that need to be answered:
- 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 a starting guide 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 solutions:
- 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.
- 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).
- 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.
- 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 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
|Use Case #1||Quiz Instant Feedback|
|Description||An educational technology company wants to develop a feature that allows students to take quizzes and receive instant feedback.|
|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 quizSystem presents the student with the quiz questionsStudent answers the questions and submits the quizSystem evaluates the student's answers and provides instant feedback on their performanceStudent views the feedback and can review their answers if they desireSystem records the quiz results and makes them available for the student, educator, and administration to view|
|Alternate path||Student logs into the educational technology platform and selects the option to view previous quiz resultsSystem presents the student with a list of previous quizzes they have taken, along with their resultsStudent selects a previous quiz to viewSystem displays the student's answers and the correct answers for each questionStudent reviews their answers and receives feedback on their performance|
|Use Case #2||Social Media Live Streaming Feature|
|Description||A social media company wants to develop a feature that allows users to live stream video to their followers.|
|Actors||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||User must have a stable internet connection|
|Post-conditions||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 userUser starts the live stream, which is broadcasted to their followers in real-timeFollowers can view the live stream, interact with the user through comments or other interactions, and can share the live stream to their own followersUser ends the live stream|
|Alternate path||User logs into the social media platform and selects the option to schedule a live streamSystem 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 startingAt the scheduled time, the user starts the live stream, which is broadcasted to their followers in real-timeFollowers can view the live stream, interact with the user through comments or other interactions, and can share the live stream to their own followersUser ends the live stream|
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). Each of these is described in more detail below:
- Business Use Case - also known as an "Abstract-Level Use Case", these use cases 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 use cases are written at 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 (borrower, librarian, etc.) with the system in carrying out the end-to-end process.
Typically, you will start by defining the high-level business use cases, and 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 that describes how a user would experience the functionality of the system. As the name suggests it is a "short story" that describes the tasks they carry out, what information they see and how they interact with the system. User stories have become more popular with the advent 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. The diagrams 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 becomes 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 our specific business objectives. However, they are typically not a good way of defining 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 test writers 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 cases "variants" of the same use case to cover different testing scenarios. Part of this will involve the identification of the critical exception cases that could cause the system to fail, and the development of the necessary test data to ensure full coverage of all test conditions.
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.
- Writing requirements is only the start — 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 can be used to improve your management of requirements and use cases: