MODUL PERTEMUAN 2

KEBUTUHAN DATA & BUSINESS RULES

A. INFORMASI UMUM MATA KULIAH

B. INFORMASI PERTEMUAN

B.1 Sub-CPMK Pertemuan 2

Sub-CPMK 3.1: Mahasiswa mampu menjelaskan konsep-konsep dasar pemodelan data, termasuk bagaimana mengidentifikasi kebutuhan data dari proses bisnis, peran berbagai stakeholder data, mendefinisikan business rules, serta menerapkan teknik elisitasi kebutuhan data.

B.2 Tujuan Pembelajaran (Learning Objectives)

Setelah mengikuti pertemuan ini, mahasiswa akan mampu:

1. Mengidentifikasi kebutuhan data dari proses bisnis menggunakan berbagai pendekatan analisis (C3 – Mengaplikasikan)
2. Menjelaskan peran dan perspektif berbagai stakeholder data dalam proyek data (C2 – Memahami)
3. Mendefinisikan business rules dan constraint data beserta kategorinya (C2 – Memahami)
4. Memilih teknik elisitasi kebutuhan data yang tepat untuk berbagai situasi (C3 – Mengaplikasikan)
5. Menganalisis kebutuhan data dari studi kasus nyata (sistem akademik / e-commerce) (C4 – Menganalisis)

B.3 Kompetensi yang Dikembangkan

B.4 Indikator Pencapaian

Setelah mengikuti pertemuan ini, mahasiswa diharapkan mampu:

1. Memetakan proses bisnis sederhana dan mengidentifikasi data apa yang dibutuhkan dari proses tersebut
2. Mengelompokkan stakeholder data berdasarkan perspektif dan kebutuhan mereka
3. Menulis business rules dalam bentuk pernyataan formal yang jelas dan tidak ambigu
4. Mengklasifikasikan business rules ke dalam kategori yang tepat (structural, procedural, derivation, validation)
5. Menerapkan minimal dua teknik elisitasi kebutuhan data pada sebuah studi kasus

B.5 Alokasi Waktu

C. MATERI PEMBELAJARAN

C.1 Aktivitas Pemantik – "From Story to Data"

Instruksi (15 menit): Mahasiswa dibagi menjadi 3–4 kelompok. Setiap kelompok menerima satu narasi singkat tentang proses bisnis. Tugas kelompok adalah menjawab tiga pertanyaan berikut dalam 10 menit, lalu dipresentasikan selama 5 menit (satu kelompok mewakili).

Narasi Kelompok A – Toko Online "BatuBulan":

Rina membuka toko online pakaian batik. Setiap hari ia menerima pesanan dari berbagai kota. Pelanggan memilih produk, mengisi alamat pengiriman, dan melakukan pembayaran. Rina kemudian mengemas produk, menyerahkan ke jasa ekspedisi, dan mengirimkan nomor resi ke pelanggan. Ia juga sering mengecek stok produk agar tidak overselling.

Narasi Kelompok B – Perpustakaan "Ilmu Cahaya":

Perpustakaan ini memiliki ribuan koleksi buku. Anggota yang ingin meminjam harus menunjukkan kartu anggota. Petugas mencatat buku yang dipinjam, nama peminjam, dan tanggal kembali. Jika buku terlambat dikembalikan, anggota dikenakan denda per hari. Buku yang rusak atau hilang harus diganti oleh peminjam.

Narasi Kelompok C – Klinik "Sehat Selalu":

Pasien datang ke klinik dan mendaftar ke resepsionis. Dokter memeriksa pasien dan membuat catatan rekam medis. Dokter meresepkan obat yang kemudian disiapkan oleh apotek klinik. Setiap kunjungan dicatat, dan pasien yang memiliki asuransi dapat mengklaim biaya ke perusahaan asuransi.

Pertanyaan yang Harus Dijawab Setiap Kelompok:

1. Data apa saja yang perlu disimpan dari narasi bisnis di atas? (daftar minimal 8 item data)
2. Siapa saja yang membutuhkan data tersebut? (daftar pihak yang berkepentingan)
3. Aturan apa yang mengatur data tersebut? (contoh: "Anggota hanya boleh meminjam 3 buku sekaligus")

C.2 Materi 1: Identifikasi Kebutuhan Data dari Proses Bisnis

C.2.1 Mengapa Identifikasi Kebutuhan Data Itu Penting?

Sebelum kita bisa merancang model data, kita harus tahu data apa yang perlu kita simpan, mengapa kita menyimpannya, dan bagaimana data tersebut akan digunakan. Melewatkan tahap ini adalah penyebab paling umum kegagalan proyek data.

Analogi: Membangun model data tanpa memahami kebutuhan bisnis ibarat seorang arsitek yang langsung menggambar denah rumah tanpa bertanya kepada pemilik rumah berapa kamar yang mereka butuhkan, apakah ada garasi, atau apakah ada anggota keluarga yang menggunakan kursi roda.

Kebutuhan data yang tidak terdefinisi dengan baik akan menyebabkan:

• Over-engineering: Model data terlalu kompleks dan menyimpan data yang tidak pernah digunakan
• Under-engineering: Data penting tidak tersimpan, ditemukan belakangan setelah sistem berjalan
• Inkonsistensi: Berbagai bagian sistem menyimpan data yang sama dengan format berbeda
• Ketidaksesuaian dengan proses bisnis: Model data tidak mencerminkan cara bisnis sebenarnya beroperasi

C.2.2 Business Process Mapping

Business process mapping adalah teknik visual untuk mendokumentasikan bagaimana suatu proses bisnis berjalan dari awal hingga akhir. Dari peta proses ini, kita bisa mengidentifikasi data apa yang dihasilkan, dikonsumsi, atau dimodifikasi di setiap langkah.

