Modul Praktikum APS 2017

Modul Praktikum Analisis dan Perancangan Sistem Halaman 1 dari 58
Praktikum Analisis dan Perancangan

REKAYASA KEBUTUHAN
1.1. TUJUAN PRAKTIKUM :
a) Mahasiswa mampu memahami konsep rekayasa kebutuhan

b) Mahasiswa mampu memahami proses-proses dalam rekayasa kebutuhan
c) Mahasiswa mampu menerapkan teori-teori elisitasi kebutuhan
d) Mahasiswa mampu menyusun kebutuhan perangkat lunak
e) Mampu melakukan verifikasi kebutuhan sesuai dengan parameter
1.2. DASAR TEORI
Konsep Rekayasa Kebutuhan

Kebutuhan adalah kondisi atau kemampuan yang dibutuhkan oleh user
untuk mengatasi suatu masalah atau untuk mencapai tujuan tertentu. Kondisi
atau kemampuan yang harus dimiliki oleh sistem untuk memenuhi sebuah kontrak,
standar, spesifikasi atau dokumen resmi yang ditetapkan. Kata rekayasa
(engineering) sendiri memiliki arti yaitu proses atau serangkaian kegiatan yang
terstruktur untuk mengelola serangkaian sumber daya sehingga membentuk
suatu sistem yang memiliki nilai bagi penggunanya.
Sommervile (2007) mengartikan bahwa rekayasa kebutuhan (software
engineering) sebagai suatu proses mewujudkan serangkaian layanan yang
dibutuhkan oleh pelanggan atas suatu sistem dan batasan-batasan yang harus
dipenuhi ketika dibangun maupun dioperasikan. Kebutuhan dikategorikan
menjadi 3 jenis :
1) Kebutuhan Fungsional
2) Kebutuhan Non Fungsional
3) Usability

Proses rekayasa kebutuhan perangkat lunak terdiri dari beberapa aktifitas
yaitu:
a) Elisitasi dan analisis kebutuhan
b) Spesifikasi kebutuhan
c) Validasi dan verifikasi kebutuhan
d) Manajemen kebutuhan
Elisitasi dan Analisis Kebutuhan

Elisitasi atau pengumpulan kebutuhan merupakan aktifitas awal dalam proses
rekayasa kebutuhan. Proses elisitasi kebutuhan dilakukan sebelum kebutuhan
dapat dianalisis, dimodelkan, atau ditetapkan. Elisitasi kebutuhan adalah
sekumpulan aktifitas yang ditujukan untuk menemukan kebutuhan suatu sistem
melalui komunikasi dengan pelanggan, pengguna sistem dan pihak lain yang
memiliki kepentingan dalam pengembangan sistem (Sommervile and Sawyer,
1997).
Pada aktivitas ini berbagai kebutuhan dari para pemangku kepentingan
dikumpulkan. Pemangku kepentingan (stakeholder) setiap adalah pihak yang
memiliki kepentingan terhadap proyek pengembangan perangkat lunak.
Pemangku kepentingan dapat diklasifikasikan sebagai berikut: pelanggan, pemilik
modal, pemilik sistem, pengguna, regulator, penyelia, pengembang, analis sistem,
dan programmer.
Berikut ini merupakan langkah-langkah untuk elisitasi kebutuhan (Sommervile
and Sawyer, 1997):
1) Identifikasi orang-orang yang akan membantu menentukan kebutuhan
dan memahami organisasi. Menilai kelayakan bisnis dan teknis untuk
sistem yang di usulkan.
2) Menentukan lingkungan teknis (misalnya, komputasi arsitektur, sistem
operasi, kebutuhan telekomunikasi) kemana sistem atau produk akan
ditempatkan.
3) Identifikasi ranah permasalahan, yaitu karakteristik lingkungan bisnis
yang spesifik ke ranah aplikasi

4) Menentukan satu atau lebih metode elisitasi kebutuhan misalnya
wawancara, discussion group, dan pertemuan tim.
5) Meminta partisipasi dari banyak orang sehingga dapat mereduksi
dampak dari kebutuhan yang bias yang bisa muncul dari sudut pandang
yang berbeda dari pemangku kepentingan.
6) Mengidentifikasi kebutuhan yang ambigu dan menyelesaikannya.
7) Membuat skenario penggunaan untuk membantu pelanggan/
pengguna mengidentifikasi kebutuhan utama.
Contoh:
Deskripsikan pemangku kepentingan dari sistem layanan ATM suatu bank.
Jawab:
1) Nasabah Bank: yaitu orang yang menerima layanan sistem
2) Representatif dari bank lain: bank yang melakukan perjanjian timbal
balik penggunaan ATM untuk para nasabah
3) Manajer Bank: orang yang memperoleh informasi manajemen dari
sistem
4) Administrator Basis data: orang yang bertanggung jawab untuk
menggabungkan sistem dengan basis data nasabah.
Dalam melakukan elisitasi terdapat beberapa teknik yang dapat membantu
analis:
1) Wawancara, pada saat wawancara analis sistem memberikan
beberapa pertanyaan kepada pemangku kepentingan tentang sistem
yang digunakan (existing) dan sistem yang akan dikembangkan.
Beberapa panduan yang perlu diperhatikan pada saat wawancara
adalah: pemilihan narasumber (interviewer) yang potensial, membuat
perjanjian dengan narasumber potensial, menyiapkan struktur
pertanyaan yang lengkap dan jelas, dan memilih orang yang
diwawancarai secara pribadi dan merekamnya.
2) Kuisioner, didesain dengan menggunakan standar kuisioner, kuisioner
dikirim ke lingkungan kerja end-user, dan struktur respon diringkas
dalam statistik distribusi.

3) Observasi, kegiatan ini dilakukan dengan mengunjungi lokasi
pengamatan dan merekam kejadian dalam lokasi pengamatan
termasuk volume dan pengolahan lembar kerja.
4) Prototyping, adalah versi awal dari sistem perangkat lunak yang
digunakan untuk mendemonstrasikan konsep, mencoba pilihan
rancangan, dan secara umum, mencari lebih jauh tentang kesalahan
dan solusi yang dimungkinkan.
Spesifikasi Kebutuhan
Spesifikasi kebutuhan adalah proses untuk menjelaskan kebutuhan PL yang
telah didefinisikan sebelumnya secara lebih detil dan tepat yang akan menjadi
dasar bagi perancangan dan implementasi.
Contoh :
Definisi kebutuhan (requirement definition) :
1. PL harus mampu menyediakan sarana untuk menampilkan dan mengakses
file-file yang dibuat oleh tool yang lain. (SRS_PRJ_100)
Spesifikasi kebutuhan (requirement specification) :
1.1 Pengguna harus disediakan fasilitas untuk mendefinisikan tipe file.
(SRS_PRJ_101)
1.2 Setiap tipe file direpresentasikan dengan ikon tertentu pada layar
pengguna. (SRS_PRJ_102)
Panduan penyusunan kebutuhan (SMART)

Dalam konteks penyusunan hendaklah menspesifikasi kebutuhan yang SMART.
Tujuannya bukanlah untuk membuktikan bahwa spesifikasi kebutuhan yang telah
ditetapkan sudah benar secara teknis (yaitu bahwa kebutuhan yang dinyatakan
adalah benar-benar yang dibutuhkan, tapi lebih kepada agar spesifikasi kebutuhan
tersebut dapat dicek dan diverifikasi kebenarannya dari aspek ekspresi (bukan isi)
1) Specific (spesifik)
Setiap kebutuhan harus menyebutkan tepat seperti yang dibutuhkan.
Hindari penggunaan asumsi dalam menginterpretasikan arti sebuah
kalimat kebutuhan.
2) Measureable (terukur)
Suatu kebutuhan akan diuji nanti ketika selesai dibangun, sehingga
penting untuk menyusun kalimat kebutuhan yang terukur sehingga
memudahkan dalam melakukan pengujian.
3) Attainable (dapat dicapai)
Memastikan bahwa kebutuhan yang didefinisikan dapat dicapai sesuai
dengan batas-batas kekuatan dan pengetahuan manusia.
4) Realizable (dapat direalisasikan)
Suatu kebutuhan haruslah dapat direalisasikan dengan
mempertimbangkan sumber daya yang dimiliki.
5) Traceable/bounded (memiliki dimensi waktu/dapat dilacak)
Suatu kebutuhan hendaklah dapat diselesaikan atau direalisasikan
dalam waktu yang telah ditentukan. Dalam hal ini adalah sesuai dengan
rencana proyek (project plan). Selain itu kebutuhan juga perlu suatu
mekanisme untuk menjustifikasi alasan keberadannya. Kebutuhan
mungkin muncul karena ada kebutuhan lainnya.
Validasi dan verifikasi kebutuhan

Proses ini dilakukan untuk memastikan bahwa seluruh kebutuhan yang telah
didapatkan telah didefinisikan dan dispesifikasikan adalah benar, akurat dan
lengkap. Parameter validasi:
1) Validity, apakah sistem menyediakan semua fungsi yang mendukung
semua yang dibutuhkan oleh customer?
2) Consistency, apakah ada kebutuhan yang konflik?
3) Comprehensibility, apakah semua fungsi yang diinginkan customer
sudah tercakup didalamya? (kelengkapan)
Parameter verifikasi:
1) Readability
2) Testability
3) Completeness
4) Identifiability
5) Ambiguity

