LAB 3 – REQUIREMENT ELICITATION WITH USE CASE DIAGRAM

Objectives
• Understanding how to capture functional requirements using a use case diagram.
• Learn to create a Use Case Diagram.
• Learn Textual Analysis using Abbott’s Technique to extract use cases from a scenario.
• Learn to create a use case diagram on a UML Tool (Visual Paradigm).

Time Required : 3 hrs

Programming Language : NIL
Software Required : Web browser, Visual Paradigm, Argo UML
Hardware Required : PC/Laptop

1. Requirements Elicitation: Tasks in this activity are meant to understand user requirements and
represent them in a form that can be understood by the user. For this purpose, formal use cases are
written and use case diagrams are drawn during this activity.This activity produces four things:
a. A vision statement - a paragraph or two on the shared vision of customer and developers on what the
app should do.
b. a feature list - a bulleted list of features the application should have
c. a set of use cases - each use-case is a step-by-step sequence of how a particular scenario of user-
system interaction should play out
d. Sketches/storyboards of potential User Interfaces.

2. Scenario: A scenario is a description of a series of interactions between a concrete end user and the
system. The description is written to describe usage of the system from an end user’s point of view. A
scenario can include text, video, pictures and story boards. It usually also contains details about the work
place, social situations and resource constraints. So, a scenario holds within itself the system
requirements.

3. Eliciting Functional Requirements from Scenarios: Formal use cases are derived from various
scenarios and UML’s use case diagrams are drawn to understand and document the functional
requirements. This makes up a larger part of the system’s functional model.

4. Use Case Diagram: Use case diagram is a behavioural UML diagram type and frequently used to
analyse and understand functional requirements of a system. They enable you to visualize the different
types of external roles in a system and how those roles interact with the system. They are visual and
usually very easy to understand. That’s why UCDs are drawn during requirement elicitation and
analysis in OBJECT-ORIENTED SOFTWARE DEVELOPMENT.

5. Importance of Use Case Diagrams: Depending on the requirement UCDs can be used to…

a. To identify system functions and how roles/actors interact with them – This is the primary
purpose of use case diagrams.
b. For a high level view of the system – Especially useful when presenting to managers or
stakeholders. You can highlight the roles that interact with the system and the functionality provided
by the system without going deep into inner workings of the system.
c. To identify internal and external factors – This might sound simple but in large complex projects
a system can be identified as an external role in another use case.

SOFTWARE CONSTRUCTION & DEVELOPMENT

6. Use Case Diagram Parts: Use case diagrams consist of 4 parts:Actor, Use case, SystemBoundary and
Package. These parts are further explained below.

a. Actor: Actor in a use case diagram is any entity that performs a role in one given system. This
could be a person, organization or an external system and usually drawn like stick-figure as shown. A
Primary actor is an actor who directly uses some function of the system. Whereas a secondary actor
is an actor who may use a system function to aid primary actor’s usage goals.

b. Use Case: A use case represents a function or an action within the system. It is drawn as an oval
and named with the function.

c. SystemBoundary: System boundary is used to define the scope of the use case and drawn as a
rectangle. This an optional element but useful when your visualizing large systems. For example you
can create all the use cases and then use the system object to define the scope covered by your
project. Or you can even use it to show the different areas covered in different releases.

d. Package: Package is another optional element that is extremely useful in complex diagrams. Similar
to class diagrams, packages are used to group together use cases. They are drawn like the image
shown below.

SOFTWARE CONSTRUCTION & DEVELOPMENT

Creating Use Case Diagram from a Scenario: Read a scenario and apply Abbott’s textual analysis: verbs
are selected as candidates for use cases whereas nouns are candidates for actors.

EXAMPLE: Please follow the example(s) given by Instructor.

SOFTWARE CONSTRUCTION & DEVELOPMENT

EXAMPLE - Creating Use Case Diagram from a Scenario:

CourseRegistration System
A student can register new courses through the CMS before classes start. The CMS will allow a student
to drop courses within due time as well. An administrator is in charge of managing the courses in the
CMS database. He/she may add a course, delete a course or even cancel a course when the Instructor
makes a request.

