Contoh SRS (Spesifikasi Kebutuhan Perangkat Lunak) Lengkap + Cara Bikinnya Tanpa Ribet

Dosen minta dokumen SRS. Atau calon vendor bilang belum bisa kasih penawaran sebelum kamu kirim spesifikasi kebutuhan perangkat lunak. Kamu googling, yang keluar penjelasan IEEE 830 sepuluh paragraf, template Word yang kalimatnya jelas hasil terjemahan mesin, dan PDF yang baru kebuka kalau kamu bayar atau unggah dokumen dulu.

Panduan ini kebalikannya. Teorinya cuma satu layar. Sisanya satu contoh SRS utuh untuk satu aplikasi beneran, dari bab pendahuluan sampai kriteria penerimaan, yang bisa kamu salin lalu ganti nama aplikasi dan isinya. Di bagian bawah ada hal yang hampir nggak pernah dibahas artikel lain: kalau SRS ini nanti mau kamu serahkan ke AI coding seperti Cursor atau Claude Code, ada beberapa kebiasaan SRS gaya kampus yang justru bikin AI-nya ngarang.

SRS itu apa (versi sependek mungkin)

SRS (Software Requirements Specification), di Indonesia sering ditulis SKPL alias Spesifikasi Kebutuhan Perangkat Lunak, adalah dokumen yang menjelaskan apa yang harus dilakukan sebuah perangkat lunak sebelum kodenya ditulis. Isinya dua hal utama: kebutuhan fungsional (apa saja yang bisa dikerjakan aplikasi) dan kebutuhan non-fungsional (seberapa cepat, seaman apa, semudah apa dipakai).

Itu saja. Sisanya bab pembungkus supaya orang yang belum pernah dengar idemu bisa ikut nyambung. Yang bikin dokumen ini kelihatan menakutkan biasanya struktur IEEE 830-nya: belasan sub-bab bernomor, penuh istilah yang nggak kepakai buat aplikasi kecil.

• Anak kuliah: syarat mata kuliah RPL, proposal skripsi, atau lampiran laporan KP.
• Orang yang mau nyewa developer: biar penawaran dari beberapa vendor bisa dibandingkan apel-ke-apel, dan biar nggak ada omongan 'itu di luar scope' di tengah jalan.
• Orang yang ngoding sendiri pakai AI: biar agent-nya punya satu sumber kebenaran, bukan potongan chat yang berserakan.

Contoh SRS lengkap: aplikasi peminjaman ruangan kampus

Studi kasusnya sengaja yang kecil tapi punya aturan main beneran: SIPRUK, aplikasi web untuk mengajukan dan menyetujui peminjaman ruang kelas di sebuah fakultas. Mahasiswa dan UKM mengajukan, staf BAAK menyetujui atau menolak, dan sistem harus mencegah dua acara duduk di ruangan yang sama pada jam yang beririsan. Semua nama, tanggal, dan angka di bawah ini karangan buat contoh. Ganti dengan datamu sendiri.

Isinya dipisah per bab supaya gampang disalin sebagian. Kalau dosenmu minta format IEEE 830, urutan bab di bawah sudah mengikuti kerangkanya, cuma dibuang sub-bab yang nggak kepakai buat aplikasi sekecil ini. Satu konteks yang perlu kamu tahu: IEEE Std 830-1998 sendiri sudah ditarik dan digantikan ISO/IEC/IEEE 29148 (terbit 2011, direvisi 2018). Kerangkanya tetap dipakai luas di kampus Indonesia dan tetap masuk akal buat aplikasi kecil, jadi silakan pakai — cuma jangan kaget kalau ada penguji yang menanyakan standar penggantinya.

Bab 1: Pendahuluan

Bab ini yang paling sering diisi asal-asalan, padahal dia yang menentukan apakah pembaca nanti komplain 'lho kok fitur X nggak ada'. Bagian ruang lingkup wajib punya dua daftar: yang dikerjakan dan yang TIDAK dikerjakan.