Manajemen kebutuhan
Aktifitas untuk melakukan kontrol terhadap kebutuhan yang sedang maupun
telah didefinisikan dan dispesifikasikan :
1) Identifikasi, bagaimana setiap kebutuhan dapat diidentifikasi dengan
mudah (Cont. : SRS_PRJ_XXX, IRS_PRJ_XXX)
2) Manajemen perubahan, bagaimana mekanisme untuk menangani
perubahan kebutuhan yang terjadi
3) Dokumentasi, SRS dan IRS sebagai deliverable, ECP, PCR
4) Tracking, penelusuran informasi yang berhubungan dengan sebuah
kebutuhan (sumber/asal, alokasi ke perancangan)
1.3. SOAL-SOAL LATIHAN
STUDI KASUS :
Vario Advertising merupakan perusahaan biro iklan yang terletak di Jalan
Soekarno Hatta Malang. Vario didirikan pada tahun 2000. Awalnya perusahaan ini
berkonsentrasi pada periklanan untuk industri motor indonesia, yang sebagian
besar pemasarannya di daerah Jawa dan Bali. Namun seiring berjalannya waktu,
perusahaan diperluas menuju skala internasional dan memiliki klien di berbagai
industri manufaktur dan jasa. Strategi perusahaan bertujuan untuk terus tumbuh
perlahan-lahan dan mengembangkan ke pasar internasional.
Dalam menjalankan bisnisnya Vario Advertising bekerjasama dengan
perusahaan lain yang bisa disebut juga sebagai klien. Setiap kerjasama yang
dilakukan oleh Vario terdapat dokumentasi yang selalu dibuat dan disimpan
secara baik. Disamping itu dalam melakukan kerjasama biasanya dari pihak klien
akan mengirimkan beberapa perwakilannya untuk melakukan komunikasi dan
koordinasi dengan Vario. Begitu juga dengan Vario, mengirimkan wakilnya untuk
melakukan koordinasi dengan klien. Perwakilan dari vario memungkinkan
bertanggung jawab pada klien yang berbeda dalam pekerjaan yang berbeda pula.
Tentunya hal seperti ini perlu dikelola secara benar agar tiak overlap, baik target
kerja, pengelolaan dana, dan penjadwalan kerja.

Untuk mendukung skala bisnis internasional, perusahaan memiliki strategi
dengan berfokus dalam membangun suatu sistem informasi guna membantu
aktifitas proses bisnis yang berjalan diperusahaan tersebut. Beberapa aktifitas dan
kebutuhan yang perlu didefinisikan dalam sistem tersebut terangkum sebagai
berikut
Sistem mampu merekam detail informasi klien termasuk order layanan
kampanye iklan. Dalam perekaman informasi setiap klien, data terkait nama,
alamat, kontak klien harus masuk didalamnya. Selain itu dalam pencatatan
informasi layanan order kampanye iklan, harus terekam terkait judul kampanye,
tanggal mulai dan selesai pelaksanaan kampanye, estimasi biaya, biaya riil, dan
tanggal pembayaran. Selanjutnya setelah perekaman telah dilakukan maka sistem
mampu menyediakan suatu fungsi mencetak invoice bagi klien yang dapat
dieksekusi oleh lebih dari satu akun staf yang tersedia di sistem tersebut.
Demikian pula dengan proses pembayaran yang dilakukan oleh klien juga dapat
dilayani oleh beberapa akun yang tersedia di sistem dan terekam secara baik. Pada
kebutuhan ini sistem nantinya juga perlu untuk merekam informasi tentang staf
yang ditugaskan untuk terlibat dalam proses produksi iklan beserta kampanye
iklan untuk tiap klien termasuk mencatat manager proyek yang terlibat dalam
kampanye. Selanjutnya sistem juga dapat mekakukan pengecekan status
kampanye, baik proses produksi hingga akhir pelaksaaan kampanye dan
kesesuaian dengan biaya yang tersedia.
Sistem mampu menyediakan fungsi bagi staf kreatif untuk merekam rincian
proses produksi iklan termasuk proses pengembangan konsep kampanye iklan.
Rincian proses produksi iklan yang dimaksud adalah kemampuan sistem untuk
merekam catatan ide detail untuk kampanye dan konsep iklan yang bisa diakses
atau dilihat oleh staf lain termasuk didalamnya informasi progress produksi hingga
penjadwalan kampanye iklan dimulai hingga selesai.
Sistem mampu menyediakan fungsi merekam detail informasi seluruh staf
perusahaan bagi staf. Detail informasi staf yang direkam antara lain pengelolaan
data staf kreatif dan staf administratif. Disamping itu juga sistem harus mampu
untuk menyediakan fungsi bagi staf keuangan dan manajer proyek untuk
memberikan grade nilai kepada staf dan mengakomodir proses pembayaran staf

berdasarkan grade nilai tersebut dan terekam dalam sistem. Selain itu sistem juga
perlu mengakomodir fungsi untuk menghitung bonus tahunan dari setiap staf
berdasarkan kinerja .
Dalam sistem yang dibangun, perusahaan menginginkan data terkait dengan
klien, kampanye, iklan dan staf dapat diakses antar kantor yang berbeda dan untuk
kemudahan pengoperasian, sistem diharapkan dapat diakses menggunakan
beberapa bahasa yang berbeda pula.
1. Tentukanlah domain permasalahan yang mungkin ditemukan di lapangan

terkait dengan studi kasus tersebut!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
2. Tentukanlah pemangku kepentingan beserta dengan deskripsinya!

_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
3. Susunlah pertanyaan-pertanyaan untuk melakukan elisitasi kebutuhan.
Pertanyaan-pertanyaan tersebut dikelompokan berdasarkan pemangku
kepentingan yang terkait. Selain itu tentukan juga metode apa yang cocok
untuk melakukan elisitasi!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

4. Susunlah pernyataan kebutuhan sesuai dengan konsep SMART. Kelompokan
berdasarkan kategorinya: Kebutuhan Fungsional, Kebutuhan Non Fungsional,
dan Usability.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
5. Perhatikan dan analisis kebutuhan berikut ini:

1) Sistem dapat melayani permintaan peminjaman ruang rapat secara
bersamaan dengan cepat.
2) Ketika modul X memanggil modul Z, berkas catatan pesannya
diperbaharui.
3) Sistem tentunya dapat menyimpan dokumentasi rapat dalam format
bervariasi, seperti misalnya: JPG, TIF, BMP, dsb.
Apakah kebutuhan tersebut telah memenuhi aspek Spesific (S) pada konsep
SMART? Jelaskan jawaban Anda kemudian perbaiki kebutuhan tersebut
apabila belum memenuhi aspek Specific (S).
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

1) Sistem dapat memproses data permohonan rapat dengan cepat dan
akurat.
2) Besaran berkas yang diunggah pada dokumen notulensi rapat tidak
terlalu besar ukurannya.

Apakah kebutuhan tersebut telah memenuhi aspek Measureable (M) pada
konsep SMART? Jelaskan jawaban Anda kemudian perbaiki kebutuhan
tersebut apabila belum memenuhi aspek Measureable (M).
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

1) Sistem memiliki tingkat ketersediaan 100% dan dapat dihandalkan
100%.
2) Sistem akan bekerja 24 jam / hari serta 365 hari/ tahun tanpa
berhenti.
3) Sistem dapat mengirimkan data maksimal 10 TB per detik.
Apakah kebutuhan tersebut telah memenuhi aspek Attainable (A) pada
tersebut apabila belum memenuhi aspek Attainable (A).
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

1) Sistem akan memiliki ketersediaan ruang rapat 97%.
Apakah kebutuhan tersebut telah memenuhi aspek Realizeable (R) pada
tersebut apabila belum memenuhi aspek Realizeable (R).
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

_______________________________________________________________
_______________________________________________________________
9. Berdasarkan kebutuhan yang telah didefinisikan pada studi kasus: Sistem

Informasi Manajemen Ruangan dan Notulensi Rapat, lakukan proses validasi
dan verifikasi kebutuhan berdasarkan parameter-parameter yang telah
ditentukan.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

PEMODELAN KEBUTUHAN TERSTRUKTUR
a) Mahasiswa mampu memahami konsep-konsep pemodelan dalam rekayasa
kebutuhan.
b) Mahasiswa mampu memahami konsep pendekatan terstruktur dalam
pemodelan kebutuhan.
c) Mahasiswa mampu memahami konsep pendekatan berorientasi obyek dalam
pemodelan kebutuhan.
1.2. DASAR TEORI

