Overview

Business Modeling
and 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)

1
Tujuan :
 Memahami peran software terhadap
proses bisnis customers.
 Mengumpulkan permasalahan dan
solusi yang bisa ditawarkan dengan IT.
 Menentukan fitur apa saja yang ada
dalam sistem.
 Menuangkan features ke dalam
kebutuhan fungsional dan non-
fungsional sistem.
2
The Problem Domain

Users +
other Stakeholders
Needs

Challenge: understand
the problem to be solved Stakeholders: anyone who could be
materially affected by the
implementation of a new system or
application.
3
Moving Toward the Solution Domain 1

Needs
Problem
Domain
Features: a service that the system
FEATURES
provides to fulfill one or more stakeholder
needs.

Examples:
• The system will prevent intruders
• The system will have automatic backup
• Web-enabled entry for sales orders

4
 Moving Toward the Solution Domain 2

Needs
Problem
Domain

FEATURES
Solution Domain
Software
Requirements

Non-Functional Functional Use Case

URPS+

5
 Problem/Solution Domains
RUMAH SAKIT

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 6
 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.

7
 Use Case Defines System Boundaries
Goal: Menjalani rawat inap

HOSPITAL

Pasien Unit Rekam Medis

RM
Petugas Medis Application
Petugas RM

Keluarga karyawan

Goal: Berobat jalan

Goal: Mengupdate data pasien
Goal: Memeriksa pasien
8
Requirement Tracebility
Stakeholder request
document
Software Requirement
Specification
Document Vision document

Use Case Supplementary

Specification document
Document

9
Requirement Pyramid
 Stakeholder need: a requirement from
a stakeholder
 Feature: a service provided by the
system, usually formulated by a
business analyst; a
 purpose of a feature is to fulfill a
stakeholder need
 Use case: a description of system
behavior in terms of sequences of
actions
 Supplementary requirement: another
requirement (usually nonfunctional)
that cannot be captured in use cases
 Test case: a specification of test
inputs, execution conditions, and
expected results
 Scenario: a specific sequence of
actions; a specific path through a use
case

10
Good Requirement
 Unambiguous
 Testable (verifiable)
 Clear (concise, terse, simple, precise)
 Correct
 Understandable
 Feasible (realistic, possible)
 Independent
 Atomic
 Necessary
 Implementation-free (abstract)
11
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 full
name and provide an acronym in parentheses:

 REQ1 The system shall be implemented using

Active Server Pages (ASP).

12
Unambigous
 REQ1 The system shall not accept passwords longer than 15
characters.

 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 15

characters. If the user enters more than 15 characters while
choosing the password, an error message shall ask the user to
correct it.

13
testable
 REQ1 The search facility should allow the user to find a reservation based on
Last Name, Date, etc.

 In this requirement, all search criteria should be explicitly listed. The designer
and 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.

14
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 still
be 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.
15
Correct
 REQ1 Car rental prices shall show all
applicable taxes (including 6% state tax).

16
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.”

17
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 a
short span of development time.

18
Independent
 Tounderstand the requirement, there should
not be a need to know any other requirement:
 REQ1 The list of available flights shall include
flight numbers, departure arrival time for every leg
of a flight.
 REQ2 It should be sorted by price.
 The word “It” in the second sentence refers to
the previous requirement. However, order of
the requirements changes, this requirement
will not be understandable.
19
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 a
car, and provide information about attractions.
 This requirement combines five atomic
requirements, which makes traceability very difficult.
Sentences including the words “and” or “but” should
be reviewed to see if they can be broken into atomic
requirements.

20
Necessary
A requirement is unnecessary if
 None of the stakeholders needs the requirement,
or
 Removing the requirement will not affect the
system.

 REQ1All requirements specified in the Vision

document shall be implemented and tested.

21
Implementation-free (Abstract)
 Requirementsshould 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 designer’s or
architect’s decision.

22
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 is
expected:
 REQ1 Dates shall be displayed in the mm/dd/yyyy
format.
 REQ2 Dates shall be displayed in the dd/mm/yyyy
format.

23
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.
 Thiscan eventually lead to the following
requirement:
 REQ3 Dates shall be displayed based on the
format defined in the user’s web browser.

24
Consistent
 Indirect conflict occurs when requirements do not describe the
same functionality, but it is not possible to fulfill both
requirements 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 inconsistent

terminology:
 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 the
smallest number of stops.
 To describe the same concept, in the first requirement the term
“inbound flights” is used, and in the second requirement the term
“return flights” is used. The usage should be consistent.
25
Nonredundant
 Each requirement should be expressed only
once and should not overlap with another
requirement:
 REQ1 A calendar shall be available to help with
entering the flight date.
 REQ2 The system shall display a pop-up
calendar when entering any date.
 The first requirement (related to only the flight
date) is a subset of the second one (related
to any date entered by the user).
26
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.”
27
Each Individual Requirement
Should Be :
 Necessary: If the system can meet prioritized real needs without the requirement, it isn’t
