Requirement modelling

□ Use-case diagrams

Static view Architectural view

Class diagrams Package diagrams
Object diagrams Component diagrams

Users view
Use-case diagrams

Dynamic view Deployment view

Interaction diagrams Deployment diagrams
State diagrams
Activity diagrams

OOAD
73
Software Development Activities

Requirements
Analysis Design
Gathering
Design the solution /
Define requirement Define the conceptual model
software plan
specification

Implementation Integration and Test Deployment

Code the system based on Prove that the system meets
Installation and training
the design the requirements

Maintenance
Post-install review
Support docs
Active support

OOAD
74
Requirement

□ Requirements are capabilities and conditions to which the

system - and more broadly, the project - must conform

□ Requirement analysis is about describing problems

OOAD
75
Use-case diagram

□ The first step in requirement analysis is to determine use-cases of the

system
□ Use-case diagrams
■ allow to represent the functionalities of the system in the users
view
■ allow to delimit the boundary of the system

UserManagement
add user

delete user
<<use>> find user
admin

modify user

OOAD
76
User-centred design

□ The development of a system should always be centred around the needs

of users
■ Understand who are the users
■ Understand the tasks performed by the users
■ Make sure that users are involved in the decision-making process
■ Design the interface well following the needs of the user
■ Users will need to evaluate prototypes and return their comments

Cash register at the supermarket

OOAD
77
Interest of user-centred design

□ Meets the actual requirements

□ Reduce costs related to changes or maintenance
□ Allow to better define the properties in the development
□ Reduce learning time
□ Reduce training and supporting costs
□ Allow efficient use
□ Making the system more attractive and better suited to its market

OOAD
78
Determining users’ characteristics

□ Good questions
■ What are their goals?
■ How will they use the software?
■ What is their level of computer literacy?
■ What are their psychological characteristics?
■ What are their habits?

OOAD
79
Use-case diagrams

□ A use-case diagram consists of three parts

■ The system
■ The use-case
■ The actor

□ Graphical representation

« actor »

System Use-case Actor Actor

OOAD
80
System

□ The system can be any system, not only the software system
□ It defines the boundary of the system in a clear and precise manner
■ Not too ambitious
■ Only determine basic functionalities
■ Build a well defined architecture
■ Additional functionality can be added during development

“Books Online” system “Restaurant” system “Weather Service” system

OOAD
81
Use-case

□ A use-case is a typical interaction or a typical sequence of interactions

between the system and its environment
□ The objective of a use-case is to model the system
■ according to the perspective of user interacting with the system
■ to accomplish their objectives
□ A use-case may can be either large or small
□ Example: developing a tool for text processing
■ Some possible use-cases
□ Create a new document
□ Modify an existing documents
□ Delete a document
□ Input new text, …
Text processing tool

OOAD
82
Use-case

□ A use-case needs to
■ always correspond to a high level objective
■ describe the interaction between the user and the system, not the
operations that the system should perform
■ cover all the steps to follow in performing a given task
■ be written, to the possible extent, independently of the user interface
■ include only the interactions with the system

OOAD
83
Use-case

□ Objectives and interactions

■ Objectives of users: what users expect from the system
■ Interactions with the system: mechanisms to meet those objectives
■ Define the objectives then determine the interactions to achieve
objectives
■ Example
□ Objective: define the document style
□ Interactions: choose the font, choose sizes, choose the page layout,
…

OOAD
84
Use-case

□ Example: developing of an ATM system

□ Some interactions in the following scenario
■ Insert the card
■ Enter the PIN code
■ Choose the amount to be withdrawn
■ Confirm the amount
■ Take the card
■ Take the money
■ Take the receipt

□ Are all interactions use-cases?

OOAD
85
Use-case

□ Example (continue)
■ The answer is no
■ Since some interactions such as “confirm the amount” do not meet a
goal of the user
■ The goal of the user in this case is to withdraw money: this is a use-
case

OOAD
86
Actors

□ An actor is a role played by the user or an external entity during

interaction with the system
□ Who or what uses the system
□ Actors communicate with the system by sending and receiving messages
□ Example
■ Develop a system of cash register at the supermarket
□ Possible actors
■ Client
■ Cashier
■ Manager
■ Inventory manager