A. Konsep Pemodelan Kebutuhan
Pemodelan dalam pengembangan perangkat lunak bermaksud untuk
menggambarkan sistem dalam bentuk yang lebih mudah dipahami. Kebutuhan
adalah suatu hal dalam pengembangan perangkat lunak yang perlu dimodelkan.
Tujuan dari pemodelan kebutuhan antara lain adalah:
Menjelaskan apa saja kebutuhan dari pengguna,
Menjadi dasar dari pengembangan perangkat lunak,
Menjadi referensi dalam proses validasi kebutuhan.
Pemodelan kebutuhan terdapat dua pendekatan, yaitu pendekatan
Terstruktur dan Berorientasi Objek. Terdapat beberapa prinsip dalam
memodelkan kebutuhan, antara lain adalah:
Model kebutuhan yang dibuat harus sesuai dengan kebutuhan pada domain
permasalahan, what bukan how.
Model kebutuhan harus bisa dilacak pada model perancangan yang dihasilkan
pada fase perancangan.
Model kebutuhan disajikan dengan lengkap dan mampu memperjelas
pemahaman secara utuh tentang domain permasalahan, fungsionalitas dan
perilaku sistem.

Model kebutuhan hendaknya dapat mengurangi tingkat keterkaitan antar
modul/klas (kopling).
Model kebutuhan harus dapat memberikan nilai manfaat bagi seluruh
stakeholder
Model kebutuhan direpresentasikan dalam notasi yang sederhana dan
meniadakan duplikasi, sehingga dapat dengan mudah dipahami oleh
stakeholder.
Tipe-tipe model kebutuhan antara lain adalah:
Scenario-based Models
Model kebutuhan yang menggambarkan sistem dari sudut pandang aktor.
Data Models
Model kebutuhan yang menggabarkan model data atau informasi dari domain
permasalahan.
Class-oriented Models
Model kebutuhan yang menggambarkan model klas yang relevan dengan
domain permasalahan.
Flow-oriented Models
Model kebutuhan yang menggambarkan suatu aliran yang terjadi di dalam
sistem. Aliran data dan proses dapat digambarkan menggunakan model flow-
oriented model.
Behavioral Models
Model perilaku dari sistem dalam menanggapi even-even dari luar sistem.
B. Pemodelan Terstruktur
Konsep perancangan sistem dengan pendekatan terstruktur (Structural
Analysis) pertama kali diperkenalkan oleh Tom DeMarco pada tahun 1979. Tom
DeMarco menuliskan penjelasannya tentang pendekatan terstruktur pada
bukunya yang berjudul Structured Analysis and System Specification. Dalam
buku tersebut penekanan utamanya adalah pada proses spesifikasi struktur
domain masalah.

Terdapat tiga hal yang diperhatikan dalam pemodelan kebutuhan dengan
pendekatan terstruktur, yaitu, pemodelan data, proses dan perilaku dari sistem.
Penggambaran data menggunakan Entity Relationship Diagram (ERD),
penggambaran proses menggunakan Data Flow Diagram/ Control Flow Diagram
(DFD/CFD), dan penggambaran perilaku menggunakan State Transition Diagram
(STD). Terdapat juga beberapa model yang melengkapi penjelasan ketiga model
terdahulu seperti, Data Dictionary (kamus data), PSPEC (Process Specification),
dan CSPEC (Control Specification). Gambar 2.1 menunjukkan elemen-elemen
pemodelan kebutuhan dengan pendekatan terstruktur.
Gambar 2.1. Elemen-Elemen dalam Pemodelan Kebutuhan
Data Dictionary
Kamus data atau systems data dictionary adalah katalog fakta tentang data
dan kebutuhan-kebutuhan informasi dari suatu sistem informasi. Dengan Data
Dictionary analis sistem dapat mendefinisikan data yang mengalir di sistem
dengan lengkap.
Entity Relationship Diagram (ERD)
Terdapat beberapa pertanyaan yang dapat mempermudah dalam
perancangan model data, antara lain adalah:

Apa objek data utama yang diproses oleh sistem?
Bagaimana komposisi masing-masing objek data dan apa saja atributnya?
Di mana objek-objek data tersebut saat ini berada?
Apa hubungan antara masing-masing objek?
Apa hubungan antara obyek dan proses yang mengubah mereka?
Komponen-komponen yang harus ada pada pemodelan data adalah entitas,
atribut, relasi, kardinalitas dan modalitas. Gambar 2.2 menggambarkan contoh
gambaran entitas dan relasinya.
Gambar 2.2. Entity Relationship Diagram
Data Flow Diagram/ Control Flow Diagram (DFD/ CFD)

Data Flow Diagram/ Control Flow Diagram dapat digunakan untuk
menggambarkan dekomposisi proses dari sistem yang ada dalam rangka
pengembangan sistem yang baru. DFD/ CFD fokus pada peredaran data dari
entitas ke proses, proses ke proses, dan proses ke data store. Selain itu CFD juga
dapat menggambarkan perilaku proses yang terjadi pada sistem. DFD/ CFD
memiliki beberapa level detail. Model yang paling tinggi disebut sebagai Diagram
Kontek (Context Diagram). Elemen-elemen model DFD/ CFD adalah sebagai
berikut:
1. Terminator/ External Entity
Representasi entitas eksternal
External Entity
Notasi: persegi panjang
Tidak memproses data
2. Data Flow
Representasi aliran data
Notasi: anak panah penuh
Umumnya satu arah
Hubungkan terminator, process dan storage

3. Control Flow
Representasi aliran kontrol proses
Notasi: anak panah putus2
Hubungkan terminator, process dan control bar
4. Process
Representasi aktifitas sistem
1
Notasi: lingkaran
Memproses data Prosess A
5. Storage
Representasi tempat penyimpanan data
Notasi: dua garis paralel
Data flow in = diubah, data flow out = dibaca
6. Control Bar
Representasi spesifikasi kontrol
Notasi: garis tegak
Beberapa hal yang harus diperhatikan dalam menyusun DFD/ CFD adalah sebagai
berikut:
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
Proses pemodelan DFD/CFD adalah proses iterasi, tidak sekali jadi
Penjenjangan CFD harus sesuai dengan DFD

DFD/ CFD merupakan model yang memiliki beberapa level detail. Mulai dari level
konteks, level 1 dan seterusnya. Semakin kebawah semakin khusus. Diagram pada
level bawah menjelaskan satu proses pada level atasnya. Gambar 2.3
memperlihatkan gambaran level yang ada pada DFD/ CFD.
Gambar 2.3. Gambaran Level pada DFD/ CFD
State Transition Diagram (STD)

State Transition Diagram adalah model yang menggambarkan tentang
perilaku sistem. STD menjelaskan perilaku sistem yang terkait dengan perubahan
state yang terjadi pada sistem. State adalah sebuah kondisi yang terlihat oleh
pengguna atau user. Dalam pembuatan STD, terdapat beberapa hal yang harus
didefinisikan, antara lain adalah State, Event, dan Action. Gambar 2.4
menunjukkan gambaran notasi STD.
Gambar 2.4. Contoh STD

Untuk mempermudah dalam pembuatan STD, terdapat beberapa langkah:
1. Buatlah daftar state dari sistem yang terlihat oleh pengguna.
2. Tunjukkan bagaimana sistem melakukan transisi dari satu state ke state yang
lain.

3. Definisikan event sebagai suatu kejadian yang memicu transisi antar state.
4. Definisikan action (aksi) yang dilakukan sistem.
5. Gambarlah STD.
1. Buatlah Data Flow Diagram untuk kasus studi Vario Advertising pada Modul
Praktikum Rekayasa Kebutuhan.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
2. Buatlah process specification (P-Spec) dari DFD yang telah dibuat sebelumnya!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
3. Buatlah control specification (C-Spec) dari DFD yang telah dibuat sebelumnya!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
4. Buatlah data dictionary dari DFD yang telah dibuat sebelumnya!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

5. Perhatikan diagram berikut ini: ER
a) Menurut Anda, apakah ERD diatas sudah benar? Jelaskan jawaban Anda!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
b) Jika terdapat kesalahan, lakukan analisis terhadap kesalahan yang terjadi pada
ERD tersebut dan gambarkan ulang hasil perbaikannya!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
c) Setelah diperbaiki, amati dan jelaskan makna ERD tersebut dalam bahasa Anda
sendiri!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
6. Perhatikan deskripsi sistem dan context diagram berikut ini :

Sistem reservasi hotel adalah sistem yang berfungsi untuk membantu para
calon tamu dalam memesan kamar hotel. Tamu dapat mengisi formulir data
diri, menentukan tipe kamar dan dapat memberikan permintaan khusus.
Permintaan khusus ini menentukan ada atau tidaknya dan bagaimana
tambahan fasilitas kamar yang disediakan oleh pihak hotel. Kemudian sistem
dapat memberikan informasi harga kamar dari hotel kepada calon tamu.
Setelah pemesanan dilakukan maka tamu akan mendapatkan bukti
pemesanan kamar hotel. Kemudian dari sisi pihak hotel, pihal hotel akan
mendapatkan detail data pemesanan kamar dan data diri tamu. Pihak hotel
dapat mempublikasikan informasi tentang kondisi kamar yang dapat dipesan.
Pihak hotel memiliki informasi tentang ketersediaan kamar yang menentukan
pemesanan dapat dilakukan atau tidak.

a) Menurut Anda, apakah context diagram di atas sudah benar secara aturan
sintaks dan apakah sudah sesuai dengan deskripsi sistem yang sudah
dijelaskan? Jelaskan jawaban Anda!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
b) Jika terdapat kesalahan, lakukan analisis terhadap kesalahan yang terjadi pada
context diagram tersebut dan gambarkan ulang hasil perbaikannya!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
7. TPL airline adalah maskapai penerbangan terbaik di Indonesia. TPL airline

