View
220
Download
0
Category
Preview:
Citation preview
8/14/2019 Sesi-6-From BM to ReqSpec
1/89
1
Business Modelingand Requirements
Perancangan Sistem Informasi 2008
Petrus Mursanto (santo@cs.ui.ac.id)
Dana Indra Sensuse (dana@cs.ui.ac.id)
Indra Budi (indra@cs.ui.ac.id)
Overview
mailto:santo@cs.ui.ac.idmailto:dana@cs.ui.ac.idmailto:indra@cs.ui.ac.idmailto:indra@cs.ui.ac.idmailto:dana@cs.ui.ac.idmailto:santo@cs.ui.ac.id8/14/2019 Sesi-6-From BM to ReqSpec
2/89
2
Tujuan :
Memahami peran software terhadapproses bisnis customers.
Mengumpulkan permasalahan dansolusi yang bisa ditawarkan dengan IT.
Menentukan fitur apa saja yang adadalam sistem.
Menuangkan features ke dalamkebutuhan fungsional dan non-fungsional sistem.
8/14/2019 Sesi-6-From BM to ReqSpec
3/89
3
The Problem Domain
Users +other Stakeholders
Stakeholders: anyone who could be
materially affected by the
implementation of a new system or
application.
Challenge: understandthe problem to be solved
Needs
8/14/2019 Sesi-6-From BM to ReqSpec
4/89
4
Moving Toward the Solution Domain 1
NeedsProblem
Domain
Features: a service that the system
provides to fulfill one or more stakeholderneeds.
FEATURES
The system will prevent intruders
The system will have automatic backup Web-enabled entry for sales orders
Examples:
8/14/2019 Sesi-6-From BM to ReqSpec
5/89
5
Moving Toward the Solution Domain 2
NeedsProblem
Domain
FEATURES
Software
Requirements
Solution Dom
ain
FunctionalNon-Functional Use CaseURPS+
8/14/2019 Sesi-6-From BM to ReqSpec
6/89
6
Problem/Solution Domains
Problem space
Stakeholder Request: Diperlukan mekanisme pelaporan yang
real time dan komprehensif tentang data statistik pasien.
Solution space
FEATURES:
Sistem mampu mendeteksi kekurangan obat yang dalam waktu
dekat akan habis/kedaluwarsa Sistem mampu menampilkan data rekam medis pasien yang
paling up to date Sistem mampu menyajikan laporan tingkat hunian dan data
statistik pasien dan alokasi dokter unit layanan
RUMAH SAKIT
8/14/2019 Sesi-6-From BM to ReqSpec
7/89
7
Problem/Solution Domains
Solution space
USE CASE:
- Mengupdate data rekam medis pasien
- Melihat informasi ketersediaan layanan RS- Melihat informasi ketersediaan kamar, dokter dan spesialist
- Melihat informasi tagihan
SUPPLEMENTARY:- Response time pelayanan informasi tidak lebih dari 1 menit
- Kompilasi data statistik real-time maximum 1 menit.
8/14/2019 Sesi-6-From BM to ReqSpec
8/89
8
HOSPITAL
Unit Rekam Medis
Use Case Defines System Boundaries
RM
ApplicationPetugas RM
Petugas Medis
Pasien
Keluarga karyawan
Goal: Mengupdate data pasien
Goal: Memeriksa pasien
Goal:Berobat jalan
Goal: Menjalani rawat inap
8/14/2019 Sesi-6-From BM to ReqSpec
9/89
9
Requirement TracebilityStakeholder request
document
Vision document
Software Requirement
Specification
Document
Use Case
Specification
Document
Supplementary
document
8/14/2019 Sesi-6-From BM to ReqSpec
10/89
10
Requirement Pyramid
Stakeholder need: a requirement froma stakeholder
Feature: a service provided by thesystem, usually formulated by abusiness analyst; a
purpose of a feature is to fulfill a
stakeholder need Use case: a description of system
behavior in terms of sequences ofactions
Supplementary requirement: anotherrequirement (usually nonfunctional)that cannot be captured in use cases
Test case: a specification of testinputs, execution conditions, andexpected results
Scenario: a specific sequence ofactions; a specific path through a usecase
8/14/2019 Sesi-6-From BM to ReqSpec
11/89
11
Good Requirement
Unambiguous Testable (verifiable) Clear (concise, terse, simple, precise)
Correct Understandable Feasible (realistic, possible) Independent Atomic Necessary Implementation-free (abstract)
8/14/2019 Sesi-6-From BM to ReqSpec
12/89
12
Unambigous
REQ1 The system shall be implemented using ASP.
Does ASP mean Active Server Pages or Application
Service Provider? To fix this, we can mention a fullname and provide an acronym in parentheses:
REQ1 The system shall be implemented usingActive Server Pages (ASP).
8/14/2019 Sesi-6-From BM to ReqSpec
13/89
13
Unambigous
REQ1 The system shall not accept passwords longer than 15characters.
It is not clear what the system is supposed to do:
The system shall not let the user enter more than 15 characters. The system shall truncate the entered string to 15 characters. The system shall display an error message if the user enters
more than 15 characters.
REQ1 The system shall not accept passwords longer than 15characters. If the user enters more than 15 characters whilechoosing the password, an error message shall ask the user tocorrect it.
8/14/2019 Sesi-6-From BM to ReqSpec
14/89
14
testable
REQ1 The search facility should allow the user to find a reservation based onLast Name, Date, etc.
In this requirement, all search criteria should be explicitly listed. The designerand developer cannot guess what the user means by etc. Other problems can be introduced by ambiguous words or phrasing:
Modifying phrases: as appropriate, as required, if necessary, shall be considered Vague words: manage, handle Passive voice: the subject of the sentence receives the action of the verb rather than
performing it
REQ1 The airport code shall be entered by the user. REQ2 The airport code shall be entered.
Indefinite pronouns: few, many, most, much, several, any, anybody, anything,some, somebody, someone, etc.
REQ1 The system shall resist concurrent usage by many users.
8/14/2019 Sesi-6-From BM to ReqSpec
15/89
15
Clear (Concise, Terse, Simple,
Precise)
REQ1 Sometimes the user will enter Airport Code,
which the system will understand, but sometimes
the closest city may replace it, so the user does not
need to know what the airport code is, and it will stillbe understood by the system.
This sentence may be replaced by a simpler one:
REQ1 The system shall identify the airport based on
either an Airport Code or a City Name.
8/14/2019 Sesi-6-From BM to ReqSpec
16/89
16
Correct
REQ1 Car rental prices shall show all
applicable taxes (including 6% state tax).
8/14/2019 Sesi-6-From BM to ReqSpec
17/89
17
Understandable
Requirements should be grammatically
correct and written in a consistent style.
Standard conventions should be used. The
word shall should be used instead of will,
must, or may.
8/14/2019 Sesi-6-From BM to ReqSpec
18/89
18
Feasible (Realistic, Possible)
The requirement should be doable within
existing constraints such as time, money, and
available resources:
REQ1 The system shall have a natural
language interface that will understand
commands given in English language.
This requirement may be not feasible within ashort span of development time.
8/14/2019 Sesi-6-From BM to ReqSpec
19/89
19
Independent
To understand the requirement, there shouldnot be a need to know any other requirement: REQ1 The list of available flights shall include
flight numbers, departure arrival time for every legof a flight.
REQ2 It should be sorted by price.
The word It in the second sentence refers to
the previous requirement. However, order ofthe requirements changes, this requirementwill not be understandable.
8/14/2019 Sesi-6-From BM to ReqSpec
20/89
20
Atomic
The requirement should contain a single traceable
element: REQ1 The system shall provide the opportunity to book the
flight, purchase a ticket, reserve a hotel room, reserve acar, and provide information about attractions.
This requirement combines five atomic
requirements, which makes traceability very difficult.
Sentences including the words and or but shouldbe reviewed to see if they can be broken into atomic
requirements.
8/14/2019 Sesi-6-From BM to ReqSpec
21/89
21
Necessary
A requirement is unnecessary if None of the stakeholders needs the requirement,
or
Removing the requirement will not affect the
system.
REQ1 All requirements specified in the Visiondocument shall be implemented and tested.
8/14/2019 Sesi-6-From BM to ReqSpec
22/89
22
Implementation-free (Abstract)
Requirements should not contain
unnecessary design and implementation
information: REQ1 Content information shall be stored in a
text file.
How the information is stored is transparent
to the user and should be the designers orarchitects decision.
8/14/2019 Sesi-6-From BM to ReqSpec
23/89
23
Consistent
There should not be any conflicts between
the requirements. Conflicts may be direct or
indirect. Direct conflicts occur when, in the
same situation, different behavior isexpected: REQ1 Dates shall be displayed in the mm/dd/yyyy
format. REQ2 Dates shall be displayed in the dd/mm/yyyy
format.
8/14/2019 Sesi-6-From BM to ReqSpec
24/89
24
Consistent
REQ1 For users in the U.S., dates shall be
displayed in the mm/dd/yyyy format.
REQ2 For users in France, dates shall be
displayed in the dd/mm/yyyy format. This can eventually lead to the following
requirement:
REQ3 Dates shall be displayed based on theformat defined in the users web browser.
8/14/2019 Sesi-6-From BM to ReqSpec
25/89
25
Consistent
Indirect conflict occurs when requirements do not describe thesame functionality, but it is not possible to fulfill bothrequirements at the same time: REQ1 System should have a natural language interface. REQ2 System shall be developed in three months.
Some requirements do not conflict, but they use inconsistentterminology: REQ1 For outbound and inbound flights, the user shall be able to
compare flight prices from other, nearby airports.
REQ2 The outbound and return flights shall be sorted by thesmallest number of stops. To describe the same concept, in the first requirement the term
inbound flights is used, and in the second requirement the termreturn flights is used. The usage should be consistent.
8/14/2019 Sesi-6-From BM to ReqSpec
26/89
26
Nonredundant
Each requirement should be expressed onlyonce and should not overlap with anotherrequirement:
REQ1 A calendar shall be available to help withentering the flight date.
REQ2 The system shall display a pop-upcalendar when entering any date.
The first requirement (related to only the flightdate) is a subset of the second one (relatedto any date entered by the user).
8/14/2019 Sesi-6-From BM to ReqSpec
27/89
27
Complete
A requirement should be specified for all
conditions that can occur: REQ1 A destination country does not need to be
displayed for flights within the U.S.
REQ2 For overseas flights, the system shall
display a destination country.
What about flights to Canada and Mexico?They are neither within the U.S. nor
overseas.
8/14/2019 Sesi-6-From BM to ReqSpec
28/89
28
Each Individual Requirement
Should Be :
Necessary: If the system can meet prioritized real needs without the requirement, it isntnecessary.
Feasible: The requirement is doable and can be accomplished within budget andschedule.
Correct: The facts related to the requirement are accurate, and it is technically and legallypossible.
Concise: The requirement is stated simply. Unambiguous: The requirement can be interpreted in only one way. Complete: All conditions under which the requirement applies are stated, and it expresses
a whole idea or statement. Consistent: It is not in conflict with other requirements. Verifiable: Implementation of the requirement in the system can be proved. Traceable: The source of the requirement can be traced, and it can be tracked throughout
the system (e.g., to the design, code, test, and documentation).
Allocated: The requirement is assigned to a component of the designed system. Design independent: It does not pose a specific implementation solution. Nonredundant: It is not a duplicate requirement. Written using the standard construct: The requirement is stated as an imperative using
shall. Assigned a unique identifier: Each requirement shall have a unique identifying number. Devoid of escape clauses: Language should not include such phrases as if, when,
but, except, unless, and although. Language should not be speculative or general(i.e., avoid wording such as usually, generally, often, normally, and typically).
8/14/2019 Sesi-6-From BM to ReqSpec
29/89
29
Purpose of Business Modeling
To understand the structure and dynamics of
the organization.
To ensure that customers, end users, and
developers have a common understanding of
the organization.
8/14/2019 Sesi-6-From BM to ReqSpec
30/89
30
Business Use Case Model
Business Actor
Enterprise
Business Use Case
Business UC: pelayanan apa saja yang disediakan oleh organisasi
bisnis bagi customers-nya.
Contoh: Business UC untuk
8/14/2019 Sesi-6-From BM to ReqSpec
31/89
31
Contoh: Business UC untuk
Sistem Informasi Rumah Sakit
PB Farmasi
Rumah SakitBerobat jalan
Memonitor Kinerja RS
Menjalani rawat inap
Melakukan check-upPasien
DepKes
MemonitorKetersediaan dan
Status Obat
8/14/2019 Sesi-6-From BM to ReqSpec
32/89
32
Business Object Model (BOM)
Business Actor
Business Entity
Business Worker
Enterprise
BOM: interaksi antar komponen organisasi dalam rangka melayani
cutomers.
8/14/2019 Sesi-6-From BM to ReqSpec
33/89
33
Contoh: BOM Berobat Jalan
Pasien
Rekam Medis
Petugas Reservasi
Rumah Sakit
Petugas Unit
Layanan
Bukti Berobat
Kasir
8/14/2019 Sesi-6-From BM to ReqSpec
34/89
34
Stakeholder Requests
The purpose of this artifact is to capture all requests made on the
project, as well as how these requests have been addressed.Although the system analyst is responsible for this artifact, manypeople will contribute to it: marketing people, end users, customersanyone who is considered to be a stakeholder to the result of theproject.
Examples of sources Results of stakeholder interviews Results from requirements elicitation sessions and workshops Term of Reference (TOR) Statement of work Request for proposal Mission statement
Problem statement Business rules Laws and regulations Legacy systems Business models
8/14/2019 Sesi-6-From BM to ReqSpec
35/89
35
Stakeholder Requests
A system analyst is responsible for theintegrity of the Stakeholder Requests
artifact, ensuring that:
All stakeholders have been given the
opportunity to add requests.
All items in this artifact are taken into
consideration when developing detailed
requirements in the use-case model andthe supplementary specifications.
Activity Diagram Berobat Jalan
8/14/2019 Sesi-6-From BM to ReqSpec
36/89
36
Activity Diagram Berobat Jalan
8/14/2019 Sesi-6-From BM to ReqSpec
37/89
37
Activity
Diagram
OpenRegistration
8/14/2019 Sesi-6-From BM to ReqSpec
38/89
38
Activity
Diagram
Make anOrder
8/14/2019 Sesi-6-From BM to ReqSpec
39/89
39
Going from Business Models to
Systems
Business workers become the actors to the system.Behaviors described for business workers are things that can
be automated.
Business entities are things we may want the
system to help us maintain entity class in
analysis model.
8/14/2019 Sesi-6-From BM to ReqSpec
40/89
40
Contoh: System Use Case Model
Petugas RM Mengupdate Rekam Medis
Actor
System Application
Boundary Controller
Entity
Analysis & Design
8/14/2019 Sesi-6-From BM to ReqSpec
41/89
41
Use Case Diagrams
A use case diagram illustrates a set of use casesfor a system, the actors, and the relation betweenthe actors and use cases.
UC A
UC B
UC C
System
Actor X Actor Y
8/14/2019 Sesi-6-From BM to ReqSpec
42/89
42
Point-of-Sale Terminal
Assume that we have been requested to create the
software to run a point-of-sale terminal (POST).
Systems and their boundaries
8/14/2019 Sesi-6-From BM to ReqSpec
43/89
43
POST system boundary
Buy Items
Log In
Refund Purchased
Items
POST
Cashier
Repository
System
Systems and their boundaries
Authorization
System
Systems and their boundaries
8/14/2019 Sesi-6-From BM to ReqSpec
44/89
44
POST Checkout boundary
Buy Items
Refund Purchased
Items
POST Checkout
Customer
Systems and their boundaries
8/14/2019 Sesi-6-From BM to ReqSpec
45/89
45
Software RequirementSpecification
8/14/2019 Sesi-6-From BM to ReqSpec
46/89
46
FURPS+
Functionality (behavior use cases)
Usability (typical users and operational envrmt)
Reliability (Availability, MTBF, MTTR, Accuracy)Performance (Response time, throughput,
capacity, degradation modes)
Supportability (ability to be easily modified toaccommodate enhancements and repairs)
+(Constraint) (restrictions on design)
8/14/2019 Sesi-6-From BM to ReqSpec
47/89
47
Functional Requirements
These requirements generally represent the
main product features. In a warehouse
application, we might have requirements
pertaining to order processing or stockcontrol, for example. However, functional
requirements are not always domain-specific.
Providing printing capability is a functionalrequirement of particular significance to
architecture, for example.
8/14/2019 Sesi-6-From BM to ReqSpec
48/89
48
Functional Requirement
Function Description
Auditing Provide audit trails of system execution.
Licensing Provide services for tracking, acquiring, installing, and monitoring license usage.
Localization Provide facilities for supporting multiple human languages.
Mail Provide services that allow applications to send and receive mail.
Online help Provide online help capability.
Printing Provide facilities for printing.
Reporting Provide reporting facilities.
Security Provide services to protect access to certain resources or information.
System
management
Provide services that facilitate management of applications in a distributed
environment.
WorkflowProvide support for moving documents and other work items, including review
and approval cycles.
8/14/2019 Sesi-6-From BM to ReqSpec
49/89
49
Usability, Reliability, Performance,
and Supportability Requirements
The remaining "URPS" categories describe non-functional requirements that are generallyarchitecturally significant. Usabilityis concerned with characteristics such as aesthetics
and consistency in the user interface. Reliabilityis concerned with characteristics such as availability
(the amount of system "up time"), accuracy of systemcalculations, and the system's ability to recover from failure.
Performance is concerned with characteristics such asthroughput, response time, recovery time, start-up time, and
shutdown time. Supportabilityis concerned with characteristics such astestability, adaptability, maintainability, compatibility,configurability, installability, scalability, and localizability.
8/14/2019 Sesi-6-From BM to ReqSpec
50/89
50
Design, Implementation, Interface,
and Physical Requirements
The "+" in the FURPS+ acronym is used to identify additionalcategories that generally represent constraints. A design requirement, often called a design constraint,
specifies or constrains the options for designing a system.For example, if you specify that a relational database is
required, that's a design constraint. An implementation requirementspecifies or constrains the
coding or construction of a system. Examples might includerequired standards, implementation languages, andresource limits.
An interface requirementspecifies an external item withwhich a system must interact, or constraints on formats orother factors used within such an interaction.
Aphysical requirementspecifies a physical constraintimposed on the hardware used to house the system shape, size, or weight, for example.
8/14/2019 Sesi-6-From BM to ReqSpec
51/89
51
Fit Criterion
The idea is for each requirement to have a quality
measure that makes it possible to divide all solutions
to the requirements into two classes: those for which
we agree that they fit the requirement and those forwhich we agree that they do not fit the requirement.Source: Christopher Alexander, Notes on the Synthesis of Form.
Keep in mind that any requirement can be measured.All you have to do is find a suitable scale.
8/14/2019 Sesi-6-From BM to ReqSpec
52/89
52
Define the fit criterion! (1)
Domain: Music Online Store
Description: Sistem harus mempermudah pembeli
untuk menemukan musik pilihannya.
Fit Criterion: Pembeli dapat menemukan musik yangdicari rata2 dalam waktu enam detik dengan tidak
lebih dari 3 langkah.
Refined Fit Criterion: 90% pembeli dapat
menemukan musik yang dicari rata2 dalam waktuenam detik dengan tidak lebih dari 3 langkah.
8/14/2019 Sesi-6-From BM to ReqSpec
53/89
53
Define the fit criterion! (2)
Domain: graphical tool untuk menggambar peta. Description: The product shall be user-friendly. Fit Criterion: Pengguna baru dapat menambah,
mengubah dan menghapus komponen peta (jalan,bangungan, persimpangan) dalam waktu 30 menitsejak pertama kali menggunakan aplikasi.
Refined Fit Criterion: Dalam tiga bulan pertamaproduk dipakai, 60% pengguna memanfaatkannyauntuk menyelesaikan pekerjaan rutin. Daripengguna baru tersebut, produk harus dapatditerima oleh 75% tingkat kepuasan.
8/14/2019 Sesi-6-From BM to ReqSpec
54/89
54
Define the fit criterion! (3)
Domain: graphical tool untuk menggambar peta.
Description: The product shall be intuitive.
Fit Criterion: Engineer harus bisa melakukan koreksi
dalam waktu 10 menit sejak ditemukannyakesalahan tanpa referensi ke user manual.
Refined Fit Criterion: 90% engineer dapat
menyelesaikan tugasnya untuk .. (daftar tugas)
setelah mengikuti 4 jam pelatihan.
8/14/2019 Sesi-6-From BM to ReqSpec
55/89
55
USE CASE
8/14/2019 Sesi-6-From BM to ReqSpec
56/89
56
What is Use Case?
A use case describes a sequence of actions of a
system performs that yields a result of value to a
particular actor.
A series of user system interactions that
helps the user to accomplish something.
Use Case
8/14/2019 Sesi-6-From BM to ReqSpec
57/89
57
What kind of services .
does an ATM provide?
does a Library Information System
provide?
8/14/2019 Sesi-6-From BM to ReqSpec
58/89
58
Use Case and Domain Process
` A use case describes a process.
` A process describes, from start to finish, a
sequence of events, actions, and
transactions required to produce or complete
something of value to an organization or
actor.
` e.g. Withdraw cash from an ATM, Register forcourses at school, etc.
8/14/2019 Sesi-6-From BM to ReqSpec
59/89
59
Identifying Use Cases
Actor-based:
1. Identify the actors related to a system or organization.
2. For each actor, identify the process they initiate or
participate in.Event-based:
1. Identify the external events that a system must
respond to.
2. Relate the events to actors and use cases.
8/14/2019 Sesi-6-From BM to ReqSpec
60/89
60
Actors
An actor is an entity external to the system who
in some way participates in the story of the use
case.
8/14/2019 Sesi-6-From BM to ReqSpec
61/89
61
Actors (2)
a There is one initiator actorwho generatesthe starting stimulus, and possibly severalotherparticipating actors.
a Kind of actors include:a roles that people playa computer systemsa electrical or mechanical devices
8/14/2019 Sesi-6-From BM to ReqSpec
62/89
62
Find Actors
To find the actors, ask the following questions:
Which user groups require help from the system toperform their tasks?
Which user groups are needed to execute thesystem's most obvious main functions?
Which user groups are required to performsecondary functions, such as system maintenance
and administration? Will the system interact with any external hardware
or software system?
8/14/2019 Sesi-6-From BM to ReqSpec
63/89
63
Use Case Diagrams
A use case diagram illustrates a set of use casesfor a system, the actors, and the relation betweenthe actors and use cases.
UC A
UC B
UC C
System
Actor X Actor Y
8/14/2019 Sesi-6-From BM to ReqSpec
64/89
64
Point-of-Sale Terminal
Assume that we have been requested to create the
software to run a point-of-sale terminal (POST).
Systems and their boundaries
8/14/2019 Sesi-6-From BM to ReqSpec
65/89
65
POST system boundary
Buy Items
Log In
Refund Purchased
Items
POST
Cashier
Repository
System
Authorization
System
Systems and their boundaries
8/14/2019 Sesi-6-From BM to ReqSpec
66/89
66
POST Checkout boundary
Buy Items
Refund Purchased
Items
POST Checkout
Customer
Fi d A t
8/14/2019 Sesi-6-From BM to ReqSpec
67/89
67
Find Actors
Activity Diagram Berobat Jalan
8/14/2019 Sesi-6-From BM to ReqSpec
68/89
68
y g
8/14/2019 Sesi-6-From BM to ReqSpec
69/89
69
Activity
Diagrams(Optional)
8/14/2019 Sesi-6-From BM to ReqSpec
70/89
70
Activity
Diagrams(Optional)
Use Case Specification in ATM System
8/14/2019 Sesi-6-From BM to ReqSpec
71/89
71
Withdraw Money
1. The use case begins when a client inserts a card into the
ATM. The system reads and validates information on the
card.
2. The system prompts for a personal identification number
(PIN). Client enters the PIN. The system validates the PIN.3. The system asks which operation the client wishes to
perform. Client selects Withdraw Money.
4. The system requests the amount of withdrawal. Client
enters amount.
Use Case Specification in ATM System
8/14/2019 Sesi-6-From BM to ReqSpec
72/89
72
Withdraw Money
1. The system request the account type. Client selects the
account type (checking, saving, credit).
2. The system communicates with the ATM network to validate
the account ID, PIN, and availability of the amount requested.
3. The system asks the Client whether a receipt is desired. Thisstep is performed only if there is paper available to print the
receipt.
4. The system asks the Client to remove the card. Client
removes the card.
5. The system dispenses the requested amount of cash.6. The system prints a receipt, if required, which ends the use
case.
Use Case Specification
8/14/2019 Sesi-6-From BM to ReqSpec
73/89
73
Use case: Buy Items
Actors: Customer (initiator), Cashier
Description: A Customer arrives at a checkout with
items to purchase. The Cashier records
the purchased items and collectspayment. On completion, the Customer
leaves with the items.
Use Case Specification
Examples
8/14/2019 Sesi-6-From BM to ReqSpec
74/89
74
Use Case Specification
Actor Action System Response
1. This use case begin when a
Customer arrives at a POST
checkout with items to pur-
chase.2. The Cashier records UPC 3. Determines the item price
for each item. and adds the item informa-
tion to the running sales
transaction.
8/14/2019 Sesi-6-From BM to ReqSpec
75/89
75
Use Case Specification
Actor Action System Response
If there is more than one of The description and price
the same item, the Cashier of the current item are
can enter the quantity as displayed.
well.
4.On completion of item entry, 5. Calculates and present the sale
the Cashier indicates to the total.
POST that item entry is complete.
6. The Cashier tells the Customer
the total
..
A Common Mistake
8/14/2019 Sesi-6-From BM to ReqSpec
76/89
76
A Common Mistake
with Use Cases
A use case is a relatively large end-to-end process
description that typically includes many steps or
transactions; it is not normally an individual step or
activity in a process, e.g. printing the receipt
Identifying use cases differs from process/ function
decomposition
8/14/2019 Sesi-6-From BM to ReqSpec
77/89
77
Naming Use Cases
Name a use case starting with a verb in order
to emphasize that it is a process.
s Buy Items
s Enter an Order
s Maintain Customer Profiles
8/14/2019 Sesi-6-From BM to ReqSpec
78/89
78
Decision Points and Branching
1. Within the main section Flow of Events, indicatebranches to subsections.
2. Write a subsection for each branch, again using aFlow of Events. Start the event numbering at one for
each section.
3. If subsections have alternatives, write them in an
Alternativessection for each subsection.
8/14/2019 Sesi-6-From BM to ReqSpec
79/89
79
Include UC Relationship
Check Balance
Withdraw Money
Transfer Money
ATM
Clientlogin
8/14/2019 Sesi-6-From BM to ReqSpec
80/89
80
Extend UC Relationship
Mengembalikan
Buku
Meminjam Buku
Sistem Informasi
Perpustakaan
PetugasMenagih Denda
8/14/2019 Sesi-6-From BM to ReqSpec
81/89
81
UC Scenario
8/14/2019 Sesi-6-From BM to ReqSpec
82/89
82
Notes on UC Specifications
1. A UC description must include how and when the use case begins andends. Also, consider the possibility of any looping behavior within theuse case.
2. Be specific when defining the activities of an actor. Avoid using adverbs(e.g. very, more, rather).
3. UC should not include technology considerations. Its not solely createdfor user interface specification. A UC should not contain any userinterface information (e.g. radio button, check box, drop-down menu).
4. Verify that all the functional requirements have been addressed in theuse case model. Scrutinize the specification carefully to ensure that allrequirements have been met by the various use cases.
Library Information System
8/14/2019 Sesi-6-From BM to ReqSpec
83/89
83
Browse Catalog
Memesan Buku
Undergrad
Student
Meminjam Buku
Librarian
Memesan Copy
Meng-konfirmasi
Transaksi
Menambah Koleksi
Memperpanjang
Pinjaman
Postgrad
Student
Lecturer
Undergrads Point of View
8/14/2019 Sesi-6-From BM to ReqSpec
84/89
84
Browse Catalog
Memesan Buku
Undergrad
Student
Meminjam Buku
Librarian
Postgrad
Student
Lecturer
Postgrads Point of View
8/14/2019 Sesi-6-From BM to ReqSpec
85/89
85
Browse Catalog
Memesan Buku
Undergrad
Student
Meminjam Buku
Librarian
Memesan Copy
Postgrad
Student
Lecturer
Lecturers Point of View
8/14/2019 Sesi-6-From BM to ReqSpec
86/89
86
Browse Catalog
Memesan Buku
Undergrad
Student
Meminjam Buku
Librarian
Memesan Copy
Meng-konfirmasi
Transaksi
Memperpanjang
Pinjaman
Postgrad
Student
Lecturer
Librarians Point of View
8/14/2019 Sesi-6-From BM to ReqSpec
87/89
87
Browse Catalog
Memesan Buku
Undergrad
Student
Meminjam Buku
Librarian
Memesan Copy
Meng-konfirmasi
Transaksi
Menambah Koleksi
Memperpanjang
Pinjaman
Postgrad
Student
Lecturer
UC - Library Information System
8/14/2019 Sesi-6-From BM to ReqSpec
88/89
88
Browse Catalog
Memesan Buku
Undergrad
Student
Meminjam Buku
Librarian
Memesan Copy
Meng-konfirmasi
Transaksi
Menambah Koleksi
Memperpanjang
Pinjaman
Postgrad
Student
Lecturer
UC - Library Information System (Revised)
8/14/2019 Sesi-6-From BM to ReqSpec
89/89
Browse Catalog
Memesan Buku
Member
Meminjam Buku
Librarian
Memesan Copy
Meng-konfirmasi
Pinjaman
Menambah Koleksi
Memperpanjang
Pinjaman
Postgrad
Lecturer
Meng-konfirmasi
Perpanjangan
Recommended