Contoh Business Process Map – Proses Pemesanan di E-Commerce:

[Pelanggan] → Pilih Produk → Tambah ke Keranjang → Checkout → 
[Sistem]     → Verifikasi Stok → Hitung Ongkir → 
[Pelanggan] → Pilih Metode Bayar → Konfirmasi Pesanan →
[Sistem]     → Notifikasi ke Penjual → Update Stok →
[Penjual]   → Kemas & Kirim → Input Nomor Resi →
[Sistem]     → Notifikasi ke Pelanggan → Tutup Pesanan

Dari setiap langkah, kita bisa bertanya: "Data apa yang dibuat atau diubah di sini?"

C.2.3 Pendekatan Input-Process-Output (IPO) Analysis

Salah satu cara sistematis mengidentifikasi kebutuhan data adalah dengan menganalisis setiap proses menggunakan kerangka Input → Process → Output:

                    ┌─────────────────────┐
INPUT               │                     │       OUTPUT
(Data yang masuk) → │   PROSES BISNIS     │ →    (Data yang keluar)
                    │                     │
                    └─────────────────────┘
                              ↑
                         CONSTRAINT
                    (Aturan yang mengatur)

Contoh – Proses Pendaftaran Mahasiswa Baru:

C.2.4 Use Case Analysis

Use case menggambarkan interaksi antara pengguna (actor) dengan sistem untuk mencapai tujuan tertentu. Setiap use case mengandung petunjuk tentang data apa yang diperlukan.

Contoh Use Case Diagram (Tekstual) – Sistem Perpustakaan:

ACTOR: Anggota
USE CASE: Meminjam Buku
  - Precondition: Anggota sudah login, kartu anggota aktif
  - Flow Utama:
    1. Anggota mencari buku berdasarkan judul/penulis/kategori
    2. Sistem menampilkan detail buku dan status ketersediaan
    3. Anggota memilih buku dan mengajukan peminjaman
    4. Sistem mengecek kuota pinjaman anggota
    5. Sistem mencatat transaksi peminjaman
    6. Sistem update status buku menjadi "Dipinjam"
  - Postcondition: Transaksi peminjaman tersimpan, status buku terupdate
  - Data yang Terlibat: Anggota, Buku, Transaksi_Pinjam, Tanggal_Kembali

Dari analisis use case di atas, kita bisa langsung mengidentifikasi entitas data utama: ANGGOTA, BUKU, dan TRANSAKSI_PINJAM.

C.3 Materi 2: Stakeholder Data

C.3.1 Siapa Stakeholder Data?

Stakeholder data adalah setiap pihak yang memiliki kepentingan terhadap data dalam suatu sistem — baik sebagai pengguna, pencipta, pengelola, maupun penerima manfaat dari data tersebut. Setiap stakeholder memiliki perspektif dan kebutuhan yang berbeda.

Memahami stakeholder adalah kunci karena model data yang baik harus melayani semua stakeholder, bukan hanya satu pihak.

C.3.2 Kategori Stakeholder dan Kebutuhannya

1. End Users (Pengguna Operasional)

End users adalah orang-orang yang menggunakan sistem sehari-hari untuk menjalankan operasional bisnis. Mereka biasanya tidak peduli dengan struktur data, tapi sangat peduli dengan kemudahan penggunaan dan akurasi data.

• Contoh: Kasir, operator call center, staf administrasi, petugas gudang
• Kebutuhan data: Data yang mudah diinput, pencarian cepat, validasi real-time
• Pertanyaan kunci: "Data apa yang saya butuhkan untuk menyelesaikan tugas ini?"
• Risiko jika diabaikan: Form yang terlalu rumit, data duplikat karena tidak ada validasi, proses operasional lambat

2. Data Analysts (Analis Data)

Data analysts menggunakan data untuk menghasilkan laporan, visualisasi, dan insight bagi pengambilan keputusan bisnis.

• Contoh: Business analyst, reporting specialist, marketing analyst
• Kebutuhan data: Data historis yang lengkap, konsistensi, kemudahan aggregasi, data dengan konteks waktu
• Pertanyaan kunci: "Dari data ini, bisa saya buat laporan penjualan per bulan per kategori?"
• Risiko jika diabaikan: Data tidak bisa di-slice dan di-dice sesuai kebutuhan, laporan tidak bisa dibuat

3. Data Scientists (Ilmuwan Data)

Data scientists menggunakan data untuk membangun model prediktif, machine learning, dan analisis lanjutan.

• Contoh: Machine learning engineer, AI researcher, quantitative analyst
• Kebutuhan data: Data mentah dengan granularitas tinggi, data label untuk supervised learning, data dalam jumlah besar
• Pertanyaan kunci: "Apakah data ini cukup bersih dan representatif untuk melatih model churn prediction?"
• Risiko jika diabaikan: Model tidak bisa dilatih, bias dalam prediksi karena data tidak representatif

4. Data Engineers (Insinyur Data)

Data engineers membangun dan memelihara infrastruktur data: pipeline, ETL, data warehouse.

• Contoh: ETL developer, pipeline engineer, database administrator
• Kebutuhan data: Format data yang konsisten, metadata yang lengkap, data lineage
• Pertanyaan kunci: "Bagaimana data dari sistem A bisa diintegrasikan dengan sistem B tanpa konflik?"
• Risiko jika diabaikan: Pipeline rusak, data loss, integrasi sistem yang gagal

5. Management / Decision Makers

Manajemen membutuhkan data agregat level tinggi untuk pengambilan keputusan strategis.

• Contoh: CEO, CFO, kepala divisi, direktur
• Kebutuhan data: Dashboard KPI, laporan eksekutif, tren dan forecast
• Pertanyaan kunci: "Bagaimana performa perusahaan kita bulan ini dibanding bulan lalu?"
• Risiko jika diabaikan: Keputusan dibuat berdasarkan intuisi bukan data, pelaporan tidak konsisten

