Sesi-6-From BM to ReqSpec

8/14/2019 Sesi-6-From BM to ReqSpec

1/89

1

Business Modelingand Requirements

Perancangan Sistem Informasi 2008

Petrus Mursanto ([email protected])

Dana Indra Sensuse ([email protected])

Indra Budi ([email protected])

Overview
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


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.


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


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:


5/89

5

Moving Toward the Solution Domain 2

NeedsProblem

Domain

FEATURES

Software

Requirements

Solution Dom

ain

FunctionalNon-Functional Use CaseURPS+


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


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/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


9/89

9

Requirement TracebilityStakeholder request

document

Vision document

Software Requirement

Specification

Document

Use Case

Specification

Document

Supplementary

document


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


11/89

11

Good Requirement

Unambiguous Testable (verifiable) Clear (concise, terse, simple, precise)

Correct Understandable Feasible (realistic, possible) Independent Atomic Necessary Implementation-free (abstract)


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


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.


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.


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.


16/89

16

Correct

REQ1 Car rental prices shall show all

applicable taxes (including 6% state tax).


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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


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.


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


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


32/89

32

Business Object Model (BOM)

Business Actor

Business Entity

Business Worker

Enterprise

BOM: interaksi antar komponen organisasi dalam rangka melayani

cutomers.


33/89

33

Contoh: BOM Berobat Jalan

Pasien

Rekam Medis

Petugas Reservasi

Rumah Sakit

Petugas Unit

Layanan

Bukti Berobat

Kasir


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


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


36/89

36



37/89

37

Activity

Diagram

OpenRegistration


38/89

38

Activity

Diagram

Make anOrder


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.


40/89

40

Contoh: System Use Case Model

Petugas RM Mengupdate Rekam Medis

Actor

System Application

Boundary Controller

Entity

Analysis & Design


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


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


43/89

43

POST system boundary

Buy Items

Log In

Refund Purchased

Items

POST

Cashier

Repository

System


Authorization

System



44/89

44

POST Checkout boundary

Buy Items

Refund Purchased

Items

POST Checkout

Customer



45/89

45

Software RequirementSpecification


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)


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.


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.


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.


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.


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.


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.


53/89

53


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.


54/89

54


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.


55/89

55

USE CASE


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


57/89

57

What kind of services .

does an ATM provide?

does a Library Information System

provide?


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.


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.


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.


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


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?


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


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



65/89

65

POST system boundary

Buy Items

Log In

Refund Purchased

Items

POST

Cashier

Repository

System

Authorization

System



66/89

66

POST Checkout boundary

Buy Items

Refund Purchased

Items

POST Checkout

Customer

Fi d A t


67/89

67

Find Actors



68/89

68

y g


69/89

69

Activity

Diagrams(Optional)


70/89

70

Activity

Diagrams(Optional)

Use Case Specification in ATM System


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


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


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.


Examples


74/89

74


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.


75/89

75


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


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


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


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.


79/89

79

Include UC Relationship

Check Balance

Withdraw Money

Transfer Money

ATM

Clientlogin


80/89

80

Extend UC Relationship

Mengembalikan

Buku

Meminjam Buku

Sistem Informasi

Perpustakaan

PetugasMenagih Denda


81/89

81

UC Scenario


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


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


84/89

84

Browse Catalog

Memesan Buku

Undergrad

Student

Meminjam Buku

Librarian

Postgrad

Student

Lecturer

Postgrads Point of View


85/89

85

Browse Catalog

Memesan Buku

Undergrad

Student

Meminjam Buku

Librarian

Memesan Copy

Postgrad

Student

Lecturer

Lecturers Point of View


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


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


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)


89/89

Browse Catalog

Memesan Buku

Member

Meminjam Buku

Librarian

Memesan Copy

Meng-konfirmasi

Pinjaman

Menambah Koleksi

Memperpanjang

Pinjaman

Postgrad

Lecturer

Meng-konfirmasi

Perpanjangan

Sesi-6-From BM to ReqSpec

Documents

Transcript of Sesi-6-From BM to ReqSpec