Memahami SRS: Spesifikasi Teknis yang Bikin Developer Gak Bikin Fitur Ngawur

Series: Memahami SDLC — Part 3 dari 10

Dua artikel sebelumnya kita udah bahas BRD (apa yang bisnis mau) dan PRD (fitur apa yang harus dibangun). Sekarang waktunya turun ke level yang paling dekat sama developer: SRS — Software Requirements Specification.

Kalau BRD buat bos dan PRD buat product manager, SRS itu buat developer dan QA. Gak ada SRS yang jelas? Siap-siap aja debat gak ada habisnya soal “ini bug apa feature?”

Apa Bedanya SRS sama PRD?

Dimensi	PRD	SRS
Pembaca	PM, designer, dev	Developer, QA, arsitek
Fokus	Fitur dan user journey	Spesifikasi teknis dan implementasi
Contoh	“User bisa cari produk”	“GET /api/products?q={query} return 200, page size 20”
Level detail	Fungsional – apa yang terjadi	Teknis – bagaimana mengukur dan implementasi

PRD bilang apa yang harus terjadi. SRS bilang gimana cara ngukurnya. Tanpa SRS, developer dan QA punya interpretasi masing-masing — dan itu sumber konflik nomor satu di proyek software.

Contoh: Fitur Cari Produk

PRD: “User bisa mencari produk berdasarkan nama, kategori, dan rentang harga.”

Ini kalimat yang keliatan jelas, tapi sebenernya kabur banget. Cari di mana? Response-nya gimana? Kalau gak ketemu? Performance-nya gimana?

SRS yang proper:

• Endpoint: GET /api/v2/products/search
• Parameter: q (string, min 2 karakter), category_id (int, opsional), min_price dan max_price (int, opsional), page dan per_page (default 20, max 100)
• Response 200: array of product objects — masing-masing berisi id, name, price, stock, image_url, category_name
• Error 400: kalau q kurang dari 2 karakter — return error message “Kata kunci minimal 2 karakter”
• Error 500: kalau database connection failed — return generic error, log detail ke server
• Performance: response time < 500ms untuk 10.000 produk (P95)
• Search engine: PostgreSQL full-text search via tsvector + GIN index pada kolom name dan description

Satu fitur — 10 baris SRS. Developer langsung ngoding tanpa tanya. QA langsung bikin test case. Gak ada ambiguitas.

Template SRS Minimal

Gak perlu SRS 50 halaman kayak proyek pemerintahan. Buat proyek mid-size, template ini cukup:

1. Functional Requirements (FR)

Daftar fitur dengan ID unik. Tiap fitur punya: deskripsi, input, output, error conditions.

FR-001: Search Produk
Deskripsi: User mencari produk via search bar di halaman utama
Input: query string (min 2 karakter)
Output: JSON array produk dengan pagination
Error: 400 kalau query < 2 chars, 500 kalau DB down

FR-002: Filter by Category
Deskripsi: User bisa mempersempit pencarian dengan filter kategori
Input: category_id (integer, dari dropdown)
Output: Filtered product list
Error: 404 kalau category_id gak valid

2. Non-Functional Requirements (NFR)

• Performance: response time < 500ms (P95) untuk 10K produk
• Availability: 99.9% uptime (maksimal 8.7 jam downtime per tahun)
• Security: semua endpoint pakai JWT token dengan expiry 1 jam
• Scalability: support 100 concurrent users tanpa degradasi performa signifikan
• Maintainability: kode harus linter-pass, coverage minimal 80%

3. Interface Specifications

API contracts lengkap (request/response shapes), database schema (tables, columns, indexes, relationships), dan integrasi dengan service eksternal (contoh: payment gateway, warehouse API).

4. Acceptance Criteria

Ini yang paling penting. “Fitur search dianggap selesai ketika:”