dapat melayani pelanggannya dengan baik, sehingga setiap tahun jumlah
pelanggannya semakin bertambah. Pada tahun 2007, pada saat pertama kali
TPL airline terbentuk, TPL airline telah memiliki 1000 pelanggan pada tahun
pertama. Hingga pada tahun 2017 ini, pelanggan TPL airline telah mencapai
lebih dari 5000 pelanggan. Untuk meningkatkan jumlah pelanggan, TPL airline
membuat sistem reservasi tiket pesawat online sehingga pelanggan yang ingin
menggunakan jasa TPL airline dapat memesan dan mendapatkan tiket tanpa
harus datang ke loket TPL airline. Selain hal tersebut, TPL airline juga
memberikan promo khusus berupa diskon 20% bagi pelanggan yang membeli
tiket lebih dari lima.
a) Buatlah ERD dari kasus yang terdapat pada ilustrasi tersebut!

_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

_______________________________________________________________
_______________________________________________________________
b) Buatlah Context Diagram dan Data Flow Diagram Level 1 dari kasus yang
terdapat pada ilustrasi tersebut!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
c) Buatlah State Transition Diagram dari kasus yang terdapat pada ilustrasi
tersebut!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

PEMODELAN KEBUTUHAN BERORIENTASI OBJEK
1.1. TUJUAN PRAKTIKUM:

Memahami konsep pendekatan berorientasi objek dalam pemodelan kebutuhan
1.2. DASAR TEORI

Pendekatan berorientasi objek merupakan suatu teknik atau cara pendekatan
baru dalam melihat permasalahan dari sistem (sistem perangkat lunak, sistem
informasi, atau sistem lainnya). Pendekatan berorientasi objek dipopulerkan pada
akhir tahun 1980an 1990an oleh Booch, Rumbaugh-OMT, Jacobson-OOSE, Coad
dan Yourdon, Wirfs-Brock.
Pendekatan berorientasi objek akan memandang sistem yang akan
dikembangkan sebagai suatu kumpulan objek yang berkorespondensi dengan
objek-objek dunia nyata. Ada banyak cara untuk mengabstraksikan dan
memodelkan objek-objek tersebut, mulai dari abstraksi objek, kelas, hubungan
antar kelas sampai abstraksi sistem. Saat mengabstraksikan dan memodelkan
objek ini, data dan proses-proses yang dipunyai oleh objek akan dienkapsulasi
(dibungkus) menjadi satu kesatuan.
Hal-hal yang perlu dilakukan dalam memodelkan berorientasi objek meliputi:
Elisitasi kebutuhan customer
Identifikasi skenario / use-case (use-case diagram)
Identifikasi klas berdasarkan kebutuhan customer
Identifikasi atribut dan operasi setiap klas
Definisi struktur klas (class diagram)
Definisi model relasi antar klas (collaboration/sequence diagram)
Definisi perpindahan status sistem (statechart diagram)
Pada tahun 1996, bahasa yang digunakan untuk pemodelan berorientasi objek
dibuatlah UML (Unified Modeling Language). UML dibuat oleh Grady Booch,
James Rumbaugh dan Ivar Jacobson.

Kelebihan dari pemodelan berorientasi objek meliputi:
Sangat natural, sesuai dengan cara berpikir manusia
Dapat meningkatkan interaksi antara ahli domain masalah dengan
analis
Meningkatkan konsistensi hasil analisis
Hal ini dikarenakan dengan pemodelan berorientasi objek, mampu
mengabstraksikan atribut hingga operasi dalam sebuah objek
Konsep penurunan klas memberikan kemudahan dalam generalisasi
objek
Kemudahan dalam perubahan
Terjaganya konsistensi model antara analisis dan perancangan
Konsep reusability
KOMPONEN PADA PEMODELAN OO
Object
Menurut Rumbaugh definisi objek adalah sebuah konsep, abstraksi, atau
sesuatu yang memiliki batasan dan masalah utama serta bersifat tangible dan
intangible (sesuatu yang bisa diraba atau tidak). Karakteristik dari sebuah objek
adalah memiliki identity (identitas-pembeda), state (sekumpulan atribut) &
behaviour (sekumpulan operasi, aksi, servis).
Contoh dari objek pada sistem akademik adalah: Andi, Eko, Susi.
Notasi dari objek:
Nma Objek
Atribut2
Operasi2
Gambar 3.1 Notasi Objek
Class
Menurut Yourdon, class (klas) adalah sebuah deskripsi dari satu atau lebih
objek yang memiliki kesatuan dari atribut dan layanan/operasi yang sama
termasuk bagaimana membuat objek baru dalam klas.

Fungsi dari sebuah klas adalah sebagai gambaran umum (template, blue-print)
yang menjelaskan sekumpulan objek yang memiliki kesamaan karakteristik
(atribut dan operasi) dan cetakan dari objek. Dimana sebuah kelas akan
mempunyai sifat (atribut), kelakuan (operasi), hubungan (relationship) dan arti.
Dan suatu klas dapat diturunkan dari kelas yang lain, dimana atribut dari kelas
semula dapat diwariskan ke kelas yang baru. Klas juga digunakan untuk
menginstansiasi objek yang memiliki identitas yang berbeda.
Contoh 1: Klas Mahasiswa objek Andi, Eko, Susi
Klas memiliki bentuk abstract dan concrete. Dimana klas abstrak adalah klas
yang berasal dari sesuatu yang bersifat abstrak.
Contoh 2:
Gambar 3.2 Kelas Abstrak
Pemodelan berorientasi objek juga berfungsi untuk menemukan domain

masalah. Langkah-langkah dalam menentukan objek dan klas adalah:
Observasi langsung ke dunia industri atau lapangan (Observe first-hand)
Secara aktif menggali permasalahan dengan pertanyaan apa, siapa,
bagaimana, kapan mengapa
Selalu melihat hasil dari analisis berorientasi objek sebelumnya
Melakukan perbandingan dengan sistem yang lain
Sering membaca untuk mendapatkan informasi
Yang harus diperhatikan dalam menentukan objek dan klas adalah dengan
memperhatikan kata benda yang muncul pada domain masalah seperti:

Struktur
Perhatikan relasi antar objek termasuk ke dalam jenis generalisasi atau
agregasi
Sistem lainnya
Perlu diperhatikan juga sistem lain yang berinteraksi dengan sistem
yang akan dibangun
Sesuatu hal atau kejadian yang disimpan
Data, status atau kejadian yang harus disimpan dalam sistem
Role played
Identifikasi peran manusia dalam sistem apakah berinteraksi langsung
atau tidak berinteraksi tetapi informasinya disimpan dalam sistem
Lapangan
Informasi lokasi/posisi yang harus diingat oleh sistem
Identifikasi Atribut
Beberapa data (informasi data) yang dimiliki oleh setiap objek yang ada dalam
klas objek (Yourdan).
Langkah dalam menentukan atribut:
Identifikasi atribut umum (adjectives, possessives)
Identifikasi atribut yang relevan dengan domain masalah
Identifikasi atribut yang relevan dengan peran atau tanggung jawab
dalam sistem
Restrukturisasi atribut sehingga atomic yang bisa memunculkan
kemudahan
Reposisi atribut yang sesuai dengan hirarki klas nya yang menyebabkan
terjadinya pewarisan klas
Spesifikasi atribut seperti presisi, nilai default, batasan, dll.
Identifikasi Operasi/Layanan
Kegiatan spesifik/tertentu yang dilakukan oleh sebuah objek sendiri [Yourdon]
Langkah-langkah dalam mengidentifikasi operasi/layanan:
Identifikasi tanggung jawab umum sebuah klas (verbs)
Identifikasi operasi yang spesifik untuk domain masalah

Identifikasi operasi yang relevan dengan peran atau tanggung jawab
dalam sistem
Spesifikasi operasi yang berasal dari argumen, batasan/aturan,
logika/algoritma
DIAGRAM UML
UML adalah salah satu standar bahasa yang banyak digunakan di dunia industri
untuk mendefinisikan requirement, membuat analisis dan desain serta
menggambarkan arsitektur dalam pemrograman berorientasi objek. UML
berfungsi untuk melakukan pemodelan.
Use Case Diagram
Use Case merupakan pemodelan untuk kelakuan sistem informasi yang akan
dibuat. Use Case menjelaskan perilaku sistem dari tampak luar dan menyediakan
fungsi-fungsi yang harus dipenuhi sistem sesuai dengan aktornya. Elemen-elemen
yang ada pada use case adalah actor dan use case. Actor adalah orang, proses atau
sistem lain yang berinteraksi dengan sistem informasi. Sedangkan use case
merupakan fungsionalitas yang disediakan sistem sebagai unit-unit yang saling
bertukar pesan antar unit atau aktor.
Langkah-langkah dalam membuat use case:
Identifikasi aktor
Identifikasi use-case per aktor
Simbol-simbol yang digunakan pada use case adalah:
Tabel 1. Simbol Use Case
No Simbol (Nama) Deskripsi
1 use case fungsionalitas yang disediakan sistem sebagai unit-unit yang
saling bertukar pesan antar unit/aktor. Biasanya dinyatakan
dengan menggunakan kata kerja awal di awal frase nama
Nama use case use case.
2 aktor orang, proses atau sistem lain yang berinteraksi dengan