SRS - Sistem Informasi Peminjaman Ruangan (SIPRUK)
Versi 1.0 | 5 Agustus 2026

1. PENDAHULUAN

1.1 Tujuan
Dokumen ini menjelaskan kebutuhan SIPRUK versi 1.0, aplikasi web
untuk mengajukan, menyetujui, dan mencatat peminjaman ruang kelas
di lingkungan Fakultas Teknik. Dokumen ditujukan untuk tim
pengembang, dosen pembimbing, dan staf BAAK sebagai calon pengguna.

1.2 Ruang Lingkup
Yang dikerjakan di v1.0:
  - Pengajuan peminjaman ruangan oleh mahasiswa dan pengurus UKM
  - Persetujuan atau penolakan oleh admin BAAK, dengan alasan
  - Kalender ketersediaan ruangan per bulan
  - Rekap peminjaman per bulan, bisa diunduh sebagai CSV

Yang TIDAK dikerjakan di v1.0:
  - Pembayaran sewa ruangan
  - Sinkronisasi otomatis dengan jadwal kuliah di SIAKAD
  - Aplikasi mobile (cukup web yang enak dibuka di HP)
  - Notifikasi WhatsApp atau SMS (v1.0 hanya email)

1.3 Definisi Istilah
  Peminjam : mahasiswa aktif atau pengurus UKM yang mengajukan
  Admin    : staf BAAK yang menyetujui atau menolak pengajuan
  Slot     : satu ruangan, satu tanggal, jam mulai sampai jam selesai
  Bentrok  : dua peminjaman berstatus DISETUJUI yang slotnya beririsan

1.4 Referensi
  - IEEE Std 830-1998, sebagai acuan struktur dokumen
  - Hasil wawancara dengan staf BAAK (lampiran A)

Bab 2: Deskripsi umum

Bab dua menjawab pertanyaan 'aplikasi ini hidup di lingkungan seperti apa'. Bagian batasan dan asumsi kelihatannya sepele, tapi di situlah kamu memasang pagar. Kalau nanti ada yang minta fitur di luar pagar, kamu tinggal tunjuk halaman ini.

2. DESKRIPSI UMUM

2.1 Perspektif Produk
SIPRUK berdiri sendiri, tidak menggantikan SIAKAD. Daftar ruangan
dimasukkan sekali di awal oleh admin dan jarang berubah.

2.2 Karakteristik Pengguna
  Peminjam : mahasiswa/pengurus UKM, terbiasa pakai HP, jarang
             membuka aplikasi ini (2-3 kali per semester).
             Tidak boleh butuh pelatihan.
  Admin    : staf BAAK, pakai laptop, membuka aplikasi tiap hari
             kerja, memproses belasan pengajuan per hari.

2.3 Batasan
  - Aplikasi web, dibuka lewat browser, tanpa instalasi.
  - Data disimpan di satu basis data relasional milik fakultas.
  - Hanya akun dengan email domain kampus yang bisa mendaftar.
  - Bahasa antarmuka: Indonesia saja.

2.4 Asumsi dan Ketergantungan
  - Server email kampus tersedia untuk mengirim pemberitahuan.
  - Daftar ruangan dan kapasitasnya disediakan oleh BAAK sebelum
    aplikasi dipasang.
  - Jika layanan email mati, pengajuan tetap tersimpan; email
    menyusul, bukan gagal total.

Bab 3: Kebutuhan fungsional

Ini jantungnya. Tiap kebutuhan diberi kode (SRS-F-01, SRS-F-02) supaya nanti bisa ditunjuk dari bab kriteria penerimaan dan dari daftar tugas koding. Perhatikan bagian Aturan dan Alur alternatif. Di situ letak beda antara spesifikasi dan sekadar daftar judul fitur.

3. KEBUTUHAN FUNGSIONAL