OOAD
87
Actors

□ Distinguishing two notions: actor and user

■ Multiple users may correspond to a single actor
□ Different cashiers play the same role in the system
■ A user may correspond to several actors
□ A user can simultaneously be a cashier and a manager in the
system

cashier and manager cashier and customer

OOAD
88
Actors

□ Questions for identifying the system actors

■ Who will use the main features of the system?
■ Who will need the support of the system to perform its tasks?
■ Who should update, administer and maintain the system?
■ Does the system interacts with other systems?
■ Who or what has interests on the results of the system?

Cash register of supermarket

identification

purchase
Cashier

refund
Customer

Manager label products

OOAD
89
Relations between the actors

□ Inheritance between actors

Client

Individual Entreprise

OOAD
90
Use-case specification

□ Typical specification of a use-case

■ Use-case: name of a use-case often begins with a verb
■ Actors: list of stakeholders concerning the use-case
■ Objective: objective of the use-case
■ Description: a brief description of treatment to achieve

□ Example
■ Use-case: purchase of products
■ Actors: Client, Cashier
■ Objective: describe a purchase of products by the customer with cash
payment
■ Description: The clients comes in the box with the selected products.
The cashier encodes products, announces the total. The customer
pays. The cashier registers the payments.

OOAD
91
Use-case specification

□ The use-case specification may add

■ the references concerning the specification of the requirement
■ the pre- and post-conditions of the use-case

□ Example
■ Use-case: purchase of products
■ Actors: Client, Cashier
■ Objective: describe a purchase of products by the customer with cash
payment
■ References: R1.2, R3.4
■ Pre-conditions: the cashier is identified and authorised
■ Post-conditions: the purchased is registered, the payment is made,
the receipt is printed
■ Description: The clients comes in the box with the selected products.
The cashier encodes products, announces the total. The customer
pays. The cashier registers the payments.

OOAD
92
Use-case specification

□ A use-case can be specified by adding scenarios

□ A scenario describes the specific actions of the actors in the system
□ A scenario consists of principal interactions and exceptional interactions
□ The actions can be divided into two flows
■ Flow of actions concerning the actors
■ Flow of actions concerning the systems
□ Example
■ A scenario for “purchase products” use-case

OOAD
93
Use-case specification

□ Principal interactions of “purchase products” scenario

Actions  of  actor Actions  of  system

• The  customer  comes  to  the  cash  desk  with  

the  products  to  buy

• The  cashier  encodes  the  identifier  of  each   • The  cash  desk  displays  the  description  and  
product   price  of  the  product  
If  a  product  has  more  than  one  item,  the   This  number  is  displayed
cashier  inputs  the  number  of  items
• After  having  encoded  all  of  the  products,  the   • The  cash  desk  calculates  and  displays  the  
cashier  signals  the  end  of  the  purchase total  amount  that  the  customer  has  to  pay
• The  cashier  announces  the  total  amount  to  
the  customer
• The  customer  pays

• The  cashier  input  the  amount  of  money  paid   • The  cash  desk  displays  the  balance
by  the  customer

OOAD
94
Use-case specification

□ Principal interactions of “purchase products” scenario (continue)

Actions  of  actor Actions  of  system

• The  cash  desk  prints  the  receipt

• The  cashier  gives  change  to  the  customer   • The  cash  desk  saves  the  purchase
and  the  receipt
• The  customer  leaves  the  cash  desk  with  the  
bought  products

□ Exceptional interactions of “purchase products” scenario

Actions  of  actor Actions  of  system

• The  product  identifier  is  not  correct,  the  

system  displays  the  error

• The  customer  doesn’t  have  enough  money.  

The  cashier  cancel  the  purchase

OOAD
95
Use-case specification

□ Remarks
■ The use-case’s specification format is only a proposal. Therefore, it is
not strict
■ The interactions are described in more detail for important use-cases
■ Use-case’s interaction can also be described using activity diagram,
state diagram or interaction diagram

Use-case’s interactions described in activity diagram

OOAD
96
Use-cases identification techniques

□ Software Developer write requirements specification themselves

■ Lack of human reactions (future users of the system)

□ Interview

User interview User interview

OOAD
97
Use-cases identification techniques

□ Workshop (Organise meetings)

