SDLC punya tujuh fase inti, dari ide sampai software yang terus dirawat:

Tahap pemeliharaan akan memicu perencanaan baru, sehingga prosesnya berupa siklus, bukan garis lurus. Di bab ini kita membahas dua tahap pertama secara rinci, karena keduanya menentukan arah seluruh proyek.

Perencanaan adalah tahap fondasi. Tujuannya memastikan proyek layak dijalankan dan semua pihak sepakat tentang apa yang akan dibangun. Ada tiga pertanyaan kunci di tahap ini:

1. Apa masalahnya?
2. Apakah layak secara teknis dan finansial?
3. Berapa lama dan berapa biayanya?

Aktivitas Utama

• Mendefinisikan masalah, tujuan, dan ruang lingkup proyek.
• Melakukan studi kelayakan dari lima sisi: teknis, ekonomi, operasional, hukum, dan jadwal.
• Mengestimasi biaya, waktu, dan sumber daya.
• Mengidentifikasi risiko awal beserta rencana mitigasinya.
• Menyusun jadwal, milestone, dan membentuk tim.

Studi Kelayakan pada Aplikasi Kas Kelas

Mari terapkan lima sisi kelayakan ke contoh berjalan kita:

Kalau salah satu sisi jawabannya "tidak", lebih baik proyek ditunda atau ruang lingkupnya dikurangi sekarang, bukan setelah kode setengah jadi.

Output dan Peran

Deliverable tahap perencanaan adalah Project Charter, Laporan Studi Kelayakan, Rencana Proyek dan Jadwal, serta Daftar Risiko (Risk Register). Pihak yang terlibat: Project Manager, Sponsor, Stakeholder, dan Business Analyst.

Risk register tidak perlu rumit. Untuk kas kelas, isinya bisa seperti ini: "Risiko: anggota tim sibuk ujian di minggu ke-4. Mitigasi: fitur inti selesai sebelum minggu ke-4."

Kalau perencanaan menjawab "apakah proyek ini layak", analisis kebutuhan menjawab APA yang dibutuhkan pengguna secara rinci. Hasilnya dituangkan ke dalam dokumen Software Requirements Specification (SRS).

Tahap ini sangat menentukan. Kebutuhan yang buruk adalah penyebab umum kegagalan proyek. Kode sebagus apa pun tidak berguna kalau yang dibangun bukan yang dibutuhkan.

Fungsional vs Non-Fungsional

Kebutuhan dibagi dua jenis:

• Kebutuhan fungsional: apa yang harus dilakukan sistem. Ini berupa fitur.
• Kebutuhan non-fungsional: seberapa baik sistem bekerja. Ini berupa kualitas.

Contoh dari deck:

Trik cepat membedakannya: kebutuhan fungsional biasanya bisa ditulis sebagai "pengguna dapat ..." atau "sistem ...", sedangkan non-fungsional biasanya mengandung ukuran kualitas seperti waktu, persen, atau tingkat kemudahan.

Untuk aplikasi kas kelas:

• Fungsional: bendahara dapat mencatat iuran, siswa dapat melihat saldo, wali kelas dapat mencetak laporan bulanan.
• Non-fungsional: halaman saldo terbuka di bawah 2 detik di ponsel, hanya bendahara yang bisa mengubah data.

Teknik Pengumpulan Kebutuhan

Kebutuhan tidak muncul sendiri. Kamu harus menggalinya dengan teknik berikut:

• Wawancara: bertanya langsung ke bendahara dan wali kelas.
• Kuesioner: menyebar pertanyaan ke seluruh siswa sekaligus.
• Observasi: melihat bagaimana bendahara mencatat di buku tulis saat ini.
• Workshop: duduk bersama semua pihak untuk menyepakati fitur.
• Prototyping: menunjukkan rancangan kasar agar pengguna bisa bilang "ya, seperti ini" atau "bukan".
• User Story: menulis kebutuhan dari sudut pandang pengguna.

Contoh user story: "Sebagai bendahara, saya ingin melihat siapa saja yang belum membayar minggu ini, agar saya bisa menagih tepat sasaran."

Output tahap ini adalah SRS, Use Case, dan User Story.

Memeriksa Kelengkapan Kebutuhan dengan Kode

Daftar kebutuhan yang baik punya identitas, deskripsi, dan jenis yang jelas. Kamu bisa memodelkan pemeriksaan sederhana seperti ini:

const kebutuhan = [
  { id: "F-01", deskripsi: "Bendahara dapat mencatat iuran", jenis: "fungsional" },
  { id: "NF-01", deskripsi: "Halaman saldo terbuka di bawah 2 detik", jenis: "non-fungsional" },
];

const fungsional = kebutuhan.filter((k) => k.jenis === "fungsional");
console.log(fungsional.length); // 1

Di latihan bab ini, kamu akan menulis fungsi yang memisahkan kebutuhan berdasarkan jenisnya.

• Menulis kebutuhan yang kabur, misalnya "aplikasi harus cepat". Lebih baik "respons di bawah 2 detik" karena bisa diukur dan diuji.
• Melupakan kebutuhan non-fungsional. Fitur lengkap tapi lambat dan tidak aman tetap mengecewakan pengguna.
• Hanya bertanya ke satu orang. Wali kelas dan siswa punya kebutuhan yang berbeda dari bendahara.
• Melewatkan studi kelayakan. Proyek yang ternyata tidak layak sebaiknya dihentikan di awal, bukan di tengah jalan.