SRS-F-01  Masuk ke sistem
  Aktor      : Peminjam, Admin
  Prakondisi : Akun terdaftar dan berstatus aktif
  Alur utama :
    1. Pengguna mengisi email kampus dan kata sandi.
    2. Sistem memeriksa pasangan email dan kata sandi.
    3. Sistem membuka beranda sesuai peran (peminjam atau admin).
  Aturan:
    - Kata sandi disimpan sebagai hash, tidak pernah teks polos.
    - Salah 5 kali berturut-turut: akun dikunci 15 menit.
  Alur alternatif:
    - Kata sandi salah -> pesan "Email atau kata sandi salah".
      Jangan beri tahu mana yang salah.

SRS-F-02  Mengajukan peminjaman
  Aktor      : Peminjam
  Prakondisi : Sudah masuk sebagai peminjam
  Alur utama :
    1. Peminjam memilih ruangan, tanggal, jam mulai, jam selesai.
    2. Peminjam mengisi nama kegiatan dan perkiraan jumlah peserta.
    3. Sistem memeriksa bentrok dan aturan di bawah.
    4. Sistem menyimpan pengajuan berstatus MENUNGGU.
    5. Sistem mengirim email pemberitahuan ke admin.
  Aturan:
    - Pengajuan paling lambat H-2 dari tanggal kegiatan.
    - Durasi minimal 1 jam, maksimal 8 jam, dalam satu hari yang
      sama (tidak boleh melewati tengah malam).
    - Jam peminjaman hanya 07:00-21:00.
    - Jumlah peserta tidak boleh melebihi kapasitas ruangan.
    - Satu peminjam maksimal 3 pengajuan berstatus MENUNGGU.
    - Pengecekan bentrok hanya melawan status DISETUJUI. Dua
      pengajuan MENUNGGU di slot sama boleh ada; admin yang memilih.
  Alur alternatif:
    - Slot bentrok -> tolak, tampilkan jadwal yang sudah terisi
      pada tanggal itu, jangan cuma bilang "gagal".
    - Jam selesai <= jam mulai -> tolak sebelum data dikirim.

SRS-F-03  Menyetujui atau menolak pengajuan
  Aktor      : Admin
  Alur utama :
    1. Admin membuka daftar pengajuan berstatus MENUNGGU,
       urut dari tanggal kegiatan terdekat.
    2. Admin menekan Setujui atau Tolak.
    3. Jika Tolak, admin wajib mengisi alasan (minimal 10 karakter).
    4. Sistem mengubah status dan mengirim email ke peminjam.
  Aturan:
    - Saat menyetujui, sistem memeriksa ulang bentrok. Kalau slot
      sudah keburu diisi pengajuan lain, persetujuan dibatalkan
      dan admin diberi tahu.
    - Pengajuan yang tanggal kegiatannya sudah lewat tidak bisa
      disetujui, otomatis berstatus KEDALUWARSA.
    - Keputusan tidak menghapus data. Status berubah, riwayat tetap.

SRS-F-04  Melihat kalender ketersediaan
  Aktor      : Peminjam, Admin (dan tamu tanpa login)
  Alur utama :
    1. Pengguna memilih bulan dan ruangan.
    2. Sistem menampilkan slot yang sudah DISETUJUI per tanggal.
  Aturan:
    - Nama kegiatan ditampilkan, nama pemohon tidak.

SRS-F-05  Rekap bulanan
  Aktor      : Admin
  Alur utama :
    1. Admin memilih rentang tanggal.
    2. Sistem menampilkan jumlah peminjaman per ruangan dan
       total jam pemakaian.
    3. Admin mengunduh hasilnya sebagai CSV.
  Aturan:
    - Rekap hanya menghitung status DISETUJUI dan SELESAI.

Bab 4: Kebutuhan non-fungsional

Bagian yang paling gampang berubah jadi kalimat kosong. "Sistem harus cepat dan aman" itu doa, belum kebutuhan. Tiap baris di bawah punya angka atau kondisi yang bisa dites orang lain.

4. KEBUTUHAN NON-FUNGSIONAL

