Scenario Based Requirement Analysis Method

Tambah pranala
Dari Wikipedia bahasa Indonesia, ensiklopedia bebas


Scenario Based Requirement Analysis Method (disingkat SCRAM) adalah salah satu metode rekayasa kebutuhan berbasis skenario. Terdapat dua metode rekayasa kebutuhan yang telah menempatkan peran penting bagi skenario, yaitu ScenIC[1] dan SCRAM.[2][3][4] Dalam metode SCRAM, skenario digunakan bersama prototipe awal untuk memperoleh kebutuhan sebagai respon dari desain awal. Pada dasarnya, pendekatan ini menggabungkan peran skenario pada proses elisitasi dan validasi dengan cara menyediakan konteks bagi pengguna untuk menilai desain yang menggambarkan skenario penggunaan.[5] SCRAM menggabungkan concept demonstrator, skenario, dan design rationale.[6] SCRAM menggunakan metode penelusuran naskah skenario untuk memvalidasi opsi desain untuk 'poin utama' dalam naskah. Desain alternatif didokumentasikan dalam design rationale dan dijelaskan pada pengguna melalui demo prototipe awal.[7] SCRAM terbukti bermanfaat untuk memfasilitasi requirement elaboration begitu prototipe awal dibuat.[8]

Definisi Skenario[sunting | sunting sumber]

Kamus Bahasa Inggris Oxford mendefinisikan skenario sebagai "ikhtisar atau naskah film dengan detail adegan atau bayangan urutan kejadian pada masa yang akan datang".[5] Dalam konteks rekayasan kebutuhan, skenario didefinisikan sebagai fakta yang menggambarkan sistem saat ini dan lingkungannya, termasuk juga perilaku dari agen dan informasi konteks yang memadai untuk memungkinkan adanya penemuan dan validasi kebutuhan sistem. Skenario merupakan contoh pengalaman nyata yang dialami pengguna selama menggunakan sistem.[9] Skenario dianjurkan sebagai metode komunikasi yang efektif antara pengguna dan stakeholder, serta dapat menangkap analisis kebutuhan dalam pengalaman di dunia nyata yang dapat diekspresikan dalam bahasa alami, gambar, atau media lainnya.[10][11][12]

Skenario sebagai representasi desain[sunting | sunting sumber]

Skenario yang merupakan representasi dari dunia nyata digeneralisasikan selama proses analisis kebutuhan untuk menghasilkan sebuah model yang familier bagi praktisi dalam bidang rekayasa kebutuhan dan rekayasa perangkat lunak.[5] Representasi informil lainnya, seperti design rationale[13] dapat menangkap keputusan desain yang didapatkan dari pernyataan masalah berbasis skenario, spesifikasi model dan spesifikasi kebutuhan diubah menjadi desain dan kemudian akan diimplementasikan. Selama proses itu, skenario yang menggambarkan perilaku dari artifak yang dirancang memiliki peran dalam proses validasi. Dalam hal ini, skenario serupa dengan model, baik dalam format maupun konten, meskipun keduanya biasanya mengilustrasikan urutan perilaku yang valid dalam batasan spesifikasi kebutuhan.[14] Dalam rute pengembangan alternatif melalui prototyping, skenario berfungsi sebagai inspirasi desain dan bahan untuk menguji desain prototipe.[2][12][15] Skenario dapat digunakan sebagai bahan pertimbangan untuk sebuah desain dan juga sebagai naskah uji dalam metode evaluasi.[16][17]

Peran skenario[sunting | sunting sumber]

Skenario memiliki 3 peran berbeda, yaitu:

  1. Sebuah cerita atau contoh peristiwa sebagai narasi dasar yang diambil dari pengalaman dunia nyata.[15] Cerita-cerita ini dekat dengan penggunaan akal sehat dan mungkin memuat perincian konteks sistem (adegan).[5]
  2. Gambaran masa depan sebuah sistem dengan urutan perilaku dan deskripsi kontekstual yang memungkinkan.[18] Pada kasus ini, skenario lebih dekat perannya dengan desain mockup.[5]
  3. Sebuah utas atau jalur yang digambarkan melalui model (biasanya use case). Istilah ini biasanya digunakan oleh komunitas berorientasi objek.[19][20][21] Model tersebut mungkin direpresentasikan sebagai tampilan animasi dari urutan peristiwa dalam urutan pesan atau diagram transisi keadaan.[5]