• Use cases: (Can be identified as phrases with verbs that depict the usage of system).

• Register new course, drop course, add course, delete course, cancel course.

• Participating actors:(Can be identified as nouns that depict a role interacting with the system).

• Student (primary actor), Administrator (primary actor), Instructor (secondary actor).

The following example shows a use case diagram for a “Course Registration System”. Notice the various
concepts and their relationships represented by the different elements of UCD:

Relationships in Use Case Diagrams: There are five types of relationships in a use case diagram. They are:

1. Association between an actor and a use case

2. Generalization of an actor
3. Include relationship between two use cases
4. Extend relationship between two use cases
5. Generalization of a use case

1. Association between Actor and Use Case: This one is straightforward and present in every use case
diagram. Few things to note.

• An actor must be associated with at least one use case.

SOFTWARE CONSTRUCTION & DEVELOPMENT

 • An actor can be associated with multiple use cases.
• Multiple actors can be associated with a single use case.

Different ways association relationship appears in use case diagrams

2. Generalization of an Actor: Generalization of an actor means that one actor can inherit the role of
another actor. The descendant inherits all the use cases of the ancestor. The descendant have one or more
use cases that are specific to that role. Let’s expand the previous use case diagram to show the generalization
of an actor.

A generalized actor in a use case diagram

3. Include Relationship between Two Use Cases: Include relationship show that the behaviour of the
included use case is part of the including (base) use case. The main reason for this is to reuse the common
actions across multiple use cases. In some situations this is done to simplify complex behaviours. 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.

Lest expand our banking system use case diagram to show include relationships as well.

SOFTWARE CONSTRUCTION & DEVELOPMENT

 Includes is usually used to model common behaviour

4. Extend Relationship between Two Use Cases: it extends the base use case and adds more functionality
to the system. Here are few things to consider when using the <<extend>> relationship.

• The extending use case is dependent on the extended (base) use case. In the below diagram the
“Calculate Bonus” use case doesn’t make much sense without the “Deposit Funds” use case.

• The extending use case is usually optional and can be triggered conditionally. In the diagram you
can see that the extending use case is triggered only for deposits over 10,000 or when the age is over
55.

• The extended (base) use case must be meaningful on its own. This means it should be
independent and must not rely on the behaviour of the extending use case.

Let’s expand our current example to show the <<extend>> relationship.

SOFTWARE CONSTRUCTION & DEVELOPMENT

 Extend relationship in use case diagrams

Although extending use case is optional most of the time it is not a must. An extending use case can
have non optional behaviour as well. This mostly happens when you’re modelling complex behaviours.

For example in an accounting system one use case might be “Add Account Ledger Entry”. This might have
extending use cases “Add Tax Ledger Entry” and “Add Payment Ledger Entry”. These are not optional but
depend on the account ledger entry. Also they have their own specific behaviour to be modelled as a
separate use case.

5. Generalization of a Use Case: This is similar to the generalization of an actor. The behaviour of the
ancestor is inherited by the descendant. This is used when there are common behaviour between two use
cases and also specialized behaviour specific to each use case.

For example in the previous banking example there might be a use case called “Pay Bills”. This can be
generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.

6. Use Case Diagram Guidelines: Although use case diagrams can be used for various purposes there are
some common guidelines to follow when drawing use case diagrams. These include naming standards,
directions of arrows, placing of use cases, usage of system boxes and also proper usage of relationships. It is
important to remember that these are guidelines and not rules. It is alright to deviate if it improves the
overall quality of the diagram.

Guidelines about Actor:

• Give meaningful business relevant names for actors – For example if your use case interacts with
an outside organization it is much better to name it with the function rather than the organization
name. (Eg: Airline Company is better than PanAir)

• Primary actors should be to the left side of the diagram – This enables you to quickly highlight
the important roles in the system.

SOFTWARE CONSTRUCTION & DEVELOPMENT

