SAD - Ch4 - Requirements Modeling
SAD - Ch4 - Requirements Modeling
SAD - Ch4 - Requirements Modeling
Requirements
Analysis Design
Gathering
Define the conceptual Design the solution /
Define requirement
model software plan
specification
Maintenance
Post-install review
Support docs
Active support
3
Requirement
• The systems development process transforms the existing (as is) system
into the proposed (to be) system
• Requirements determination
• The single most critical step of the entire SDLC
• Changes can be made easily in this stage
• Most (>50%) system failures are due to problems with requirements
• The iterative process of OOSAD is effective because:
• Small batches of requirements can be identified and implemented incrementally
• The system will evolve over time
Requirements Determination
• Purpose: to convert high level business requirements (from the system
request) into detailed requirements that can be used as inputs for
creating models
• What is a requirement?
• A statement of what the system must do or a characteristic it must have
• Will later evolve into a technical description of how the system will be
implemented
• Types:
• Functional: relates to a process or data
• Non-functional: relates to performance or usability
Nonfunctional Requirements
Requirement type Example
Operational • The system should be able to fit in a pocket or purse
• The system should be able to integrate with the existing inventory system.
Performance • Any interaction between the user and the system should not exceed 2
seconds.
• The system should receive updated inventory information every 15 minutes.
Security • Only direct managers can see personnel records of staff
• Customers can see their order history only during business hours.
Cultural & Political • The system should be able to distinguish between United States and European
currency
• The system shall comply with insurance industry standards.
Requirements Definition
• Functional & non-functional requirements listed in outline format
• May be prioritized
• Provides information needed in subsequent workflows
• Defines the scope of the system
Determining Requirements
How
High-level: can order
Very general processing be
improved?
Users view
Use-case diagrams
UserManagement
add user
delete user
<<include>> find user
admin
modify user
33
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
34
Interest of user-centred design
35
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?
36
Use-case diagrams
• Graphical representation
« actor »
37
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
39
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
40
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, …
41
Use-case
42
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
43
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
44
Actors
purchase
Cashier
refund
Customer
Manager label products
46
Relations between the actors
Client
Individual Enterprise
47
Use-case specification
• Example
• Use-case: purchase products
• Actors: Client, Cashier
• Objective: describe a purchase of products by the customer with cash payment
• Description: The client comes in the box with the selected products. The cashier encodes
products, announces the total. The customer pays. The cashier registers the payment.
48
Use-case specification
• Example
• Use-case: purchase 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 purchase 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.
49
Use-case specification
50
Use-case specification
• Main interactions of “purchase products” scenario
8. The cashier input the amount of money paid by the 9. The cash desk displays the balance
customer
51
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
53
Use-cases identification techniques
• Interview
54
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 Workshop
• Analyse and describe briefly each use-case
• 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
55
Relationships between use-cases
• “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
56
Relationships between use-cases
• “extension” relationship
• Example: “purchase product with payment by credit card” use-case
• Use-case: purchase product with payment by credit card
• 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.
57
Relationships between use-cases
• “extension” relationship
• “Purchase products with credit card payment” use-case is an extension of the “Purchase
products” use-case
• Notation
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.
58
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
59
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
• “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 << include >>
Encode products
<< include >>
• 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
62
Classification of use-cases
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
63
Example
• An automated teller machine (ATM) is a 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/VISA ATM to Check Balances of his/her bank accounts,
Deposit Funds, Withdraw Cash and/or Put money
• On most bank ATMs, the customer is authenticated by inserting a plastic ATM card and
entering a personal identification number (PIN).
• Operator need to regularly put money into the machine, get checks, get cards
• Identify actors, use cases, and use case diagrams
Example
• Actors
• Bankcard (Người có thẻ ngân hàng )
• VISAcard (Người có thẻ VISA)
• Operator (Người vận hành máy)
• VISA (Hệ thống VISA)
• Bank (Hệ thống thông tin ngân hàng)
Example
• Use-cases
• withdraw by bankcard (Rút tiền với thẻ ngân hàng)
• withdraw by VISAcard (Rút tiền với thẻ VISA)
• Identify (Kiểm tra mã PIN)
• Balance (Xem số tiền còn trong tài khoản )
• Deposit (Bỏ tiền vào tài khoản bằng ngân phiếu hoặc tiền mặt )
• put money (Nạp tiền vào máy )
• get cards (Lấy thẻ bị nuốt trong máy )
• get checks (Lấy ngân phiếu trong máy )
Example
balance
bankcard bank
deposit
<<include>>
<<extend>> identify
deposit by check deposit by cash
Example
put money
get cards
operator
get checks
Project
• Divide groups of 4-5 students
• Each group chooses a problem
• Guide students through the steps of project
• Describe the problem requirement
Project (2)
• Divide groups of 4-5 students
• Each group chooses a problem
• Building use case diagrams: Choose one of the following tools:
• Microsoft Visio (2007 -2016)
• StarUML: http://staruml.io/
• Argo UML: https://argouml.jaleco.com/
• Lucidchart: https://www.lucidchart.com/pages/examples/uml_diagram_tool