sistem informasi yang akan dibuat.
3 asosiasi komunikasi antar aktor/ use case yang berpartisipasi pada

use case atau use case memiliki interaksi dengan aktor.

4 ekstensi/ extend relasi use case tambahan ke sebuah use case dimana use
<<extend>> case yang ditambahkan dapat berdiri sendiri walau tanpa
use case tambahan itu
5 generalisasi hubungan generalisasi antara dua buah use case dimana

fungsi yang satu adalah fungsi yang lebih umum dari lainnya
6 include relasi use case tambahan ke sebuah use case dimana use
<<include>> case yang ditambahkan memerlukan use case ini untuk
menjalankan fungsinya atau sebagai syarat dijalankan use
case ini
Setiap use case yang dibuat, dilengkapi dengan skenario. Skenario use case
adalah alur jalannya proses use case dari sisi aktor dan sistem. Bentuk skenario use
case bisa dilihat pada gambar di bawah ini:
Tabel 2. Usecase Scenario
Flow of events for the Select product use-case
Objective Allow customer to select a certain product to dispense
Actors Customer
Pre-condition Coin detected and valid
Main flow
The customer selects a button product.

The system displays an entry prompt of number of product to order.
Alternative flows If the selected product is not available, the system will display a message
Your selected product is not available.
If the selected product is available but there isnt enough number to
order, the system will display a message The number isnt enough, max.
x. X is the existing number of the product.
Post-condition The selected product dispensed as the number needed

Pada use case asosiasi, terdapat include dan extend seperti yang ditunjukkan
pada tabel 1. Include digunakan pada saat sebuah use case menggunakan use case
lainnya (functional decomposition). Penggunaan include sebagai sebuah fungsi
yang berada pada pernyataan masalah utama yang sangat rumit untuk
diselesaikan sesegera mungkin. Sehingga include wajib ada jika dibutuhkan
sebuah fungsi agregasi untuk sebuah fungsi yang lebih sederhana. Extend
digunakan pada saat ada use case yang ditambahkan dapat berdiri sendiri. Fungsi
dari sebuah pernyataan permasalahan utama perlu dilakukan sebuah
perpanjangan. Sehingga bisa disimpulkan bahwa extend menghubungkan use
case untuk memiliki peran sebagai use case opsional.
Actor-Generalization
Dua atau lebih sub-aktor digeneralisikan dari super aktor. Sehingga sub-aktor
tersebut memiliki behavior/operasi/layanan dan atribut yang dimiliki oleh super
aktor. Super aktor harus berinteraksi dengan use case ketika semua sub-aktor
berinteraksi dengan cara yang sama. Sub-aktor harus berinteraksi dengan use case
ketika interaksi use case berbeda dengan super aktor. Class Diagram (Diagram Klas)
Diagram klas atau class diagram menggambarkan struktur sistem dari segi
pendefinisian klas-klas yang akan dibuat untuk membangun sistem. Class yang ada
pada struktur sistem harus dapat melakukan fungsi-fungsi sesuai dengan
kebutuhan sistem.
Class Diagram (Diagram Klas)
Diagram klas atau class diagram menggambarkan struktur sistem dari segi
pendefinisian klas-klas yang akan dibuat untuk membangun sistem. Class yang ada
pada struktur sistem harus dapat melakukan fungsi-fungsi sesuai dengan
kebutuhan sistem. Class diagram memiliki node/klas dan relasi. Jenis relasi pada
class diagram meliputi:

Tabel 3. Notasi Diagram Klas
No Simbol/Nama Deskripsi
1 Klas klas pada struktur sistem
nama_klas
+atribut()
+operasi()
2 interface sama dengan konsep interface dalam

pemrograman berorientasi objek
3 asosiasi relasi antar klas dengan makna umum
4 asosiasi berarah relasi antar klas dengan makna klas yang satu
digunakan oleh klas yang lain
5 generalisasi relasi antar klas dengan makna generalisasi-

spesialisasi (umum-khusus)
6 agregasi relasi antar klas dengan makna semua bagian
7 kebergantungan/dependency relasi antar klas dengan makna

kebergantungan antar klas
Class Stereotype
Dalam sebuah diagram klas, dibutuhkan sebuah template agar diagram klas
yang dibuat sesuai dengan sistem yang akan dibangun. Berikut merupakan
komponen yang harus ada pada sebuah diagram klas:
Boundary class
Boundary class merupakan sebuah model dalam sistem yang menunjukkan
bagaimana sistem berinteraksi dan berkomunikasi antara sistem komputer

dengan aktor, tetapi tidak secara langsung menggambarkan implementasi dari
antarmuka objek secara spesifik. Boundary class berfungsi untuk mengidentifikasi
antarmuka logis utama antara user dengan sistem lain seperti perangkat lunak lain
atau printer. Tugas utama dari boundary class adalah untuk menterjemahkan
informasi antar batasan sistem. Boundary class merupakan bagian dari sistem
dimana sebuah antarmuka akan dipisahkan dengan Business logic.
Entity class
Entity class digunakan untuk memodelkan data dan behavior/operasi/layanan
dari konsep sistem sesungguhnya atau entitas. Seperti member, bank account,
order, employee. Bagian ini akan membutuhkan penyimpanan lebih untuk sebuah
informasi. Sebagai contoh detail dari mahasiswa yang akan disimpan sebagai
record mahasiswa.
Control class
Control class berfungsi untuk menggambarkan koordinasi, urutan, transaksi
dan kontrol dari objek lain. Seperti halnya sebuah keterikatan antara elemen
boundary dan elemen entitas, yang bisa menggambarkan kebutuhan logis untuk
mengatur berbagai macam elemen dan interaksinya. Dibutuhkan minimal satu
Control class untuk setiap use case.
Contoh dari stereotype class dapat dilihat pada gambar di bawah ini:
<<control>>
<<boundary> <<boundary>>
Actor 1 >
Actor 2
<<entity>> <<entity>>
Gambar 3.3 Stereotype Klas
Sequence Diagram
Diagram sekuen menggambarkan perilaku objek pada use case dengan
mendeskripsikan waktu hidup objek dan message yang dikirimkan dan diterima
antar objek. Oleh karena itu harus diketahui objek-objek yang terlibat dalam
sebuah use case beserta metode-metode yang dimiliki klas yang diinstansiasi
objek tersebut.
boundary entity control
Diagram sekuen yang dibuat minimal sebanyak pendefinisian use case yang
memiliki proses sendiri atau interaksi jalannya pesan sudah diidentifikasi. Elemen-
elemen yang ada pada diagram sekuen adalah objek, garis putus-putus dan pesan.
Fungsi dari tiap elemen dari diagram sekuen:
Objek: menggambarkan objek yang berinteraksi pesan. Wujud dari elemen ini
adalah kotak.
Dashed line atau garis putus-putus: menyatakan kehidupan sebuah objek dan
disebut sebagai lifeline.
Message/pesan: digambarkan dalam bentuk panah dengan garis horizontal
yang berfungsi melewatkan pesan dari objek ke objek yang lain sebagai tanda
bahwa objek tersebut melewati jalur hidupnya.
1. Berdasarkan studi kasus : Vario Advertising, lakukan identifikasi aktor yang

terlibat dalam sistem dan buat pula daftar spesifikasi kebutuhan yang mampu
menghubungkan peran actor terhadap kebutuhan sistem!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
2. Berdasarkan studi kasus : Vario Advertising, buatlah usecase diagram
berdasarkan peran actor dan usecase scenario berdasarkan pandangan
setelah membaca soal cerita di atas!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

_______________________________________________________________
_______________________________________________________________
3. Berdasarkan soal cerita diatas, lakukan analisis sequence diagram termasuk
identifikasi objek-objek yang saling berinteraksi satu dengan yang lain
berdasarkan kebutuhan yang telah di definisikan sebelumnya !
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
4. Berdasarkan soal cerita diatas, lakukan analisis class diagram termasuk

identifikasi objek-objek yang perlu didefinisikan dalam sistem yang akan
dibangun
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

5. Berdasarkan usecase lakukan analisis diagram tersebut dari sisi semantik dan
sintaksis

PEMODELAN PERANCANGAN TERSTRUKTUR
1.1. TUJUAN PRAKTIKUM
a) Mahasiswa mampu memahami konsep pemodelan perancangan terstruktur

b) Mahasiswa mampu menerapkan langkah-langkah perancangan terstruktur
c) Mahasiswa mampu menyusun perancangan yang memenuhi parameter
kualitas perancangan
d) Mahasiswa mampu menyusun algoritma dalam perancangan
1.2. DASAR TEORI
Konsep Perancangan
Pemodelan perancangan terstruktur adalah metode untuk memodelkan suatu
rancangan yang dibangun dengan pendekatan terstruktur. Pemodelan ini
menggunakan model DFD (Data Flow Diagram) sebagai dasar dalam
mentransformasi (Transform Mapping).
Langkah-langkah dalam melakukan Transform Mapping adalah sebagai berikut.
1. Review dan refine DFD sampai ke level paling bawah.
Pada proses ini, DFD pada level terbawah kemudian digabung menjadi satu
perspektif. Sebagai contoh DFD berikut.
6.3*
Sensor
Format for
information
display
Configuration Configuration
Information Sensor ID, type,
data location
6.2*
Assess Against
Setup
6.4*
Alarm data Generate Alarm
Signal Alarm type
Sensor ID, type Telephone

