Scenario-based Requirements Engineering

***Scenario-based Requirements Engineering*** berfokus pada penggunaan skenario pada rekayasa kebutuhan. Beberapa interpretasi mengenai skenario telah diusulkan, mulai dari contoh perilaku yang diambil dari *[[:en:Use case|use case]]*, deskripsi penggunaan sistem untuk membantu memahami sistem sosio-teknis, dan narasi berbasis pengalaman untuk elisitasi dan validasi kebutuhan. Kamus Bahasa Inggris Oxford mendefinisikan skenario sebagai "garis besar atau skrip film, dengan detail adegan atau urutan kejadian yang dibayangkan di masa depan". Dalam konteks rekayasa kebutuhan, skenario didefinisikan sebagai fakta yang mendeskripsikan sistem yang ada saat ini dan lingkungannya termasuk perilaku (*behaviour*) agen dan konteks informasi yang mencukupi untuk memungkinkan adanya penemuan dan validasi dari kebutuhan sistem. Skenario sering kali mendeskripsikan informasi pada level perumpamaan atau contoh. Hal ini menimbulkan pertanyaan mengenai bagaimana informasi pada level perumpamaan dapat digeneralisasi menjadi model dan spesifikasi yang digunakan pada rekayasa perangkat lunak. Skenario dapat juga digunakan untuk memvalidasi kebutuhan, karena ‘data uji’ dikumpulkan dari praktik yang dapat diamati, di mana pengoperasian sistem baru dapat diperiksa. Atau, skenario dapat dilihat sebagai jalur melalui spesifikasi penggunaan sistem, dan direpresentasikan sebagai animasi dan simulasi sistem baru. Dalam praktik industri, skenario telah digunakan sebagai situasi umum yang dapat mendorong penggunaan kembali pola desain. Penggunaan kembali pengetahuan selama rekayasa kebutuhan berpotensi membawa manfaat yang cukup besar bagi produktivitas pengembang. Skenario dapat dibuat sebagai proyeksi penggunaan sistem di masa depan, sehingga membantu mengidentifikasi kebutuhan, tetapi hal ini menimbulkan pertanyaan tentang berapa banyak skenario yang diperlukan untuk memastikan kebutuhan yang memadai, sehingga taksonomi peristiwa  dan teori kesalahan manusia  digunakan untuk menyelidiki skenario penggunaan sistem di masa depan. Skenario telah diadopsi dalam metode berorientasi objek  sebagai proyeksi interaksi dengan sistem yang dirancang. Dalam konteks ini, skenario didefinisikan sebagai jalur interaksi yang dapat terjadi dalam *use case*. Beberapa metode menyarankan tentang cara menggunakan skenario dalam proses analisis kebutuhan dan validasi, di antaranya metode ScenIC  dan SCRAM. Salah satu pengecualian adalah *Cycle of Potts Inquiry*  yang menggunakan skrip skenario untuk mengidentifikasi hambatan atau masalah dalam *[[Goal-based Requirement Analysis Method (GBRAM)|goal-oriented requirement analysis]][[Goal-based Requirement Analysis Method (GBRAM)|.]]*

## Kelebihan dan kekurangan skenario
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 "*[[:en:The devil is in the detail|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 *[[:en:Library (computing)|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 *[[:en:Design rationale|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.

### ''Generate scenarios''
Langkah ini menghasilkan skenario dengan menelusuri setiap urutan peristiwa yang mungkin dalam *use case*, menerapkan heuristik yang menunjukkan kemungkinan pengecualian (''exceptions'') dan kesalahan yang mungkin terjadi pada setiap langkah. Analisis ini membantu analis untuk menguraikan jalur melalui *use case* dalam dua fase; pertama untuk perilaku normal dan kedua untuk perilaku abnormal. Setiap jalur menjadi skenario. Pembuatan skenario didukung oleh alat (*tools*) yang secara otomatis mengidentifikasi semua jalur yang mungkin melalui *use case* dan meminta pengguna untuk memilih jalur kesalahan yang lebih mungkin.

### ''Validate System requirements using scenarios''
Pembuatan skenario diikuti oleh validasi yang dibantu oleh alat yang mendeteksi pola peristiwa dalam skenario dan menyajikan daftar kebutuhan umum yang sesuai untuk pola peristiwa normal dan abnormal tertentu. Hasilnya adalah serangkaian *use case* yang diformat, skenario, dan spesifikasi kebutuhan yang telah diuraikan dengan kebutuhan yang dapat digunakan kembali.

Meskipun metode ini tampaknya mengikuti urutan linear, dalam praktiknya tahapannya saling terkait dan berulang. Ada beberapa alat yang mendukung proses *scenario-based requirements engineering*. Memformat dan memeriksa skenario untuk konsistensi dapat dibantu oleh pendekatan leksikal yang menyediakan basis data kata kunci dan templat untuk memformat pengetahuan terkait skenario. Alat hypertext RETH  menghubungkan skenario, *goal* dan kebutuhan fungsional untuk mendukung inspeksi skenario. Alat CREWS-SAVRE membantu menghasilkan variasi pada bibit skenario dengan pertama-tama memperluas urutan kejadian yang mungkin dapat dilacak dari model perilaku seperti *use case*, kemudian menyarankan permutasi yang mungkin ke urutan peristiwa menggunakan taksonomi kesalahan yang ditarik dari literatur faktor manusia. Beirkut ini merupakan fungsi-fungsi utama dari CREWS-SAVRE:

* Spesifikasi *use case* tambahan dan kebutuhan sistem tingkat tinggi (domainer / pemodel *use case* mendukung metode tahap 1);
* Pembuatan skenario secara otomatis dari *use case* (generator skenario mendukung tahap 3);
* Deskripsi manual *use case* dan skenario dari data historis penggunaan sistem sebelumnya, sebagai alternatif untuk pembuatan skenario otomatis berbasis alat (komponen pembuat *use case* / skenario mendukung tahap 1);
* Presentasi skenario, mendukung *walkthrough* yang dipimpin pengguna dan validasi kebutuhan sistem (*scenario presenter* mendukung tahap 4);
* Validasi semi-otomatis dari kebutuhan sistem yang tidak lengkap dan tidak benar menggunakan pola peristiwa skenario yang biasa terjadi (validator kebutuhan mendukung tahap 4). CREWS-SAVRE digabungkan dengan basis data kebutuhan pada RequisitePro sehingga dapat membuat kesimpulan tentang konten, jenis, dan struktur kebutuhan.

## Batasan dalam ''Scenario-based RE''
Skenario sangat padat karya untuk ditangkap dan didokumentasikan. Selain itu, ada sedikit rekomendasi konkret tentang bagaimana *scenario-based requirements engineering* harus dipraktikkan, dan bahkan lebih sedikit lagi dukungan alat yang tersedia untuk melakukan proses tersebut.

## Referensi