Metode SCRAM[sunting | sunting sumber]

SCRAM tidak secara eksplisit mencakup pemodelan dan spesifikasi, karena kedua hal tersebut dianggap berkembang secara paralel, mengikuti metode rekayasa perangkat lunak pilihan perancang.[5] Metode ini terdiri dari empat fase, yaitu:

Initial Requirements Capture and Domain Familiarisation[sunting | sunting sumber]

Fase ini dilakukan dengan wawancara konvensional dan teknik pencarian fakta untuk mendapatkan informasi yang cukup untuk mengembangkan concept demonstrator pertama. Initial Requirements Capture mengumpulkan fakta tentang domain dan menangkap sasaran tingkat tinggi pengguna untuk sistem yang akan dibangun. Skenario muncul sebagai contoh penggunaan sehari-hari dari sistem saat ini, dengan serangkaian masalah yang dihadapi dan bagaimana masalah tersebut ditangani. Jika dalam proses pencarian fakta menemui beberapa masalah, hal terbaik yang harus dilakukan adalah mencari kesamaan antara setiap versi individu yang berbeda dan membuat "normal use case" yang umum. Setelah use case tersedia, kumpulkan satu set exceptions, yaitu jalur alternatif dalam use case. Jumlah dari alternatif yang diperlukan tergantung pada kompleksitas sistem dan safety criticality. Fase ini juga menangkap sasaran tingkat tinggi pengguna.[5]

Storyboarding and Design Visioning[sunting | sunting sumber]

Fase ini menciptakan visi awal dari sistem yang diperlukan yang dijelaskan kepada pengguna dalam penelusuran storyboard untuk mendapatkan umpan balik tentang kelayakan sistem. Storyboard dibuat dengan mengembangkan desain awal dari sub-set skenario use case yang dikumpulkan dalam fase 1. Storyboard adalah sketsa atau layar tiruan yang menunjukkan langkah-langkah kunci dalam interaksi sistem pengguna. Analis menganalisis storyboard dengan menjelaskan apa yang terjadi pada setiap tahap dalam fungsi sistem, dan meminta pendapat pengguna. Umpan balik yang lebih baik akan diperoleh dengan menunjukkan prototipe interaktif pada fase selanjutnya, yaitu Requirements Exploration.[5]

Requirements Exploration[sunting | sunting sumber]

Tahap ini menggunakan concept demonstrator dan prototipe awal untuk menyajikan desain yang lebih rinci kepada pengguna dalam demonstrasi semi interaktif skenario sehingga desain dapat dikritik dan kebutuhan sistem dapat divalidasi. Concept Demonstrator adalah prototipe awal dengan fungsi dan interaktivitas terbatas, sehingga hanya dapat dijalankan sebagai skrip. Skrip menggambarkan skenario tindakan pengguna yang khas dengan respon sistem yang ditiru oleh perancang. Concept demonstrator berbeda dari prototipe karena hanya fungsionalitas minimal saja yang diterapkan dan pengguna tidak dapat dengan mudah berinteraksi dengan demonstrator. Skenario kontekstual dikembangkan berdasarkan analisis domain awal yang menggambarkan situasi yang diambil dari konteks kerja pengguna, skenario kontekstual tersebut juga harus berisi latar belakang yang mencukupi untuk menempatkan tindakan, yang dapat memberikan informasi yang cukup kepada pengguna untuk menafsirkan skrip. Para pengguna diundang untuk mengkritik concept demonstrator. Concept demonstrator dijelaskan oleh analis, sementara anggota tim desain lain berinteraksi dengan sistem. Pengujian langsung yang bersifat terbatas dapat diberikan pada sesi ini. Dalam fase selanjutnya, para pengguna didorong untuk mengklarifikasi setiap poin yang mereka temukan ambigu, kembali ke bagian mana pun dari demonstrasi, dan menguraikan kebutuhan lebih lanjut. Requirement engineer juga dapat menindaklanjuti poin yang diajukan atau komentar yang dibuat pengguna selama sesi tersebut. Skenario dapat dihubungkan dengan keputusan yang ditunjukkan dalam diagram design rationale yang menggambarkan trade-off dan asumsi yang mempengaruhi pilihan. Tautan lebih lanjut dapat melengkapi jalur dari skenario ke spesifikasi kebutuhan yang lebih formal.[5]

