Rekayasa Kebutuhan

Pemodelan Terstruktur

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Tujuan

 Memahami konsep rekayasa kebutuhan

 Memahami konsep pemodelan dalam rekayasa kebutuhan
 Memahami konsep pendekatan terstruktur dalam pemodelan kebutuhan

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Requirement Engineering?

 RE – requirements engineering  istilah lain dari requirements analysis

 Each software development process goes through the phase of RE
 The process of establishing the services that the customer requires from a
system and the constraints under which it operates and is developed [Ian
Sommerville]
 The broad spectrum of tasks and techniques that lead to an understanding
of requirements [Roger S. Pressman]

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Requirement?
 Suatu kondisi atau kemampuan yang dibutuhkan oleh pengguna untuk
menyelesaikan permasalahan atau untuk mencapai sebuah tujuan [IEEE]
 Sebuah kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sebuah
sistem…untuk memenuhi sebuah kontrak, standard, spesifikasi, atau dokumen2 formal
lainnya [IEEE]
 Setiap fungsi, batasan, atau properti lainnya yang harus disediakan, dimiliki atau
dipenuhi untuk mencapai kebutuhan dari sistem yang dimaksudkan oleh pengguna
[R. J. Abbott]
 IEEE-STD-1220-1998:
a statement that identifies a product or process operational, functional, or design characteristic
or constraint, which is unambiguous, testable or measurable, and necessary for product or
process acceptability (by consumers or internal quality assurance guidelines).
 CMMI (Capability Maturity Model Integration) version 1.3:
i. a condition or capability needed by a user to solve a problem or achieve an objective,
ii. a condition or capability that must be met/possessed by a product, service, product
component or service component to satisfy a supplier agreement, standard, specification or
other formally imposed documents,
iii. a documented representation of a condition or a capability as in (i) or (ii) above.
Kategori Kebutuhan

 Functional  what a system does

 Deskripsi proses, masukan dan keluaran
 Non-functional  constraint or quality of a system
 Performance, availability, security, reliability, implementation & design
constraints, storage size
 Usability  constraint to use
 Acceptance criteria, end-user characteristics, system environments

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Level Kebutuhan

 Normal requirement  kebutuhan yang harus dipenuhi dan dinyatakan

secara eksplisit
 Fungsionalitas sistem, unjuk kerja
 Expected requirement  kebutuhan yang tidak dinyatakan secara eksplisit
tetapi menentukan kepuasan customer
 Kemudahan interaksi dengan sistem, correctness
 Exciting requirement  kebutuhan yang melebihi dari kebutuhan normal
untuk lebih memuaskan customer
 Fungsionalitas tambahan sistem

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Fungsi RE

 Requirements form the basis for :

 Project planning
 Risk management
 Acceptance testing
 Trade off
 Change control

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Proses RE

 Penggalian dan analisis kebutuhan (s/w req. elicitation and analysis)

 Spesifikasi kebutuhan (s/w req. specification)
 Validasi & verifikasi kebutuhan (s/w req. validation and verification)
 Manajemen kebutuhan (s/w req. management)

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Konsep Pemodelan Kebutuhan
 Model kebutuhan menjembatani antara deskripsi sistem secara umum
dengan model perancangan
 Tujuan utama model kebutuhan:
 Menjelaskan apa yang dibutuhkan oleh customer
 Menjadi dasar bagi perancangan PL
 Menjadi referensi dalam melakukan validasi kebutuhan
 Metode: terstruktur (structured analysis – SA) & berorientasi objek (object
oriented analysis – OOA)

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Prinsip Pemodelan Kebutuhan

 Model yang dibuat harus fokus pada kebutuhan yang relevan dengan
domain permasalahan  WHAT
 Setiap model kebutuhan harus bisa dilacak ke model perancangan 
traceability
 Setiap elemen dalam model kebutuhan harus mampu memperjelas
pemahaman secara utuh terhadap kebutuhan PL  domain masalah,
fungsionalitas dan perilaku sistem
 Minimalisasi kopling  antar klas
 Memastikan bahwa model kebutuhan memiliki nilai manfaat untuk seluruh
stakeholders
 Model dibuat sesederhana mungkin  notasi yang sederhana, non
duplikasi informasi

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Tipe-Tipe Model Kebutuhan

 Scenario-based models
 Berdasarkan sudut pandang aktor
 Data models
 Menjelaskan domain informasi dari masalah
 Class-oriented models
 Merepresentasikan klas-klas yang relevan dengan kebutuhan PL
 Flow-oriented models
 Merepresentasikan proses dan data dari sistem
 Behavioral models
 Merepresentasikan perilaku sistem berdasar event

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Pemodelan Terstruktur

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Konsep

 Pertama kali dipopulerkan oleh T. DeMarco (1979)  Structured Analysis

and System Specification
 Perluasan notasi untuk kebutuhan real-time systems oleh Hatley dan Pirbhai
(1987) – SA/RT  Strategies for Real-Time System Specification

Processes

Data Behavior

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Elemen-Elemen Pemodelan

Process
Data Object
Specification
Description
(PSPEC)
Data Flow
ER Diagram Diagram
(DFD)

Data
Dictionary

State
Transition
Diagram
(STD)