SRS-NF-01  Kinerja
  - Kalender satu bulan tampil di bawah 3 detik pada koneksi
    kampus, dengan data 2.000 peminjaman.
  - Pengecekan bentrok saat mengajukan selesai di bawah 1 detik.

SRS-NF-02  Keamanan
  - Kata sandi disimpan sebagai hash ber-salt.
  - Peminjam hanya bisa melihat pengajuannya sendiri. Menebak
    nomor pengajuan orang lain di alamat URL harus ditolak,
    bukan sekadar tombolnya disembunyikan.
  - Semua halaman diakses lewat HTTPS.

SRS-NF-03  Kebergunaan
  - Pengajuan pertama bisa diselesaikan tanpa panduan, dalam
    5 langkah atau kurang.
  - Semua pesan kesalahan berbahasa Indonesia dan menyebutkan
    apa yang harus diperbaiki.
  - Layar 360px (HP paling kecil di kampus) masih terpakai
    tanpa geser ke samping.

SRS-NF-04  Keandalan
  - Kegagalan kirim email tidak boleh membatalkan penyimpanan
    pengajuan. Email masuk antrean, dicoba ulang 3 kali.
  - Basis data dicadangkan otomatis setiap hari.

SRS-NF-05  Kemudahan Pemeliharaan
  - Daftar ruangan, kapasitas, dan jam operasional diubah lewat
    halaman admin, bukan lewat kode.

Bab 5: Model data

Bab ini sering ditaruh di lampiran, padahal buat yang bakal ngoding dia paling sering dibuka. Salah bentuk data di sini, semua fitur di atasnya ikut miring. Kalau kamu mau menerjemahkannya jadi tabel basis data beneran, alurnya ada di cara membuat database schema dari PRD.

5. MODEL DATA

Pengguna
  id, nama, email (unik, domain kampus), kata_sandi_hash,
  peran (peminjam | admin), status (aktif | nonaktif)

Ruangan
  id, kode (mis. TR-301), nama, kapasitas (int),
  aktif (bool)

Peminjaman
  id, pengguna_id, ruangan_id, tanggal,
  jam_mulai, jam_selesai, nama_kegiatan, jumlah_peserta (int),
  status (menunggu | disetujui | ditolak | selesai | kedaluwarsa),
  alasan_penolakan (boleh kosong),
  diputuskan_oleh (pengguna_id admin, boleh kosong),
  dibuat_pada, diputuskan_pada

Catatan model:
  - Kapasitas ruangan tidak disalin ke Peminjaman. Kapasitas
    diperiksa saat pengajuan, hasilnya tidak perlu disimpan.
  - Status tidak pernah dihapus, hanya berubah. Peminjaman yang
    dibatalkan tetap ada barisnya.
  - Satu Peminjaman selalu satu ruangan. Acara yang butuh dua
    ruangan diajukan dua kali.

Bab 6: Kriteria penerimaan

Bab penutup yang paling sering dilewat, dan justru yang bikin dokumenmu balik modal. Isinya daftar kondisi yang bisa dicek benar-salahnya oleh orang lain tanpa berdebat. Kalau kamu mau menulisnya lebih rapi, bentuk lengkapnya dibahas di user story dan acceptance criteria untuk AI coding.

6. KRITERIA PENERIMAAN

Terkait SRS-F-02 (Mengajukan peminjaman)
  1. Ajukan ruang TR-301, 20 Sep, 13:00-15:00. Pengajuan tersimpan
     berstatus MENUNGGU dan muncul di daftar admin.
  2. Ajukan slot yang beririsan dengan peminjaman DISETUJUI
     (14:00-16:00 di ruang yang sama). Ditolak, dan layar
     menampilkan jadwal terisi hari itu.
  3. Ajukan untuk besok. Ditolak dengan pesan aturan H-2.
  4. Isi jumlah peserta 60 untuk ruangan berkapasitas 40.
     Ditolak sebelum data terkirim.
  5. Punya 3 pengajuan MENUNGGU, ajukan yang keempat. Ditolak.

