�ݺ�ߣ

REQUIREMENT MODELLING
Requirements Modeling: Scenario-Based Methods
1. Pendahuluan
 Definisi: Scenario-Based Requirements Modeling adalah teknik pemodelan
yang menggunakan skenario (cerita atau narasi) untuk menggambarkan
interaksi antara pengguna dan sistem yang akan dikembangkan.
 Tujuan: Membantu pengembang untuk memahami kebutuhan
pengguna dengan cara yang lebih nyata dan mendalam, serta
memberikan konteks yang lebih terarah.
2. Peran Skenario dalam Pemodelan Kebutuhan
 Skenario sebagai Komunikasi Kebutuhan: Menggambarkan interaksi
pengguna yang konkret dan membantu pemangku kepentingan dalam
memahami bagaimana sistem akan bekerja dari sudut pandang
pengguna.
 Penghubung antara Stakeholder dan Pengembang: Skenario
memungkinkan diskusi dan validasi antara pengguna dan pengembang.
 Jenis Skenario: Skenario dapat berkisar dari skenario penggunaan
sederhana hingga skenario yang lebih kompleks untuk mengakomodasi
kasus-kasus khusus.
3. Use Case Modeling
 Pengertian Use Case: Use case adalah deskripsi sederhana dari suatu
rangkaian langkah-langkah yang dilakukan oleh pengguna saat
berinteraksi dengan sistem untuk mencapai tujuan tertentu.
 Komponen Utama dalam Use Case:
o Aktor: Pengguna atau entitas eksternal yang berinteraksi dengan
sistem.
o Tujuan: Hasil yang ingin dicapai oleh aktor.
o Alur Utama (Main Flow): Langkah-langkah utama dalam interaksi.
o Alur Alternatif (Alternative Flow): Langkah-langkah tambahan
yang mungkin terjadi.
1

 Mengembangkan Use Case: Langkah-langkah dalam mengidentifikasi
aktor, menentukan tujuan setiap aktor, dan mendefinisikan alur utama
serta alternatif.
4. Use Case Diagram
 Diagram UML: Diagram use case adalah alat grafis yang digunakan
untuk menggambarkan interaksi antara aktor dan use case dalam sistem.
 Elemen dalam Use Case Diagram:
o Aktor: Direpresentasikan sebagai simbol manusia atau objek
eksternal.
o Use Case: Direpresentasikan dalam bentuk oval.
o Hubungan: Hubungan antara aktor dan use case, seperti asosiasi,
generalisasi, dan dependensi.
 Keuntungan Diagram Use Case: Memberikan gambaran menyeluruh
tentang sistem, membantu dalam identifikasi kebutuhan fungsional, dan
memudahkan komunikasi antar tim.
5. Benefits dari Scenario-Based Modeling
 Pemahaman Mendalam tentang Kebutuhan Pengguna: Menjelaskan
alur interaksi pengguna secara detail.
 Pengujian dan Validasi Awal: Skenario memudahkan tim untuk
memvalidasi kebutuhan dengan pengguna sebelum implementasi
dimulai.
 Manajemen Kebutuhan yang Lebih Baik: Dengan skenario, tim
pengembang dapat lebih mudah menyesuaikan kebutuhan jika ada
perubahan.
6. Langkah-Langkah dalam Requirements Modeling Berbasis Skenario
 1. Identifikasi Aktor: Tentukan siapa saja yang akan berinteraksi dengan
sistem (user, administrator, sistem eksternal).
 2. Definisikan Tujuan: Tentukan tujuan yang ingin dicapai oleh setiap
aktor.
 3. Buat Use Case: Tentukan langkah-langkah atau alur yang akan
dilakukan aktor untuk mencapai tujuan.
2

 4. Desain Alur Alternatif: Identifikasi alur alternatif yang mungkin
muncul.
 5. Buat Diagram Use Case: Visualisasikan interaksi antara aktor dan use