Control
Specification
(CSPEC)
Data Dictionary
Representasi Simbol :
= : composed of + : and
{} : iterations of [….|…] : selection / or
() : optional “ “ : literal
* * : comment/description
Vend product (partly) :
Name Element Type
object [coin | slug](product) data
product [ice cream | coffee | candy] data
coins 0{[quarter | nickel | dime]}8 data
product available [TRUE | FALSE] control
[“YES” | “NO”]
quarter *25 cents US currency*
coin return request [TRUE | FALSE] control
Entity Relationship Diagram (Data
Model)
 Komponen ERD :
 Entitas (atribut dan nilai atribut)
 Sebuah barang (sesuatu) atau obyek yang dapat dibedakan dari obyek lain

 Relasi
 Hubungan antara 2 atau lebih entitas

 Atribut
 Properti yang dimiliki oleh sebuah entitas

 Modalitas : tingkat mandatory (minimal)

 Partisipasi sebuah entitas pada sebuah relasi, contoh : 0 opsional, 1 wajib

 Kardinalitas : tingkat relasi (maksimal)

 Angka yang menunjukkan banyaknya kemunculan suatu obyek terkait dengan
kemunculan obyek lain pada suatu relasi, contoh : (1:1, 1:N, M:N)
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
Data Model

 Data object
 represents a composite information
 consists of a number of different attributes or properties
 encapsulates data only  no operation applied to its data
 can be external entity, thing, occurrence/event, role, organizational unit,
structure, etc.
 e.g. dimensions (height, weight, depth), cars (make, model, ID, body type, color,
owner)
 can be represented in a tabular representation

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Data Flow Diagram (Process Model)

 Useful for analyzing existing as well as proposed systems  process

decomposition
 Focus on the movement of data between external entities and processes,
and between processes and data stores
 A relatively simple technique to learn and use
 Model elements: terminator, process, data flow, control flow, storage,
control bar
 The highest level (0)  Context diagram
 Single process
 Terminators
 Data flows, control flows
Elemen – Elemen DFD

 Terminator/ External Entity

 Representasi entitas eksternal
 Notasi: persegi panjang Customer
 Tidak memproses data
 Data flow
 Representasi aliran data
 Notasi: anak panah penuh
 Umumnya satu arah
data
 Hubungkan terminator, process dan storage
 Control flow
 Representasi aliran kontrol proses
 Notasi: anak panah putus2 control
 Hubungkan terminator, process dan control bar
Elemen – Elemen DFD (2)

 Process
 Representasi aktifitas sistem
1
 Notasi: lingkaran Proses A
 Memproses data
 Storage
 Representasi tempat penyimpanan data
 Notasi: dua garis paralel data X
 Data flow in = diubah, data flow out = dibaca
 Control bar
 Representasi spesifikasi kontrol
 Notasi: garis tegak
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
Panduan DFD

 Jumlah proses dalam satu diagram DFD : 4 + 2

 Maks. 4 level dekomposisi (DFD/CFD)
 Dekomposisi fungsional (DFD) :
 fungsi-fungsi yang saling berhubungan dikelompokkan
 fungsi-fungsi yang tidak berhubungan dipisahkan
 setiap fungsi dispesifikasi hanya sekali
 Data flow membawa informasi yg diperlukan oleh sebuah proses
untuk transformasi, control flow membawa informasi yang harus
diinterpretasikan untuk merubah perilaku sistem dan/ aktifasi proses
(Trigger)
 Proses pemodelan DFD/CFD adalah proses iterasi, tidak sekali jadi
 Penjenjangan CFD harus sesuai dengan DFD
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
Data – Control Identification

 Identifikasi aliran data terlebih dahulu sebelum menentukan control (untuk

mengetahui proses mana dulu yang dikontrol)
 Garis bersambung yang terhubung dengan sebuah proses (memproses)
adalah data (data flow)
 Garis putus-putus yang terhubung dengan sebuah proses (memproses)
adalah control (control flow)
 Istilah seperti pengaktifan, menyalakan, menggunakan, dan menjalankan
(dan istilah lain yang senada) biasanya berhubungan dengan aliran
kontrol

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Process Model – DFD/CFD Leveling

 Harus konsisten
 Pada masing-masing diagram
(tiap level) hanya memiliki satu
control bar

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Data/Control Context Diagram
(DCD/CCD)

object
returned coins
0*

customer
selection Vend
Customer Customer
product

slug
product

coin return
request product
available
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
Data/Control Flow Diagram (DFD/CFD
level 1)
coin return
object request
coins

1* 5* returned coins
slug payment Dispense
Get
customer change
payment change due
sufficient
coin detected payment 3p
Validate product
payment product
price 6p
available product
2p Dispense
dispensed
Get product
product
4p valid selection
price valid selection
price table Get valid
selection
customer product products
selection
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D available
Data/Control Flow Diagram (DFD/CFD
level 2)
 DFD/CFD level 2 : Dispense change
coin return
request
product
change due
available

5.1p change coins returned coins

Get change
coin

5.2p
payment coins
Get
coins payment
coin
payment
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D
Process model – Process specification

 PSPEC – Validate payment (Process 3)

Inputs : payment (data in)

price (data in)
Outputs : change due (data out)
sufficient payment (control out)
Body :
IF payment >= price THEN
change due = payment – price
sufficient payment = TRUE
ELSE
change due = 0
sufficient payment = FALSE
END IF
Behavior Model

 State Transition Diagram (STD) initial

accept new coin

Waiting for a
coin payment returned
accept new coin
coin detected
accept customer coin return request
request return payment
product dispensed
Waiting for Returning
accept new coin
selection payment
product
sufficient payment available=FALSE
dispense product return payment

Dispensing
product
Behavior model (1)

 CSPEC – Dispense change : Process Activation Table

get
coin return product get change
payment
request available coin
coin

TRUE TRUE 1 0

D/C FALSE 0 1

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D