ScenIC

**ScenIC** adalah metode rekayasa kebutuhan perangkat lunak untuk sistem yang berkembang. Berasal dari model *Inquiry Cycle* pada penyempurnaan kebutuhan, metode ini menggunakan penyempurnaan *goal* dan analisis skenario sebagai strategi metodologis utamanya. ScenIC bersandar pada analogi memori manusia: *semantic memory* terdiri dari generalisasi tentang sifat-sifat sistem; *episodic memory* terdiri atas episode dan skenario tertentu; dan *working memory* terdiri dari pengingat tentang penyempurnaan yang tidak lengkap. Metode khusus dari pedoman pengingat dan resolusi diaktifkan oleh keadaan dari *episodic memory* atau *semantic memory*. ScenIC merupakan representatif dari *Inquiry Cycle*, yang merupakan aplikasi siklus dari langkah-langkah berikut: ekspresi ide semantik atau episodik, mengangkat dan menyelesaikan masalah (kritik), dan penyempurnaan memori jangka panjang. Ekspresi didukung dengan mengadopsi skema *semantic memory* dan *episodic memory*, kemudian kritik oleh pedoman pengungkapan masalah yang dapat mengarahkan perhatian, sedangkan penyempurnaan didukung oleh pedoman resolusi yang menyarankan penyempurnaan.

## Skema Memori ScenIC
Masing-masing dari tiga memori ScenIC memiliki skema *entity-relationship*. Spesifikasi detail elemen skema dibiarkan tidak terdefinisi sehingga ScenIC dapat diterapkan pada berbagai tingkat formalitas.

**Skema ''Semantic Memory***