necessary.
 Feasible: The requirement is doable and can be accomplished within budget and
schedule.
 Correct: The facts related to the requirement are accurate, and it is technically and legally
possible.
 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 28
(i.e., avoid wording such as “usually,” “generally,” “often,” “normally,” and “typically”).
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.

29
 Business Use Case Model

Enterprise

Business Actor Business Use Case

Business UC: pelayanan apa saja yang disediakan oleh organisasi

bisnis bagi customers-nya.
30
 Contoh: Business UC untuk
Sistem Informasi Rumah Sakit

Berobat jalan Rumah Sakit

Pasien Melakukan check-up

Menjalani rawat inap

DepKes
Memonitor Kinerja RS
Memonitor
Ketersediaan dan
Status Obat

PB Farmasi
31
 Business Object Model (BOM)

Enterprise

Business Worker
Business Actor

Business Entity

BOM: interaksi antar komponen organisasi dalam rangka melayani

cutomers.
32
 Contoh: BOM “Berobat Jalan”

Rumah Sakit Kasir

Bukti Berobat

Petugas Reservasi
Pasien Petugas Unit
Layanan

Rekam Medis

33
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, many
people will contribute to it: marketing people, end users, customers—
anyone who is considered to be a stakeholder to the result of the
project.

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

34
Stakeholder Requests
A system analyst is responsible for the
integrity 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 and
the supplementary specifications.

35
Activity Diagram “Berobat Jalan”

36
Activity
Diagram
“Open
Registration”

37
Activity
Diagram
“Make an
Order”

38
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.

39
 Contoh: System Use Case Model

Petugas RM Mengupdate Rekam Medis

Analysis & Design

System Application
Entity

Actor

Boundary Controller

40
Use Case Diagrams

System
UC A

UC B
Actor X Actor Y

UC C

A use case diagram illustrates a set of use cases

for a system, the actors, and the relation between
the actors and use cases.
41
Point-of-Sale Terminal
Assume that we have been requested to create the
software to run a point-of-sale terminal (POST).

42
Systems and their boundaries

POST system boundary

POST
Authorization
Buy Items System

Log In
Cashier
Refund Purchased
Items

Repository
System
43
Systems and their boundaries

POST Checkout boundary

POST Checkout

Buy Items

Customer
Refund Purchased
Items

44
Software Requirement
Specification

45
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 to
accommodate enhancements and repairs)
 +(Constraint) (restrictions on design)
46
Functional Requirements
 These requirements generally represent the
main product features. In a warehouse
application, we might have requirements
pertaining to order processing or stock
control, for example. However, functional
requirements are not always domain-specific.
Providing printing capability is a functional
requirement of particular significance to
architecture, for example.
47
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 Provide services that facilitate management of applications in a distributed
management environment.

Provide support for moving documents and other work items, including review
Workflow
and approval cycles.
48
Usability, Reliability, Performance,
and Supportability Requirements
 The remaining "URPS" categories describe non-
functional requirements that are generally
architecturally significant.
 Usability is concerned with characteristics such as aesthetics
and consistency in the user interface.
 Reliability is concerned with characteristics such as availability
(the amount of system "up time"), accuracy of system
calculations, and the system's ability to recover from failure.
 Performance is concerned with characteristics such as
throughput, response time, recovery time, start-up time, and
shutdown time.
 Supportability is concerned with characteristics such as
testability, adaptability, maintainability, compatibility,
configurability, installability, scalability, and localizability.

49
Design, Implementation, Interface,
and Physical Requirements
 The "+" in the FURPS+ acronym is used to identify additional
categories 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 requirement specifies or constrains the
coding or construction of a system. Examples might include
required standards, implementation languages, and
resource limits.
 An interface requirement specifies an external item with
which a system must interact, or constraints on formats or
other factors used within such an interaction.
 A physical requirement specifies a physical constraint
imposed on the hardware used to house the system —
shape, size, or weight, for example.
50
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 for
which 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.

51
Define the fit criterion! (1)
 Domain: Music Online Store
 Description: Sistem harus mempermudah pembeli
untuk menemukan musik pilihannya.
 Fit Criterion: Pembeli dapat menemukan musik yang
dicari rata2 dalam waktu enam detik dengan tidak
lebih dari 3 langkah.
 Refined Fit Criterion: 90% pembeli dapat
menemukan musik yang dicari rata2 dalam waktu
enam detik dengan tidak lebih dari 3 langkah.

52
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 menit
sejak pertama kali menggunakan aplikasi.
 Refined Fit Criterion: Dalam tiga bulan pertama
produk dipakai, 60% pengguna memanfaatkannya
untuk menyelesaikan pekerjaan rutin. Dari
pengguna baru tersebut, produk harus dapat
diterima oleh 75% tingkat kepuasan.
53
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 ditemukannya
kesalahan tanpa referensi ke user manual.
 Refined Fit Criterion: 90% engineer dapat