number
6.1
Read Sensor
6.5* Telephone
Sensor status Dial Phone Number tones
Gambar 4.1 DFD level 2: Monitor sensors

Pada gambar satu terdapat lima proses dimana proses enam poin dua, tiga,
dan lima merupakan proses-proses yang harus didekomposisi. Sedangkan proses
enam poin 1 dan 4 tidak perlu didekomposisi, sehingga hasil dekomposisinya
menjadi seperti gambar berikut.
Format ID, type,

location Sensor Dekomposisi
Configuration 6 9 Information
information Format display Generate Display
Proses 6.3
Configuration
data
Sensor ID, type, 7 Alarm type

Sensor Status location Generate alarm
signal
1
Read Sensor
Alarm data
2 Telephone
Sensor ID, tones
Acquire response
Type
info
3
Alarm cond code, Establish 8
Sensor ID, Alarm Generate pulses
timing information condition 4 to line
List of Select phone 5
number number Set up conn. To
Telephone phone net Tone ready Dekomposisi
Dekomposisi number Telephone number Proses 6.5
Proses 6.2
Gambar 4.2 DFD level 3: Monitor sensors
2. Tentukan apakah DFD tsb. memiliki karakteristik tipe transform flow atau
transaction flow.
Untuk dapat menentukan karakteristik DFD memiliki tipe transform flow atau
transaction flow maka dapat kita lihat contoh DFD berikut.
Gambar 2.3 Contoh DFD memiliki tipe transform flow

Pada gambar tiga merupakan DFD yang bertipe transform flow. Pada DFD ini
terdapat tiga bagian yaitu:
Incoming flow : aliran/ jalur informasi eksternal masuk ke sistem untuk
ditransformasikan menjadi informasi internal,
Transform center : pusat transformasi di dalam sistem yang akan me-
trigger informasi keluar dari sistem,
Outgoing flow: aliran/ jalur informasi internal keluar dari sistem
menjadi informasi eksternal.
Gambar 4.4 Contoh DFD memiliki transaction flow
Pada gambar tiga merupakan DFD yang bertipe transaction flow. Pada DFD ini
terdapat tiga bagian yaitu:
Transaction: data tunggal yang me-trigger satu atau beberapa aliran
data,
Transaction center: penghubung antara aliran-aliran data hasil pen-
trigger-an dengan data trigger-nya,
Action path: aliran/ jalur informasi hasil trigger.
Perbedaan mendasar dari kedua jenis DFD di atas adalah jika pada Transform
Flow, informasi dari incoming flow akan dirubah menjadi informasi internal dan
akan diproses oleh transform center untuk kemudian digunakan oleh outgoing
flow. Sementara jika pada transaction flow adalah informasi atau transaction akan
menentukan action path mana yang akan dilewati.
Jadi jika ada informasi kemudian berubah menjadi informasi lain maka kita bisa
gunakan transform flow. Sementara jika ada informasi yang sifatnya semacam

kondisi yang dapat mengaktifkan proses yang berbeda-beda maka sebaiknya kita
pilih transaction flow.
3. Tentukan batas antara incoming flow, transform center dan outgoing flow
atau incoming path/transaction, transaction center dan action path.
Untuk menentukan batas tentunya harus memahami proses dan informasi
yang dibuat. Jika sudah dapat menentukan jenis DFD yang dibuat selanjutnya
dapat menentukan batasnya. Sebagai contoh adalah gambar berikut.
Format ID, type,

location Sensor
Configuration 6 9 Information
information Format display Generate Display
Configuration
data
INCOMING FLOW
Sensor ID, type, 7 Alarm type

Sensor Status location Generate alarm
signal OUTGOING FLOW
1
Read Sensor
Alarm data
2 Telephone
Sensor ID, tones
Acquire response
Type
info
3
Alarm cond code, Establish 8
Sensor ID, Alarm Generate pulses
timing information condition 4 to line
List of Select phone 5
number number Set up conn. To
Telephone phone net Tone ready
number Telephone number
TRANSFORM
CENTRE
Gambar 4.5 Penentuan Incoming, transform center, outgoing flow.
4. Bangun first level factoring.

DFD yang sudah dipetakan pada gambar lima kemudian di transformasi
menjadi arsitektur modul (lihat gambar 5). Incoming Flow dibuat ke dalam modul
sensor input controller. Transform Center dibuat kedalam modul alarm conditions
controller. Outgoing Flow dibuat ke dalam modul alarm output controller.

Configuration
information 6 9
7
1
2
3
8
4
5
Monitor Sensor
Executive
Sensor Input Alarm Condition Alarm Output

Controller Controller Controller
Gambar 4.6 First Level Factoring : Monitor Sensor.
Untuk gambar enam kemudian juga dilakukan first level factoring menjadi
arsitektur modul yang tergambar pada gambar berikut.
User
System parameters
Command Raw
and data
Configuration
data
Formatted
Read user Command
Configuration
command type Read System Build
data
data configuration file
Configuration information
Configure
Invoke command
processing Start/stop
Configuration data
Activate/
deactive A/D Data
system
Display messages
Password and status
Configuration
data Display
Password information
Read
Password
Valid Password
Compare
Four Digits password with
file
Produce
Try Again message
invalid message
Invalid Password
Gambar 4.7 First Level Factoring: Transaction Flow User Interaction.

5. Bangun second level factoring.
Second level factoring adalah proses untuk memetakan proses-proses yang
ada pada masing-masing incoming flow, transform center, outgoing flow ke dalam
bagian-bagian pada modul yang sudah ada pada first level factoring. Sebagai
contoh adalah gambar berikut.
Monitor Sensor
Executive
Sensor Input Alarm Condition Alarm Output

Alarm Output Alarm Output Alarm Output Alarm Output Alarm Output Alarm Output
Controller Controller Controller Controller Controller Controller
Alarm Output Alarm Output Alarm Output

Gambar 4.8 Second Level Factoring: Monitor Sensor.
Proses Second Level Factoring untuk contoh transaction flow (gambar 8)

kemudian menjadi bentuk gambar berikut.
User interaction
interactive
Invoke command
Read user command
processing
System configuration Activate/deactive Password processing

controller system controller
Build configuration Compare password Password output

Ready system data Read Password
controller with file controller
Display message and Produce invalid

status message
Gambar 4.9 Second Level Factoring: User Interaction.

6. Refine first iteration.
Proses selanjutnya adalah refine first iteration yaitu proses untuk membuat
desain menjadi sederhana, memiliki kohesifitas yang tinggi, tingkat kopling yang
rendah dan memiliki struktur yang mudah untuk diimplementasikan. Hasil dari
first level factoring kemudian diubah menjadi bentuk lebih sederhana pada
gambar berikut.
Monitor Sensor
Executive
Sensor Input Establish alarm Alarm Output

Controller condition Controller
Alarm Output Set up conn to phone

Read Sensor Produce Display
Controller net
Generate pulse to line
Gambar 4.10 Hasil Refine First Iteration: Monitor Sensor.
Incoming controller dihapus: data input tunggal, cukup sederhana.

Transform controller dihapus dan digabung dalam satu modul: ada
penurunan tingkat kohesifitas.
Format display dan generate display digabung: sederhana.
Hasil first level factoring untuk gambar 10 menjadi bentuk yang lebih
sederhana tampak pada gambar berikut.

User Interaction
Executive
Invoke command
Read user command
processing
System Configuration Activate/deactive Password processing

controller system controller
System Configuration System Configuration System Configuration System Configuration System Configuration
controller controller controller controller controller
Gambar 4.11 Hasil Refine First Iteration: User Interaction.
Setelah semua tahap dilalui, kemudian langkah terakhir adalah menggabung

keseluruhan arsitektur modul kedalam satu rangkaian arsitektur modul. Hasil
penggabungan arsitektur Software Safehome Security dapat dilihat pada gambar
berikut.
Safe home
security
Monitor
Sensor
Executive
User Interaction
Executive
Establish Alarm
Sensor Input
alarm Output
Controller
condition Controller
Invoke
Read user
command
command Alarm
processing Produce Set up conn
Read Sensor Output
Display to phone net
Controller
System Password Generate

Activate/
Configuration processing pulse to line
deactive system
controller controller
System System System System System

Configuration Configuration Configuration Configuration Configuration
controller controller controller controller controller
Gambar 4.12 Arsitektur Modul SafeHome Security.
Masing-masing modul kemudian berisi algoritma yang didapatkan dari

P-SPEC, C-SPEC pada masing-masing proses yang ada pada DFD.