Terkait SRS-F-03 (Persetujuan)
  6. Tolak tanpa mengisi alasan. Tombol tidak jalan.
  7. Setujui pengajuan. Status berubah, email masuk ke peminjam,
     dan slot itu langsung muncul di kalender.
  8. Dua admin menyetujui dua pengajuan di slot sama hampir
     bersamaan. Hanya satu yang jadi DISETUJUI, satunya ditolak
     sistem dengan pesan slot sudah terisi.

Terkait SRS-NF-02 (Keamanan)
  9. Masuk sebagai peminjam A, buka alamat detail pengajuan milik
     peminjam B. Muncul halaman ditolak, bukan datanya.

Terkait SRS-F-05 (Rekap)
  10. Unduh CSV rentang satu bulan. Jumlah baris sama dengan
      jumlah peminjaman DISETUJUI dan SELESAI di bulan itu.

Sepuluh baris itu, kalau semuanya lolos, berarti aplikasinya jadi. Bukan "kayaknya sih udah jalan".

Tiga hal yang bikin SRS dicoret bolak-balik

Dari pola SRS yang biasa dikembalikan, masalahnya jarang di jumlah halaman. Biasanya di tiga tempat ini.

1. Kebutuhan yang nggak bisa diuji

"Sistem harus user friendly." Siapa yang menilai, dan pakai apa? Ganti dengan kondisi yang bisa diperagakan: pengajuan pertama selesai dalam 5 langkah tanpa baca panduan. Cara cepat menyaringnya, coba tulis langkah pengetesannya di sebelah tiap baris. Baris yang bikin kamu mandek di situ berarti belum layak masuk dokumen.

2. Ruang lingkup yang cuma punya satu sisi

Daftar "yang dikerjakan" ada, daftar "yang tidak dikerjakan" kosong. Akibatnya semua orang mengisi kekosongan itu dengan asumsi masing-masing. Dosen mengira ada laporan grafik, kamu nggak pernah berniat bikin. Daftar yang tidak dikerjakan itu murah ditulis dan mahal kalau nggak ada.

3. Bab yang isinya cuma judul

Bab risiko, bab analisis pemangku kepentingan, lampiran C yang isinya "[akan ditentukan kemudian]". Bab kosong lebih buruk daripada bab yang nggak ada, karena pembaca menyangka ada aturan yang tersembunyi di sana. Buang saja kalau memang nggak kepakai, kecuali dosenmu mewajibkan.

Kalau kamu masih penasaran seperti apa dokumen spesifikasi yang sudah jadi dan bukan kerangka kosong, ada beberapa yang bisa kamu buka dan baca isinya sampai habis.

SRS yang bisa langsung dibaca AI coding agent

Sekarang bagian yang beda dari kebanyakan artikel SRS. Kalau dokumen ini bukan cuma buat dikumpulkan, tapi mau kamu tempel ke Cursor, Claude Code, atau agent sejenis, ada beberapa kebiasaan SRS gaya kampus yang bikin hasilnya melenceng.

Agent membaca dokumenmu dari atas ke bawah dan memperlakukan hampir semua kalimat sebagai perintah. Dia nggak bisa membedakan mana bab seremonial dan mana aturan sungguhan. Jadi kebiasaan di bawah ini akibatnya sampai ke kode, bukan berhenti di ketebalan dokumen.

Yang bikin agent ngarang

