Scenario Based Requirement Analysis Method

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 dan SCRAM. 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.A.G. Sutcliffe, "Scenario-based Requirement Engineering", Manchester, 2003 SCRAM menggabungkan concept demonstrator, skenario, dan design rationale. 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.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. SCRAM terbukti bermanfaat untuk memfasilitasi requirement elaboration begitu prototipe awal dibuat.

 Definisi Skenario 
Kamus Bahasa Inggris Oxford mendefinisikan skenario sebagai "ikhtisar atau naskah film dengan detail adegan atau bayangan urutan kejadian pada masa yang akan datang". 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.A. Sutcliffe, Scenario-Based Requirement Analysis, London: Centre for HCI Design School of Informatics City University Northampton Square. 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.

 Skenario sebagai representasi desain 
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. Representasi informil lainnya, seperti design rationale 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 artefak 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. Dalam rute pengembangan alternatif melalui prototyping, skenario berfungsi sebagai inspirasi desain dan bahan untuk menguji desain prototipe. Skenario dapat digunakan sebagai bahan pertimbangan untuk sebuah desain dan juga sebagai naskah uji dalam metode evaluasi.A.G. Monk and P. Wright, Improving Your Human- Computer Interface: A Practical Technique: Prentice Hall, 1993.A.G. Sutcliffe, “Bridging the Communications Gap: Developing a Lingua Franca for Software Developers and Users,” INFORSID, 2000, 13-32, Toulouse: Inforsid.

 Peran skenario 
Skenario memiliki 3 peran berbeda, yaitu:

 Sebuah cerita atau contoh peristiwa sebagai narasi dasar yang diambil dari pengalaman dunia nyata. Cerita-cerita ini dekat dengan penggunaan akal sehat dan mungkin memuat perincian konteks sistem (adegan).
 Gambaran masa depan sebuah sistem dengan urutan perilaku dan deskripsi kontekstual yang memungkinkan.M. Kyng, “Creating Contexts for Design,” in Scenario Based Design, J.M. Carroll, Ed. New York: Wiley, 1995 Pada kasus ini, skenario lebih dekat perannya dengan desain mockup.
 Sebuah utas atau jalur yang digambarkan melalui model (biasanya use case). Istilah ini biasanya digunakan oleh komunitas berorientasi objek.Rational Corporation, UML: Unified Modelling Language Method, [http://www.rational.com], 1999. Model tersebut mungkin direpresentasikan sebagai tampilan animasi dari urutan peristiwa dalam urutan pesan atau diagram transisi keadaan.

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

 Initial Requirements Capture and Domain Familiarisation 
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.

 Storyboarding and Design Visioning 
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.

 Requirements Exploration 
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 memengaruhi pilihan. Tautan lebih lanjut dapat melengkapi jalur dari skenario ke spesifikasi kebutuhan yang lebih formal.

 Prototyping and Requirements Validation 
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.

 Referensi 

Kategori:Teknologi informasi
Kategori:Teknologi media