Pengumpulan requirements itu sebenarnya bukan hal yang sepele. Ada enam langkah utama dalam proses ini untuk mendefinisikan masalah yang perlu diselesaikan dan mendokumentasikan bagaimana cara menyelesaikannya. Langkah-langkah tersebut termasuk:

1. Mengidentifikasi stakeholder
2. Menetapkan tujuan dan objektif
3. Mengumpulkan requirements dari stakeholder
4. Mendokumentasikan requirements
5. Menganalisis dan mengonfirmasi requirements
6. Memprioritaskan requirements

Pada umumnya, stakeholder itu adalah orang-orang yang bekerja di organisasi yang meminta pengembangan produk perangkat lunak. Beberapa orang penting di organisasi ini bisa termasuk pengambil keputusan, pengguna akhir, administrator sistem, tim engineering, pemasaran, sales, dan customer support. Idealnya, setiap grup yang berpengaruh terhadap produk sebaiknya punya perwakilan di sini.

Tujuan produk harus jelas, ya. Tujuan itu adalah hasil jangka panjang yang bisa dicapai, dan bisa mencakup hasil yang diinginkan oleh pelanggan serta tujuan bisnis. Setelah itu, objektif harus ditentukan. Objektif lebih spesifik daripada tujuan, dan merupakan langkah-langkah yang dapat diukur untuk mencapai tujuan yang sudah ditetapkan.

Nah, tiga langkah berikutnya—mengumpulkan, mendokumentasikan, dan konfirmasi requirements—biasanya dilakukan secara iteratif. Proses elicitation atau pengumpulan requirements bisa dilakukan dengan survei, kuesioner, atau wawancara. Ketika requirements mulai terlihat, mereka harus langsung didokumentasikan dan diperiksa agar selaras dengan tujuan dan objektif. Requirements yang sudah didokumentasikan harus jelas dan mudah dipahami oleh semua stakeholder dan tim proyek. Setelah itu, untuk mengonfirmasi requirements, mereka harus dianalisis untuk memastikan konsistensi, kejelasan, dan kelengkapannya. Setelah dianalisis, requirements harus dibagikan dan disetujui oleh stakeholder.

Setelah terkonfirmasi, baru deh requirements diprioritaskan. Label seperti “must-have”, “highly desired”, dan “nice to have” bisa sangat membantu dalam hal ini. Kalau bisa, urutkan requirements dalam kategori tersebut.

Biasanya, ada tiga dokumen utama yang dihasilkan dari proses pengumpulan requirements ini:

• Software Requirements Specification (SRS)
• User Requirements Specification (URS)
• System Requirements Specification (SysRS)

Yang paling umum dipakai adalah SRS. SRS adalah dokumen yang menangkap semua fungsionalitas yang harus dilakukan oleh perangkat lunak dan juga menetapkan benchmark atau standar layanan untuk performanya. Di dalam SRS, ada beberapa bagian penting, antara lain:

1. Purpose statement – berisi tujuan dari SRS itu sendiri, siapa audiensnya, ruang lingkupnya, serta constraints, asumsi, dan dependencies terkait.
2. Requirements – dibagi ke dalam empat kategori:
   • Functional requirements: Fungsionalitas perangkat lunak itu sendiri
   • External Interface requirements: Perilaku perangkat lunak terhadap entitas eksternal seperti pengguna atau interaksi dengan perangkat keras/ perangkat lunak lain
   • System Features: Fitur-fitur yang wajib ada untuk sistem bekerja dengan baik
   • Non-functional requirements: Standar kualitas, performa, keamanan, dll.

Bagian dari dokumen SRS yang juga perlu diperhatikan adalah constraints dan assumptions. Constraints itu mengatur bagaimana produk harus bekerja di kondisi tertentu yang mungkin membatasi opsi desain—contohnya, produk harus sesuai standar atau dibatasi oleh hardware tertentu. Asumsi bisa berupa hal-hal seperti sistem operasi atau hardware yang dibutuhkan. Dependency juga harus dicatat, misalnya ketergantungan dengan perangkat lunak lain.

User Requirements Specification (URS) biasanya lebih fokus pada kebutuhan bisnis dan ekspektasi pengguna akhir dari sistem perangkat lunak itu. User stories atau use cases biasanya digunakan untuk menjelaskan kebutuhan pengguna. Tiga pertanyaan yang harus dijawab dalam user stories adalah:

• Siapa pengguna?
• Fungsi apa yang perlu dilakukan?
• Kenapa pengguna membutuhkan fungsi tersebut?

Testing yang dilakukan oleh pengguna atau user acceptance testing (UAT) bertujuan untuk memastikan apakah requirements ini sudah dipenuhi atau belum.

Nah, terakhir, ada juga System Requirements Specification (SysRS), yang lebih luas dibandingkan SRS. Dokumen ini menggambarkan kebutuhan sistem secara keseluruhan, bukan hanya software-nya saja. Beberapa hal yang di-cover di SysRS antara lain:

• Kemampuan sistem, antarmuka, dan karakteristik pengguna
• Kebijakan, regulasi, kebutuhan personalia, performa, dan persyaratan keamanan
• Kriteria penerimaan sistem
• Ekspektasi terhadap hardware yang dibutuhkan oleh sistem selain software

SysRS sering kali disamakan dengan SRS, tapi kenyataannya lebih banyak digunakan untuk proyek yang membutuhkan dokumentasi lebih mendalam mengenai keseluruhan sistem.