Requirements Engineering

Prepared by: Dr Atiya

Welcome!!
Lecture 4
 Topics covered
 Use Case Diagram
 Activity Diagram

3
UML
the Language
 UML Views

Static View
Class Diagram

Dynamic View
Functional View Sequence Diagram
Use Case Diagram Collaboration Diagram
Activity Diagram State Chart Diagram
 use case view
 Use cases are logical models -- they describe the activities of a sys-
tem without specifying how the activities are implemented.
The use case view / diagram
 Actor Rules
1. Place Your Primary Actor(S) In the Top-Left
Corner Of The Diagram

2. Draw Actors to The Outside of A Use Case

Diagram

3. Name Actors with Singular, Business-Rele-

vant Nouns

4. Associate Each Actor with One Or More Use

Cases

5. Actors Model Roles (Customer), Not Posi-

tions (the name of person, Jenifer)

6. Use <<system>> to Indicate System Actors

7. Actors Do not Interact With One Another

 Active/Passive
 Actors  in situation where two or more actors are associ-
ated with a use case, one of them must initiate the actions
and the other(s) will play a passive role
 Use case
 This behavior (action) is what the system does when re-
sponding to the events that arise from its interaction with
a set of actors
 How we identify use cases
 What are main task performed by each actor?
 Will the actor read or update any information in the sys-
tem?
Stepping from the problem to its solution

 the system boundary: what is in scope and out of the

scope of the system?

 the system boundary is an important conceptual line

that separates what we are interested in from the rest of
the world.
Example
 Example
An automated teller machine (ATM) or the automatic banking machine (ABM) is banking subsystem
that provides bank customers with access to financial transactions in a public space without the need
for a cashier, clerk or bank teller.
Customer uses bank ATM to check balances of his/her bank accounts, deposit funds, withdraw
cash and/or transfer funds . ATM Technician provides maintenance and repairs. All these use cases
also involve Bank actor whether it is related to customer transactions or to the ATM servicing.
Modeling the relationships between use cases
Modeling the relationships between use cases
Example3
The Use-Case Diagram for Appointment System

Individual patient executes

the make Appointment use
case as many times as they
wish and that it is possible
for the Make Appointment
use case appointment to be
executed by many different
patients.

Slide 24
 Use-Case Diagram with Specialized Actor

The specialized actor will

Three primary use cases: inherit the behavior of the
Make Appointment, Pro- more general actor and ex-
duce Schedule Information, tend it in some way
and Record Available

Slide 25
 Extend and Include Relationships

1
Include additional
functionality 2
Single use case con-
tains common func-
tions that are used by
other use cases

3
Use a include relationship to sim-
plify the individual use cases
Slide 26
User Model view or Functional View
Use Case Modeling: Core El-
ements
Use Case Modeling: Core Rela-
tionships

<<extend>>
User Model view or Functional View
Use Case Modeling: Core Rela-
tionships (cont’d)

<<include>>
Example
Example
Relationship
Example
 Example
 Company has several holiday homes in their possession and it rents them to employees. Com-
pany wants an information system that would allow room reservation on the net.

Employee will be able to reserve a room in desired holiday home for himself and his family
members. Besides he can review his reservations and be able to cancel them.

Holiday home manager will be able to do same things as employee - manager will be able to
add new reservation (ie. for people that doesn't have access to the net and would like to re-
serve by phone), review reservations and cancel any reservation. Manager will also be able to
edit info about particular holiday home.

Administrator will have the same access as the manager and he is responsible to add and edit
Reservation data.
Everyone must log into the system before they can use it
 Class Exercise
 Create use case diagram for the following system. A Book Store (ABS) runs a series of fairly stan-
dard Libraries. Before a book can be put on the shelf, store staff must be cataloged and entered into
the book database. Every customer must have a valid ABS customer card in order to rent a book.
Customers rent books for three days at a time. Every time a customer rents a book, the system must
ensure that they do not have any overdue books. If so, the overdue books must be returned and an
overdue fee paid before customer can rent more books. Likewise, if the customer has returned
overdue books, but has not paid the overdue fee, the fee must be paid before new books can be
rented. Every morning, the store manager prints a report that lists overdue books before this he must
sort overdue book records. If a book is two or more days overdue, the manager calls the customer to
remind them to return the book. If a book is returned in damaged condition, the manager removes it
from the book database and may sometimes charge the customer.
Major use cases are listed by actor:
 
