Belajar System Analyst - System Design Document

#Pendahuluan

Setelah di episode 6 kalian menguasai diagram UML — activity untuk alur, sequence untuk interaksi, class/domain untuk struktur data — saatnya menyatukan seluruh hasil analisis ke dalam satu dokumen induk: System Design Document (SDD).

Mengapa SDD masih relevan di era Agile yang anti-dokumen-tebal? Karena masalahnya bukan dokumen vs tanpa dokumen, melainkan informasi desain tersebar vs terpusat. Saat developer baru bergabung bulan ketiga, saat QA butuh konteks exception flow, saat owner bertanya "kenapa diputuskan begitu" enam bulan kemudian — jawabannya harus ada di satu tempat yang bisa dirujuk. SDD adalah single source of truth untuk keputusan desain, dengan bobot secukupnya (just enough).

#Struktur SDD yang Rapi

Struktur berikut adalah pola yang terbukti bekerja lintas proyek — sesuaikan kedalamannya dengan risiko:

Bagian nomor 9 adalah pembeda SDD dewasa dari SDD pelajaran sekolah: decision log. Desain tanpa alasan akan ditantang ulang setiap kali orang barunya datang; catatan "kami memilih sinkronisasi batch karena internet cabang tidak stabil, alternatif realtime ditolak karena biaya" menyelesaikan debat sebelum dimulai.

#Prinsip Menulis

Tiga prinsip yang menjaga SDD tetap dibaca, bukan diarsipkan:

1. Progressive disclosure — ringkasan eksekutif di depan untuk manajer, detail teknis di belakang untuk dev. Tidak semua orang membaca semuanya, dan itu by design.
2. Diagram dulu, teks melengkapi — setiap bagian arsitektur/data flow dibuka gambar, teks menjelaskan yang tak tampak.
3. Versi & status — tiap perubahan besar dicatat (v1.0 draft, v1.1 setelah review arsitektur). SDD basi yang tidak di-update lebih berbahaya daripada tidak ada sama sekali.

#Menulis Bagian Arsitektur

Arsitektur pada level analyst menjawab bentuk logis solusi — bukan memilih versi library. Untuk TokoKita, konteksnya: 12 cabang, internet tidak stabil, kasir harus tetap jalan offline, owner ingin laporan pusat.

Pola: offline-first edge + central server
 
[Kasir Cabang]
  App POS desktop/web-PWA
  DB lokal (SQLite) -- sumber kebenaran sementara saat offline
       |
       | sync HTTPS batch (retry, idempotent)
       v
[Server Pusat - Cloud]
  API transaksi & master data
  DB pusat (PostgreSQL)
  Modul laporan & dashboard owner
 
Keputusan kunci:
K1  Offline-first: kasir tidak boleh bergantung jaringan
K2  Sync batch + antrian pending, bukan realtime push
K3  Master data (produk/harga) didorong dari pusat,
    perubahan harga hanya lewat modul pusat
K4  Setiap cabang database terpisah secara logis
    (tenant = cabang), digabung di laporan pusat

Perhatikan gaya penulisannya: pendek, bernomor, menyebut alternatif yang ditolak. Diagram pendampingnya bisa berupa component diagram sederhana — kotak komponen dan panah protokol komunikasi, cukup satu halaman.

#Data Flow Diagram (DFD)

DFD melengkapi arsitektur dengan pertanyaan: data mengalir ke mana dan diubah oleh proses apa. Notasi klasiknya empat simbol: proses (lingkaran/rounded), data store (garis ganda/terbuka), entitas eksternal (persegi), aliran data (panah berlabel).

Level DFD juga bertingkat: context diagram (satu lingkaran = seluruh sistem + entitas eksternal) → DFD level 0 (proses utama) → level 1 (pecahan proses). Untuk SDD ukuran menengah, dua level sudah cukup.

#Praktik: Kerangka SDD TokoKita

Berikut kerangka aktual yang kita pakai di 03-design/sdd-tokokita.md — lengkap namun tetap ~12 halaman:

# System Design Document — TokoKita POS & Inventory
Versi: 1.0 | Status: Draft untuk review | Tanggal: 2026-08-16
 
## 1. Introduction
1.1 Tujuan dokumen — pegangan tim dev & QA fase pilot
1.2 Scope — POS inti, inventori, sync, laporan dasar;
    OUT: member/poin, e-commerce, auto-order supplier