C.3.3 Stakeholder Matrix

Dalam praktik, kita sering menggunakan stakeholder matrix untuk mendokumentasikan kebutuhan setiap stakeholder secara sistematis:

💡 Tips Praktis: Saat melakukan elisitasi, jangan hanya wawancara satu jenis stakeholder. Perspektif yang berbeda akan menghasilkan model data yang lebih robust dan melayani lebih banyak kebutuhan.

C.4 Materi 3: Business Rules dan Constraint Data

C.4.1 Apa Itu Business Rule?

Business rule adalah pernyataan yang mendefinisikan atau membatasi bagaimana sesuatu harus terjadi dalam bisnis. Dalam konteks data modelling, business rule menjadi dasar dari:

• Constraint pada tabel database (NOT NULL, UNIQUE, CHECK)
• Kardinalitas dalam ERD (one-to-many, many-to-many)
• Validasi dalam aplikasi
• Workflow dan urutan proses

Ciri Business Rule yang Baik:

• Deklaratif (menyatakan APA, bukan BAGAIMANA)
• Atomik (satu aturan, satu pernyataan)
• Tidak ambigu (dipahami sama oleh semua pihak)
• Dapat diverifikasi (bisa dicek benar atau salahnya)
• Menggunakan bahasa bisnis (bukan bahasa teknis)

Contoh Business Rule yang Baik vs Kurang Baik:

C.4.2 Kategori Business Rules

1. Structural Rules (Aturan Struktural)

Mendefinisikan struktur data: atribut apa yang wajib ada, tipe data yang harus digunakan, dan hubungan antar entitas.

CONTOH STRUCTURAL RULES:
• Setiap PELANGGAN harus memiliki satu dan hanya satu alamat email
• PRODUK harus memiliki nama, kategori, dan harga yang tidak boleh kosong
• Setiap TRANSAKSI harus terhubung dengan tepat satu PELANGGAN
• Satu KARYAWAN dapat memiliki banyak NOMOR_TELEPON (opsional)

Implikasi ke Model Data: Structural rules menentukan apakah atribut bersifat mandatory (NOT NULL) atau optional (NULL), dan menentukan kardinalitas relationship.

2. Procedural Rules (Aturan Prosedural)

Mendefinisikan urutan, alur, atau kondisi yang harus dipenuhi dalam proses bisnis.

CONTOH PROCEDURAL RULES:
• Pesanan hanya dapat diproses setelah pembayaran dikonfirmasi
• Mahasiswa hanya dapat mengajukan KRS setelah menyelesaikan pembayaran UKT
• Klaim asuransi hanya dapat diajukan dalam 30 hari setelah kejadian
• Pengembalian barang hanya dapat dilakukan dalam 7 hari setelah penerimaan

Implikasi ke Model Data: Procedural rules sering memerlukan kolom status (status pesanan, status pembayaran) dan kolom timestamp untuk melacak perubahan.

3. Derivation Rules (Aturan Derivasi)

Mendefinisikan bagaimana suatu nilai dihitung atau diturunkan dari nilai lain.

CONTOH DERIVATION RULES:
• Usia pelanggan dihitung dari tanggal lahir dan tanggal hari ini
• Total tagihan = Subtotal + Ongkir + Pajak - Diskon
• Status pelanggan = "VIP" jika total pembelian dalam setahun > Rp 5.000.000
• IPK = Rata-rata berbobot nilai semua mata kuliah yang telah diambil
• Stok tersedia = Stok masuk - Stok keluar - Stok rusak

Implikasi ke Model Data: Derivation rules menentukan mana atribut yang perlu disimpan (stored) dan mana yang bisa dihitung saat query (derived). Keputusan ini mempengaruhi performa dan konsistensi data.

4. Validation Rules (Aturan Validasi)

Mendefinisikan batas, format, atau nilai yang valid untuk suatu atribut.

CONTOH VALIDATION RULES:
• NIM mahasiswa harus terdiri dari 10 digit angka
• Nomor telepon harus diawali dengan "08" atau "+62"
• Tanggal lahir mahasiswa tidak boleh kurang dari 15 tahun lalu
• Nilai ujian harus berada di rentang 0–100
• Kode pos Indonesia terdiri dari 5 digit angka
• Email harus mengandung karakter "@" dan domain yang valid

Implikasi ke Model Data: Validation rules langsung diterjemahkan menjadi CHECK constraint di SQL, atau validasi di level aplikasi.

5. Business Logic Constraints

Aturan yang mencerminkan kebijakan atau logika bisnis spesifik yang tidak masuk dalam kategori di atas.

CONTOH BUSINESS LOGIC CONSTRAINTS:
• Seorang dosen tidak dapat membimbing lebih dari 10 mahasiswa skripsi sekaligus
• Diskon tidak dapat dikombinasikan dengan voucher promo
• Karyawan tidak dapat menyetujui pengajuan yang dibuat oleh dirinya sendiri
• Barang yang sudah dikirim tidak dapat dibatalkan pemesanannya
• Reservasi kamar tidak dapat dilakukan kurang dari 2 jam sebelum check-in

C.4.3 Cara Mendokumentasikan Business Rules

Business rules harus didokumentasikan secara formal. Berikut adalah format standar yang umum digunakan:

FORMAT PENULISAN BUSINESS RULE:

BR-[Nomor]: [Nama Singkat]
Kategori  : [Structural | Procedural | Derivation | Validation | Logic]
Pernyataan: [Pernyataan aturan yang jelas dan tidak ambigu]
Entitas   : [Entitas data yang terlibat]
Atribut   : [Atribut spesifik yang terpengaruh]
Sumber    : [Siapa yang menetapkan aturan ini? Dokumen mana?]
Catatan   : [Pengecualian atau kondisi khusus]

