Scenario-based Requirements Engineering

Tambah pranala
Dari Wikipedia bahasa Indonesia, ensiklopedia bebas


Scenario-based Requirements Engineering berfokus pada penggunaan skenario pada rekayasa kebutuhan. Beberapa interpretasi mengenai skenario telah diusulkan, mulai dari contoh perilaku yang diambil dari use case,[1] deskripsi penggunaan sistem untuk membantu memahami sistem sosio-teknis,[2] dan narasi berbasis pengalaman untuk elisitasi dan validasi kebutuhan.[3][4] 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.[5] Atau, skenario dapat dilihat sebagai jalur melalui spesifikasi penggunaan sistem, dan direpresentasikan sebagai animasi dan simulasi sistem baru.[6] Dalam praktik industri, skenario telah digunakan sebagai situasi umum yang dapat mendorong penggunaan kembali pola desain.[7][8] Penggunaan kembali pengetahuan selama rekayasa kebutuhan berpotensi membawa manfaat yang cukup besar bagi produktivitas pengembang.[9] 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 [10] dan teori kesalahan manusia [11][12] digunakan untuk menyelidiki skenario penggunaan sistem di masa depan.[9] Skenario telah diadopsi dalam metode berorientasi objek [1][13] 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 [14] dan SCRAM.[15][16][17] Salah satu pengecualian adalah Cycle of Potts Inquiry [3] yang menggunakan skrip skenario untuk mengidentifikasi hambatan atau masalah dalam goal-oriented requirement analysis[9].

Kelebihan dan kekurangan skenario[sunting | sunting sumber]

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.[16]

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,[15] 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.[18] Skenario juga dapat membiaskan kepercayaan pada frekuensi kejadian dan probabilitas,[15] 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.[16]

Metode dan alat dalam Scenario-based RE[sunting | sunting sumber]

Metode Scenario-based Requirements Engineering dimaksudkan untuk diintegrasikan dengan pengembangan berorientasi objek (misalnya OOSE [1]), 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.[9] Tahapan dari metode ini terdiri dari elicit and document use case, analyse generic problems and requirements, generate scenarios, dan validate system requirements using scenarios[9].

Elicit and document use case[sunting | sunting sumber]

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.[9]

Analyse generic problems and requirements[sunting | sunting sumber]

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.[9]

Generate scenarios[sunting | sunting sumber]

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.[9]

Validate System requirements using scenarios[sunting | sunting sumber]

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.[9]

Meskipun metode ini tampaknya mengikuti urutan linear, dalam praktiknya tahapannya saling terkait dan berulang.[9] 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.[19] Alat hypertext RETH [20] menghubungkan skenario, goal dan kebutuhan fungsional untuk mendukung inspeksi skenario. Alat CREWS-SAVRE[11] 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.[3][21] Beirkut ini merupakan fungsi-fungsi utama dari CREWS-SAVRE:[9]

  • Spesifikasi use case tambahan dan kebutuhan sistem tingkat tinggi (domainer / pemodel use case mendukung metode tahap 1);[9]
  • Pembuatan skenario secara otomatis dari use case (generator skenario mendukung tahap 3);[9]
  • 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);[9]
  • Presentasi skenario, mendukung walkthrough yang dipimpin pengguna dan validasi kebutuhan sistem (scenario presenter mendukung tahap 4);[9]
  • 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.[9]

