Gambaran besar dulu
Bayangkan kamu mau renovasi rumah. Sebelum tukang mulai bongkar dinding, pasti ada obrolan dulu: “Mau tambahin kamar berapa? Budgetnya berapa? Mau pakai keramik atau granit?” Semua kesepakatan itu ditulis di atas kertas supaya nanti nggak ada drama “lho, kok beda sama yang saya minta.”
NRD itu versi dunia jaringan dari surat kesepakatan renovasi tadi.
NRD, atau Network Requirement Document, adalah dokumen tertulis yang mencatat semua kebutuhan jaringan sebuah organisasi: mau berapa komputer yang terhubung, kecepatan internetnya berapa, kapan jaringan harus nyala, dan berapa duit yang tersedia. Dokumen ini dibuat sebelum satu pun kabel dipasang atau satu pun router dinyalakan.
Kenapa repot-repot bikin dokumen segala? Karena tanpa NRD, kamu bisa saja membangun jaringan yang “secara teknis jalan” tapi nggak sesuai harapan klien. Misalnya klien butuh jaringan untuk video conference 50 orang, tapi kamu cuma sediain bandwidth buat browsing biasa. Hasilnya? Video patah-patah, klien kecewa, dan kamu harus kerja ulang.
Isi NRD: apa saja yang harus ada?
NRD punya beberapa bagian utama. Kita bedah satu per satu.
1. Ringkasan organisasi
Ini semacam “profil klien.” Isinya: nama organisasi, bidang usaha, jumlah karyawan, jumlah gedung/lantai, dan gambaran umum aktivitas yang butuh jaringan. Contoh: “SMK Satya Bhakti Ilmu, sekolah kejuruan dengan 3 jurusan, 2 lab komputer masing-masing 40 PC, dan 1 ruang guru.”
Kenapa ini perlu? Karena kebutuhan jaringan warnet beda jauh sama kebutuhan jaringan rumah sakit. Profil organisasi jadi landasan semua keputusan teknis selanjutnya.
2. Kebutuhan fungsional (functional requirements)
Ini jawaban dari pertanyaan: “Jaringan ini mau dipakai buat apa?”
Contoh kebutuhan fungsional:
- Akses internet untuk 80 PC siswa secara bersamaan
- Sharing printer di setiap ruangan
- Sistem CCTV yang bisa dipantau dari ruang kepala sekolah
- WiFi untuk area kantor guru
3. Kebutuhan non-fungsional (non-functional requirements)
Kalau fungsional itu soal “mau bisa ngapain,” non-fungsional itu soal “seberapa bagus.” Ini yang sering dilupakan padahal sama pentingnya.
Contoh:
- Uptime target 99% (artinya dalam setahun, jaringan boleh mati maksimal sekitar 3,5 hari)
- Waktu respons maksimal 50 ms untuk akses aplikasi internal
- Data siswa harus terenkripsi saat ditransmisikan
4. Spesifikasi minimum
Di sinilah angka-angka teknis muncul. Bukan sekadar “internet cepat,” tapi harus terukur:
- Jumlah node (perangkat yang terhubung): misalnya 120 node
- Bandwidth minimum: misalnya 100 Mbps dedicated
- Target uptime: 99%
- Kapasitas WiFi: minimal 50 koneksi simultan
5. Constraint (batasan)
Setiap proyek punya batasan. Nggak ada proyek dengan anggaran tak terbatas. Batasan yang umum:
- Anggaran: Rp 50.000.000
- Ruang fisik: server room cuma 3×3 meter, ventilasi terbatas
- Keamanan khusus: data keuangan harus di VLAN terpisah
- Waktu pengerjaan: maksimal 2 bulan
6. Klasifikasi must-have vs nice-to-have
Ini bagian yang bikin NRD lebih realistis. Nggak semua kebutuhan punya prioritas yang sama, apalagi kalau anggarannya terbatas.
Must-have itu kebutuhan yang kalau nggak ada, jaringan gagal total memenuhi fungsinya. Contoh: koneksi internet untuk lab komputer.
Nice-to-have itu kebutuhan yang bagus kalau ada, tapi proyek tetap bisa jalan tanpanya. Contoh: WiFi di taman sekolah.
Cara membedakannya gampang: tanya “kalau fitur ini dihilangkan, apakah operasional sehari-hari terganggu parah?” Kalau jawabannya ya, itu must-have. Kalau jawabannya “ya agak kurang enak sih, tapi masih bisa kerja,” itu nice-to-have.
Langkah kerja menyusun NRD
Prosesnya berurutan. Jangan loncat-loncat.
Langkah 1: Buka lagi dokumen User Requirement Analysis
Di tugas sebelumnya, kamu sudah wawancara “klien” dan mencatat semua kebutuhannya. Dokumen itu jadi bahan baku NRD. Baca ulang dengan teliti, tandai bagian yang masih ambigu atau kurang detail.
Langkah 2: Pisahkan must-have dan nice-to-have
Ambil setiap kebutuhan dari dokumen wawancara, lalu masukkan ke salah satu kolom. Kalau ragu, tanya ke klien. Jangan asal tebak sendiri.
Langkah 3: Tentukan spesifikasi minimum
Terjemahkan kebutuhan jadi angka. “Butuh internet lancar” itu bukan spesifikasi. “Bandwidth minimum 50 Mbps untuk 40 user simultan” itu spesifikasi. Setiap angka harus bisa dijustifikasi: kenapa 50 Mbps? Karena rata-rata 1 user browsing butuh sekitar 1-2 Mbps, dan ada buffer untuk download file besar.
Langkah 4: Identifikasi semua constraint
Cek anggaran, ukuran ruangan, kebijakan keamanan yang sudah ada, dan deadline proyek. Tulis semuanya. Constraint yang nggak ditulis di awal bakal jadi masalah di tengah jalan.
Langkah 5: Susun dokumen NRD
Gabungkan semua bagian tadi jadi satu dokumen dengan format profesional. Urutannya: ringkasan organisasi dulu, baru kebutuhan fungsional, non-fungsional, spesifikasi minimum, constraint, dan terakhir tabel prioritas must-have/nice-to-have.
Langkah 6: Presentasikan dan minta validasi
NRD yang sudah selesai dipresentasikan ke klien. Tujuannya bukan cuma “kasih lihat,” tapi memastikan klien setuju dengan semua isi dokumen. Kalau ada yang kurang atau salah, perbaiki di tempat. Setelah klien setuju, minta tanda tangan sebagai bukti persetujuan.
Apa yang sering salah
Jebakan paling umum: NRD yang isinya terlalu abstrak.
Contoh NRD buruk:
“Dibutuhkan jaringan internet yang cepat dan stabil untuk seluruh gedung.”
Kalimat ini nggak bisa dipakai buat apa-apa. “Cepat” itu berapa? “Stabil” itu uptime-nya berapa persen? “Seluruh gedung” itu berapa lantai, berapa ruangan, berapa titik akses?
Contoh NRD yang lebih baik:
“Dibutuhkan koneksi internet dedicated 100 Mbps (simetris) untuk gedung A (3 lantai, 15 ruangan, 85 node). Target uptime 99%. Setiap lantai minimal 2 access point WiFi dengan kapasitas 30 koneksi simultan per AP.”
Bedanya kelihatan, kan? Yang kedua bisa langsung dipakai sebagai panduan belanja perangkat dan konfigurasi.
Kesalahan kedua: nggak memisahkan must-have dan nice-to-have. Akibatnya, waktu anggaran dipotong (dan ini sering terjadi), tim nggak tahu fitur mana yang boleh dikorbankan duluan. Semua dianggap sama penting, padahal realitanya nggak begitu.
Kesalahan ketiga: lupa mencantumkan constraint. Misalnya nggak nulis bahwa ruang server cuma 2×2 meter. Baru ketahuan pas perangkat sudah dibeli dan ternyata nggak muat. Pemborosan waktu dan uang.
Kenapa NRD penting buat karir kamu
Tugas ini bukan sekadar tugas sekolah. Di dunia kerja, Network Project Manager yang nggak bisa bikin NRD yang jelas itu seperti arsitek yang nggak bisa bikin denah. Klien nggak akan percaya, dan proyek bakal berantakan.
NRD juga jadi “tameng” kalau di kemudian hari klien komplain: “Kok jaringannya nggak bisa gini?” Kamu bisa buka NRD dan bilang: “Pak, kebutuhan itu nggak ada di dokumen yang sudah Bapak tanda tangani.” Profesional, terukur, dan nggak ada debat kusir.
Kuis cek pemahaman
-
Apa bedanya kebutuhan fungsional dan kebutuhan non-fungsional? Kasih masing-masing satu contoh.
-
Seorang siswa menulis di NRD-nya: “Dibutuhkan WiFi yang kencang untuk semua ruangan.” Apa yang salah dengan kalimat ini, dan bagaimana kamu memperbaikinya?
-
Anggaran proyek jaringan sekolahmu dipotong 30%. Kamu punya daftar kebutuhan tapi belum dipisah prioritasnya. Langkah apa yang harus kamu lakukan pertama kali, dan kenapa?