---------------------------------------------------------------------
CONTOH:

BR-001: Batas SKS Per Semester
Kategori  : Business Logic
Pernyataan: Mahasiswa aktif hanya dapat mengambil maksimal 24 SKS 
            per semester, kecuali jika IPK semester sebelumnya ≥ 3.50 
            (diperbolehkan hingga 27 SKS)
Entitas   : MAHASISWA, PENGAMBILAN_MK
Atribut   : total_sks_diambil, ipk_semester_lalu
Sumber    : Peraturan Akademik UIN, Pasal 15 Ayat 3
Catatan   : Mahasiswa semester 1 otomatis diizinkan mengambil 20 SKS

C.5 Materi 4: Teknik Elisitasi Kebutuhan Data

Elisitasi adalah proses mengumpulkan, mengungkap, dan mendokumentasikan kebutuhan dari berbagai stakeholder. Ini bukan hanya tentang bertanya, tapi juga menganalisis, memvalidasi, dan memprioritaskan kebutuhan yang sering kali implisit atau tidak terucapkan.

C.5.1 Teknik Wawancara (Interview)

Wawancara adalah teknik paling umum dan efektif untuk menggali kebutuhan dari stakeholder individual.

Jenis Wawancara:

Contoh Pertanyaan Wawancara untuk Identifikasi Kebutuhan Data:

Pembuka:
  • "Ceritakan tugas utama Anda dalam proses [X]. Bagaimana alurnya?"
  • "Data apa yang Anda butuhkan untuk memulai tugas tersebut?"

Mendalam:
  • "Informasi apa yang paling sering Anda cari?"
  • "Adakah data yang sering tidak tersedia atau tidak akurat?"
  • "Laporan atau analisis apa yang ingin Anda buat dari data ini?"

Validasi:
  • "Jika saya rangkum, berarti Anda membutuhkan [X]. Apakah benar?"
  • "Adakah kondisi atau pengecualian yang perlu saya ketahui?"

Tips Wawancara:

• Rekam (dengan izin) atau catat setiap detail
• Jangan langsung menyimpulkan solusi teknis
• Tanya "mengapa" untuk menggali kebutuhan di balik permintaan
• Validasi pemahaman Anda di akhir wawancara

C.5.2 Workshop Facilitation (JAD Session)

Joint Application Development (JAD) atau workshop adalah teknik di mana semua stakeholder kunci berkumpul bersama untuk mendefinisikan kebutuhan secara kolaboratif.

Keunggulan:

• Semua perspektif terdengar dalam satu sesi
• Konflik atau inkonsistensi bisa langsung diselesaikan
• Menghasilkan konsensus dan buy-in dari semua pihak
• Lebih efisien dibanding wawancara satu per satu

Struktur Sesi JAD:

1. PEMBUKAAN (15-30 menit)
   - Fasilitator menjelaskan tujuan dan aturan
   - Perkenalan peserta dan peran masing-masing
   
2. REVIEW PROSES BISNIS (60-90 menit)
   - Walk-through proses bisnis yang ada (as-is)
   - Identifikasi pain points dan gap
   
3. DEFINISI KEBUTUHAN (90-120 menit)
   - Brainstorming kebutuhan data
   - Diskusi dan klarifikasi
   - Penentuan prioritas
   
4. VALIDASI (30-60 menit)
   - Review output bersama
   - Konfirmasi kelengkapan
   - Identifikasi tindak lanjut

C.5.3 Document Analysis

Teknik ini melibatkan analisis dokumen yang sudah ada: formulir, laporan, SOP, spreadsheet lama, atau dokumen kebijakan.

Dokumen yang Sering Dianalisis:

• Form fisik atau digital yang diisi pengguna → mengungkap atribut data
• Laporan Excel yang dibuat manual → mengungkap kebutuhan analitik
• SOP (Standard Operating Procedure) → mengungkap business rules
• Kontrak atau perjanjian → mengungkap constraint legal
• Dokumen sistem lama → mengungkap model data yang sudah ada

Teknik Analisis:

LANGKAH DOCUMENT ANALYSIS:
1. Kumpulkan semua dokumen relevan
2. Identifikasi elemen data di setiap dokumen (kolom form, field laporan)
3. Catat nilai-nilai yang valid (pilihan dropdown, contoh data)
4. Identifikasi aturan yang tersirat (mandatory/optional, format)
5. Bandingkan antar dokumen: adakah inkonsistensi?
6. Validasi temuan dengan stakeholder

Contoh: Menganalisis formulir pendaftaran mahasiswa manual untuk mengidentifikasi atribut entitas MAHASISWA.

C.5.4 Observasi

Mengamati langsung pengguna bekerja dalam lingkungan nyata untuk memahami proses dan kebutuhan data yang tidak selalu terungkap melalui wawancara.

Kapan Observasi Paling Berguna:

• Pengguna kesulitan mengartikulasikan kebutuhan mereka ("lebih mudah ditunjukkan daripada dijelaskan")
• Proses bisnis sangat kompleks dengan banyak variasi
• Ingin memahami workaround yang dilakukan pengguna (tanda model data tidak memenuhi kebutuhan)

Hal yang Perlu Diperhatikan Saat Observasi:

✓ Catat setiap data yang dibuat, dibaca, diubah, atau dihapus
✓ Perhatikan data yang dicatat di luar sistem (kertas, sticky note, WhatsApp)
✓ Perhatikan proses yang membutuhkan banyak langkah manual
✓ Tanya "mengapa" ketika melihat sesuatu yang tidak biasa
✓ Jangan mengganggu alur kerja natural pengguna

C.5.5 Prototyping

Membuat mockup atau prototype interface untuk mendapatkan feedback cepat dari stakeholder tentang kebutuhan data.