case dalam bentuk diagram.
7. Contoh Studi Kasus: Sistem Pemesanan Tiket Online
 Aktor: Pelanggan, Petugas Layanan, Sistem Pembayaran.
 Use Case: Melakukan pemesanan tiket, melakukan pembayaran,
memeriksa status pemesanan.
 Diagram Use Case: Visualisasi interaksi antara pelanggan dan sistem
dalam diagram use case.
8. Diskusi dan Kesimpulan
 Review Use Case: Lakukan review terhadap use case dan diagram untuk
memastikan semua kebutuhan telah tercakup.
 Kesimpulan: Scenario-Based Methods adalah pendekatan yang efektif
untuk memahami kebutuhan pengguna dan memberikan dasar yang
kuat bagi proses pengembangan perangkat lunak.
3

Tipe-tipe model requirements dalam requirements modeling berdasarkan
berbagai perspektif untuk memahami dan merancang sistem secara
menyeluruh:
1. Scenario-Based Models
 Deskripsi: Scenario-Based Models menggambarkan persyaratan dari
sudut pandang aktor atau pengguna sistem, yaitu entitas yang
berinteraksi dengan sistem untuk mencapai tujuan tertentu.
 Contoh: Use Case Diagrams atau skenario pengguna yang menunjukkan
bagaimana pengguna akan menggunakan sistem dalam situasi nyata.
 Tujuan: Untuk memahami kebutuhan dan ekspektasi pengguna secara
praktis serta menggambarkan skenario interaksi yang dapat diikuti oleh
sistem.
2. Class-Oriented Models
 Deskripsi: Class-Oriented Models digunakan dalam pemodelan berbasis
objek untuk mengidentifikasi dan mengorganisasi kelas-kelas yang
diperlukan dalam sistem.
 Komponen:
4

o Kelas: Objek yang memiliki atribut dan operasi (fungsi atau
metode) tertentu.
o Atribut: Properti atau karakteristik dari kelas.
o Operasi: Fungsi atau perilaku yang dapat dilakukan oleh kelas.
 Contoh: Diagram kelas dalam Unified Modeling Language (UML) yang
menunjukkan hubungan dan kolaborasi antara kelas-kelas.
 Tujuan: Untuk merancang struktur objek yang akan membentuk sistem,
memfasilitasi penggunaan ulang kode, dan memastikan bahwa semua
kebutuhan sistem dapat dipenuhi oleh interaksi antar kelas.
3. Behavioral and Patterns-Based Models
 Deskripsi: Behavioral Models menggambarkan bagaimana perangkat
lunak merespons terhadap peristiwa eksternal, seperti aksi pengguna
atau sinyal dari sistem lain. Patterns-Based Models menggunakan pola
tertentu untuk mengatasi masalah desain yang umum.
 Contoh: State Diagrams yang menunjukkan transisi kondisi sistem, atau
Sequence Diagrams yang menggambarkan urutan interaksi antar objek
sebagai respons terhadap suatu peristiwa.
 Tujuan: Untuk memodelkan perilaku dinamis dari sistem, terutama
dalam situasi yang kompleks di mana berbagai elemen sistem bereaksi
terhadap banyak stimulus eksternal.
4. Data Models
 Deskripsi: Data Models memetakan dan menggambarkan struktur
informasi yang dikelola oleh sistem. Ini termasuk representasi data dan
relasinya dalam sistem.
 Contoh: Entity-Relationship Diagrams (ERD) atau Data Flow Diagrams (DFD)
yang menunjukkan entitas data utama, atributnya, dan hubungan antar
entitas.
 Tujuan: Untuk memastikan bahwa semua informasi yang dibutuhkan
oleh sistem tercakup dan terorganisir dengan baik, membantu dalam
integritas data, dan mempermudah manajemen informasi.
5. Flow-Oriented Models
5

 Deskripsi: Flow-Oriented Models menggambarkan bagaimana data
mengalir dan ditransformasikan oleh sistem. Model ini juga memetakan
komponen fungsional sistem dan peran mereka dalam memproses data.
 Contoh: Data Flow Diagrams (DFD) atau diagram Process Flow yang