1.3 Referensi — BRD v0.2, backlog MoSCoW ep.04, use case ep.05
 
## 2. Overall Description
2.1 Konteks — 12 cabang, Excel legacy, internet flaky
2.2 User classes — Kasir, Manajer Cabang, Owner
2.3 Asumsi — 1 device kasir/cabang pilot; printer thermal USB
 
## 3. System Architecture
3.1 Pola offline-first edge + central (lihat K1-K4)
3.2 Diagram komponen
3.3 DFD level 0 & 1
3.4 Decision log
 
## 4. Data Design
4.1 Domain model & ERD (Produk, StokCabang, Transaksi,
    TransaksiItem, Shift, PenyesuaianStok)
4.2 Data dictionary (tabel per entitas)
4.3 Strategi ID unik: UUID untuk sync-safety
 
## 5. Component Design
5.1 Modul Kasir — UC-01..UC-03
5.2 Modul Sinkronisasi — antrian pending_sync, retry eksponensial
5.3 Modul Inventori — opname & penyesuaian berjejak
 
## 6. Interface Design
6.1 API internal (endpoint utama + contoh payload)
6.2 Integrasi eksternal — QRIS gateway (detail ep.13)
6.3 UI guideline — target: kasir baru produktif < 30 menit
 
## 7. Non-Functional Specifications
NFR-01 respons kasir <= 2 detik (p95) mode online
NFR-02 transaksi offline tersinkron <= 60 detik setelah pulih
NFR-03 uptime jam operasional 99.5%/bulan
NFR-04 audit trail semua penyesuaian stok (siapa-kapan-apa)
 
## 8. Deployment & Migration
8.1 Pilot 1 cabang -> evaluasi 2 sprint -> rollout bertahap
8.2 Migrasi data awal: master produk dari gabungan 12 Excel
    (strategi cleansing di episode 16)
 
## 9. Decision Log
DL-01 SQLite lokal vs web murni -> SQLite (kebutuhan offline)
DL-02 UUID vs auto-increment -> UUID (hindari bentrok saat sync)
DL-03 Harga diedit pusat saja -> konsistensi promo & pajak

Catatan penting di bagian 4.3: keputusan UUID vs auto-increment adalah contoh keputusan desain yang lahir dari analisis — database lokal tiap kasir membuat nomor urut otomatis pasti bentrok saat sinkron. Inilah cara NFR offline memaksa keputusan data.

#Kesalahan Umum

1. SDD novel 80 halaman — ditulis sekali, tidak dibaca siapa pun. Kalau ada bagian yang tidak akan memengaruhi keputusan siapa pun, hapus.
2. Campur requirement dengan desain — "kasir harus bisa scan" adalah requirement (di BRD/SRS); "scan via kamera fallback ke USB scanner" adalah desain. Pisahkan supaya perubahan tidak merembek.
3. Tanpa decision log — enam bulan kemudian tim bertengkar ulang soal UUID vs increment karena alasannya tidak tertulis.
4. Sekali tulis tidak dirawat — SDD harus ikut berubah saat desain berubah; jadikan update SDD bagian definition-of-done per sprint untuk item desain.
5. Bahasa implikatif tanpa keputusan — frasa "mungkin akan digunakan" atau "kemungkinan besar" di dokumen desain adalah tanda keputusan belum matang; pindahkan ke daftar open issues dengan deadline.

#Penutup

Inti yang harus dibawa pulang:

• SDD adalah single source of truth keputusan desain dengan bobot just enough — struktur 9 bagian dari introduction sampai decision log.
• Arsitektur level analyst = pola logis + keputusan bernomor + alternatif yang ditolak; DFD menjelaskan aliran data antar proses dan penyimpanan.
• Decision log mencegah perdebatan ulang; progressive disclosure membuat dokumen terbaca lintas audiens.
• SDD TokoKita v1.0 sudah berdiri: offline-first, UUID sync-safe, harga terpusat — siap jadi pegangan pilot.

Desain sistem tidak berdiri di atas proses yang benar saja, tapi juga proses bisnis yang benar. Di episode 8 selanjutnya kita membahas business process modeling: standar BPMN, teknik process mapping, dan cara menemukan peluang improvement — dipraktikkan pada alur stok opname TokoKita. Pastikan tetap semangat!