• User bisa nyari produk dengan nama parsial (e.g., ketik “sams” muncul “Samsung Galaxy A76”)
• Filter kategori dan rentang harga bekerja bersamaan (e.g., kategori “Smartphone” + harga Rp 5-7 juta)
• Response time < 500ms dengan 10.000 produk di database
• Pagination support — infinite scroll di mobile, page numbers di desktop
• Tidak ada hasil duplikat

Tools buat Nulis SRS

• OpenAPI/Swagger — buat API contract. Lo bisa generate YAML, langsung dapet dokumentasi interaktif. Recommended banget.
• Notion atau Google Docs — buat kolaborasi dengan tim non-teknis. Tapi hati-hati, dokumen gampang kadaluarsa kalo gak di-maintain.
• Markdown + Git — yang gue pake sendiri. SRS di repo yang sama dengan kode. Version controlled, reviewable via PR, gak ada alasan “tapi kan udah gue update di doc” tanpa jejak audit.

SRS Itu Asuransi, Bukan Beban

Gue pernah mengalami sendiri: PRD udah approved, gue mulai ngoding fitur laporan stok. Seminggu coding, pas demo ternyata yang dimaksud user adalah laporan bentuk grafik, bukan tabel. PRD cuma nulis “laporan stok” — gak ada spesifikasi formatnya, jenis chart-nya, atau filter yang diperlukan. Seminggu coding terbuang sia-sia.

Kalau waktu itu ada SRS yang nulis:

• FR-042: “Visualisasi berupa grouped bar chart — sumbu X = bulan, sumbu Y = quantity, filter by warehouse dropdown dan date range picker”
• NFR-007: “Chart harus render < 2 detik untuk 12 bulan data dengan 10 warehouse"

Gak bakal ada miskomunikasi. Developer tinggal coding. QA tinggal bikin test case. Stakeholder tinggal tanda tangan ACC.

Kapan Lo Butuh SRS (dan Kapan Gak)

SRS bukan buat semua proyek. Gue pake threshold simpel:

• Side project / prototyping: Gak perlu SRS. Lo sendirian, lo eksplor, lo ubah-ubah sesuka hati.
• Fitur internal dengan 1 developer: SRS lisan atau 1 halaman A4 cukup. Selama lo dan developer ngerti, gas.
• Fitur dengan 2+ developer atau 3rd party: SRS WAJIB. Semakin banyak orang yang terlibat, semakin besar potensi miskomunikasi.
• Proyek dengan budget di atas 50 juta: SRS WAJIB. Ini asuransi — kalo terjadi dispute soal scope, lo punya dokumen yang bisa dirujuk.

SRS Anti-Gagal

Dari pengalaman gue, SRS yang gagal biasanya karena:

1. Terlalu detail di awal
Gak usah SRS 50 halaman yang nulis state diagram buat tombol login. Mulai dari endpoint utama dulu, detail di-iterasi pas sprint planning. SRS bisa hidup — dia gak harus final di awal.

2. Gak ada contoh konkret
Jangan cuma nulis “response time cepat.” Tulis “response time < 500ms untuk 10K produk di PostgreSQL." Angka konkret > kata sifat abstrak.

3. Gak direview developer
SRS yang ditulis PM doang tanpa review developer biasanya penuh asumsi teknis yang gak realistis. Contoh: “database harus support 1 juta user concurrent.” Developer yang review langsung bilang “bro, ini perlu Redis cluster + sharding, budgetnya gede.”

4. Kadaluarsa tanpa update
SRS yang gak diupdate selama 6 bulan lebih bahaya daripada gak punya SRS sama sekali — karena developer baru percaya dokumen itu, padahal udah gak relevan.

Tips gue simpen SRS di repo yang sama dengan kode. Review via PR setiap kali ada perubahan spec. Version controlled — lo bisa liat kapan spec berubah dan kenapa.

Next: SDD (Software Design Document) — dari spesifikasi ke arsitektur, gimana caranya nerjemahin SRS jadi diagram dan keputusan teknis.