Pendekatan:

• Paper prototyping: Sketsa form atau layar di kertas
• Wireframing: Mockup digital dengan tools seperti Figma atau Balsamiq
• Proof of concept: Prototype sederhana yang bisa diklik

Keunggulan: Stakeholder lebih mudah memberikan feedback ketika melihat sesuatu yang konkret, bukan hanya mendengar deskripsi abstrak.

Contoh: Membuat mockup form "Tambah Produk" untuk e-commerce, lalu tanya kepada penjual: "Field apa lagi yang Anda butuhkan untuk mendeskripsikan produk Anda?"

C.5.6 Perbandingan Teknik Elisitasi

💡 Best Practice: Gunakan kombinasi beberapa teknik untuk hasil yang komprehensif. Mulai dengan document analysis dan wawancara, validasi dengan workshop, dan konfirmasi akhir dengan prototyping.

C.6 Studi Kasus: Identifikasi Kebutuhan Data Sistem Akademik UIN

C.6.1 Latar Belakang

UIN K.H. Abdurrahman Wahid Pekalongan ingin membangun sistem informasi akademik baru untuk mengelola data mahasiswa, dosen, mata kuliah, dan proses perkuliahan. Tim pengembang perlu mengidentifikasi kebutuhan data sebelum merancang model data.

C.6.2 Hasil Wawancara dengan Stakeholder

Dari wawancara dengan Bagian Akademik (End User Operasional):

• "Kami perlu merekam data mahasiswa lengkap: NIM, nama, prodi, angkatan, status aktif/non-aktif"
• "Setiap semester kami membuka periode KRS. Mahasiswa mengambil mata kuliah sesuai jadwal"
• "Nilai akhir diinput dosen dan disetujui Kaprodi sebelum menjadi resmi"
• "Mahasiswa yang IPK-nya turun di bawah 2.0 perlu status peringatan akademik"

Dari wawancara dengan Dosen (End User & Data Creator):

• "Saya perlu melihat daftar mahasiswa yang mengambil mata kuliah saya"
• "Saya memasukkan nilai UTS, UAS, dan tugas. Sistem yang hitung nilai akhir"
• "Satu dosen bisa mengampu di beberapa prodi berbeda"
• "Ruang kelas dan jam jadwal harus tidak bentrok"

Dari wawancara dengan Kepala Prodi (Management):

• "Saya perlu laporan IPK rata-rata per angkatan, perbandingan antar semester"
• "Berapa persen mahasiswa yang lulus tepat waktu? Berapa yang drop out?"
• "Dosen mana yang beban mengajarnya sudah penuh?"

Dari wawancara dengan Tim IT (Data Engineer):

• "Sistem harus bisa integrasi dengan SIAKAD nasional milik Kemdikbud"
• "Data mahasiswa yang sudah lulus harus tetap tersimpan untuk keperluan transkip"
• "Perlu log aktivitas untuk audit trail"

C.6.3 Identifikasi Entitas Data Utama

Berdasarkan hasil wawancara, berikut entitas data yang teridentifikasi:

C.6.4 Business Rules yang Teridentifikasi

BR-001: Batas SKS KRS
Kategori  : Business Logic
Pernyataan: Mahasiswa aktif dapat mengambil maksimal 24 SKS per semester. 
            Jika IPK semester sebelumnya ≥ 3.50, batas menjadi 27 SKS.
            Mahasiswa semester 1 mendapat batas default 20 SKS.
Entitas   : MAHASISWA, KRS, MATA_KULIAH

BR-002: Pengampu Mata Kuliah
Kategori  : Structural
Pernyataan: Setiap jadwal kelas harus memiliki tepat satu dosen pengampu.
            Satu dosen dapat mengampu lebih dari satu jadwal per semester.
Entitas   : JADWAL, DOSEN

BR-003: Konflik Jadwal Mahasiswa
Kategori  : Validation
Pernyataan: Seorang mahasiswa tidak dapat mengambil dua mata kuliah yang 
            terjadwal pada hari dan jam yang sama.
Entitas   : KRS, JADWAL

BR-004: Konflik Jadwal Ruangan
Kategori  : Validation
Pernyataan: Satu ruangan hanya dapat digunakan oleh satu kelas pada 
            waktu yang sama.
Entitas   : JADWAL, RUANGAN

BR-005: Periode Input Nilai
Kategori  : Procedural
Pernyataan: Nilai dapat diinput dosen setelah UAS berlangsung dan 
            sebelum batas akhir periode input nilai (H+14 setelah UAS).
Entitas   : NILAI, SEMESTER

BR-006: Formula Nilai Akhir
Kategori  : Derivation
Pernyataan: Nilai_Akhir = (Nilai_Tugas × 20%) + (Nilai_UTS × 35%) + 
            (Nilai_UAS × 45%). Nilai_Akhir dikonversi ke skala huruf:
            A (≥81), B+ (71-80), B (66-70), C+ (61-65), C (56-60),
            D+ (51-55), D (46-50), E (<46)
Entitas   : NILAI

BR-007: Status Peringatan Akademik
Kategori  : Business Logic
Pernyataan: Mahasiswa yang IPK kumulatifnya < 2.0 setelah semester 2 
            atau selanjutnya mendapat status "Peringatan Akademik" dan 
            wajib mengikuti program bimbingan akademik.
Entitas   : MAHASISWA

BR-008: Prasyarat Mata Kuliah
Kategori  : Business Logic
Pernyataan: Beberapa mata kuliah memiliki prasyarat. Mahasiswa hanya 
            dapat mengambil mata kuliah tersebut jika sudah lulus (nilai ≥ C) 
            mata kuliah prasyaratnya.
Entitas   : MATA_KULIAH, KRS, NILAI

C.7 Studi Kasus Lanjutan: Kebutuhan Data E-Commerce "NusantaraShop"