menunjukkan aliran data melalui berbagai proses dalam sistem.
 Tujuan: Untuk memodelkan proses dan aliran informasi dalam sistem,
sehingga memudahkan dalam pemahaman cara data diproses dan
dipindahkan antara komponen atau modul yang berbeda.
System Description adalah penjelasan terperinci tentang sistem yang
mencakup fungsionalitas, komponen utama, dan tujuan sistem secara
keseluruhan. Ini adalah langkah awal untuk memahami apa yang akan
dilakukan oleh sistem, mengapa sistem itu dibutuhkan, dan bagaimana sistem
tersebut beroperasi secara garis besar.
System description penting karena memberikan panduan awal bagi
pengembang, pemangku kepentingan, dan tim lainnya tentang gambaran
sistem yang akan dibangun. Ini membantu memastikan bahwa semua pihak
memiliki pemahaman yang sama tentang proyek sebelum beralih ke fase
desain dan implementasi.
Elemen Utama dalam System Description
1. Tujuan Sistem: Penjelasan singkat tentang tujuan sistem atau masalah
yang ingin diselesaikan.
6

2. Lingkup Sistem: Batasan atau cakupan sistem, seperti proses bisnis
yang akan didukung atau pengguna yang akan dilayani.
3. Fungsionalitas Utama: Gambaran umum tentang fungsi atau fitur
utama sistem yang memungkinkan sistem untuk mencapai tujuannya.
4. Komponen Utama: Bagian atau modul penting dalam sistem yang
berperan untuk melaksanakan fungsi tertentu.
5. Kebutuhan Pengguna: Deskripsi tentang siapa pengguna sistem dan
kebutuhan utama mereka.
6. Interaksi Sistem dengan Lingkungan Eksternal: Cara sistem
berinteraksi dengan pengguna, sistem lain, atau perangkat eksternal.
7. Asumsi dan Batasan: Kondisi atau batasan yang dianggap dalam
pengembangan sistem, seperti keterbatasan teknologi atau regulasi.
Contoh System Description
Sistem E-commerce untuk Toko Online
1. Tujuan Sistem: Sistem ini bertujuan untuk memungkinkan pelanggan
membeli produk secara online, mempermudah transaksi, dan
meningkatkan penjualan dengan menyediakan berbagai fitur yang
memudahkan proses belanja.
2. Lingkup Sistem: Sistem ini akan melayani seluruh siklus pembelian
produk, dari pencarian produk, penambahan ke keranjang belanja,
pembayaran, hingga pelacakan pengiriman. Sistem ini akan diakses oleh
pelanggan, admin toko, dan pihak logistik.
3. Fungsionalitas Utama:
o Pencarian dan Katalog Produk: Memungkinkan pelanggan untuk
mencari dan menelusuri produk berdasarkan kategori, nama
produk, atau filter lainnya.
o Keranjang Belanja dan Checkout: Pelanggan dapat
menambahkan produk ke keranjang belanja dan melanjutkan ke
proses checkout.
o Pembayaran: Mendukung beberapa metode pembayaran seperti
kartu kredit, e-wallet, dan transfer bank.
o Pelacakan Pengiriman: Pelanggan dapat melacak status
pengiriman pesanan mereka.
7