*Semantic memory* ScenIC mencerminkan informasi tentang sistem. Karena *semantic memory* berubah selama penyempurnaan, "sistem" dapat mencakup "lingkungan" dan "mesin". Entitas semantik dalam ScenIC meliputi aktor (*actor)*, tujuan *(goal)*, dan hambatan *(obstacle)*. Aktor adalah entitas yang berpartisipasi dalam perubahan keadaan . Aktor eksternal termasuk peran pengguna, organisasi, perangkat fisik, sistem eksternal, dan alam. Aktor internal adalah yang diduga sebagai komponen arsitektur, atau keseluruhan sistem yang dipandang sebagai kotak hitam *(black box).* Ada dua macam tujuan: objektif dan tugas. Objektif diekspresikan oleh lintasan perbaikan (mis. "Mengurangi keluhan pelanggan") atau pelestarian atau pencegahan keadaan (mis. "Lift tidak boleh bergerak saat pintunya terbuka").Tugas adalah tujuan yang dinyatakan dalam hal pencapaian suatu keadaan atau kinerja suatu tindakan (mis. "Begitu permintaan rapat dimasukkan ke dalam sistem, waktu dan tempat akan langsung dijadwalkan.) Objektif tidak dapat dicapai secara langsung oleh mesin, tetapi secara tidak langsung diwujudkan melalui kombinasi tugas. Misalnya, untuk mengurangi keluhan pelanggan, pengguna dan mesin melakukan tindakan terkoordinasi yang terperinci. Tugas, sebaliknya, dapat direalisasikan langsung oleh aktor, meskipun beberapa mungkin memerlukan ekspansi lebih lanjut. Spesifikasi sistem adalah sekumpulan spesifikasi tugas yang dialokasikan untuk aktor internal.

Tujuan dapat digagalkan oleh hambatan, kebanyakan melekat pada tujuan itu sendiri (mis. Ketidakpuasan terhadap batasan yang ada), tetapi adapula yang muncul karena mode kegagalan para aktor yang dialokasikan tugas. Hambatan termasuk perilaku non-normatif secara umum, bukan hanya kegagalan. Aktor non-mekanis dapat berperilaku dengan cara yang tidak diantisipasi yang melanggar asumsi yang diperlukan untuk pencapaian tujuan. Hambatan yang sering atau berat harus diselesaikan dengan tugas defensif atau mitigasi.

*'Skema *Episodic Memory***

Perwakilan pengguna dan pelanggan tidak selalu dapat menghasilkan dan membayangkan konsekuensi dari spesifikasi, sehingga sistem tertentu mungkin tampak lebih diinginkan daripada implementasinya. Argumen-argumen ini telah disuarakan untuk membenarkan [[Purwarupa|prototipe]], spesifikasi dan model yang dapat dieksekusi, [[maket]] dan ''[[Papan cerita|storyboard]]'', penelusuran data praktik kerja, dan skenario. ''Episodic memory'' ScenIC terdiri dari episode, urutan contoh tugas yang memiliki tujuan. ''Episodic memory'' ScenIC terdiri dari episode yang diarahkan pada tujuan dan yang menggambarkan hambatan yang digabung sebagai skenario pada berbagai tingkat detail. Skenario digunakan untuk mengeksplorasi kemungkinan seperti alokasi tugas alternatif untuk aktor, metode penyelesaian kendala alternatif, dan misi masa depan alternatif. Struktur narasi skenario adalah tata bahasa cerita yang disederhanakan.

**Skema *Working Memory**'

*Working memory* berorientasi pada tindakan. Isinya mengingatkan dan mengarahkan *Inquiry*. Proyek *Working memory* di ScenIC adalah catatan masalah yang tertunda atau keputusan perbaikan yang belum ditindaklanjuti. Skema *working memory* yang berfungsi dapat diperluas ke IBIS atau skema yang lebih kompleks, dan *working memory* dapat ditangkap atau diarsipkan sebagai *rationale*. Pedoman metodologis disediakan dengan mengajukan masalah standar tentang informasi jangka panjang. Pedoman ScenIC dikodekan sebagai templat pengingat dengan konteks pemicu.

== Strategi dan Panduan ScenIC ==
ScenIC membuat fase ekspresi *Inquiry Cycle* dengan menyediakan skema *episodic memory* dan *semantic memory* untuk informasi tentang sistem yang diusulkan. Kritik didukung oleh masalah standar yang dipicu oleh keadaan ingatan jangka panjang. Penyempurnaan didukung oleh pedoman resolusi. Kerangka kerja tersebut diuraikan dalam Tabel 1.

Aktor eksternal ada di luar kendali [[Perancang|desainer]]. Aktor eksternal dimasukkan jika melakukan tindakan signifikan dalam ruang lingkup sistem. *Goal* dapat diidentifikasi dengan merefleksikan tujuan sistem, mewawancarai [[pemangku kepentingan]], atau menyimpulkan tujuan dari [[dokumentasi]] latar belakang. *Goal* juga dapat diidentifikasi dari konten memori jangka panjang. Skenario, misalnya, dapat menerangi tujuan yang sebelumnya diabaikan atau kurang ditekankan. Hambatan mungkin akan menyarankan tugas tambahan. *Goal* kemudian diperluas dengan [[:en:Means-ends analysis|analisis *means-end*]]*.*

Terdapat pedoman umum untuk memperluas objektif dan tugas pemeliharaan, tetapi objektif peningkatan cenderung spesifik ke domain tertentu. Tugas sering kali harus dilakukan secara berurutan, karena tergantung pada kondisi awal. Pengaturan waktu ini tersirat dalam ketergantungan antar tugas. Tugas pada tingkatan yang lebih tinggi secara bertahap mengonsumsi [[informasi]] atau bergantung pada penyelesaian sebagian tugas dependen. Untuk alasan ini, yang terbaik adalah menunda analisis dependensi tugas sampai tugas dirinci dan dapat dialokasikan untuk aktor. Terkadang tugas tergantung pada ketersediaan informasi tanpa menjelaskan bagaimana informasi tersebut diperoleh. Tugas mana yang harus dilakukan oleh sistem dan yang harus dilakukan oleh aktor eksternal jarang ditentukan sebelumnya. Misalnya, suatu sistem dapat memutuskan waktu dan tempat terbaik untuk rapat secara otomatis. Atau, sistem bisa menyusun informasi dan menyajikannya kepada pengguna untuk meminta keputusan akhir. Kedua sistem tersebut mendukung tujuan penjadwalan pertemuan tetapi memiliki batasan yang berbeda. Alokasi tugas dibantu oleh analisis skenario. Alokasi alternatif dapat didiskusikan dalam skenario alternatif, dan masalah yang diangkat digunakan dalam mengevaluasinya. Kemungkinan alokasi ditentukan sebagian oleh arsitektur saat ini dan sebagian oleh praktik saat ini.

Hambatan dapat diidentifikasi dengan sejumlah proses yang berkisar dari praktik rekayasa yang paling informal hingga sistematis. Secara umum, hambatan diidentifikasi dengan pendekatan *top-down* atau *bottom-up*.

* Identifikasi *top-down* dari kombinasi hambatan yang menghalangi objektif. Hambatan tunggal jarang memiliki tanggung jawab atas tujuan yang tidak tercapai. Strategi *top-down* minimal adalah *generate-and-test*: bertanya secara sistematis apakah setiap keputusan alokasi merusak tujuan. Cara lain adalah membangun anti-skenario dari insiden kritikal.
* Identifikasi *bottom-up* dari hambatan yang menghalangi tugas. Beberapa kendala melekat dalam domain masalah. Misalnya, tempat terbaik untuk rapat tidak dapat dipilih jika tidak ada ruang yang tersedia. Di sisi lain, banyak muncul dari kegagalan aktor.

Ada tiga cara untuk mengatasi hambatan, antara lain abaikan saja, mempertahankannya, idealnya mencegahnya sama sekali, dan mengurangi dampaknya, idealnya pulih sama sekali. Dalam banyak kasus, pertahanan lebih efektif dan lebih murah daripada mitigasi, tetapi ketika konsekuensi hambatannya ringan dan biaya pertahanan tinggi, lebih masuk akal untuk mengandalkan mitigasi. Mitigasi hanya layak dipertimbangkan ketika pertahanan cenderung gagal dan risiko hambatan residual masih perlu dikhawatirkan.

== *Inquiry Cycle* dan Skenario ==
Inti dari mengeksplorasi skenario adalah untuk mengangkat dan menyelesaikan masalah tentang kebutuhan. Salah satu manfaat dari analisis skenario adalah wawasan yang tidak sengaja ditemukan yang dihasilkan dari skenario. Ketika masalah yang diangkat dari skenario diselesaikan, perubahan yang dihasilkan dapat terjadi di mana saja dalam *episodic memory* atau *semantic memory.'' Episode mengikuti struktur tugas. Skenario disusun dari episode sehingga kasus-kasus normal dan anti-skenario diuraikan.

Setelah mengidentifikasi hambatan, dimungkinkan untuk menyusun sejumlah skenario yang berisi episode normatif (kepuasan tujuan) dan eksepsi (kemunculan hambatan), yang sebagian besar adalah redundan atau tidak menarik. Karena itu, komposisi skenario merupakan bentuk pengambilan sampel, seperti pembuatan kasus uji. Namun, skenario berbeda dari kasus uji dalam dua hal penting. Pertama, skenario digunakan untuk menemukan dan menguraikan kebutuhan, sehingga setiap ukuran arti penting atau cakupan skenario adalah target yang bergerak. Kedua, kita dapat menilai kecukupan kasus uji terhadap paduk yang objektif, sedangkan paduk kebutuhan apa pun bersifat subjektif. Solusi ScenIC bersifat pragmatis, yang artinya kumpulan tujuan dan hambatan diambil sebagai dasar untuk menilai cakupan skenario.

* Cakupan kasus normal. Harus ada setidaknya satu skenario untuk setiap kasus normal. Biasanya ada kasus normal alternatif, beberapa di antaranya mencakup tujuan inisiasi atau pemeliharaan sistem.
* Cakupan hambatan tunggal. Setiap rintangan harus terjadi dalam setidaknya satu skenario.
* Cakupan objektif. Idealnya, setiap skenario harus dinilai terhadap setiap tujuan. Untuk efisiensi yang lebih besar, disarankan untuk membagi tujuan menjadi dua: tujuan yang mutlak harus dicapai, dan tujuan yang kuat tetapi bisa dilanggar. Tujuan dari tipe pertama harus diperiksa ketika mengelaborasi setiap skenario, sedangkan yang dari tipe kedua dapat disampel secara acak.

## Referensi