Prototyping and Requirements Validation[sunting | sunting sumber]

Fase ini mengembangkan prototipe yang lebih fungsional dan terus menyempurnakan kebutuhan sistem sampai prototipe disetujui untuk dapat diterima oleh semua pengguna. Setelah demonstrasi selesai, ringkasan dari kebutuhan akan dicantumkan. Kebutuhan-kebutuhan tersebut akan dibahas dan diberi prioritas menggunakan skala. Design rationale dapat digunakan dalam langkah ini untuk membantu diskusi terstruktur tentang trade-off desain dengan kriteria penilaian (sering kali kebutuhan non-fungsional) yang dapat digunakan untuk menilai manfaat dari solusi alternatif. Proses ini dapat diulangi menggunakan prototipe yang lebih fungsional sesuai kebutuhan.[5]

  1. ^ 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. 
  2. ^ a b Sutcliffe, Alistair (1998-03). "Scenario-based requirements analysis". Requirements Engineering. 3 (1): 48–65. doi:10.1007/bf02802920. ISSN 0947-3602. 
  3. ^ Sutcliffe, Alistair (2002). "User-Centred Requirements Engineering". doi:10.1007/978-1-4471-0217-5. 
  4. ^ 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. 
  5. ^ a b c d e f g h i j k A.G. Sutcliffe, "Scenario-based Requirement Engineering", Manchester, 2003
  6. ^ 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. 
  7. ^ A. G. Sutcliffe, N. A. Maiden, S. Minocha and D. Manuel, "Supporting Scenario-Based Requirements Engineering," IEEE Transactions on Software Engineering, pp. 1072-1088, 1998.
  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. Sutcliffe, Scenario-Based Requirement Analysis, London: Centre for HCI Design School of Informatics City University Northampton Square.
  10. ^ Stapleton, Jennifer. (1999). Dynamic systems development method : version 3. Tesseract Pub. on behalf of the DSDM Consortium. ISBN 2002442770. OCLC 51087823. 
  11. ^ Gough, P.A.; Fodemski, F.T.; Higgins, S.A.; Ray, S.J. "Scenarios-an industrial case study and hypermedia enhancements". Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95). IEEE Comput. Soc. Press. doi:10.1109/isre.1995.512541. ISBN 0818670177. 
  12. ^ a b Carroll, John M., author. Making Use : Scenario-based Design of Human-computer Interactions. MIT Press. ISBN 9780262269926. OCLC 904719220. 
  13. ^ Conklin, Jeff; Begeman, Michael L. (1988-10-01). "gIBIS: a hypertext tool for exploratory policy discussion". ACM Transactions on Information Systems. 6 (4): 303–331. doi:10.1145/58566.59297. ISSN 1046-8188. 
  14. ^ Heymans, Patrick; Dubois, Eric (1998-03-01). "Scenario-Based Techniques for Supporting the Elaboration and the Validation of Formal Requirements". Requirements Engineering. 3 (3-4): 202–218. doi:10.1007/s007660050005. ISSN 0947-3602. 
  15. ^ a b Carroll, John M. 1950- (John Millar) (1995). Scenario-based design : envisioning work and technology in system development. Wiley. ISBN 0471076597. OCLC 989040972. 
  16. ^ A.G. Monk and P. Wright, Improving Your Human- Computer Interface: A Practical Technique: Prentice Hall, 1993.
  17. ^ A.G. Sutcliffe, “Bridging the Communications Gap: Developing a Lingua Franca for Software Developers and Users,” INFORSID, 2000, 13-32, Toulouse: Inforsid.
  18. ^ M. Kyng, “Creating Contexts for Design,” in Scenario Based Design, J.M. Carroll, Ed. New York: Wiley, 1995
  19. ^ Ben-Menachem, Mordechai (2001-01-01). "Writing effective use cases". ACM SIGSOFT Software Engineering Notes. 26 (1): 94. doi:10.1145/505894.505918. ISSN 0163-5948. 
  20. ^ Jacobson, I. (1998). Object-oriented software engineering a use case driven approach. ACM Press: Addison Wesley. ISBN 0201544350. OCLC 693444408. 
  21. ^ Rational Corporation, UML: Unified Modelling Language Method, [http://www.rational.com], 1999.
Diperoleh dari "https://id.wikipedia.org/w/index.php?title=Scenario_Based_Requirement_Analysis_Method&oldid=22476539"