o Manajemen Produk: Admin toko dapat menambah, mengedit,
atau menghapus produk serta mengelola stok.
o Manajemen Pengguna: Sistem mencatat dan menyimpan
informasi pelanggan serta riwayat pembelian mereka.
4. Komponen Utama:
o Antarmuka Pengguna (UI): Antarmuka untuk pelanggan yang
memungkinkan mereka melakukan pembelian.
o Server Back-End: Mengelola logika bisnis, pemrosesan pesanan,
dan pengelolaan data.
o Database: Menyimpan data produk, pesanan, dan pelanggan.
o API Gateway: Menghubungkan sistem dengan layanan pihak
ketiga, seperti pembayaran dan pelacakan pengiriman.
5. Kebutuhan Pengguna:
o Pelanggan: Membeli produk dengan mudah dan mendapatkan
informasi tentang status pesanan.
o Admin Toko: Mengelola inventaris, harga, dan promosi.
o Pihak Logistik: Mengakses data pesanan untuk proses pengiriman.
6. Interaksi Sistem dengan Lingkungan Eksternal:
o Sistem berinteraksi dengan layanan pembayaran pihak ketiga
untuk memproses transaksi.
o Sistem terhubung dengan pihak logistik untuk memperbarui
informasi pengiriman.
7. Asumsi dan Batasan:
o Sistem ini diasumsikan akan beroperasi pada lingkungan berbasis
web dan mendukung akses dari perangkat mobile.
o Pembayaran dilakukan melalui integrasi dengan penyedia layanan
pembayaran eksternal yang aman.
8

Domain Analysis adalah proses yang digunakan untuk memahami konteks atau
lingkungan dari suatu sistem perangkat lunak dalam suatu area tertentu
(domain), seperti perbankan, kesehatan, atau e-commerce. Tujuan utama dari
domain analysis adalah mengidentifikasi kebutuhan, konsep, dan persyaratan
umum dalam domain tersebut sehingga dapat diterapkan dalam
pengembangan perangkat lunak.
Dalam domain analysis, terdapat dua elemen penting: input dan output. Kedua
elemen ini membantu memastikan bahwa domain dianalisis secara menyeluruh
untuk menghasilkan solusi perangkat lunak yang relevan dan efisien.
1. Input untuk Domain Analysis
Input untuk domain analysis mencakup informasi dan materi yang dibutuhkan
untuk memahami domain dan konteks sistem yang akan dibangun. Berikut
adalah beberapa input utama:
 Dokumen Requirements: Informasi mengenai kebutuhan dan ekspektasi
pengguna serta pemangku kepentingan, yang memberikan dasar untuk
memahami apa yang harus dilakukan oleh sistem.
 Studi Pasar dan Tren Industri: Data dan laporan mengenai tren terbaru di
dalam domain yang dianalisis. Ini mencakup standar industri, peraturan,
dan praktik terbaik.
 Data dari Sistem yang Ada: Data dan pengalaman dari sistem atau
aplikasi yang sudah berjalan di domain tersebut untuk memahami
kebutuhan dan tantangan yang mungkin dihadapi.
 Wawancara dengan Ahli Domain: Mendapatkan wawasan dari para ahli
yang bekerja di bidang terkait untuk mengidentifikasi proses, kebutuhan,
dan terminologi spesifik.
9

 Analisis Pengguna atau Personas: Mengidentifikasi siapa saja pengguna
sistem (persona), termasuk tujuan, kebutuhan, dan cara kerja mereka
untuk memahami persyaratan fungsional dan non-fungsional yang
relevan.
 Dokumen atau Referensi Teknis: Standar teknis, peraturan, dan
dokumentasi lainnya yang berhubungan dengan domain, misalnya
standar keamanan data di domain perbankan.
2. Output dari Domain Analysis
Output dari domain analysis adalah hasil analisis yang memberikan panduan
lengkap untuk membangun sistem perangkat lunak di domain tertentu. Berikut
adalah beberapa output utama:
 Domain Model: Representasi abstrak dari elemen-elemen penting dalam
domain, seperti konsep, entitas, atribut, dan hubungan antar entitas.
Domain model biasanya diwujudkan dalam bentuk diagram entitas-
atribut, diagram kelas, atau diagram ERD (Entity-Relationship Diagram).
 Kamus Domain (Glossary): Daftar istilah dan definisi yang digunakan
dalam domain untuk memudahkan pemahaman bersama antara
pengembang dan pemangku kepentingan.
 Use Cases atau Skenario Penggunaan: Deskripsi interaksi pengguna
dengan sistem untuk mencapai tujuan tertentu. Use case membantu
memahami kebutuhan pengguna dan skenario nyata yang akan
didukung oleh sistem.
 Analisis Proses: Dokumentasi mengenai alur kerja atau proses utama