■ Meeting of all the concerned people of the system to be developed
□ Customers, Users, Software developers
□ Everyone gives their ideas
■ List all the possible actors, use-cases
■ Analyse and describe briefly each use-case Workshop
□ Model the use-cases and actors

■ Remarks
□ Don’t try to search for all the use-cases
■ Other use-cases can appear in the development process
OOAD
98
Relationships between use-cases

□ Two types of relationship between use-cases

■ Extension
■ Inclusion

□ “extension” relationship
■ Used to specify the optional interactions
□ These are exceptional cases
■ The case where a use-case is similar to another but it includes
additional actions
■ The extending use-case must list all the actions in the main use-case
and also the supplementary actions

OOAD
99
Relationships between use-cases

□ “extension” relationship
■ Example: “purchase product with payment by credit card” use-case
□ Use-case: purchase products
□ Actors: Customer, Cashier
□ Objective: describe a purchase of
products by the customer with
payment by credit card
□ Description: The customer comes
to checkout with selected products.
The cashier encodes products, announces the total amount. The
customer gives his credit card. The cashier inserts the credit card
into the system. The customer types the PIN code. The system
verifies the card and then deducts the total of the card.

■ This use-case is a variation of the “purchase products” use-case but

adds actions relating to the use of credit card.

OOAD
100
Relationships between use-cases

□ “extension” relationship
■ “Purchase products with credit card payment” use-case is an extension
of the “Purchase products” use-case
■ Notation

<< extends >>

Purchase products with
Purchase products
credit card payment

extension

■ Remarks: If a use-case is associated with an actor, all extensions are

also associated with this actor. This is expressed implicitly in the use-
case diagrams.

OOAD
101
Relationships between use-cases

□ “inclusion” relationship
■ describes a series of joint actions in several cases of different usages
■ if several use-cases share the same sequence of actions and this
common part is intended to meet a clearly defined goal then the part
is described in a separate use-case
■ helps to avoid repeating the same details in different use-cases

OOAD
102
Relationships between use-cases

■ Example of “inclusion” relationship

□ Suppose we have two use-cases “purchase product” and “purchase
products with credit card payment”
■ Both use-cases have the same sequence of actions of encoding
products that can be described by the “encode products” use-
case

Actions  of  actor Actions  of  system

• The  customer  comes  to  the  cash  desk  with  
the  products  to  buy
• The  cashier  encodes  the  identifier  of  each   • The  cash  desk  displays  the  description  and  
product   price  of  the  product  
If  a  product  has  more  than  one  item,  the   This  number  is  displayed
cashier  inputs  the  number  of  items

• After  having  encoded  all  of  the  products,  the   • The  cash  desk  calculates  and  displays  the  
cashier  signals  the  end  of  the  purchase total  amount  that  the  customer  has  to  pay
• The  cashier  announces  the  total  amount  to  
the  customer

actions of encoding products

OOAD
103
Relationships between use-cases

□ “inclusion” relationship
■ Example (continue)
□ “encode products” use-case
■ Use-case: encode products
■ Actor: Customer, Cashier
■ Objective: describe the encoding of the products bought by a
customer
■ Description: The customer comes to checkout with the selected
products. The cashier encodes products, announces the total
amount to the customer.
□ Notation

Purchase products << includes >>

Encode products
<< includes >>

Purchase products with

credit card payment
inclusion

OOAD
104
Building use-case diagrams

□ A use-case diagram describes the relationships between the use-cases

and actors of the system

□ The steps to build a use-case diagram

■ Define the limits of the system
■ Identify the actors
■ Identify the use-cases
■ Define the relationships between use-cases
■ Verify the diagrams
Cash register of supermarket

identification

purchase
Cashier

refund
Customer

Manager label products

OOAD
105
Classification of use-cases

□ Assign the use-cases to iterations of development process

iteration 1 iteration 2 cycle 3 …

A B D

Use-case

□ How to assign use-cases to iterations of development process?

■ Use-cases should be implemented in the order of importance. For
example:
□ Use-cases that may contain risks
□ Use-cases that build the architecture of the software
□ Use-cases that realise a large part of the system functionality
□ Use-cases that require new technology or significant research
□ Use-cases that have great interests by the customer

OOAD
106