Requirements

Modeling – StructuredTIF-151551

REKAYASA DAN MANAJEMEN KEBUTUHAN

Goals

� Memahami konsep pemodelan terstruktur pada rekayasa

kebutuhan.

� Terampil dalam pembuatan diagram-diagram yang diperlukan

dalam pemodelan terstruktur pada rekayasa kebutuhan.

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

2

Konsep Dasar

� Pertama kali dipopulerkan oleh T. DeMarco (1979) � Structured

Analysis and System Specification

� Perluasan notasi untuk kebutuhan real-time systems oleh Hatley danPirbhai (1987) – SA/RT � Strategies for Real-Time System Specification

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

3

Processes

Data Behavior

Elemen-elemen Pemodelan

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

4

Data Dictionary

Data Flow Diagram

(DFD)

ER Diagram

State Transition Diagram

(STD)

Process Specification

(PSPEC)

Data Object Description

Control Specification

(CSPEC)

Data Dictionary

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

5

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

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

6

Manufacturer CarBuilds

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

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

7

Process Model – DFD

� 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

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

8

Process Model – Elemen2 DFD

� Terminator

� Representasi entitas eksternal

� Notasi: persegi panjang

� Tidak memproses data

� Data flow

� Representasi aliran data

� Notasi: anak panah penuh

� Umumnya satu arah

� Hubungkan terminator, process dan storage

� Control flow

� Representasi aliran kontrol proses

� Notasi: anak panah putus2

� Hubungkan terminator, process dan control bar

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

9

Customer

data

control

Process Model – Elemen2 DFD

(contn’d)

� Process

� Representasi aktifitas sistem

� Notasi: lingkaran

� Memproses data

� Storage

� Representasi tempat penyimpanan data

� Notasi: dua garis paralel

� Data flow in = diubah, data flow out = dibaca

� Control bar

� Representasi spesifikasi kontrol

� Notasi: garis tegak

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

10

1

Proses A

data X

Process Model – 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 harusdiinterpretasikan untuk merubah perilaku sistem dan/ aktifasi proses

� Proses pemodelan DFD/CFD adalah proses iterasi, tidak sekali jadi

� Penjenjangan CFD harus sesuai dengan DFD

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

11

Data – Control Identification

� 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

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

12

Process Model – DFD/CFD

Leveling

� Must be consistent

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

13

Examples

� Vending Machine System

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

14

Data/Control Context Diagram

(DCD/CCD)

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

15

Vendproduct

Customer

returned coins

0*

Customer

product

object

customer

selection

slug

coin return

request product

available

Data/Control Flow Diagram

(DFD/CFD Level 1)

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

16

1*

Get

customer

payment

2p

Get

product

price

3p

Validate

payment

4p

Get valid

selection

5*

Dispense

change

6p

Dispense

product

price table

coins

products

returned

coins

product

object

customer

selection

slug

coin return

request

payment

price

valid

selection

change due

valid

selection

coin detectedsufficient

payment

product

dispensed

product

available

product

available

Data/Control Flow Diagram

(DFD/CFD Level 2)

� DFD/CFD level 2 : Dispense change

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

17

5.1p

Get

change

coin

coin return

request

5.2p

Get

payment

coin

product

availablechange due

coins

payment

payment

coins

change coinsreturned

coins

Process Model – Process

Specification (PSPEC)� PSPEC – Validate payment (Process 3)

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

18

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

� CSPEC – Dispense change : Process Activation Table (PAT)

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

19

coin return request

product available

get change coin

get payment

coin

TRUE TRUE 1 0

D/C FALSE 0 1

Behavior Model (contn’d)

� State Transition Diagram (STD)

Rekayasa dan Manajemen Kebutuhan | Requirements Modeling - Structured

20

Waiting for a coin

Waiting for selection

Dispensing product

Returning payment

initial

accept new coin

payment returned

accept new coincoin detected

accept customer

requestproduct dispensed

accept new coin

sufficient payment

dispense product

product

available=FALSE

return payment

coin return request

return payment