C.7.1 Skenario

NusantaraShop adalah marketplace produk kerajinan UMKM yang ingin membangun sistem manajemen penjualan. Berikut ringkasan kebutuhan dari berbagai stakeholder:

C.7.2 Proses Bisnis Utama

PROSES 1: Pendaftaran Penjual
Penjual (UMKM) mendaftar dengan mengisi profil bisnis → 
Admin verifikasi dokumen → Akun diaktivasi → 
Penjual bisa upload produk

PROSES 2: Pembelian
Pembeli browsing produk → Tambah ke keranjang → 
Isi alamat pengiriman → Pilih ekspedisi & lihat ongkir →
Bayar → Konfirmasi otomatis ke penjual →
Penjual kemas & kirim → Pembeli konfirmasi penerimaan →
Transaksi selesai, dana masuk ke penjual

PROSES 3: Review & Rating
Setelah transaksi selesai, pembeli bisa memberikan rating (1-5) 
dan ulasan teks → Rating terakumulasi menjadi rating rata-rata penjual

C.7.3 Entitas dan Business Rules Teridentifikasi

Entitas Data:

Business Rules Kunci:

BR-E01: Stok Tidak Boleh Negatif
Pernyataan: Sistem tidak mengizinkan pemesanan produk yang stoknya = 0.
            Stok produk dikurangi otomatis saat pesanan dikonfirmasi.

BR-E02: Harga Tersimpan di Pesanan
Pernyataan: Harga produk yang direkam di ITEM_PESANAN adalah harga 
            pada saat pembelian, bukan harga saat ini. Hal ini memastikan
            riwayat pesanan tidak berubah jika harga produk diubah.

BR-E03: Periode Ulasan
Pernyataan: Pembeli hanya dapat memberikan ulasan dalam 30 hari 
            setelah status pesanan menjadi "Selesai".

BR-E04: Satu Ulasan per Transaksi
Pernyataan: Satu pembeli hanya dapat memberikan satu ulasan per 
            item produk dalam satu transaksi.

BR-E05: Rating Penjual
Pernyataan: Rating_Penjual = Rata-rata semua rating dari ulasan yang 
            diterima dalam 12 bulan terakhir. Minimum 5 ulasan 
            diperlukan untuk menampilkan rating.

BR-E06: Pembatalan Pesanan
Pernyataan: Pembeli dapat membatalkan pesanan selama status masih 
            "Menunggu Konfirmasi" (sebelum penjual konfirmasi).
            Setelah dikonfirmasi, pembatalan memerlukan persetujuan penjual.

D. WORKSHOP KELAS

D.1 Instruksi Workshop

Durasi: 25 menit kerja kelompok + 10 menit presentasi Kelompok: 3–4 mahasiswa (berbeda dari kelompok aktivitas pemantik)

Pilih SATU dari dua skenario berikut:

SKENARIO A: Sistem Peminjaman Buku – Perpustakaan Digital "Pustaka Saintis"

Perpustakaan Program Studi Sains Data ingin membangun sistem peminjaman buku digital. Buku bisa dibaca secara online maupun dipinjam dalam bentuk fisik (jika ada). Anggota adalah mahasiswa dan dosen aktif. Anggota mahasiswa bisa meminjam maksimal 3 buku fisik sekaligus (dosen 5 buku), dengan masa pinjam 2 minggu (bisa diperpanjang sekali). Terlambat kembali dikenakan denda Rp 500/hari/buku. Buku digital bisa diakses tanpa batas waktu, tapi hanya bisa dibaca oleh satu anggota sekaligus untuk buku yang dilisensikan per-satu-pengguna. Ada buku yang langka (hanya 1 eksemplar), sehingga bisa direservasi oleh anggota lain ketika sedang dipinjam.

SKENARIO B: Sistem Manajemen Event – Komunitas "DataFest"

DataFest adalah komunitas mahasiswa sains data yang rutin mengadakan event (workshop, seminar, hackathon). Mereka perlu sistem untuk mengelola event, registrasi peserta, pembicara, dan sponsorship. Setiap event memiliki kuota peserta, dan ada event berbayar dan gratis. Peserta yang mendaftar event berbayar perlu mengunggah bukti pembayaran. Event memiliki sesi-sesi (schedule) yang berbeda dengan pembicara yang berbeda pula. Panitia perlu melacak kehadiran peserta di setiap sesi. Sponsor memberikan kontribusi berupa uang atau fasilitas (venue, konsumsi).

D.2 Tugas Workshop

Untuk skenario yang dipilih, kelompok harus menghasilkan:

1. Identifikasi Stakeholder (5 menit)

• Daftar minimal 4 stakeholder yang berbeda
• Jelaskan perspektif dan kebutuhan data masing-masing

2. Identifikasi Entitas Data (5 menit)

• Daftar minimal 6 entitas data utama
• Sebutkan 3–5 atribut untuk masing-masing entitas

3. Business Rules (10 menit)

• Tulis minimal 6 business rules menggunakan format: BR-[No]: [Nama] | Kategori: [...] | Pernyataan: [...]
• Pastikan mencakup minimal 3 kategori berbeda (structural, procedural, derivation, validation, atau logic)

4. Teknik Elisitasi yang Direkomendasikan (5 menit)

• Rekomendasikan 2–3 teknik elisitasi yang paling tepat untuk kasus ini
• Jelaskan mengapa teknik tersebut dipilih

D.3 Format Output Workshop

HASIL WORKSHOP KELOMPOK [Nama Kelompok]
Skenario: [A/B]
Anggota: [Nama-nama]

=== STAKEHOLDER ===
1. [Nama Stakeholder] – [Perspektif & Kebutuhan Data]
2. ...