dalam domain, seperti bagaimana proses penjualan dilakukan dalam e-
commerce atau bagaimana pasien diproses dalam sistem kesehatan.
 Daftar Kebutuhan Fungsional dan Non-fungsional: Daftar kebutuhan
yang dihasilkan dari domain analysis, yang mencakup kebutuhan
fungsional (apa yang harus dilakukan oleh sistem) dan non-fungsional
(misalnya performa, keandalan, keamanan).
 Standar dan Peraturan: Daftar standar dan peraturan yang relevan
dengan domain, misalnya regulasi keamanan data atau aturan terkait
keuangan.
Contoh Domain Analysis: Sistem Manajemen Rumah Sakit
10

 Input:
o Wawancara dengan staf medis dan manajemen rumah sakit.
o Dokumen standar layanan kesehatan.
o Pengalaman dari sistem manajemen rumah sakit lain.
o Analisis kebutuhan pasien, seperti layanan pendaftaran,
pemeriksaan, dan rawat inap.
 Output:
o Domain Model: Model yang menunjukkan entitas seperti pasien,
dokter, perawat, jadwal, dan layanan medis, beserta relasi di
antaranya.
o Kamus Domain: Daftar istilah medis dan prosedur rumah sakit
yang penting bagi pengembang.
o Use Cases: Skenario seperti "Pasien mendaftar untuk
pemeriksaan," atau "Dokter membuat resep obat."
o Analisis Proses: Alur kerja mulai dari penerimaan pasien hingga
penanganan lanjutan dan rekam medis.
o Kebutuhan Fungsional: Misalnya, fitur pendaftaran pasien, fitur
pembuatan resep, atau sistem pengelolaan jadwal.
o Standar dan Peraturan: Panduan HIPAA untuk perlindungan data
medis pasien (jika relevan).
Dengan input dan output yang dihasilkan, domain analysis memberikan
pemahaman mendalam tentang domain sehingga sistem yang dikembangkan
dapat memenuhi kebutuhan spesifik dengan tepat.
11

ANALYSIS MODEL
Analysis Model adalah representasi abstrak dari sistem perangkat lunak yang
dirancang untuk menjelaskan bagaimana sistem tersebut memenuhi
kebutuhan atau requirements yang telah ditentukan. Model ini membantu tim
pengembang memahami dan menyusun persyaratan sistem dengan lebih jelas
sebelum mulai mengimplementasikan kode. Model ini bertujuan untuk
menguraikan berbagai elemen yang mendukung kebutuhan fungsional dan
non-fungsional dari sistem.
Karakteristik Analysis Model
1. Abstraksi: Model ini menangkap konsep dan ide utama tanpa
menyertakan detail implementasi.
2. Komunikasi: Digunakan untuk menjembatani komunikasi antara
pemangku kepentingan, analis, dan pengembang.
3. Struktur Sistem: Menyediakan struktur konseptual yang
menggambarkan komponen utama, interaksi, dan proses dalam sistem.
4. Verifikasi dan Validasi: Memungkinkan proses verifikasi dan validasi
untuk memastikan semua kebutuhan telah terpenuhi.
Jenis-jenis Model dalam Analysis Model
Beberapa jenis model yang biasanya digunakan dalam analysis model
mencakup:
1. Use Case Diagrams: Menggambarkan interaksi antara aktor (pengguna
atau sistem eksternal) dengan sistem, membantu memahami kebutuhan
fungsional.
2. Class Diagrams: Menggambarkan struktur kelas atau objek dalam
sistem dan hubungannya, terutama digunakan dalam pemodelan
berbasis objek.
3. Data Flow Diagrams (DFD): Menggambarkan aliran data melalui sistem,
memetakan proses yang mengubah data dari satu bentuk ke bentuk
lainnya.
4. Entity-Relationship Diagrams (ERD): Menggambarkan data dan
hubungan antara entitas yang relevan dalam sistem, membantu dalam
pemahaman struktur data.
12

