Use cases, user stories and business

rules

11/24/20
11/24/20
 An accurate understanding of users’ requirement is a
A software Idea prerequisite to the design and implementation of
software.

How am I going to explain this

idea to my development team?

11/24/20
 Communicating design ideas in team environment?
• If the software is large scale, employing perhaps dozens of developers over several
years, it is important that all members of the development team communicate using
a common language.

• This isn’t meant to imply that they all need to be fluent in English or Python or any
other programming language, but it does mean that they need to be able to
describe their software’s operation and design to another person.

• That is, the ideas in the head of say the analyst have to be conveyed to the designer
in some way so that he/she can implement that idea in code.

11/24/20
Communicating design ideas in team environment? (contd.)
• Just as mathematicians use algebra, or electronics engineers have evolved circuit
notation and theory to describe their ideas, software engineers have evolved their
own notation for describing the architecture and behaviour of software system.

• That notation is called Unified Modelling Language or UML

• UML is a general purpose modelling language to visualize a software using a
collection of diagrams

• Use cases and user stories are the two most commonly used approach to analyse,
model and communicate requirements.

11/24/20
 Use Case Diagram
Describes the basic flow of
how system works
Use case diagram is graphical
depiction of the interactions
among the elements of a
system

11/24/20
 Components of Use Case Diagrams

• System
• Actors
• Use cases
• Relationships

11/24/20
 System
• A system is whatever you are developing (e.g. website,
software component, an application..)
• Denoted by a rectangle within which the use case diagrams are
built.
• Used to define the scope of the system

11/24/20
 Actors
• An Actor is outside or external entity to the system.
• It includes all user roles that interact with the system
• It can be a:
– Human
– Peripheral device (hardware)
– External system or subsystem
– A software
• Represented by stick figure

11/24/20
 Actors (contd.)
• In the following scenario, what or who is the actor????
“A patient calls the clinic to make an appointment for a yearly
checkup. The receptionist finds the nearest empty time slot in the
appointment book and schedules the appointment for that time
slot. "

• The actor is a Patient.

11/24/20
 Types of actors

1. Primary - A user whose goals are fulfilled by the system. E.g. patient

2. Supporting - Provides a service to the system. E.g. the clinic itself

3. Offstage - A user who has an interest in the behaviour but is not primary or
supporting. E.g. government

11/24/20
 Use Cases
• Represents an action that accomplishes some sort of task within the system
• Usually, named by verb (doing something)

• Each actor must be linked to a use case, while some use cases may not be linked to
actors

• So What is the Use Case for the previous scenario of medical clinic????

• The Use Case is Make Appointment.

Make appointment

11/24/20
 Use Cases (contd.)
• The picture below is a Make Appointment use case for the medical clinic.
• The actor is a Patient. The connection between actor and use case is an association.

Make
Appointment
Use Case

patient
Actors are stick
figures. Use cases Association are lines
are ovals. that link actors to use
cases.

11/24/20
 Relationships
Types of relationships
Relationship Symbol Meaning
Association An actor is linked with a use case with no
arrow head connector
Include A use case contain common behaviour that
is common to one other use case. The
<<include>> arrow points to the common use case
Extend A different use case handle the exception
from the basic use case. The arrow points
<<extend>> from the extended to basic use case
Generalization One “thing” is more general than another
“thing”. Arrow points to the general thing.

11/24/20
 Ovals or ellipses

Stick figures

Connectors between
use-case and actors

11/24/20
 Association
1. Association
• Connection between Actor and Use Case
• It indicates that the actor and the use case communicate with one another using
messages.
Use case uses noun-phrases,
represents only one function

An actor represents a role of a System boundary  to separate the use

user that interacts with the cases that are internal to a system
system that you are modelling from the actors that are external to
the system.

11/24/20
 Include
2. Include
• Connection between two use cases

• Describes the situation in which a include use

case is executed every time with the base use
case.

• The included use case never executes alone

• Arrowhead points to the included/common use

case

11/24/20
 Extends
3. Extends
• Connection between two use cases
• Describes the situation when the base use case is executed, the extend use case
may execute some time but not always.

<<extend>>

11/24/20
 UML component – linking use case with actor (contd.)

11/24/20
 Generalization
4. Generalization
• Implies that one thing is more typical than the
other thing.

• This relationship may exist between two actors or

two use cases.

• The arrow points to the general thing.

• For example, a Part-Time Student generalizes a

Student.

11/24/20
 Generalization is used when you find two or more
use cases that have commonalities in behavior,
structure, and purpose. When this happens, you
can describe the shared parts in a new, often
abstract, use case, that is then specialized by child
use cases.

11/24/20
 Steps in drawing a use case diagram
• Identify the different actors that will interact with your system while accounting for the
inheritance property.
• List main system functions (use cases) in a column:
– Identify what the actors need from the system
– Identify the different possible interactions with the user
– Name the use cases
• Draw system boundary
• Connect actors with use cases
• Specify include and extend relationships between use cases

11/24/20
 Activity

It is Friday night and you and your friends are celebrating the end of trimester and
a successful learning journey through MIS501 Principles of Programming. You
decide to order dinner to be delivered from a new Nepalese restaurant using
Deliveroo. You had already downloaded the app on your mobile device and used it
a couple of times before, so you were reasonably familiar with how it worked. Your
friends gather around you while you peruse the menu and you decide on what you
will have for dinner, adding options to the cart as you go. You also add soft drinks to
the order and then enter your delivery address and credit card details to the app
before confirming your order. About half an hour later, Friday night dinner is
delivered to your front door and you and your friends enjoy beautiful Nepalese
cuisine, as you celebrate the end of trimester.

11/24/20
 Activity
• First analyze the scenario

• Identify the name of the system

(e.g. Deliveroo)

• Identify the actors (customer,

Nepalese restaurant)

11/24/20
 Activity

• Then, identify the use

cases

11/24/20
 Activity

• Then, consider the relationship

between use cases

11/24/20
 User Stories
• User stories are more narrative than either traditional requirements or use cases. 
• They are intended to describe what the user wants to be able to do.
• Additionally, user stories focus on the value that comes from using the system rather than a detailed specification
of what the system should do.
• The story’s details are collaboratively worked during conversations so the user story itself becomes a promise to
hold a conversation as the project progresses. User stories are intended as a means to foster collaboration.

11/24/20
 What is User Stories :
• As a <type of user>, I want <some
goal> so that <some reason>
As a Lecturer, I want to download students’ assignment
so that I can mark them offline.

11/24/20
 What is User Stories :

11/24/20
 User Story Template :

11/24/20
 Business rules
• Almost all organisations operate according to an extensive set
of policies, procedures, legislations, and industry standard.

11/24/20
 Difference Between Business Rules and Business
Requirements
• Business Rules — These are statements (or conditions) that tell a
person whether they can perform a specific action that relates to how
the business operates.  Business rules also supply the criteria and
conditions for making these decisions.
• Business Requirements — These may include what needs to be
done to enable the business rule to be implemented.  In other words, a
business requirement may not be valid if it contradicts or breaks an
existing business rule.

11/24/20
 THANK YOU

11/24/20
11/24/20