=== ENTITAS DATA ===
1. [NAMA_ENTITAS]: [Atribut 1, Atribut 2, Atribut 3, ...]
2. ...

=== BUSINESS RULES ===
BR-01: [Nama] | Kategori: [X] | Pernyataan: [...]
BR-02: ...

=== TEKNIK ELISITASI ===
1. [Teknik] – [Alasan Pemilihan]
2. ...

E. EVALUASI DAN PENILAIAN

E.1 Kuis Penutup (10 menit, bobot partisipasi)

1. Sebutkan tiga kategori business rules dan berikan satu contoh untuk masing-masing dari domain yang berbeda dari contoh di kelas!

2. Perhatikan business rule berikut: "Seorang manajer hanya dapat menyetujui pengajuan cuti jika anggota timnya minimal 2 orang tetap hadir di hari yang sama." Termasuk kategori apakah business rule ini? Jelaskan!

3. Mengapa penting untuk mewawancarai berbagai jenis stakeholder (bukan hanya satu) dalam elisitasi kebutuhan data? Berikan contoh konflik kebutuhan yang mungkin ditemukan antara end user dan data scientist!

4. Anda ditugaskan menganalisis kebutuhan data untuk sistem baru yang akan menggantikan sistem lama berbasis Excel. Teknik elisitasi apa yang paling tepat sebagai langkah pertama? Jelaskan alasannya!

E.2 Tugas Individu (dikumpulkan sebelum pertemuan 3)

Judul: Analisis Kebutuhan Data dan Business Rules

Deskripsi: Pilih SATU sistem dari daftar berikut (atau ajukan domain lain kepada dosen):

• Sistem Manajemen Klinik / Rumah Sakit Kecil
• Sistem Reservasi Hotel Sederhana
• Sistem Manajemen Restoran (pemesanan, menu, dapur, kasir)
• Aplikasi Tabungan / Koperasi Mahasiswa
• Sistem Manajemen Tugas Akhir (skripsi/TA)

Ketentuan Output:

1. Deskripsi Sistem (200–300 kata): Jelaskan sistem yang dipilih, proses bisnis utama, dan batasannya
2. Stakeholder Matrix: Identifikasi minimal 4 stakeholder dengan kolom: Nama, Peran, Kebutuhan Data, Frekuensi Akses
3. Identifikasi Entitas Data: Minimal 6 entitas dengan atribut masing-masing
4. Business Rules: Minimal 8 business rules menggunakan format formal, mencakup semua 5 kategori
5. Teknik Elisitasi: Rancang rencana elisitasi singkat (teknik apa, dengan siapa, dan pertanyaan kunci)
6. Refleksi: Apa tantangan terbesar dalam mendefinisikan kebutuhan data di domain yang dipilih? (100–150 kata)

Format: PDF, minimal 4 halaman A4, font 11pt, margin 2.5cm Deadline: Sebelum pertemuan 3 (diupload ke Ngaji UIN Gusdur) Bobot: Bagian dari Tugas Individu (25% total nilai)

F. PERSIAPAN PERTEMUAN 3

F.1 Yang Perlu Dipelajari

Pertemuan 3 akan membahas Konsep Entity, Attribute, dan Relationship — fondasi dari Entity Relationship Diagram (ERD). Ini adalah pertemuan kunci yang membangun langsung dari apa yang kita pelajari hari ini.

Bacaan Wajib:

• Elmasri & Navathe, Bab 3: Data Modeling Using the Entity-Relationship Model
• Hoberman, Bab 3: Conceptual Data Model

Pertanyaan Pemantik untuk Pertemuan 3:

• Dari entitas yang kamu identifikasi di tugas individu, bagaimana hubungan antar entitas tersebut?
• Apakah ada entitas yang "bergantung" pada entitas lain untuk bisa ada?
• Atribut apa yang bisa dijadikan identifier unik untuk setiap entitas?

F.2 Instalasi Tools

Mulai pertemuan 4, kita akan menggunakan tools untuk menggambar ERD. Gunakan:

• Draw.io (online, gratis): https://draw.io (opens in a new tab) atau https://app.diagrams.net (opens in a new tab)

Tidak perlu instalasi — cukup akses melalui browser.

G. REFERENSI

G.1 Referensi Utama

1. Elmasri, R. & Navathe, S. B. (2015). Fundamentals of Database Systems (7th Edition). Pearson. ISBN: 978-0133970777

   • Chapter 1: Databases and Database Users
   • Chapter 3: Data Modeling Using the Entity-Relationship Model (Bagian awal – konsep entitas)

2. Hoberman, S. (2009). Data Modeling Made Simple (2nd Edition). Technics Publications. ISBN: 978-0977140060

   • Chapter 3: Conceptual Data Modeling
   • Chapter 4: Requirement Gathering and Documentation

3. Simsion, G. & Witt, G. (2004). Data Modeling Essentials (3rd Edition). Morgan Kaufmann.

   • Chapter 2: Understanding the Business (Stakeholder Analysis)

G.2 Referensi Pendukung

4. Connolly, T. & Begg, C. (2014). Database Systems: A Practical Approach to Design, Implementation, and Management (6th Edition). Pearson.

   • Chapter 12: Entity-Relationship Modeling

5. IEEE Std 830-1998. IEEE Recommended Practice for Software Requirements Specifications. IEEE.

6. Redman, T. C. (2008). Data Driven: Profiting from Your Most Important Business Asset. Harvard Business School Press.

G.3 Referensi Online

7. IIBA (International Institute of Business Analysis). "A Guide to the Business Analysis Body of Knowledge (BABOK)." — https://www.iiba.org/babok-guide/ (opens in a new tab)
8. IBM. "Business Rules in Data Modeling" — https://www.ibm.com/docs/en/data-modeling (opens in a new tab)
9. Lucidchart. "What are Business Rules?" — https://www.lucidchart.com (opens in a new tab)

