Saya mau tau Kelebihan dan kekurangan skenario dari Scenario-based Requirements Engineering

Keuntungan dari skenario terletak pada cara mereka mendasarkan argumen dan penalaran dalam detail atau contoh spesifik, tetapi kerugian dari menjadi spesifik adalah kehilangan generalitas. Skenario dalam arti dunia nyata adalah contoh spesifik. Tindakan analisis dan pemodelan adalah mencari pola dalam detail dunia nyata, kemudian mengekstrak esensi, sehingga menciptakan model. Hal ini menyebabkan skenario cocok dengan proses elisitasi kebutuhan yang mengumpulkan cerita dan contoh dari pengguna dan kemudian mencari generalisasi.

Keuntungan lain dari skenario terletak pada fokus mereka pada kenyataan yang memaksa kita untuk mengatasi "devil in the detail" selama spesifikasi kebutuhan dan validasi. Skenario juga dapat membantu untuk menangkal patologi dalam penalaran manusia, seperti tidak menguji hipotesis dan asumsi dalam model. Dalam rekayasa kebutuhan, skenario dapat membantu untuk menguji model dan spesifikasi selama validasi kebutuhan; Sayangnya, skenario juga dapat mendorong patologi lain, jadi kita harus waspada. Pertama adalah bias konfirmasi: kecenderungan mencari hanya contoh-contoh positif yang sesuai dengan prakonsepsi. Skenario juga dapat membiaskan kepercayaan pada frekuensi kejadian dan probabilitas, jadi penting untuk memastikan bahwa sampel skenario yang luas telah dikumpulkan. Hal Ini memaparkan salah satu dilema dalam scenario-based requirements engineering. Idealnya semakin banyak skenario semakin baik untuk meningkatkan cakupan tes, tetapi mengumpulkan dan menggunakan lebih banyak skenario menimbulkan biaya. Masalahnya adalah bahwa kita memerlukan banyak skenario untuk menguji spesifikasi kebutuhan umum.

Metode dan alat dalam Scenario-based RE

Metode Scenario-based Requirements Engineering dimaksudkan untuk diintegrasikan dengan pengembangan berorientasi objek (misalnya OOSE ), oleh karena itu use case digunakan untuk memodelkan fungsionalitas dan perilaku sistem. Dokumen spesifikasi kebutuhan terpisah dipertahankan untuk membuat kebutuhan eksplisit dan untuk menangkap keragaman jenis kebutuhan yang berbeda, yang banyak di antaranya tidak dapat ditemukan dalam use case. Use case dan spesifikasi kebutuhan dikembangkan secara iteratif saat analisis berlangsung. Skenario didefinisikan sebagai "satu urutan peristiwa yang merupakan salah satu jalur yang mungkin melalui use case". Oleh karena itu, banyak skenario dapat ditentukan untuk satu use case dan setiap skenario mewakili perumpamaan atau contoh peristiwa yang bisa terjadi. Tahapan dari metode ini terdiri dari elicit and document use case, analyse generic problems and requirements, generate scenarios, dan validate system requirements using scenarios.

Elicit and document use case

Pada tahap ini, use case diperoleh langsung dari pengguna sebagai riwayat penggunaan sistem dalam dunia nyata atau dibuat sebagai visi penggunaan sistem di masa depan. Model use case divalidasi untuk kebenaran sehubungan dengan sintaks dan semantiknya.

Analyse generic problems and requirements

Pada tahap ini, tersedia sebuah library umum yang dapat digunakan kembali dan dilampirkan pada model kelas aplikasi. Alat penelusuran mencocokkan use case dan fakta yang diperoleh dari perancang ke kelas aplikasi umum yang sesuai dan kemudian menyarankan kebutuhan umum tingkat tinggi yang melekat pada kelas sebagai design rationale "trade-offs". Kebutuhan umum diusulkan pada dua tingkatan: pertama, rutinitas umum untuk menangani pola kejadian yang berbeda, dan kedua, kebutuhan yang terkait dengan kelas aplikasi yang diadakan di repositori.