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,^[1][2] 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.^[3]

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.^[3]

Skema Semantic Memory

Semantic memory ScenIC mencerminkan informasi tentang sistem. Karena semantic memory berubah selama penyempurnaan, "sistem" dapat mencakup "lingkungan" dan "mesin".^[4] 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.^[3]

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.^[3]

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 prototipe,^[5] spesifikasi dan model yang dapat dieksekusi, maket dan storyboard,^[6][7] penelusuran data praktik kerja,^[8][9][10] dan skenario.^{[1][11][12][13][14][15]} 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.^{[16][17][18][19]}

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,^[20][21] dan working memory dapat ditangkap atau diarsipkan sebagai rationale.^{[19][22][23][24]} Pedoman metodologis disediakan dengan mengajukan masalah standar tentang informasi jangka panjang. Pedoman ScenIC dikodekan sebagai templat pengingat dengan konteks pemicu.^[3]

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.^[3]

Aktor eksternal ada di luar kendali 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 analisis means-end^[3].

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.^[3]

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.^[3]

• 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.^[3]
• 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.^[3]

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.^[3]

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.^[3]

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. Tetapi 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.^[3]

• 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.^[3]
• Cakupan hambatan tunggal. Setiap rintangan harus terjadi dalam setidaknya satu skenario.^[3]
• 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.^[3]

1. ^ ^{a b} 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.  Periksa nilai tanggal di: |date= (bantuan)
2. ^ 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. 
3. ^ ^{a b c d e f g h i j k l m n o p q r} 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. 
4. ^ Zave, Pamela; Jackson, Michael (1997-01-01). "Four dark corners of requirements engineering". ACM Transactions on Software Engineering and Methodology. 6 (1): 1–30. doi:10.1145/237432.237434. ISSN 1049-331X. 
5. ^ Vonk, R., Prototyping: The effective use of CASE technology. 1990, Prentice Hall.
6. ^ Muller, M., et al., Bifocal tools for scenarios and representations in participatory activities with users, in Scenario-Based Design: Envisioning Work and Technology in System Development, J.M. Carroll, (Ed.). 1995, Wiley.
7. ^ Ehn, P., The Art and Science of Designing Computer Artifacts, in Scand. J. Inf. Sys. 1989 21-42.
8. ^ Beyer, Hugh R.; Holtzblatt, Karen (1995-05-01). "Apprenticing with the customer". Communications of the ACM. 38 (5): 45–52. doi:10.1145/203356.203365. ISSN 0001-0782. 
9. ^ Brun-Cottan, Francoise; Wall, Patricia (1995-05-01). "Using video to re-present the user". Communications of the ACM. 38 (5): 61–71. doi:10.1145/203356.203368. ISSN 0001-0782. 
10. ^ Holtzblatt, Karen; Beyer, Hugh (1993-10-01). "Making customer-centered design work for teams". Communications of the ACM. 36 (10): 92–103. doi:10.1145/163430.164050. ISSN 0001-0782. 
11. ^ Anderson, J.S.; Durney, B. "Using scenarios in deficiency-driven requirements engineering". [1993] Proceedings of the IEEE International Symposium on Requirements Engineering. IEEE Comput. Soc. Press. doi:10.1109/isre.1993.324824. ISBN 0818631201. 
12. ^ Carroll, John M.; Rosson, Mary Beth (1992-04-01). "Getting around the task-artifact cycle: how to make claims and design by scenario". ACM Transactions on Information Systems. 10 (2): 181–212. doi:10.1145/146802.146834. ISSN 1046-8188. 
13. ^ Rubin, Kenneth H. (1992). Object behavior analysis. Association for Computing Machinery. OCLC 926690727. 
14. ^ Sutcliffe, Alistair (1998-03). "Scenario-based requirements analysis". Requirements Engineering. 3 (1): 48–65. doi:10.1007/bf02802920. ISSN 0947-3602.  Periksa nilai tanggal di: |date= (bantuan)
15. ^ Jacobson, I. (1998). Object-oriented software engineering a use case driven approach. ACM Press: Addison Wesley. ISBN 0201544350. OCLC 693444408. 
16. ^ Cline, Patsy, 1932-1963. (1988, 1982), Remembering, OCLC 19869279, diakses tanggal 2019-07-27  Periksa nilai tanggal di: |date= (bantuan)Pemeliharaan CS1: Banyak nama: authors list (link)
17. ^ Rumelhart, D., Notes on a Schema for Stories, in Representation and Understanding, D. Bobrow & A.Collins, (Eds.) 1975, Academic Press.
18. ^ Thorndyke, Perry W. (1977-01). "Cognitive structures in comprehension and memory of narrative discourse". Cognitive Psychology. 9 (1): 77–110. doi:10.1016/0010-0285(77)90005-6. ISSN 0010-0285.  Periksa nilai tanggal di: |date= (bantuan)
19. ^ ^{a b} Conklin, Jeff; Begeman, Michael L. (1989-05). <200::aid-asi11>3.0.co;2-u "gIBIS: A tool for all reasons". Journal of the American Society for Information Science. 40 (3): 200–213. doi:10.1002/(sici)1097-4571(198905)40:3<200::aid-asi11>3.0.co;2-u. ISSN 0002-8231.  Periksa nilai tanggal di: |date= (bantuan)
20. ^ Potts, C.; Bruns, G. "Recording the reasons for design decisions". Proceedings. [1989] 11th International Conference on Software Engineering. IEEE Comput. Soc. Press. doi:10.1109/icse.1988.93722. ISBN 0897912586. 
21. ^ Potts, C. "A Generic Model For Representing Design Methods". 11th International Conference on Software Engineering. IEEE. doi:10.1109/icse.1989.714422. ISBN 0818689412. 
22. ^ Kunz, W. & H. Rittel, Issues as Elements of Information Systems, 1970, Inst. Urban and Regional Development, Univ.Calif.: Berkeley, California.
23. ^ Lee, J. "Extending the Potts and Bruns model for recording design rationale". [1991 Proceedings] 13th International Conference on Software Engineering. IEEE Comput. Soc. Press. doi:10.1109/icse.1991.130629. ISBN 0818621400. 
24. ^ Burgess Yakemovic, K. C.; Conklin, E Jeffery (1990). "Report on a development project use of an issue-based information system". Proceedings of the 1990 ACM conference on Computer-supported cooperative work - CSCW '90. New York, New York, USA: ACM Press. doi:10.1145/99332.99347. ISBN 0897914023.