Use cases and scenarios to describe how actors (a person or a system) interact with a solution to accomplish one or more of that person or system’s goals. Use case has 2 parts: use case diagram and use case specifications.
Scenarios depict a series of steps performed by actors and solutions to achieve a goal.
Business analysts use cases to describe several scenarios in the form of primary, alternate or exception flows.
Use case diagram for a project control system is shown below:
Use case diagram: Visually depicts the scope of the solution, actors involved, and business analysts’ use cases.
Associations: Relationships between actors and business analysts use cases are known as associations. 2 commonly used relationships are:
Extend: Allows for insertion of additional behavior into a use case. Here, base use case gets extended by the extended use case.
The extended use case is optional, and its execution ALWAYS depends on a condition. The point at which extension occurs is called the extension point.
The base use case is complete without extended use case whereas the extended use case is incomplete without a base use case.
Include: Allows base use case to make business analysts use of functionality present in another business analysts use case. Included use case is ALWAYS executed. Base use case is incomplete without included business analysts use case.
Common function is included and Mandatory. Additional function is Extend and Non-mandatory.
Elements of the Use case description
Use case description typically contains:
A unique name comprising of a verb and noun.
Brief description of a successful outcome of use case from an actor’s perspective.
Any person, system, or event external to system under design that interacts with that system. Each actor must be given a unique name representing the role they play system interactions. A particular person may fill roles of multiple actors over time. A use case is started by an actor, referred to as primary actor for that business analysts use case. Other actors who participate in use case in a supporting role are called secondary actors. Roles may not match with job titles, and should NEVER be name of actual persons.
An event (action taken by a primary actor) to initiate business analysts use case.
Flow of events
Set of steps performed by actor and solution during the business analysts use case.
Type of flows:
Basic, primary, or main success flow:
Shortest or simplest successful path to achieve an actor’s goal.
Alternative flow: Other paths to be followed to achieve an actor’s goal.
Exception flow: If circumstance does not allow the actor to achieve its goal, the use case is considered unsuccessful, and is terminated. For example, in a bank transaction, the ATM machine asks the user to change the amount based on account balance. Exception flows are ones where an application fails to achieve a goal, say e.g., ATM fails to connect to the bank server.
Post-conditions or guarantees
Any fact that must be true when use case is complete. MUST be true for all flows. Can be different for successful and unsuccessful outcomes of business analysts use case.
- Good at clarifying scope and providing a high-level understanding of requirements.
- Use case specifications make it easy to understand functional behavior of a system.
- Written at higher-level of abstraction (low level of detail).
- Lack of standardized formats.
- Need analysis to identify include business analysts use cases.
Let us learn the process model by means of an example. Governance, Risk and Compliance (GRC) management system is developed for the IT and ITES domain. The primary objective of GRC management system is to help companies implement Governance, Quality, and Information Security Management Systems in an integrated manner. It has various features, one of which is to plan and track projects and programs using standards such as CMMI, ISO 9001, and ISO 27001, etc.
Through this example let us try to understand how a user logs in to the Governance, Risk, and Compliance (GRC) management system.
|USE CASE #01||Login to Governance, Risk and Compliance management|
|Goal||Allow users who have legitimate user profile ID and password to business analysts use restricted functionalities within Governance, Risk and Compliance (GRC) management system and to restrict users who are not authorized to go into the system|
|Preconditions||1. User has legitimate Governance, Risk and Compliance (GRC) management user login profile ID and password|
|Success End Conditions||1. System redirects the user to user home page with the main menu|
|Failed End Conditions||1. System redirects the user back to the login page with the appropriate error message|
|Primary, Secondary Actors||1. Governance, Risk and Compliance (GRC) management Users (not login yet)|
|Triggers||1. User clicks on Login button|
|1||User visit URL of login page of Governance, Risk and Compliance management|
|2||System display login page of Governance, Risk and Compliance management|
|3||User input user profile ID and password and submit|
|4||System validate input, accept and record user login|
|5||System redirect user to home page with main menu|
|4.a||If user input is incomplete, System prompt user with alert message|
|4.b||If password (case-sensitive) is incorrect, System record failure attempt and redirect user to login page with error message|
|4.b 1||If over failure attempt limit, System lock profile and redirect user to forget password page|
|4.c||If user profile is not valid, System redirect user to login page with error message|
|4.d||If user profile is expired, System redirect user to login page with error message|
|4.e||If user profile is locked, System redirect user to login page with error message|
|4.f||If over login session limit, System redirect user to login page with error message|
|5.a||If user is required to change password, System redirect user to change password page|
|5.b||If user is required to update profile, System redirect user to update profile page|
|Related business analysts use Cases||List any other business analysts use cases that are included (“called”) by this business analysts use case. Common functionality that appears in multiple business analysts use cases can be split out into a separate use case that is included by ones that need that common functionality.|
|Business rules||Follow corporate password policy for passwords.|
|Priority||Highest – Most of the business-critical functionalities are dependent on this business analysts use Case|
|Non-functional requirements (Performance, Security, Usability, etc.)||The system shall respond to the User within 5 seconds regardless of login acceptance, failure, or redirection to other pages|
|Frequency||Per Entity (country) – Estimated 1 request for this business analysts use Case every 5 minutes|
|Assumptions||1. User has broadband access or relatively fast connection to the Internet|