5. Sequence Diagrams: Menggambarkan interaksi antar objek atau
komponen dalam urutan waktu tertentu, membantu memahami aliran
informasi dalam skenario tertentu.
6. State Diagrams: Menggambarkan berbagai kondisi yang mungkin
terjadi dalam sistem dan bagaimana transisi antar kondisi tersebut
terjadi sebagai respons terhadap peristiwa.
Contoh Analysis Model
Mari kita ambil contoh analysis model untuk sistem Online Ticket Booking:
1. Use Case Diagram
 Aktor: Pelanggan, Sistem Pembayaran, Administrator.
 Use Case:
o Pelanggan memesan tiket.
o Sistem Pembayaran memproses pembayaran.
o Administrator memperbarui jadwal.
Use Case Diagram ini akan menampilkan pelanggan yang berinteraksi dengan
sistem untuk memesan tiket dan melakukan pembayaran, serta administrator
yang mengelola jadwal perjalanan.
2. Class Diagram
 Kelas:
o Pelanggan: memiliki atribut nama, email, ID_Pelanggan.
o Tiket: memiliki atribut ID_Tiket, tanggal, waktu, harga.
o Pembayaran: memiliki atribut ID_Pembayaran, metode, jumlah.
 Relasi:
o Pelanggan memesan Tiket.
o Pembayaran dilakukan untuk setiap Tiket.
Class Diagram ini menggambarkan entitas utama dalam sistem beserta atribut
dan relasinya, memberikan gambaran struktur data.
3. Data Flow Diagram (DFD)
 Proses:
13

o Pelanggan memasukkan informasi pemesanan.
o Sistem memvalidasi informasi.
o Sistem mengirim data ke gateway pembayaran.
 Aliran Data:
o Data pemesanan mengalir dari pelanggan ke sistem.
o Data validasi diteruskan ke sistem pembayaran.
Data Flow Diagram ini menunjukkan bagaimana data mengalir dari pelanggan
melalui proses pemesanan hingga validasi pembayaran.
4. Sequence Diagram
 Sequence Diagram ini dapat menampilkan urutan pesan dari pelanggan
yang memesan tiket, memicu validasi oleh sistem, dan menerima
respons dari sistem pembayaran setelah pembayaran berhasil.
5. State Diagram
 States:
o Menunggu Pembayaran, Pembayaran Dikonfirmasi, Tiket Tersedia,
Tiket Kadaluarsa.
 Diagram ini menggambarkan berbagai kondisi yang dilalui tiket, dari
dipesan hingga pembatalan atau kadaluarsa jika tidak digunakan.
14

DESIGN MODEL
Design Model adalah representasi teknis dari solusi perangkat lunak yang akan
diimplementasikan berdasarkan kebutuhan atau requirements yang telah
ditentukan dalam tahap analysis model. Design model mencakup desain
arsitektur, komponen, antarmuka, dan basis data yang membentuk struktur
dan fungsionalitas sistem perangkat lunak.
Tujuan utama design model adalah untuk memberikan panduan yang jelas bagi
pengembang dalam implementasi sistem. Model ini membantu memecah
sistem menjadi komponen-komponen yang lebih kecil, memungkinkan
pengembang untuk bekerja pada bagian-bagian yang spesifik dengan
mengikuti rencana desain yang komprehensif.
Elemen-elemen Design Model
1. Arsitektur Sistem: Menunjukkan komponen utama dalam sistem serta
interaksi antar komponen.
2. Desain Data: Menyusun model data untuk mendukung operasi sistem,
termasuk database dan struktur data.
3. Desain Antarmuka: Menentukan antarmuka antara berbagai komponen
dan antara pengguna dengan sistem.
4. Desain Komponen: Menyusun desain rinci dari setiap modul atau
komponen perangkat lunak untuk memenuhi fungsi tertentu.
5. Desain Perilaku (Behavioral Design): Menggambarkan perilaku dinamis
sistem, terutama untuk proses yang dipengaruhi oleh input atau
interaksi eksternal.
Jenis-jenis Model dalam Design Model
1. Class Diagram: Memperinci kelas, atribut, dan operasi beserta
hubungan antar kelas. Digunakan untuk pemodelan berbasis objek.
2. Component Diagram: Menunjukkan komponen perangkat lunak dan
bagaimana mereka berinteraksi satu sama lain.
3. Deployment Diagram: Menggambarkan konfigurasi fisik perangkat
keras dan lokasi komponen perangkat lunak.
4. Sequence Diagram: Menunjukkan aliran pesan antar objek atau
komponen untuk skenario spesifik.
15

