Pemodelan Kebutuhan

Pendekatan Terstruktur
Fajar Pradana S.ST., M.Eng
Tujuan perkuliahan
• Memahami pemodelan yang dibutuhkan dalam rekayasa
kebutuhan
• Memahami konsep pendekatan terstruktur dalam pemodelan
kebutuhan
Agenda
• Konsep pemodelan kebutuhan
• Konsep pemodelan terstruktur
• Elemen-elemen pemodelan terstruktur
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 & berorientasi objek
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/modul
• Pastikan bahwa model kebutuhan memiliki nilai manfaat untuk
seluruh stakeholders
• Model dibuat sesederhana mungkin  notasi yang sederhana,
non duplikasi informasi
Tipe pemodelan 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
Pemodelan terstruktur
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
Elemen-Elemen Pemodelan

Process
Data Object
Specificatio
Description
Data Flown (PSPEC)
ER
Diagram
Diagram
(DFD)
Data
Dictionary

State
Transition
Diagram
(STD)

Control
Specificatio
n (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
Data Model – ER Diagram
• Entitas (atribut dan nilai atribut)
• Modalitas : tingkat mandatory (minimal)
• Kardinalitas : tingkat relasi (maksimal)
• Bentuk relasi
Data Model – data object description
• 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
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 data
 Umumnya satu arah
 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
1
 Representasi aktifitas sistem
 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
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
Panduan DFD
• Identify data first rather than control  to know what you are
controlling first
• Continuous signals, and processes that act on them, are always
categorized as data
• Discrete signals, and processes that act on them, are usually
categorized as control
• Terms like activate, turn on, engage and execute are usually
associated with control requirements
Leveling
• Must be consistent
Data/Control Context Diagram (DCD/CCD)

object
returned coins
0*

customer
selection Vend
Customer Customer
product

slug
product

coin return
request product
available
 Data/Control Flow Diagram (DFD/CFD level 1)
coin return
object request
coins

1* 5* returned
slug Get payment Dispense coins
customer change
payment sufficient change due
coin detected payment 3p
Validate product
payment product
price 6p
available product
2p Dispense
dispensed
Get product
product 4p valid
valid
price Get valid selection
price table selection
selection
customer product products
selection available
Data/Control Flow Diagram (DFD/CFD level 2)

coin return
request
product
change due
available

5.1p change coins returned coins

Get change
coin

5.2p
Get payment coins
coins payment
coin
payment
PSPEC
• 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
 Behaviour 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
CSPEC

get
coin return product get change
payment
request available coin
coin

TRUE TRUE 1 0

D/C FALSE 0 1
Terima Kasih
Ada Pertanyaan