Pseudocode
Pseudocode adalah metode penulisan bahasa inggris sederhana yang
merepresentasikan lojik algoritma pemrograman. Pseudo berarti tiruan,
sedangkan Code adalah kode program sehingga pseudocode bisa disebut sebagai
kode tiruan dari program sebenarnya yang dituliskan dalam standar bahasa inggris
untuk mendekatkan dengan perintah-perintah yang terdapat pada bahasa
pemrograman. Setiap Pseudocode akan selalu terdiri dari tiga bagian yaitu :
Judul (Header)
{Berisi Judul Algoritma/ method}
Kamus ( Deklarasi )
{Berisi Deklarasi Variabel atau Konstantan}
Algoritma ( Deskripsi )
{Berisi Inti Algoritma}
Gambar 4.13 contoh pseudocode
1. Berdasarkan DFD yang telah dibuat untuk studi kasus: Vario Advertising
tentukan karakteristik DFD tersebut.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

2. Gambarkan batas-batas pada DFD tersebut sesuai dengan karakteristiknya!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
3. Lakukan First Level Factoring
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
4. Lakukan Second level factoring.

_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
5. Lakukan Refine First level factoring.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

PEMODELAN PERANCANGAN BERORIENTASI OBJEK
a) Memahami konsep OOD.

b) Mahasiswa mampu mentransformasikan model kebutuhan kedalam model
perancangan OO dengan UML.
c) Menjelaskan proses normalisasi dari class diagram yang telah ada di dalam
dokumen kebutuhan.
d) Mahasiswa dapat menentukan object-object dinamis dari suatu class dan
mengambarkan state diagram dari object-object tersebut.
e) Mahasiswa mampu menyusun dan merancang komponen (algoritma).
1.2. DASAR TEORI
Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di
sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message
yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal
(waktu) dan dimensi horizontal (objek-objek yang terkait). Sequence diagram
biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah
yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output
tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan
perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.
Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message
digambarkan sebagai garis berpanah dari satu objek ke objek lainnya.
Pada fase desain berikutnya, message akan dipetakan menjadi operasi/
metoda dari class yang akan dijelaskan pada sub bab berikutnya. Activation bar
menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan
diterimanya sebuah message. Untuk objek-objek yang memiliki sifat khusus,
standar UML mendefinisikan ikon khusus untuk objek boundary, controller dan

persistent entity. Penjelasan dapat dilihat pada Gambar 1. Contoh sequence
diagram dapat dilihat pada Gambar 2.
Gambar 5.1 Notasi squence diagram
Gambar 5.2 Contoh squence diagram

Class diagram
Objek adalah gambaran dari entity, baik dunia nyata atau konsep dengan
batasan batasan dan pengertian yang tepat. Objek bisa mewakili sesuatu yang
nyata seperti komputer, mobil atau dapat berupa konsep seperti proses kimia,
transaksi bank, permintaan pembelian, dll. Setiap objek dalam sistem memiliki tiga
karakteristik yaitu State (status), Behaviour (sifat) dan Indentity (identitas).
Cara mengidentifikasi objek:
1. pengelompokan berdasarkan kata/frase benda pada skenario.
2. berdasarkan daftar kategori object, antara lain:
objek fisik, contoh:pesawat telepon
spesifikasi/rancangan/deskripsi, contoh: deskripsi pesawat
tempat, contoh:gudang
transaksi, contoh: penjualan
butir yang terlibat pada transaksi, contoh: barang jualan
peran, contoh :pelanggan
wadah, contoh : pesawat terbang
piranti, contoh:PABX
kata benda abstrak, contoh: kecanduan
kejadian, contoh:pendaratan
aturan atau kebijakan, contoh:aturan diskon
catalog atau rujukan, contoh: daftar pelanggan
Klas adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan

sebuah objek atau dengan kata lain Klas merupakan template untuk membentuk
object. Klas merupakan inti dari pengembangan dan desain berorientasi objek.
Klas menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus
menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/ fungsi).
Class diagram menggambarkan struktur dan deskripsi class, package dan
objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi,
dan lain-lain.

Class memiliki tiga area pokok :
1. Nama (dan stereotype)
2. Atribut
3. Metoda/operasi
Penamaan class menggunakan kata benda tunggal yang merupakan abstraksi
yang terbaik. Atribut dan metoda dapat memiliki salah satu sifat berikut :
Private (-) , tidak dapat dipanggil dari luar class yang bersangkutan
Protected (#) , hanya dapat dipanggil oleh class yang bersangkutan dan anak
anak yang mewarisinya
Public (+) , dapat dipanggil oleh siapa saja
- names
- address
+ CreditRating():String
Gambar 5.3 Contoh Class Diagram
Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak
yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan,
tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian
interface mendukung resolusi metoda pada saat run-time. Sesuai dengan
perkembangan class model, class dapat dikelompokkan menjadi package. Kita
juga dapat membuat diagram yang terdiri atas package.
Hubungan Antar Class

Dalam Obyek Oriented Design, klas-klas yang terbentuk dapat memiliki
hubungan satu dengan yang lainnya, sesuai dengan kondisi dari klas-klas yang
bersangkutan. Secara umum, hubungan antar kelas dapat dibedakan menjadi
Asosiasi, agregasi, komposisi, dependency, inheritance, realization.

Gambar 5.4 Notasi relasi antar klas
Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class

yang memiliki atribut berupa class lain, atau class yang harus mengetahui
eksistensi class lain. Panah navigability menunjukkan arah query antar class.
Contoh :
Klas diagram dalam kasus Dosen Mengajar Mahasiswa. 1 Dosen dapat
mengajar banyak Mahasiswa. Dalam hubungan asosiasi, di dalam Klas Dosen ada
link atribut nim mahasiswa yg diperoleh dari Klas Mahasiswa.
Gambar 5.5 contoh Asosiasi
Agregasi, yaitu hubungan yang menyatakan suatu klas adalah bagian (terdiri
atas kumpulan) dari klas yg lain, namun kedua klas ini bisa berdiri sendiri.
Merupakan hubungan yang lebih kuat dari hubungan asosiasi.
Contoh :
Klas Jurusan menyimpan nilai atribut dari mahasiswa dengan tipe data
Klas bentukan Mahasiswa.
Mahasiswa dapat memiliki objek sendiri
Jurusan dapat memiliki objek sendiri
Mahasiswa menjadi bagian dari jurusannya.
1 jurusan bisa memiliki banyak mahasiswa.

Gambar 5.6 contoh Agregasi
Komposisi, merupakan bentuk khusus dari Agregasi di mana kelas yang

menjadi part (bagian) baru dapat diciptakan setelah kelas yang menjadi whole
(seluruhnya) dibuat dan ketika kelas yang menjadi whole dimusnahkan, maka
kelas yang menjadi part ikut musnah.
Contoh :
Hubungan komposisi antara sebuah laptop dengan komponennya.
Contoh objek:
Laptop Asus A43S memiliki CPU intel core i7; VGA Nvidia 2GB;
Laptop Toshiba S006 memiliki CPU intel core i5; VGA Nvidia 2GB;
Nilai CPU dan VGA tidak bisa didapat jika tidak melalui nilai objek Laptop. Ada
ketergantungan penuh dari class CPU & VGA ke Laptop, dengan Kata lain jika
Laptop tidak ada maka CPU dan VGA juga tidak ada.
Gambar 5.7 contoh Komposisi
Dependency, yaitu hubungan dimana satu klas tergantung/menggunakan klas

yang lain secara langsung.
Contoh :

Klas Car menggunakan attribut atau method yang ada di Klas Wheel secara
langsung tanpa instansiasi objek Wheel.
Gambar 5.8 contoh Dependency
Pewarisan (inheritance), yaitu hubungan hirarkis antar class. Class dapat

diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya
dan menambahkan fungsionalitas baru, sehingga ia disebut anak (subclass) dari
class yang diwarisinya (superclass). Operasi pada superclass dapat di-override oleh
subclass (konsep polymorphism). Kebalikan dari pewarisan adalah generalisasi.
Contoh :
Klas Shape adalah super class dari Klas Square dan Circle, sehingga atribut dan
method Klas Shape diwarisi oleh Klas Square dan Circle namun Klas Square dan
Circle bisa memiliki atribut maupun method yg spesifik.
Gambar 5.9 contoh Inheritance
Realization, Hubungan antara Interface dan Klas, di mana suatu Klas (klien)
mengimplement perilaku dari interface namun secara spesifik menentukan
perilaku di dalam Klas.
Interface adalah prototype klas yang berisi definisi konstanta dan deklarasi
perilaku/method (hanya nama method tanpa definisi kode programnya).

Ciri sebuah interface:
Semua atribut adalah public dan final (semua atribut bertindak sebagai
konstanta). Dapat juga menambahkan modifier static.
Semua method adalah abstract dan public
Tidak boleh ada deklarasi konstruktor.
Contoh :
Gambar 5.10 contoh Realization
State Transiton Diagram

Use case dan skenario menyediakan cara untuk menggambarkan kelakuan
sistem yakni interaksi antara object-object di dalam sistem. Kadang-kadang
diperlukan untuk melihat kelakuan di dalam object. State transition diagram
menunjukkan state-state dari object tunggal, event-event atau pesan yang
menyebabkan transisi dari satu state ke state yang lain, dan action yang
merupakan hasil dari perubahan sebuah state. State transition diagram tidak akan
dibuat untuk setiap class di sistem. State transition diagram hanya dibuat untuk
class yang berkelakuan dinamis.
State adalah sebuah kondisi selama kehidupan sebuah object ketika object
memenuhi beberapa kondisi, melakukan beberapa action, atau menunggu sebuah
event. State dari sebuah object dapat dikarakteristikkan oleh nilai dari satu atau
lebih atribut- atribut dari class. State-state dari sebuah object ditemukan dengan

pengujian/pemeriksaan atribut- atribut dan hubungan-hubungan dari object.
State transition diagram meliputi seluruh pesan dari object yang dapat mengirim
dan menerima. Skenario merepresentasikan satu jalur yang melewati sebuah state
transition diagram. Jarak waktu antara dua pesan yang dikirim oleh sebuah object
merepresentasikan sebuah state. Masing- masing diagram harus mempunyai satu
dan hanya satu start state ketika object mulai dibuat namun sebuah object boleh
mempunyai banyak stop state.
State
Gambar 5.11 Notasi untuk State
Event
Perubahan (transition) dari sebuah state ke state lainnya diakibatkan oleh
sebuah event digambarkan oleh state transition. Event yang menyebabkan
perubahan tersebut dituliskan di atas garis panah.
Pseudocode
Pseudocode adalah metode penulisan bahasa inggris sederhana yang
merepresentasikan lojik algoritma pemrograman. Pseudo berarti tiruan,
sedangkan Code adalah kode program sehingga pseudocode bisa disebut sebagai
kode tiruan dari program sebenarnya yang dituliskan dalam standar bahasa inggris
untuk mendekatkan dengan perintah-perintah yang terdapat pada bahasa
pemrograman. Setiap Pseudocode akan selalu terdiri dari tiga bagian yaitu :
Judul (Header)
{Berisi Judul Algoritma/ method}
Kamus ( Deklarasi )
{Berisi Deklarasi Variabel atau Konstantan}
Algoritma ( Deskripsi )
{Berisi Inti Algoritma}

Gambar 5.12 contoh pseudocode
1. Berdasarkan analisis klas modul pemodelan kebutuhan OO, buatlah klas

perancangan yang siap untuk di implementasikan
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
2. Sesuaikan diagram sekuens sesuai dengan level perancangan.

_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
3. Untuk setiap method pada klas yang telah diidentifikasi dalam soal No.1, buat
pseudocode-nya sesuai dengan kasus yang telah diuraikan!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

STUDI KASUS : DESAIN KLAS
Pabrik perakitan mobil tersebut berkeinginan untuk membuat program
aplikasi berbasis Web atau Desktop dengan kasus penggunaan sebagai berikut:
a. Simulasi perakitan mobil dilakukan oleh seorang Operator
b. Simulasi yang dapat dilakukan adalah simulasi pembuatan, pemasangan, dan
operasi yang dapat dilakukan oleh seluruh komponen Mobil
c. Proses simulasi sistem yang dilakukan oleh hanya dapat dilakukan setelah
seorang Manajer mengaktifkan program simulasi
d. Visualisasi proses simulasi yang dilakukan ditampilkan dalam dua antarmuka,
satu untuk Operator dan satu untuk Manajer.
e. Operator dapat melakukan seluruh operasi simulasi dan melihat tampilan
simulasi secara visual.
f. Selain dapat mengaktifkan dan menonaktifkan program simulasi, seorang
Manajer dapat melihat seluruh rangkaian proses simulasi.
Jawablah beberapa soal berikut dengan tepat, jelas, dan spesifik!
1. Lakukan analisis fungsionalitas dan penggunaan sistem lengkap dan lakukan

pemodelan dengan menggunakan Model Use Case (Use Case Diagram dan Use
Case Specification) berdasarkan kasus penggunaan program yang telah
diuraikan!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
2. Gambarkan aktivitas skenario penggunaan program/ sistem dalam Activity

Diagram.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

_______________________________________________________________
_______________________________________________________________
3. Lakukan analisis Boundary, Control, dan Entity dalam untuk setiap aktivitas
yang tergambar dalam skenario penggunan/use case scenario dan wujudkan
dalam Sequence Diagram.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
4. Gambarkan objek yang telah diidentifikasi dalam soal No.3 dan lengkapi
dengan jenis relasi, kardinalitas, dan modalitas antar class dalam Class
Diagram!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
5. Gambarkan Class Diagram lengkap beserta atribut, method, visibility, relasi,

kardinalitas, dan modularitas relasi antar objek yang diperoleh dari hasil
analisis class dan analisis Boundary, Control, dan Entity sehingga siap untuk
diimplementasikan!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

6. Lakukan analisis State yang mungkin untuk kasus penggunaan yang telah
diuraikan dan gambarkan dalam State Transition Diagram!
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________

Modul Praktikum APS 2017

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Modul Praktikum APS 2017

Diunggah oleh

Hak Cipta:

Format Tersedia

Modul Praktikum Analisis dan Perancangan Sistem Halaman 1 dari 58

Praktikum Analisis dan Perancangan

a) Mahasiswa mampu memahami konsep rekayasa kebutuhan