• Kalimat pasif tanpa pelaku. "Data akan divalidasi" nggak menjawab divalidasi di mana. Agent biasanya memilih di sisi browser saja, dan validasimu bisa dilewati siapa pun yang paham alamat URL.
• Bab kosong berisi [akan ditentukan]. Agent menganggap ada aturan di situ, lalu mengisinya sendiri dengan tebakan yang terdengar masuk akal.
• Diagram sebagai satu-satunya sumber aturan. Use case diagram dan ERD berbentuk gambar tidak terbaca sebagai aturan. Apa pun yang penting harus ada dalam bentuk teks.
• Istilah yang berganti-ganti di tengah dokumen. Bab 3 menyebut Peminjam, bab 5 menyebut User, lampiran menyebut Mahasiswa. Agent bisa menyimpulkan itu tiga peran berbeda dan membuatkan tiga tabel.
• Bab jadwal, anggaran, dan struktur tim. Nggak ada satu pun yang mengubah baris kode, tapi semuanya ikut memakan perhatian agent.
• Aturan angka yang nggak disebut satuannya. "Maksimal 8 jam" aman. "Durasi maksimal 8" bisa jadi 8 menit.

Perbaikannya: tulis ulang jadi kalimat yang punya pelaku

Bandingkan dua versi kebutuhan yang sama. Versi atas lolos sidang. Versi bawah lolos sidang dan menghasilkan kode yang benar.

SEBELUM (lolos sidang, bikin agent nebak)
  Sistem menyediakan fitur pengajuan peminjaman ruangan.
  Data pengajuan akan divalidasi terlebih dahulu sebelum
  disimpan ke dalam basis data. Sistem akan menampilkan
  notifikasi apabila terjadi kesalahan.

SESUDAH (isinya sama, tapi tidak ada yang perlu ditebak)
  SRS-F-02 Mengajukan peminjaman
  Aktor: Peminjam.
  Server memeriksa semua aturan berikut sebelum menyimpan.
  Pemeriksaan di browser hanya untuk kenyamanan, bukan pengaman.
    - jam_selesai > jam_mulai, keduanya di rentang 07:00-21:00
    - tanggal kegiatan minimal 2 hari dari hari ini
    - jumlah_peserta <= kapasitas ruangan
    - tidak beririsan dengan peminjaman berstatus DISETUJUI
      di ruangan dan tanggal yang sama
  Jika ada aturan yang gagal, kembalikan pesan yang menyebut
  aturan mana yang gagal, dan JANGAN simpan barisnya.

Versi kedua menyebut siapa yang melakukan apa, dan apa yang terjadi kalau gagal. Dua hal itu yang bikin agent berhenti menebak.

SRS, PRD, user story: bedanya di mana

Tiga istilah ini sering dipakai bergantian dan bikin bingung. Pembagian kasarnya begini. SRS menjawab sistemnya harus melakukan apa, ditulis lengkap dan formal, biasanya muncul kalau ada urusan akademik atau kontrak. PRD menjawab kenapa produk ini dibuat dan untuk siapa, bahasanya lebih santai dan halamannya lebih sedikit. User story potongan paling kecil dari keduanya, satu kalimat per kebutuhan.

Buat aplikasi kecil, banyak orang cukup pakai satu dokumen saja. Kalau kamu nggak lagi dikejar syarat kampus atau syarat vendor, PRD ramping biasanya lebih kepakai karena isinya langsung ke bagian yang mengubah kode. Kerangkanya bisa kamu ambil di template dan contoh PRD aplikasi, dan bab entitas, aturan bisnis, serta kriteria selesainya tinggal dipindahkan ke format SRS kalau nanti dibutuhkan.

Cara membuat SRS sendiri dalam satu duduk

Urutan ini kelihatan terbalik dari kebanyakan panduan, dan itu disengaja. Menulis dari bab satu ke bab enam bikin kamu menghabiskan energi di bagian pembungkus dan kehabisan tenaga waktu sampai ke isinya.