H. LAMPIRAN

Lampiran A: Lembar Kerja Workshop

LEMBAR KERJA WORKSHOP PERTEMUAN 2 Kelompok: ___________________________ Skenario yang Dipilih: A / B (lingkari salah satu) Anggota:

1. _______________________ NIM: __________
2. _______________________ NIM: __________
3. _______________________ NIM: __________
4. _______________________ NIM: __________

BAGIAN 1: STAKEHOLDER

BAGIAN 2: ENTITAS DATA

BAGIAN 3: BUSINESS RULES

BR-01: _______________
Kategori  : 
Pernyataan: 

BR-02: _______________
Kategori  : 
Pernyataan: 

BR-03: _______________
Kategori  : 
Pernyataan: 

BR-04: _______________
Kategori  : 
Pernyataan: 

BR-05: _______________
Kategori  : 
Pernyataan: 

BR-06: _______________
Kategori  : 
Pernyataan: 

BAGIAN 4: TEKNIK ELISITASI

Lampiran B: Daftar Cek Kebutuhan Data

Gunakan daftar cek ini saat melakukan elisitasi kebutuhan data untuk memastikan tidak ada aspek penting yang terlewat:

Aspek Data:

• Data master (entitas utama sistem)
• Data transaksi (kejadian/event bisnis)
• Data referensi (lookup tables, kode-kode)
• Data historis (perubahan data dari waktu ke waktu)
• Data agregat (summary, laporan)
• Metadata (siapa yang buat/ubah data, kapan)

Aspek Stakeholder:

• End user operasional sudah diwawancara
• Analis data sudah diwawancara
• Management sudah dimintai kebutuhan laporan
• Tim IT / data engineer sudah dikonsultasikan
• Pihak eksternal (mitra, regulator) sudah diidentifikasi

Aspek Business Rules:

• Structural rules sudah didokumentasikan
• Procedural rules sudah didokumentasikan
• Derivation rules sudah didokumentasikan
• Validation rules sudah didokumentasikan
• Business logic constraints sudah didokumentasikan
• Semua rules sudah divalidasi dengan stakeholder terkait

Aspek Kualitas:

• Tidak ada ambiguitas dalam definisi kebutuhan
• Semua singkatan dan istilah teknis sudah dijelaskan
• Konflik antar kebutuhan stakeholder sudah teridentifikasi dan diselesaikan
• Prioritas kebutuhan sudah ditentukan

Lampiran C: Template Dokumen Kebutuhan Data

# DOKUMEN KEBUTUHAN DATA
# [Nama Sistem]
 
**Versi:** 1.0
**Tanggal:** [Tanggal]
**Penulis:** [Nama]
**Status:** Draft / Review / Final
 
---
 
## 1. OVERVIEW SISTEM
[Deskripsi singkat sistem dan tujuan bisnisnya]
 
## 2. STAKEHOLDER
| Stakeholder | Peran | Kebutuhan Utama |
|---|---|---|
| | | |
 
## 3. PROSES BISNIS UTAMA
[Deskripsi proses bisnis yang relevan, bisa dalam bentuk narasi atau diagram]
 
## 4. ENTITAS DATA
 
### 4.1 [NAMA_ENTITAS_1]
**Deskripsi:** [Apa yang direpresentasikan entitas ini]
**Atribut:**
- [Atribut 1]: [Tipe] - [Deskripsi]
- [Atribut 2]: [Tipe] - [Deskripsi]
 
### 4.2 [NAMA_ENTITAS_2]
...
 
## 5. BUSINESS RULES
 
### 5.1 Structural Rules
- BR-S01: [Pernyataan]
- BR-S02: [Pernyataan]
 
### 5.2 Procedural Rules
- BR-P01: [Pernyataan]
 
### 5.3 Derivation Rules
- BR-D01: [Pernyataan]
 
### 5.4 Validation Rules
- BR-V01: [Pernyataan]
 
### 5.5 Business Logic Constraints
- BR-L01: [Pernyataan]
 
## 6. PERTANYAAN TERBUKA
[Daftar pertanyaan atau hal yang masih perlu dikonfirmasi]
 
## 7. RIWAYAT PERUBAHAN
| Versi | Tanggal | Perubahan | Oleh |
|---|---|---|---|
| 1.0 | [Tanggal] | Dokumen awal | [Nama] |

PENUTUP

Pertemuan 2 ini membangun kemampuan mahasiswa untuk berbicara dengan bisnis sebelum merancang data. Kemampuan mengidentifikasi kebutuhan data, memahami perspektif stakeholder yang beragam, mendefinisikan business rules secara formal, dan memilih teknik elisitasi yang tepat adalah keterampilan yang membedakan data modeller yang baik dari yang sekadar tahu menggambar ERD.

Key Messages Pertemuan 2:

1. Model data yang baik dimulai dari pemahaman mendalam tentang kebutuhan bisnis, bukan dari struktur tabel
2. Setiap stakeholder memiliki perspektif berbeda — model data yang bagus melayani semua pihak
3. Business rules bukan hanya constraint teknis di database — ini adalah pengetahuan bisnis yang harus dipahami sebelum diimplementasikan
4. Elisitasi adalah seni sekaligus ilmu — pilih teknik yang tepat sesuai konteks

Koneksi ke Proyek Semester: Tugas pertemuan ini adalah tahap pertama dari proyek bertahap semester. Dokumen kebutuhan data dan business rules yang Anda buat akan menjadi fondasi untuk ERD (pertemuan 3–4) dan model relasional (pertemuan 5–7).

Disusun oleh: Mohammad Reza Maulana, M.Kom Program Studi Sains Data Fakultas Ekonomi dan Bisnis Islam UIN K.H. Abdurrahman Wahid Pekalongan

Revisi: Februari 2026