Belajar Solution Architect - Requirements to Solution

#Pendahuluan

Setelah di episode 2 kita punya proses solution design — requirement → design → validation → delivery — dan kerangka SDD pertama kalian, kini kita masuk ke fase paling menentukan: requirement. Ini fondasi seluruh bangunan. Desain sebagus apa pun akan gagal jika dibangun di atas requirement yang salah baca, terlalu kabur, atau tidak lengkap.

Mengapa episode ini penting? Karena dalam praktiknya, stakeholder jarang memberi requirement yang rapi. Mereka memberi cerita, keluhan, dan permintaan solusi ("kita butuh aplikasi kayak Tokopedia tapi buat internal"). Tugas SA adalah mengekstrak dari sana dua hal: apa yang harus dilakukan sistem (functional), dan seberapa baik ia melakukannya (non-functional) — lalu mengubahnya menjadi keputusan desain yang bisa dipertanggungjawabkan.

#Functional vs Non-Functional

Dua kategori ini adalah ABC requirement engineering:

Perhatikan contoh NFR di tabel: ia selalu membawa angka dan kondisi ukur. NFR tanpa angka bukan requirement, melainkan harapan — dan harapan tidak bisa diverifikasi saat review.

NFR utama yang wajib kalian kenal:

• Performance — latency p95/p99, throughput per detik.
• Scalability — kapasitas maksimum dan cara bertambah (vertikal/horizontal).
• Availability — persentase uptime dan downtime tahunan yang ditoleransi.
• Durability — risiko data hilang yang dapat diterima.
• Security — kontrol akses, enkripsi, standar compliance.
• Maintainability — seberapa cepat tim bisa berubah dengan aman.
• Compliance/Legal — regulasi yang mengikat (PDP, GDPR, PCI-DSS).

#Menulis NFR yang Terukur

Formula praktis: metrik + target + kondisi. Bandingkan pasangan berikut:

BURUK : "Sistem harus cepat dan andal."
BAIK  : "API checkout merespons p95 <= 300 ms pada 1.000 req/detik."
BURUK : "Data tidak boleh hilang."
BAIK  : "RPO database transaksional <= 5 menit; durability >= 99,999999999% (11 sembilan)."

Tabel konversi availability ke angka nyata — hafalkan ini, sering muncul di meeting:

#Constraints: Batasan yang Membentuk Desain

Selain requirement, desain dibentuk oleh constraints — hal-hal yang tidak bisa dinegosiasikan:

• Budget — menentukan managed vs self-hosted, jumlah environment.
• Deadline — event musiman (Ramadan sale, tanggal kembar) memaksa MVP lebih kecil.
• Regulasi — misalnya data wajib tinggal di Indonesia (mengunci region cloud).
• Skill tim — arsitektur Kubernetes canggih tidak bernilai jika tak ada yang mengoperasikannya.
• Legacy — sistem lama yang tidak bisa diganti tahun ini tapi harus tetap diintegrasikan.

Catat constraints eksplisit di bagian 2c template SDD kalian. Constraint yang tidak tertulis akan kembali sebagai konflik di tengah proyek.

#Praktik: Requirement Mapping & Traceability Matrix

Jantung episode ini adalah latihan menghubungkan requirement ke solusi. Ambil studi kasus di episode 2 — sistem tiket event 50.000 user serentak — dan susun requirement-nya:

FR-01 : Pembeli dapat mencari event dan melihat detail.
FR-02 : Pembeli dapat memesan kursi dengan seat-lock selama 10 menit.
FR-03 : Sistem menerbitkan e-tiket QR unik setelah pembayaran sukses.
FR-04 : Panitia dapat memindai QR untuk validasi masuk gerbang.
 
NFR-01 : API search p95 <= 200 ms pada 5.000 req/detik.
NFR-02 : Checkout tahan lonjakan 50.000 user serentak tanpa error rate > 0,1%.
NFR-03 : Availability 99,95% selama window penjualan.
NFR-04 : Data pembayaran terenkripsi dan sesuai standar PCI-DSS.
 
C-01  : Budget infrastruktur <= 40 juta/bulan.
C-02  : Launch 90 hari, tim 6 engineer, familiar Node.js dan PostgreSQL.
C-03  : Semua data PDP-related tersimpan di region Jakarta.

Lalu buat traceability matrix — tabel yang menjawab "komponen mana yang memenuhi requirement ini, dan bagaimana kita tahu itu benar?":

Baca matrix itu dari kanan ke kiri juga: kalau sebuah keputusan solusi tidak mendukung requirement mana pun, itu gold plating — buang. Kalau ada requirement tanpa keputusan, itu celah desain — isi. Matrix inilah alat komunikasi terkuat SA ke reviewer: setiap kotak sistem punya alasan eksistensi.

#Common Pitfalls

• Requirement tersembunyi di slide presentasi — minta requirement final tertulis dan ditandatangani product owner; versi verbal akan bergeser.
• NFR saling bertentangan tanpa prioritas — "murah, cepat, aman maksimal" sekaligus mustahil; minta stakeholder memberi ranking, bukan kalian yang menebak.
• Angka tanpa sumber — target 10x traffic biasanya datang dari marketing tanpa basis; validasi dengan data historis dan rencana kampanye.
• Mengabaikan anti-requirement — hal yang sistem tidak boleh lakukan (misal: tidak boleh mengirim data pelanggan ke luar negeri) sama pentingnya dengan fitur.

#Penutup

Inti yang harus dibawa pulang:

• Functional = apa yang sistem lakukan; non-functional = seberapa baik — dan NFR tanpa metrik + target + kondisi bukan requirement.
• Availability punya harga: tiap sembilan tambahan berarti biaya yang jauh lebih besar; ukur dulu kerugian downtime riilnya.
• Constraints (budget, deadline, regulasi, skill, legacy) membentuk desain sekuat requirement — tulis eksplisit.
• Traceability matrix adalah alat kerja inti SA: menghubungkan requirement → keputusan → verifikasi, sekaligus mendeteksi gold plating dan celah desain.

Di episode 4 selanjutnya kita akan membahas architecture selection & trade-offs — cara membandingkan monolith, microservices, serverless, dan event-driven secara objektif lewat weighted scoring matrix, serta menuliskan keputusan kalian dalam ADR. Sampai jumpa di episode 4!