1. Tulis dulu daftar aktor. Siapa saja yang menyentuh aplikasi ini, dan masing-masing datang untuk apa. Biasanya cuma dua atau tiga.
2. Tulis entitas dan kolomnya. Peminjaman punya apa saja, Ruangan punya apa saja. Ini yang paling menentukan bentuk aplikasinya nanti.
3. Tulis kebutuhan fungsional per aktor, satu kode per kebutuhan. Untuk tiap satu, isi alur utamanya dulu, baru aturannya.
4. Kejar aturan yang belum tertulis dengan pertanyaan usil: kalau dua orang melakukannya bersamaan gimana, kalau datanya kosong gimana, kalau dibatalkan setelah disetujui gimana, siapa yang boleh melihat data siapa.
5. Baru tulis kebutuhan non-fungsional, dan pastikan tiap barisnya punya angka atau kondisi yang bisa dites.
6. Tulis kriteria penerimaan sambil membayangkan kamu sedang mengetes aplikasinya pegang HP. Satu langkah, satu hasil yang kelihatan.
7. Terakhir baru bab pendahuluan dan deskripsi umum. Di titik ini kamu sudah tahu persis batas ruang lingkupnya, jadi menulisnya sepuluh menit.

Langkah keempat itu yang paling memakan waktu, dan paling sering dilewat orang yang buru-buru. Padahal di situ letak nilai dokumennya. Kalau kamu mau versi yang lebih terpandu untuk urusan produk, langkah sejenis dibahas lebih dalam di cara membuat PRD untuk aplikasi.

Pertanyaan yang sering muncul

SRS harus berapa halaman?

Untuk aplikasi sekecil contoh di atas, isi yang benar-benar kepakai muat di 5 sampai 8 halaman. Kalau dosenmu menetapkan jumlah halaman minimum, tambahkan lampiran seperti contoh isi tabel, rancangan layar, atau hasil wawancara. Jangan menggemukkan bab kebutuhan dengan kalimat berputar, karena bagian itu yang paling gampang ketahuan waktu ditanya.

Wajib pakai struktur IEEE 830?

Kalau ini tugas kuliah atau lampiran skripsi, tanyakan ke dosen atau pembimbingmu, karena sebagian memang mensyaratkan nomor babnya persis. Di luar itu kamu bebas. Yang dinilai orang yang membacanya cuma satu: apakah dia bisa membangun aplikasi itu tanpa bertanya balik ke kamu.

Apa bedanya kebutuhan fungsional dan non-fungsional?

Kebutuhan fungsional itu apa yang bisa dikerjakan aplikasi: mengajukan peminjaman, menyetujui, mengunduh rekap. Kebutuhan non-fungsional itu seberapa baik dia mengerjakannya: secepat apa, seaman apa, semudah apa dipakai. Cara membedakan paling gampang, kebutuhan fungsional selalu bisa ditulis sebagai kata kerja yang dilakukan seseorang.

Boleh nggak SRS-nya dibikinin AI lalu tinggal dikumpulkan?

Bagian yang berulang dan berpola memang enak dibantu, misalnya menyusun ulang kebutuhan jadi format yang rapi. Tapi aturan bisnis yang bikin dokumenmu bernilai, misalnya batas H-2, kuota 3 pengajuan, atau keputusan bahwa data tidak pernah dihapus permanen, itu datang dari kamu yang tahu konteksnya. AI akan mengarang aturan yang terdengar wajar tapi belum tentu sesuai kenyataan di lapangan, dan kamu yang harus mempertanggungjawabkannya di depan penguji.

Langkah berikutnya

Salin contoh di atas, ganti SIPRUK dengan aplikasimu, lalu isi bab tiga sampai bab enam dengan aturan yang benar-benar berlaku di kasusmu. Bagian yang bakal terasa berat cuma satu: mengejar aturan dan kondisi tak terduga yang belum kamu pikirkan. Itu wajar, dan itu juga yang bikin dokumennya berguna.

Kalau kamu ingin bagian itu dibantu, Skematik bekerja dengan cara begini: kamu ceritakan idemu pakai bahasa sehari-hari, lalu dokumennya disusun terstruktur lengkap dengan entitas, aturan, dan kriteria selesai per fitur, dalam bentuk yang bisa langsung kamu serahkan ke AI coding agent. Struktur babnya lebih dekat ke PRD daripada IEEE 830, tapi isi bab kebutuhan, model data, dan kriteria penerimaannya tinggal kamu pindahkan ke kerangka SRS di atas.