This article goes over 3 Steps to Building UML Use Case Diagrams and Use Case Narratives

A use case is a methodology used in system analysis to identify, clarify and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. The method creates a document that describes all the steps taken by a user to complete an activity.

A use-case provides the following benefits −

It is an easy means of capturing the functional requirement with a focus on value added to the user.
Use-cases are relatively easy to write and read compared to the traditional requirement methods.
Use-cases force developers to think from the end user perspective.
Use-case engage the user in the requirement process.

Examples Include:

Process Withdrawals.
Balance Accounting & Sales Ledgers.
Back-Up Departmental Case Logs.
Online Ordering System

Before we get into the steps of building use cases I wanted to break down the components of a Use Case diagram as well as that of a use case

Table of Contents

Use case Diagram Components:

This is how a use case diagram looks. I will break down what each component means for you.

Actor = Stakeholder. An actor can be a system or a person. An actor to the left of the diagram typically represents the a person that will input a system. An actor to the right would indicate someone in the back end interacting with the system.

Oval Boxes = A Use Case. A Use Case is an activity.

Lines = Determine Relationships

The rectangular box = the System Boundary

The dotted arrows toward the Main Use Case = Extend relationships. As the name implies it extends the base use case and adds more functionality to the system. Here are a few things to consider when using the <<extend>> relationship. 3 characteristics of an extend use case are:

The extending use case is dependent on the extended (base) use case.

The extending use case is usually optional and can be triggered conditionally.

The extended (base) use case must be meaningful on its own.

The dotted line going away from the main use case: Include relationship show that the behavior of the included use case is part of the including (base) use case. The main reason for this is to reuse common actions across multiple use cases. In some situations, this is done to simplify complex behaviors. Few things to consider when using the <<include>> relationship. The base use case is incomplete without the included use case. The included use case is mandatory and not optional.

The notations are also available here https://baknowledgeshare.com/business-analysis-templates/.

Use Case Narrative Components

Section 1: Section 1 of this narrative includes the General Characteristics of a use case narrative.

The template for this is available here https://baknowledgeshare.com/business-analysis-templates/

The template below provide the descriptions.

Section 2: Covers the Main Success aka Happy Path Scenario

Section 3: This covers the alternate and the exception paths

Section 4: Covers the Non Functional Requirements and the Open Items with any additional future date requirements

Steps to building the Use Case Narrative and the Use Case Diagram.

Step 1: Identify the preconditions.

This is the starting point to building your use case diagram and narratives.

Preconditions Online Ordering System

Who are the Stakeholders?

Customer (Registered and New), Admin, Restaurant Employee

What is the Objective

To build an online ordering system

What is the Scope

Category	In Scope	Out of Scope
Menu Items
Channels
Systems
Users
Data
Triggers

What are the activities identified in the Activity Diagram?

Start

UC 1 – Login

UC 2 – Display Menu Items

UC 3 – Search Menu Items

UC 4 – View Items

UC 5 – Add to cart – View Cart, edit cart

UC 6 – Confirm Order

UC 7 – Select Delivery

UC 8 – Make Payment

UC 9 – Confirm payment and delivery

End

Step 2: Draw the Use Case Diagram

You can use a workflow tool such as Vizio or Lucid Chart to build this out. I am using Lucid Chart. You can get as detailed as you want in terms of the use cases. The more you get into this you will realize that there will be the details that will get to you.

Step 3: Build a Use Case Inventory

You can build a use Case Inventory from the diagram that essentially will help you trace your requirements.

Step 4: Write the Use Case Narrative

This is an example using one use case:

Use Case # [number: UC001]

GENERAL CHARACTERISTICS
Intent	Use Must have the ability to Log in to the online ordering System
Scope	New Customers Validation of Credentials
Level	System Level
Author	Rashmi
Last Update:	[2.7.2021 / change history]
Status	[one of : under review.]
Primary Actor	Customer
Secondary Actors	Staff and Database
Preconditions	Customer wants to order food from the Vegan restaurant online
<Dynamic Preconditions>	N/A
Assumptions	Customers are New
Trigger	New Customer Clicks on the New Customer Log in Button
Success Post Condition	Customer has successfully created the log in account and has the ability to view the menu items
Failed Post Condition	Customer will be provided with an error message and cannot log in
< Models>	See Use Case Diagram
Operations Concepts	The Wireframe will be developed
Overview	The user has the ability to log in the online ordering system

MAIN SUCCESS SCENARIO
Step	Action
S	Customer has successfully created the log in account and has the ability to view the menu items
1	New Customer Clicks on the New Customer Log in Button
2	The system will take the customer to provide their email, username and password
3	The system will validate if the email, username and password follow the right credentialling standards
4	The system will provide a message saying “ you have successfully registered”
5	Customer has successfully created the log in account and has the ability to view the menu items

In Summary

In Summary there are 3 Steps to building your use cases.

How do you build your use cases?