1.2. DASAR TEORI

Konsep Rekayasa Kebutuhan

Modul Praktikum Analisis dan Perancangan Sistem Halaman 2 dari 58

Elisitasi dan Analisis Kebutuhan

Modul Praktikum Analisis dan Perancangan Sistem Halaman 3 dari 58

Modul Praktikum Analisis dan Perancangan Sistem Halaman 4 dari 58

Panduan penyusunan kebutuhan (SMART)

Validasi dan verifikasi kebutuhan

Modul Praktikum Analisis dan Perancangan Sistem Halaman 6 dari 58

1.3. SOAL-SOAL LATIHAN

Modul Praktikum Analisis dan Perancangan Sistem Halaman 7 dari 58

Modul Praktikum Analisis dan Perancangan Sistem Halaman 8 dari 58

1. Tentukanlah domain permasalahan yang mungkin ditemukan di lapangan

2. Tentukanlah pemangku kepentingan beserta dengan deskripsinya!

Modul Praktikum Analisis dan Perancangan Sistem Halaman 9 dari 58

5. Perhatikan dan analisis kebutuhan berikut ini:

6. Perhatikan dan analisis kebutuhan berikut ini:

Modul Praktikum Analisis dan Perancangan Sistem Halaman 10 dari 58

7. Perhatikan dan analisis kebutuhan berikut ini:

8. Perhatikan dan analisis kebutuhan berikut ini:

Modul Praktikum Analisis dan Perancangan Sistem Halaman 11 dari 58

9. Berdasarkan kebutuhan yang telah didefinisikan pada studi kasus: Sistem

Modul Praktikum Analisis dan Perancangan Sistem Halaman 12 dari 58

1.2. DASAR TEORI

Modul Praktikum Analisis dan Perancangan Sistem Halaman 13 dari 58

Modul Praktikum Analisis dan Perancangan Sistem Halaman 14 dari 58

Gambar 2.1. Elemen-Elemen dalam Pemodelan Kebutuhan

Modul Praktikum Analisis dan Perancangan Sistem Halaman 15 dari 58

Gambar 2.2. Entity Relationship Diagram

Data Flow Diagram/ Control Flow Diagram (DFD/ CFD)

Modul Praktikum Analisis dan Perancangan Sistem Halaman 16 dari 58

fungsi-fungsi yang saling berhubungan dikelompokkan

fungsi-fungsi yang tidak berhubungan dipisahkan

setiap fungsi dispesifikasi hanya sekali

Modul Praktikum Analisis dan Perancangan Sistem Halaman 17 dari 58

Gambar 2.3. Gambaran Level pada DFD/ CFD

State Transition Diagram (STD)

Gambar 2.4. Contoh STD

Modul Praktikum Analisis dan Perancangan Sistem Halaman 18 dari 58

1.3. SOAL-SOAL LATIHAN

Modul Praktikum Analisis dan Perancangan Sistem Halaman 19 dari 58

6. Perhatikan deskripsi sistem dan context diagram berikut ini :

Modul Praktikum Analisis dan Perancangan Sistem Halaman 21 dari 58

7. TPL airline adalah maskapai penerbangan terbaik di Indonesia. TPL airline

a) Buatlah ERD dari kasus yang terdapat pada ilustrasi tersebut!

Modul Praktikum Analisis dan Perancangan Sistem Halaman 22 dari 58

Modul Praktikum Analisis dan Perancangan Sistem Halaman 23 dari 58

1.1. TUJUAN PRAKTIKUM:

1.2. DASAR TEORI

Modul Praktikum Analisis dan Perancangan Sistem Halaman 24 dari 58

Gambar 3.1 Notasi Objek

Modul Praktikum Analisis dan Perancangan Sistem Halaman 25 dari 58

Gambar 3.2 Kelas Abstrak

Pemodelan berorientasi objek juga berfungsi untuk menemukan domain

Modul Praktikum Analisis dan Perancangan Sistem Halaman 26 dari 58

Modul Praktikum Analisis dan Perancangan Sistem Halaman 27 dari 58

2 aktor orang, proses atau sistem lain yang berinteraksi dengan

3 asosiasi komunikasi antar aktor/ use case yang berpartisipasi pada

Modul Praktikum Analisis dan Perancangan Sistem Halaman 28 dari 58

5 generalisasi hubungan generalisasi antara dua buah use case dimana

Objective Allow customer to select a certain product to dispense