Cara Menyusun Dokumen Kebutuhan Sebelum Membuat Aplikasi

Jawaban singkat: dokumen kebutuhan aplikasi cukup memuat delapan hal: tujuan dan masalah yang ingin diselesaikan, pengguna dan peran beserta haknya, alur kerja sekarang dan yang diinginkan, data yang dikelola, laporan yang dibutuhkan, integrasi dengan sistem lain, batasan (waktu, anggaran, aturan), dan ukuran keberhasilan. Anda tidak perlu menulis spesifikasi teknis; yang dibutuhkan vendor adalah gambaran masalah yang jujur.

Banyak proyek aplikasi bermasalah bukan karena pembangunannya, melainkan karena kebutuhannya tidak pernah ditulis dengan jelas. Vendor menebak, penawaran tidak bisa dibandingkan, dan perubahan bermunculan di tengah jalan. Kabar baiknya, dokumen kebutuhan yang berguna tidak perlu ditulis oleh orang teknis. Ia perlu ditulis oleh orang yang paling paham prosesnya.

Kenapa dokumen kebutuhan penting

Dokumen kebutuhan punya tiga fungsi. Pertama, menyamakan pemahaman di internal: sering kali divisi yang berbeda punya bayangan berbeda tentang sistem yang sama. Kedua, membuat penawaran dari beberapa vendor bisa dibandingkan, karena semuanya menjawab kebutuhan yang sama. Ketiga, menjadi acuan saat ada perubahan: apa yang masuk ruang lingkup awal, dan apa yang merupakan permintaan baru.

Delapan bagian dokumen kebutuhan

Bagian	Pertanyaan yang dijawab	Contoh isi
Tujuan dan masalah	Kenapa sistem ini dibutuhkan?	“Pengajuan pembelian menunggu rata-rata seminggu karena persetujuan lewat surel”
Pengguna dan peran	Siapa memakai, dan boleh melakukan apa?	Staf mengajukan, kepala bagian menyetujui, keuangan memproses
Alur kerja	Bagaimana prosesnya berjalan, sekarang dan nanti?	Gambar langkah dari pengajuan sampai selesai, termasuk pengecualian
Data	Data apa yang dimasukkan, disimpan, dan dari mana asalnya?	Formulir pengajuan, lampiran, data pemasok
Laporan	Informasi apa yang perlu dilihat, oleh siapa, seberapa sering?	Rekap bulanan per divisi untuk manajemen
Integrasi	Sistem apa yang harus tersambung?	Aplikasi akuntansi, surel, login perusahaan
Batasan	Apa yang tidak bisa ditawar?	Tenggat, perkiraan anggaran, aturan internal atau regulasi
Ukuran keberhasilan	Bagaimana tahu sistem ini berhasil?	Waktu persetujuan turun menjadi dua hari kerja

Cara mengumpulkan isinya

1. Wawancarai orang yang menjalankan prosesnya, bukan hanya atasannya. Jalan pintas dan pengecualian biasanya hanya diketahui pelaksana.
2. Kumpulkan dokumen yang dipakai sekarang: formulir, spreadsheet, contoh laporan, dan surel persetujuan. Dokumen nyata lebih jujur daripada deskripsi.
3. Tulis pengecualian. Apa yang terjadi bila pengajuan ditolak, bila penyetuju cuti, atau bila data salah. Pengecualian sering menjadi sumber perubahan terbesar di tengah proyek.
4. Pisahkan wajib dan diinginkan. Tandai fitur yang harus ada di versi pertama dan yang bisa menyusul. Ini memudahkan vendor menyusun tahapan dan anggaran.
5. Minta setiap divisi membaca drafnya sebelum dikirim ke vendor.

Bila prosesnya masih berjalan di spreadsheet, artikel Tanda Proses Bisnis Sudah Tidak Tertampung Spreadsheet membantu memetakan masalah yang paling mahal lebih dulu.

Kerangka singkat yang bisa langsung dipakai

Salin kerangka ini ke dokumen baru, lalu isi setiap bagian dengan kalimat sederhana:

1. Latar belakang: proses apa yang dibahas, siapa yang menjalankannya, dan masalah apa yang paling terasa sekarang.
2. Tujuan: dua atau tiga hasil yang ingin dicapai, sebaiknya terukur.
3. Pengguna dan peran: tabel berisi peran, jumlah orang, dan apa yang boleh dilakukan masing-masing.
4. Alur kerja: langkah demi langkah dari awal sampai selesai, termasuk pengecualian dan siapa yang bertindak di tiap langkah.
5. Data dan dokumen: isian formulir, lampiran, dan contoh berkas yang dipakai sekarang.
6. Laporan: apa yang perlu dilihat, oleh siapa, dan seberapa sering.
7. Integrasi: sistem lain yang terlibat dan data apa yang bertukar.
8. Batasan dan prioritas: tenggat, perkiraan anggaran, aturan yang wajib diikuti, dan daftar fitur wajib serta yang bisa menyusul.

Lampirkan gambar alur, walau hanya digambar tangan dan difoto. Satu gambar alur sering menjawab pertanyaan yang butuh berhalaman-halaman teks.

Kesalahan yang sering terjadi

• Menulis solusi, bukan masalah. “Butuh tombol ekspor ke Excel” lebih sempit daripada “keuangan perlu rekap bulanan per divisi”. Masalah memberi ruang bagi solusi yang lebih baik.
• Menyalin fitur aplikasi lain tanpa menjelaskan kenapa dibutuhkan.
• Melupakan hak akses. Siapa yang boleh melihat dan mengubah data sering baru dibahas setelah sistem jadi, padahal mengubahnya di akhir lebih mahal.
• Tidak menyebut batasan anggaran. Tanpa gambaran anggaran, vendor tidak bisa menyarankan tahapan yang masuk akal.

Bagaimana Legia mengerjakannya

Anda tidak harus datang dengan dokumen lengkap. Dalam layanan Pembuatan Aplikasi Web, tahap pertama adalah pemetaan kebutuhan selama 1 sampai 2 minggu: Legia mewawancarai tim operasional dan mempelajari contoh dokumen yang dipakai sekarang, lalu menyusun dokumen ruang lingkup dan perkiraan biaya. Tahap berikutnya prototipe yang bisa diklik, yang disetujui sebelum pembangunan dimulai. Bila kebutuhan berubah di tengah jalan, perubahan dicatat sebagai permintaan tersendiri, dinilai dampaknya terhadap waktu dan biaya, lalu disepakati sebelum dikerjakan. Bila Anda belum yakin aplikasi custom adalah jawabannya, baca dulu Aplikasi Custom, Software Jadi, atau Spreadsheet.

Pertanyaan yang sering diajukan

Ada alur kerja yang sudah tidak tertampung spreadsheet dan surel? Lihat layanan Aplikasi & Software Legia, atau jadwalkan konsultasi lewat halaman kontak.