Saya menulis persyaratan database 6 atau 7 tahun yang lalu untuk menangani ini. Setiap catatan kebutuhan memiliki deskripsi singkat, memo "definisi", dan memo "catatan" (keduanya kaya teks, dengan kemampuan untuk menyematkan tangkapan layar, dll.). Ada bidang-bidang lain juga, untuk proyek, yang dapat dikirim, nomor urut (sehingga dapat dipesan secara logis), kasus penggunaan / fitur yang terkait dengan, perkiraan waktu, bidang untuk orang yang menanganinya, jika seseorang telah memilihnya untuk implementasi, dll.
Ada juga "Status" - "Dimasukkan", untuk sementara kami merancang fitur; "Disetujui", ditetapkan setelah sekelompok persyaratan ditinjau dan ditentukan untuk siap diimplementasikan; "Diimplementasikan", ditetapkan oleh programmer begitu mereka berpikir persyaratan telah selesai, dan "Divalidasi" begitu teknologi QA setuju dengan programmer. (Jika teknologi QA tidak setuju, ia dapat mengaturnya kembali ke "Disetujui" sehingga programmer mendapatkannya kembali.) Persyaratan juga dapat "Ditangguhkan", "Ditolak" atau "Dipertanyakan" (artinya Dewan Kontrol Perubahan perlu melihatnya .)
Trik untuk melakukan ini dengan baik adalah rincian yang wajar. Terkadang masuk akal untuk memiliki satu persyaratan kalimat (mis. "Masalah yang dijelaskan dalam edisi 12345 sudah diperbaiki"), tetapi secara umum, persyaratan harus menggambarkan semua aspek penting dari seluruh fitur (atau sebagian besar dari satu fitur). Misalnya, fitur "laporan baru" yang khas akan memiliki persyaratan untuk format laporan (seperti apa outputnya), dan persyaratan untuk dialog opsi (menjelaskan bidang, validasi, dll.) Bahkan mungkin ada yang ketiga jika ada generator yang rumit mengolah data, bukan hanya permintaan mudah atau sesuatu. Selain itu, kami akan membuat persyaratan "Bantuan" untuk topik bantuan yang sesuai.
Ada keuntungan besar menyimpan hal-hal ini dalam catatan basis data daripada dokumen besar. Banyak pemrogram dapat mengerjakan persyaratan pada saat yang bersamaan. Catatan individual dikunci sehingga hanya satu orang yang dapat mengedit pada satu waktu, tetapi mereka dapat dibuka dan dibaca ketika orang lain sedang mengedit. Namun, keuntungan terbesarnya adalah menyediakan dokumentasi yang mudah untuk mencari apa saja persyaratannya, dan mencatat bagaimana penerapannya. Kami memiliki lebih dari 25.000 persyaratan di sana sekarang, dan kami dapat dengan mudah menemukan semua persyaratan dengan kata-kata spesifik di semua bidang, atau definisi, atau catatan, atau apa pun, dalam waktu kurang dari 10 detik. (Cobalah dengan dokumen Word senilai 6+ tahun.)
Saya dapat melihat mengapa orang mungkin mengatakan itu adalah ide yang buruk untuk melakukan persyaratan dalam "pelacak bug", tetapi dugaan saya adalah itu karena alat menghisap, bukan karena menjaga persyaratan dalam database yang dapat dicari adalah ide yang buruk.