menyelesaikan tugasnya untuk ….. (daftar tugas) …
setelah mengikuti 4 jam pelatihan.

54
USE CASE

55
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

56
What kind of services ….
 does an ATM provide?

 does a Library Information System

provide?

57
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 for
courses at school, etc.

58
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.

59
 Actors
An actor is an entity external to the system who
in some way participates in the story of the use
case.

60
 Actors (2)
❂ There is one initiator actor who generates
the starting stimulus, and possibly several
other participating actors.
❂ Kind of actors include:
❂ roles that people play
❂ computer systems
❂ electrical or mechanical devices

61
Find Actors
To find the actors, ask the following questions:

 Which user groups require help from the system to

perform their tasks?
 Which user groups are needed to execute the
system's most obvious main functions?
 Which user groups are required to perform
secondary functions, such as system maintenance
and administration?
 Will the system interact with any external hardware
or software system?

62
Use Case Diagrams

System
UC A

UC B
Actor X Actor Y

UC C

A use case diagram illustrates a set of use cases

for a system, the actors, and the relation between
the actors and use cases.
63
Point-of-Sale Terminal
Assume that we have been requested to create the
software to run a point-of-sale terminal (POST).

64
Systems and their boundaries

POST system boundary

POST
Authorization
Buy Items System

Log In
Cashier
Refund Purchased
Items

Repository
System
65
Systems and their boundaries

POST Checkout boundary

POST Checkout

Buy Items

Customer
Refund Purchased
Items

66
Find Actors

67
Activity Diagram “Berobat Jalan”

68
Activity
Diagrams
(Optional)

69
Activity
Diagrams
(Optional)

70
Use Case Specification in ATM System

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.

71
Use Case Specification in ATM System

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. This
step 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.

72
Use Case Specification
Examples
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 collects
payment. On completion, the Customer
leaves with the items.

73
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.

74
Use Case Specification
Actor Action
If there is more than one of
the same item, the Cashier
can enter the quantity as
well.
System Response
The description and price
of the current item are
displayed.

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
………………..

75
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

76
Naming Use Cases
Name a use case starting with a verb in order
to emphasize that it is a process.

■ Buy Items
■ Enter an Order
■ Maintain Customer Profiles

77
Decision Points and Branching
1. Within the main section Flow of Events, indicate
branches to subsections.
2. Write a subsection for each branch, again using a
Flow of Events. Start the event numbering at one for
each section.
3. If subsections have alternatives, write them in an
Alternatives section for each subsection.

78
Include UC Relationship

ATM
Check Balance <<includes>>

<<includes>> login
Client Withdraw Money

<<includes>>
Transfer Money

79
Extend UC Relationship

Sistem Informasi
Perpustakaan
Mengembalikan <<extends>>
Buku

Menagih Denda
Petugas

Meminjam Buku

80
UC Scenario

81
Notes on UC Specifications
1. A UC description must include how and when the use case begins and
ends. Also, consider the possibility of any looping behavior within the
use 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. It’s not solely created
for user interface specification. A UC should not contain any user
interface information (e.g. radio button, check box, drop-down menu).
4. Verify that all the functional requirements have been addressed in the
use case model. Scrutinize the specification carefully to ensure that all
requirements have been met by the various use cases.

82
Library Information System

Browse Catalog
Menambah Koleksi

Meng-konfirmasi
Undergrad Transaksi
Student
Memesan Buku Librarian

Meminjam Buku

Memesan Copy
Lecturer
Postgrad Memperpanjang
Student Pinjaman
83
Undergrad’s Point of View

Browse Catalog

Undergrad
Student
Memesan Buku Librarian

Meminjam Buku

Lecturer
Postgrad
Student
84
Postgrad’s Point of View

Browse Catalog

Undergrad
Student
Memesan Buku Librarian

Meminjam Buku

Memesan Copy
Lecturer
Postgrad
Student
85
Lecturer’s Point of View

Browse Catalog

Meng-konfirmasi
Undergrad Transaksi
Student
Memesan Buku Librarian

Meminjam Buku

Memesan Copy
Lecturer
Postgrad Memperpanjang
Student Pinjaman
86
Librarian’s Point of View

Browse Catalog
Menambah Koleksi

Meng-konfirmasi
Undergrad Transaksi
Student
Memesan Buku Librarian

Meminjam Buku

Memesan Copy
Lecturer
Postgrad Memperpanjang
Student Pinjaman
87
UC - Library Information System

Browse Catalog
Menambah Koleksi

Meng-konfirmasi
Undergrad Transaksi
Student
Memesan Buku Librarian

Meminjam Buku

Memesan Copy
Lecturer
Postgrad Memperpanjang
Student Pinjaman
88
UC - Library Information System (Revised)

Browse Catalog
Meminjam Buku

Member
Memesan Buku
Memesan Copy
Postgrad

Memperpanjang
Pinjaman Librarian Menambah Koleksi
Lecturer

Meng-konfirmasi Meng-konfirmasi
Pinjaman Perpanjangan
89