5. State Diagram: Menggambarkan perubahan status suatu komponen
atau objek dalam sistem.
6. User Interface Design: Desain antarmuka pengguna dengan fokus pada
pengalaman pengguna dan fungsi yang mudah diakses.
Contoh Design Model
Berikut adalah contoh design model untuk sistem Online Ticket Booking:
1. Arsitektur Sistem
 Arsitektur sistem ini mencakup beberapa komponen utama:
o Komponen Front-End: Antarmuka pengguna yang berinteraksi
langsung dengan pelanggan.
o Komponen Back-End: Server yang mengelola logika bisnis dan
menyimpan data.
o Database: Menyimpan data pelanggan, tiket, dan transaksi.
2. Class Diagram
 Kelas:
o Pelanggan: Atribut ID, nama, email, metode mendaftar(), login().
o Tiket: Atribut ID_Tiket, tanggal, harga, metode pesan(), batal().
o Pembayaran: Atribut ID_Pembayaran, jumlah, metode
prosesPembayaran().
 Relasi:
o Pelanggan memesan Tiket.
o Pembayaran terkait dengan setiap pemesanan tiket.
 Class Diagram ini menjabarkan struktur objek dan hubungan antar objek
dalam sistem.
3. Component Diagram
 Menunjukkan komponen utama seperti:
o Komponen Pemesanan Tiket: Mengelola pemesanan tiket oleh
pelanggan.
o Komponen Pembayaran: Berhubungan dengan pemrosesan
pembayaran.
16

o Komponen Notifikasi: Memberi tahu pelanggan tentang status
pesanan.
 Diagram ini menggambarkan bagaimana komponen bekerja sama untuk
menjalankan sistem.
4. Sequence Diagram
 Menunjukkan alur pemesanan tiket:
1. Pelanggan memilih tiket dan memesan melalui antarmuka
pengguna.
2. Sistem memproses pemesanan dan mengirim data ke komponen
pembayaran.
3. Setelah pembayaran berhasil, sistem mengonfirmasi pemesanan
dan mengirim pemberitahuan ke pelanggan.
Sequence Diagram ini menunjukkan urutan pesan dan proses interaksi antara
berbagai komponen dalam sistem.
5. Deployment Diagram
 Menggambarkan distribusi perangkat lunak pada perangkat keras,
misalnya:
o Server Utama: Menjalankan komponen backend dan mengelola
logika bisnis.
o Server Database: Menyimpan data tiket, pelanggan, dan riwayat
pembayaran.
o Client Devices: Akses melalui web browser atau aplikasi mobile
untuk pelanggan.
Deployment Diagram ini menunjukkan bagaimana komponen perangkat lunak
ditempatkan pada infrastruktur fisik untuk memberikan layanan.
6. User Interface Design
 Menyediakan antarmuka yang ramah pengguna, termasuk:
o Formulir Pemesanan: Tempat pelanggan memilih dan memesan
tiket.
o Halaman Pembayaran: Mengizinkan pelanggan memilih metode
pembayaran dan melakukan transaksi.
17

o Dashboard Pelanggan: Menyediakan akses untuk melihat riwayat
pemesanan dan status tiket.
UI Design memastikan bahwa sistem dapat digunakan dengan mudah oleh
pelanggan dan memberikan pengalaman pengguna yang baik.
18

�ݺ�ߣ

REQUIREMENT MODELLING for Software Engineering.docx

More Related Content

REQUIREMENT MODELLING for Software Engineering.docx