Jaga keterlacakan persyaratan saat perangkat lunak berubah

Jelaskan perilaku yang dapat diverifikasi

“Buat ekspor pelanggan modern” menyisakan keputusan penting. Pernyataan itu tidak menentukan pengguna, data, field, atau perilaku kegagalan. Agen harus bertanya atau membuat asumsi. Asumsi yang tidak dicatat sulit ditinjau kemudian.

Gunakan persyaratan fiktif dengan batas jelas: manajer terautentikasi dapat mengekspor pelanggan aktif dari organisasinya sendiri. Ekspor memuat ID pelanggan dan nama tampilan. Ekspor tidak menyertakan detail kontak dan data berstatus arsip. Pengguna tanpa peran manajer tidak menerima ekspor.

Ini masih memerlukan keputusan tentang format, volume, waktu respons, dan penanganan kegagalan. Tandai hal yang belum diketahui secara eksplisit. Spesifikasi yang berguna memperlihatkan ketidakpastian alih-alih menyembunyikannya dalam uraian yang terdengar yakin.

Pisahkan persyaratan dari pilihan implementasi

Pengguna memerlukan kumpulan data yang diizinkan dalam format yang dapat digunakan. Kueri database, library, dan struktur endpoint merupakan pilihan implementasi. Hubungkan dengan persyaratan tanpa memperlakukan setiap pilihan saat ini sebagai kebutuhan bisnis permanen.

Catat keputusan berdampak penting beserta konteks, alternatif, dan alasannya. Misalnya, ekspor sinkron mungkin sesuai untuk volume kecil. Volume lebih besar dapat memerlukan job latar belakang dan pemeriksaan otorisasi unduhan terpisah.

Pertahankan persyaratan tetap stabil jika memungkinkan, sambil memberi versi pada keputusan yang berubah. Ini membantu peninjau membedakan implementasi yang berbeda dari janji yang berbeda kepada pengguna.

Buat rantai bukti singkat

Gunakan pengenal yang tetap dapat dipahami dalam peninjauan. Dalam contoh ini, EXPORT-01 dapat mengidentifikasi batas organisasi. Nama ini hanya ilustrasi, bukan sistem penomoran wajib.

Rantai harus menunjuk pada bukti nyata. Nama pengujian yang memuat ID persyaratan tidak membuktikan bahwa assertion memeriksanya. Periksa pengujian dan jalur produksi yang diuji.

SSDF NIST menyediakan konteks persyaratan dan verifikasi dalam pengembangan aman. Gunakan keterlacakan agar aktivitas tersebut dapat diperiksa, bukan sekadar menghasilkan dokumentasi. Baca kerangkanya.

Tinjau dampak perubahan asumsi

Misalkan bisnis kini memerlukan pelanggan berstatus arsip. Perubahan ini memengaruhi lebih dari satu flag kueri. Periksa aturan retensi, otorisasi, volume yang diharapkan, penjelasan kepada pengguna, dan makna laporan yang sudah ada.

Tandai dokumen dan pemeriksaan terdampak untuk ditinjau. Pertahankan keputusan sebelumnya agar operator dapat menjelaskan rilis lama. Jangan diam-diam menulis ulang riwayat agar desain terbaru tampak sebagai satu-satunya pilihan yang mungkin.

Agen dapat membantu menemukan referensi dan mengusulkan pembaruan. Penanggung jawab harus menyelesaikan persyaratan yang bertentangan dan menerima perubahan perilaku. Daftar file yang cocok merupakan titik awal, bukan penilaian dampak lengkap.

Jaga catatan cukup ringkas untuk digunakan

Catat keputusan yang memengaruhi implementasi, verifikasi, dan operasi. Hindari mengulang persyaratan yang sama dalam banyak dokumen yang tidak terhubung. Utamakan tautan ke satu sumber yang dipelihara.

Sebelum menerima perubahan, tanyakan apakah peninjau dapat menelusuri tujuannya hingga bukti yang sebenarnya. Sebelum mengoperasikannya, tanyakan apakah penanggung jawab layanan dapat menemukan batas dan keputusan pemulihan yang relevan. Ini pengujian praktis untuk keterlacakan yang berguna.