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