Book store staff
1. Catalogue book
2. Enter book into database
3. Put book on shelf

Customer
1. Obtain an account
2. Rent a book
3. Check for overdue books
4. Receive overdue books
5. Receive overdue book fine
  
Store manager
1. Print overdue book list (daily)
a. Sort overdue book records/items by length of time overdue
b. Print list
2. Call overdue book clients (two or more days late)
3. Deal with damaged book
a. Inspect books upon return
b. Remove damaged books from database
c. Prepare customer damage charges (rules not specified)
 
 
 
 Use case Narrative
• Based on the purpose of the use case and the amount of
information that the use case contains:
• Overview versus detail
– Used to enable the analyst and user to agree on a high-level overview of the requirements.
– Created very early in the purpose of understanding the system requirements, and they only document
basic information about the use case.
– A detail use case typically documents all of the information needed for the use case once the user and
the analyst agree upon a high-level overview of the requirements .

• Essential versus real

– Essential use case is one that describes the minimum essential issues necessary to understand the
required functionality
– A real use case will go further and describe a specific set of steps (detailed descriptions of how to use
the system once it is implemented)
 Overview information
 Provide the basic background information about the use case
 Use case name; should be a verb-noun phase (e.g. make appointment)
 Use case type; either overview or detail and essential or real
 Primary actor; is usually the trigger of the use case – the person or thing that
starts the execution of the use case.
 Brief description; single sentence that describe the essence of the use case.
 Preconditions: This describes what must be true at the outset of the use case.
It can relate to conditions within the system or also conditions outside of the
system under study. For example, when withdrawing money from an ATM
from a specific bank, the customer must be an existing customer of the bank.

Slide 46
 Basic Flow Of Events (aka Happy Path or Basic path)
 This is the ‘guts’ of the use case and describes the sequence of
user to system interactions and related system behavior or rules. It
is commonly referred to the primary scenario or happy path which
indicates what happens where everything is straightforward with no
complications. This is discussed later in this article along with alter-
nate flows.
 Alternative Flows
 These describe variations when things don’t follow the ‘happy path’.
This may be because it is a valid variation or it may be an exception
where an error occurs which prevents the actor from achieving their
goal.
 Postconditions
 These are things that are true at the conclusion of a use case. Tra-
ditionally, these identify things that are always true regardless of
what path is taken through the use case.
Use Case Name: ID:
Primary Actor: Use Case Type:

Brief Description:

Precondition:

Normal Flow of Events:

Alternate/Exceptional Flows:

Postcondition
 Activity Diagrams
 Each use case represent a task consists of a number of actions to complete the task.
 An activity diagram  used to model the coordination and sequencing of actions in order to achieve a
given purpose

 Before any prototyping of interfaces, the developer needs to identify the appropri-
ate interfaces from users’ requirements and determine where and when they will
be needed. One way to achieve this goal is to use an activity diagram.
 Make a Phone Call
Initial state

transition

Receive Phone
number Activity/action

Dial Number

Establish Con-
nection
Final State
 Make a Phone Call
Initial state

transition

Receive Phone
number

Dial Number
Guard
[callee busy]
Send busy tone
[callee not busy]

Establish Con-
nection
 Make a Cup of Coffee

Boil Water
Enter in a kitchen

Pour Water
Get Cup

Add coffee Add milk

Fill Kettle Drink Coffee

 Make a Cup of Coffee

Add Coffee
Enter in a kitchen

Pour Water
Fill Kettle

Boil Water Add milk

Get Cup Drink Coffee

Activity Diagrams
 Fork and Join
 Allow parallel and concurrent processes to be modeled
 Fork node – to split the behavior in to multiple concurrent flows
 Join node – brings back the separate parallel flows in to a single flow

