24
Desain slide ini dadaptasi dari University of San Fransisco 8. Analisis Kebutuhan - 2 (High Level Requirement) SIF15001 Analisis dan Perancangan Sistem Informasi Agi Putra Kharisma, S.T., M.T. Genap 2014/2015

8. Analisis Kebutuhan - 2 (High Level Requirement)agipk.lecture.ub.ac.id/files/2015/02/APSI-20142015-08.-Analisis... · terpisah yang merujuk pada use case tertentu. ... Pembuatan

Embed Size (px)

Citation preview

Desain slide ini dadaptasi dari University of San Fransisco

8. Analisis Kebutuhan - 2 (High Level

Requirement)

SIF15001

Analisis dan Perancangan Sistem Informasi

Agi Putra Kharisma, S.T., M.T.

Genap 2014/2015

Requirement?

fungsionalitas yang harus dapat dilakukan sistem

“requirements are something that a client asks for, and not

something that the team designs”

Jenis Requirements

• Functional • Nonfunctional • Supplementary

Requirement Elicitation

Mencari fungsionalitas yang harus dapat dilakukan sistem.

The time used for requirements elicitation time

must be about discovery, not invention.

Dalam perkuliahan ini, kebutuhan sistem didokumentasikan dalam

bentuk use case.

Use Case Dengan Business Rules/Constraints

Business rules/constraints dapat dinyatakan dalam

bentuk annotation atau dapat juga ditulis dalam daftar

terpisah yang merujuk pada use case tertentu.

Tantangan Requirement

(Pressman, 2010):

• How to discover requirements.

• How to communicate requirements to the other phases

and teams of the project.

• How to recall requirements during development in order to

verify if they have all been implemented.

• How to manage requirements change.

Requirement Tidak Disarankan Sebagai Dasar

Pembuatan Arsitektur Sistem

Using requirements as a base to support system architecture

is like building a house over moving sand; when

requirements change, the structure suffers.

However, the Unified Process (UP) uses a much more

stable basis for the architecture, which is based on classes

and components that encapsulate information and behavior.

Open-Close Principle (Meyer, 1988)

Suatu arsitektur yang baik dapat mengikuti prinsip buka-

tutup, yaitu:

“it is always closed for modification (it works), but open for extension (it may accommodate

new functionalities).”

Nonfunctional Requirements

Nonfunctional requirements are constraints or qualities that may be linked to specific functions

of a system.

(for example, “an order cannot contain more than one hundred

books,” “the order transaction must be preserved if communications

are broken,” etc.)

Nonfunctional requirement dapat dinyatakan pada diagram use case dalam

bentuk annotation.

Tipe – Tipe Nonfunctional Requirement

1. Logical issues Business rules attached to a function

Contoh: tidak mengirim makanan sebelum pembayaran dilunasi

2. Technological issues Constraints and qualities related to the technology used to

perform the function

Contoh: konfirmasi pembayaran tidak lebih dari 24 jam

Supplementary Requirements

Supplementary requirements are all types of constraints and qualities related to the

system as a whole and not only to individual functions.

Klasifikasi supplementary requirement dapat dilihat pada

ISO/IEC 25010.

ISO/IEC 25010:2011 (1)

ISO/IEC 25010:2011 (2)

ISO/IEC 25010:2011 (3)

ISO/IEC 25010:2011 (4)

ISO/IEC 25010:2011 (5)

ISO/IEC 25010:2011 (6)

Preliminary Conceptual Model

• Dibuat pada fase Inception

• Terdiri dari diagram kelas tanpa atribut

• Konsep – konsep dapat ditemukan dengan menganalisis

system use case diagram

Contoh Conceptual Model

Use Case Setelah Direvisi

Use Case Setelah Direvisi (Lagi)

Referensi

Raul Sidnei Wazlawick - Object-Oriented Analysis and Design

for Information Systems

Tugas

Buat system use case Web Kantin PTIIK yang melayani

pemesanan & pembayaran secara online.