Batasan dalam Scenario-based RE[sunting | sunting sumber]

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.[9]

  1. ^ a b c Jacobson, Ivar. (1992). Object-oriented software engineering : a use case driven approach. ACM Press. ISBN 0201544350. OCLC 26132801. 
  2. ^ Carroll, John M. 1950- (John Millar) (1995). Scenario-based design : envisioning work and technology in system development. Wiley. ISBN 0471076597. OCLC 989040972. 
  3. ^ a b c Potts, C.; Takahashi, K.; Anton, A.I. (1994-03). "Inquiry-based requirements analysis". IEEE Software. 11 (2): 21–32. doi:10.1109/52.268952. ISSN 0740-7459. 
  4. ^ Sutcliffe, A. "A technique combination approach to requirements engineering". Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering. IEEE Comput. Soc. Press. doi:10.1109/isre.1997.566843. ISBN 0818677406. 
  5. ^ Potts, C.; Takahashi, K.; Smith, J.; Ota, K. "An evaluation of inquiry-based requirements analysis for an Internet service". Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95). IEEE Comput. Soc. Press. doi:10.1109/isre.1995.512559. ISBN 0818670177. 
  6. ^ P. Dubois, E. Dubois, and J. Zeippen, “On the Use of a Formal Representation,” Proc. Third Int’l Symp. Requirements Eng., IEEE CS Press, pp. 128–137, 1997.
  7. ^ Coad, Peter. (©1997 :). Object models : strategies, patterns, and applications. Yourdon. ISBN 0138401179. OCLC 300681946. 
  8. ^ Sutcliffe, Alistair (1995). "Requirements rationales". Proceedings of the conference on Designing interactive systems processes, practices, methods, & techniques - DIS '95. New York, New York, USA: ACM Press. doi:10.1145/225434.225439. ISBN 0897916735. 
  9. ^ a b c d e f g h i j k l m n o p q A.G. Sutcliffe, “Supporting Scenario-Based Requirements Engineering”, IEEE Transactions on Software Engineering, vol.24, no.12, pp.1071-1088, 1998.
  10. ^ Hollnagel, Erik. (1993). Human reliability analysis : context and control. Academic Press. ISBN 0123526582. OCLC 470396287. 
  11. ^ a b Norman, Donald A. (2002). The psychology of everyday things. Basic Books. ISBN 0465067093. OCLC 249303921. 
  12. ^ Reason, James. (2009). Human error. Cambridge University Press. ISBN 0521314194. OCLC 931723874. 
  13. ^ I. Graham, “Task Scripts, Use Cases and Scenarios in Object- Oriented Analysis,” Object-Oriented Systems, vol. 3, pp. 123–142, 1996.
  14. ^ Potts, C. "ScenIC: a strategy for inquiry-driven requirements determination". Proceedings IEEE International Symposium on Requirements Engineering (Cat. No.PR00188). IEEE Comput. Soc. doi:10.1109/isre.1999.777985. ISBN 0769501885. 
  15. ^ a b c Sutcliffe, Alistair, 1951- (2002). User-centred requirements engineering. Springer. ISBN 1852335173. OCLC 912411553. 
  16. ^ a b c Sutcliffe, Alistair (1998-03). "Scenario-based requirements analysis". Requirements Engineering. 3 (1): 48–65. doi:10.1007/bf02802920. ISSN 0947-3602. 
  17. ^ Sutcliffe, A.G.; Ryan, M. "Experience with SCRAM, a SCenario Requirements Analysis Method". Proceedings of IEEE International Symposium on Requirements Engineering: RE '98. IEEE Comput. Soc. doi:10.1109/icre.1998.667822. ISBN 0818683562. 
  18. ^ P.N. Johnson-Laird, "The Computer and the Mind: An Introduction to Cognitive Science", Cambridge MA: Harvard University Press, 1988.
  19. ^ Nielsen, Jakob, 1957- (2009, ©1993). Usability engineering. Morgan Kaufmann. ISBN 0125184069. OCLC 780810387. 
  20. ^ A. Cockburn, “Structuring Use Cases with Goals,” 1995. http://members.aol.com/acockburn/papers/usecase.htm
  21. ^ J.D. Palmer, “Traceability,” Software Engineering, M. Dorfman and R.H. Thayer, eds., pp. 266–276, 1996.
Diperoleh dari "https://id.wikipedia.org/w/index.php?title=Scenario-based_Requirements_Engineering&oldid=25309303"