Slide 58
 Example: Activity Diagram

Decision
Select Course Activity/Action
Concurrent
Threads
]
[ add course ]
Synchronization
Bar (Fork)

Guard Check Check

Schedule Pre-requisites
Condition

Synchronization
Bar (Join)
[ checks completed ] [ checks failed ]

Assign to Resolve Transition

Course Conflicts

Update
Schedule
 Class Test
 ATM Transaction

Perform Transaction

Slide 60
 ADD
 If password wrong
 If User want another transaction.

Slide 61
Slide 62
Guidelines for Creating Activity Diagrams
1. Since an activity diagram can be used to model any
kind of process, you should set the context or scope of
the activity being modeled. Once you have determined
the scope, you should give the diagram an appropriate
title.
2. You must identify the activities, control flows, that
occur between the activities.
3. You should identify any decisions that are part of the
process being modeled.
4. You should attempt to identify any prospects for paral-
lelism in the process.
5. You should draw the activity diagram.

Slide 63
 Why use Activity Diagram

1. Help investigate the flow of control from one activity to another.

2. Help in understanding the basic behavior of a system.
3. Can be used to model concurrent systems.
4. Can record scenarios of use cases.
 Activity Diagram Exercise
Assume that a university allows its students to do on-line quizzes, draw an activity dia-
gram for this process if you know:
 The student should sign in with a special password before doing the quiz.
 The quiz has 2 parts, and the student could solve any part before the other.
 When the student finishes the 2 parts, he/she should press “Submit” button.
 If a student fails on the quiz, he/she could solve a bonus question to help him/her.
 Partitions (Swimlanes)
 The contents of an activity diagram may be organized into partitions using solid vertical
lines. Only used to simplify the understanding of an activity diagram.

Slide 66
 Swimlane
Develop an activity diagram based on the following narrative. The purpose of the Open Access Insur-
ance System is to provide automotive insurance to car owners. Initially, prospective customers fill out an
insurance application, which provides information about the customer and his or her vehicles. This in-
formation is sent to an agent, who start process and sends it to various insurance companies for creating
quotes for insurance. When the responses return, the agent then determines the best policy for the type
and level of coverage desired and gives the customer a copy of the insurance policy proposal and quote.
 
SWIMLANES

Slide 68
Create an activity diagram based on the following narrative. The purchasing department handles
purchase requests from other departments in the company. People in the company who initiate the ori-
ginal purchase request are the "customers" of the purchasing department. A case worker within the
purchasing department receives that request and monitors it until it is ordered and received. Case work-
ers process the requests for purchasing products under $1,500, write a purchase order, and then send it
to the approved vendor. Purchase requests over $1,500 must first be sent out for a bid from the vendor
that supplies the product. When the bids return, the case worker selects one bid. Then, the case worker
writes a purchase order and sends it to the approved vendor.
 User Stories
 User requirements are expressed as user stories or scenarios.
 These are written on cards and the development team break them
down into implementation tasks. These tasks are the basis of
schedule and cost estimates.
 The customer chooses the stories for inclusion in the next release
based on their priorities and the schedule estimates.
User Stories
Product Backlog
Wish List

Collection of user stories

How to choose?
 online store
 In agile software development, user stories are specifically written
from an end-user perspective, describing the type of user, what they
want, and why they want it.
 The Anatomy of a User Story
 There are two essential parts to a user story - a feature and a set of
acceptance criteria.

 The Feature
 The feature represents the product increment. It should be written
in this format: “As a <who>, I need to <what> so that <why>.” 
 For example: “As an online customer, I need to search for products,
so that I can find the ones I want to buy.”
 The Acceptance Criteria
 While the feature is written from the user’s point of view, the accep-
tance criteria is written from the product’s point of view.
 Referring back to the above example: “As an online customer, I need
to search for products, so that I can find the ones I want to buy,” you
might list acceptance criteria like:
1. Search for a product by name or category
2. View products by category
3. View images and details for each product
4. Add to cart from the detail or search pages
User Stories
Thank you