Lihat sumber Scenario Based Requirement Analysis Method

'''''Scenario Based Requirement Analysis Method''''' (disingkat '''SCRAM''') adalah salah satu metode [[:en:Requirements engineering|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 [[:en:Requirements elicitation|elisitasi]] dan [[:en:Verification and validation|validasi]] dengan cara menyediakan konteks bagi pengguna untuk menilai desain yang menggambarkan skenario penggunaan. SCRAM menggabungkan ''concept demonstrator'', skenario, dan ''[[:en:Design rationale|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. SCRAM terbukti bermanfaat untuk memfasilitasi ''[http://www.utm.mx/~caff/doc/OpenUPWeb/openup/guidances/concepts/elaboration_phase_BE880435.html requirement elaboration]'' begitu prototipe awal dibuat.

== Definisi Skenario ==
[[Oxford English Dictionary|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. 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 perangkat lunak|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.

=== 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. Pada kasus ini, skenario lebih dekat perannya dengan desain ''[[:en:Mockup|mockup]]''.
# Sebuah utas atau jalur yang digambarkan melalui model (biasanya ''[[:en:Use case|use case]]''). Istilah ini biasanya digunakan oleh komunitas berorientasi objek. Model tersebut mungkin direpresentasikan sebagai tampilan animasi dari urutan peristiwa dalam urutan pesan atau [[:en:State diagram|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 ''[[Papan cerita|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 [[Bahasa skrip|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 [[:en:Software requirements specification|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 ==



== Sumber dan atribusi ==

Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Scenario+Based+Requirement+Analysis+Method&oldid=28655428 Wikipedia bahasa Indonesia], revisi 28655428 (2025-12-03T02:49:34Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.