• Actors model roles (not positions) – In a hotel both the front office executive and shift manager
can make reservations. So something like “Reservation Agent” should be used for actor name to
highlight the role.

• External systems are actors – If your use case is send email and if interacts with the
email management software then the software is an actor to that particular use case.

• Actors don’t interact with other actors – In case actors interact within a system you need to create
a new use case diagram with the system in the previous diagram represented as an actor.

• Place inheriting actors below the parent actor – This is to make it more readable and to
quickly highlight the use cases specific for that actor.

Some things to consider when creating the actor element in use cases

Guidelines about Use Cases:

• Names begin with a verb – A use case models an action so the name should begin with a verb.

• Make the name descriptive – This is to give more information for others who are looking at
the diagram. For example “Print Invoice” is better than “Print”.

• Highlight the logical order – For example if you’re analysing a bank customer typical use cases
include open account, deposit and withdraw. Showing them in the logical order makes more sense.

• Place included use cases to the right of the invoking use case – This is done to improve
readability and add clarity.

• Place inheriting use case below parent use case – Again this is done to improve the readability
of the diagram.

SOFTWARE CONSTRUCTION & DEVELOPMENT

 Few things to consider when drawing use cases

Guidelines about Relationships

• Arrow points to the base use case when using <<extend>>

• <<extend>> can have optional extension conditions
• Arrow points to the included use case when using <<include>>
• Both <<extend>> and <<include>> are shown as dashed arrows.
• Actor and use case relationship doesn’t show arrows

Guidelines about Systems / Packages

• Use them sparingly and only when necessary

• Give meaningful and descriptive names to these

SOFTWARE CONSTRUCTION & DEVELOPMENT

 LAB TASK
[Total Marks = 10]

Case Study
Hurry's require a new point of sale and stock control system for their many stores throughout the UK to
replace their ageing mini based systems.

A sales assistant will be able to process an order by entering product numbers and required quantities into
the system. The system will display a description, price and available stock. In-stock products will normally
be collected immediately by the customer from the store but may be selected for delivery to the customer's
home address for which there will be a charge. If stock is not available the sales assistant will be able to
create a backorder for the product from a regional warehouse. The products will then either be delivered
direct from the regional warehouse to the customer's home address or to the store for collection by the
customer. The system will allow products to be paid for by cash or credit card. Credit card transactions will
be validated via an online card transaction system. The system will produce a receipt. Order details for in-
stock products will be printed in the warehouse including the bin reference, quantity, product number and
description. These will be collected by the sales assistant and given to the customer. The sales assistant will
be able to make refunds, provided a valid receipt is produced. The sales assistant will also be able to check
stock and pricing without creating an order and progress orders that have been created for delivery.

The store manager will be able at any time to print a summary report of sales in the store for a given period,
including assignment of sales to sales assistants in order to calculate weekly sales bonuses.

The stock manager will be able to monitor stock levels and weekly run-rates in order to set minimum stock
levels and requisition products which fall below the minimum stock levels or for which demand is
anticipated. When the stock arrives it will be booked in by the warehouse person. Stock that has been
backordered for collection from the store is held in a separate area and the store manager advised of its
arrival.

The catalogue of available products will be maintained remotely by marketing from head office. Marketing
will also be able to access sales information from each store system.

SOFTWARE CONSTRUCTION & DEVELOPMENT

Lab Task 2.1 [2]
Enlist all the possible Actors in the above scenario.
Primary Actors:
1. Sales assistant
2. Stock Manger
3. Store Manager
4. Head Office
5. Warehouse Person
6. Marketing Person
Secondary Actor:
Customer

Lab Task 2.2 [2]

Enlist all the possible Use Cases in the above scenario.

1. Process Order
2. Progress Order
3. Check Price
4. Check Stock
5. Handle Return
6. Manage Stock Level
7. Get Sales Information
8. Maintain Catalog
9. Accept New Stock
10. Print Sales Report
11. Access Sales Information

Lab Task 2.3 [6]

Draw the detailed use-case diagram of the above requirement specifications.