Lihat sumber Goal-based Requirement Analysis Method (GBRAM)

'''''Goal-based Requirement Analysis Method''''' '''(GBRAM)''' adalah salah satu metode dari pendekatan [[Goal-oriented Requirement Engineering (GORE)|''Goal-oriented Requirement Engineering'' (GORE)]]. Metode berbasis ''[[:en:Goal|goal]]'' ini menekankan perlunya mengkarakterisasi, mengkategorikan, menguraikan dan menyusun ''goal'' sebagai kebutuhan, tetapi biasanya gagal menawarkan strategi untuk mengidentifikasi ''goal'', dan menerima begitu saja bahwa ''goal'' telah didokumentasikan.<ref>Ant&, A.I., W.M. McCracken & C. Potts, “Goal Decomposition and Scenario Analysis in Business Process Reengineering,” ''Advanced Information System Engineering: 6th Int. Conf., CAiSE ‘94 Proc.,'' Utrecht, The Netherlands, 6-10 June 1994, pp. 94-104, 1994.</ref><ref>A. Dardenne. [http://dx.doi.org/10.1109/iwssd.1991.213081 Goal-directed concept acquisition in requirements elicitation]. ''Proceedings of the Sixth International Workshop on Software Specification and Design''. IEEE Comput. Soc. Press. doi:10.1109/iwssd.1991.213081. ISBN 0818623209.</ref><ref>Yu. [http://dx.doi.org/10.1109/hicss.1994.323491 Using goals, rules, and methods to support reasoning in business process reengineering]. ''Proceedings of the Twenty-Seventh Hawaii International Conference on System Sciences HICSS-94''. IEEE Comput. Soc. Press. 1994. doi:10.1109/hicss.1994.323491. ISBN 0818650907.</ref> Penekanan ''Goal-based Requirement Analysis Method'' (GBRAM) <ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref><ref>Antoń, Ana I., 1966-. [http://worldcat.org/oclc/37471644 Goal identification and refinement in the specification of software-based information systems].</ref> adalah pada identifikasi awal dan abstraksi ''goal'' dari berbagai sumber informasi. Metode Ini mengasumsikan bahwa tidak ada ''goal'' yang telah didokumentasikan atau diperoleh dari para [[pemangku kepentingan]] (''stakeholder)'' dan dengan demikian dapat menggunakan [[diagram]], pernyataan [[Teks (disambiguasi)|tekstual]], transkrip [[wawancara]], dll. untuk mendapatkan ''goal'' tersebut. Metode ini berguna untuk mengidentifikasi, menguraikan, dan mengatur ''goal'' untuk [[:en:Software requirements specification|spesifikasi kebutuhan]].<ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref> Pendekatan berbasis ''goal'' fokus pada mengapa sistem dibangun, memberikan motivasi dan alasan untuk membenarkan kebutuhan [[perangkat lunak]].<ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref> Serupa dengan pendekatan GORE lainnya, sistem dan lingkungannya di GBRAM direpresentasikan sebagai kumpulan agen. Di sini, agen didefinisikan sebagai entitas atau proses yang berusaha untuk mencapai ''goal'' dalam suatu organisasi atau sistem berdasarkan tanggung jawab yang diasumsikan untuk ''goal''. Dalam GBRAM, ''goal'', agen, pemangku kepentingan, dll. ditentukan dalam bentuk tekstual dalam ''goal schema''. Anehnya, metode ini tidak memberikan notasi grafis untuk mewakili ''goal'', penyempurnaan ''goal (goal refinement)'', agen, dll. GBRAM melibatkan kegiatan berikut: ''goal analysis'' dan ''goal refinement''.<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref>

== ''Goal Analysis'' ==
''Goal'' adalah sasaran tingkat tinggi dari sebuah [[bisnis]], [[organisasi]], atau [[sistem]]. ''Goal'' tersebut menangkap alasan mengapa suatu sistem diperlukan dan memandu keputusan di berbagai tingkatan dalam [[perusahaan]].<ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref> Proses ''goal analysis'' adalah tentang eksplorasi sumber [[informasi]] untuk identifikasi ''goal'' diikuti oleh organisasi dan klasifikasi ''goal'' itu sendiri.<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref> ''Goal analysis'' merupakan proses eksplorasi dokumen yang dikumpulkan, dimulai dari informasi tentang organisasi (misalnya tujuan perusahaan) ke informasi spesifik sistem (misalnya kebutuhan sistem). Sering diasumsikan bahwa sistem perangkat lunak dibangun dengan beberapa ''goal'' atau tujuan,<ref>A'''.''' M. Davis, "''Software Requirements: Objects, Functions,'' &’ ''Stutes",'' Prentice-Hall, 1993.</ref> tetapi terkadang ''goal'' atau tujuan tersebut tidak jelas, tujuan perusahaan tidak selalu mencerminkan apa yang sebenarnya terjadi.<ref>Ant&, A.I., W.M. McCracken & C. Potts, “Goal Decomposition and Scenario Analysis in Business Process Reengineering,” ''Advanced Information System Engineering: 6th Int. Conf., CAiSE ‘94 Proc.,'' Utrecht, The Netherlands, 6-10 June 1994, pp. 94-104, 1994.</ref> Dengan demikian, penting untuk mengumpulkan informasi sebanyak mungkin untuk mendapatkan pemahaman yang luas tentang domain, organisasi, proses dan sistem.<ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref>

Kegiatan ini selanjutnya dibagi menjadi:

* Eksplorasi (''Explore Activities''): mengeksplorasi informasi yang tersedia.<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref>
* Identifikasi (''Identify Activities''): penggalian ''goal'' dan agen yang bertanggung jawab dari informasi yang telah didapatkan pada kegiatan eksplorasi.<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref>
* Organisir (''Organize Activities''): mengklasifikasikan dan mengatur ''goal'' sesuai dengan hubungan ketergantungannya.<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref>

''Goal'' dapat diekstraksi dari berbagai jenis informasi yang dikumpulkan termasuk deskripsi proses seperti [[diagram alir]] atau [[Diagram hubungan entitas|diagram ''Entity Relationship'']] (ER). Penting untuk mengidentifikasi ''goal'' dari deskripsi proses dengan cara mencari pernyataan yang tampaknya memandu keputusan desain di berbagai tingkatan dalam suatu sistem atau organisasi. Ketika digunakan sebagai sumber informasi eksklusif, deskripsi proses tidak cukup untuk mencapai ketelitian dan kelengkapan. Oleh karena itu, jika memungkinkan, praktisi harus mempertimbangkan sumber-sumber lain yang mungkin seperti transkrip wawancara dengan para pemangku kepentingan. Namun, para pemangku kepentingan cenderung untuk mengungkapkan kebutuhan mereka dalam hal operasi dan tindakan daripada dalam bentuk ''goal''. Dengan demikian, mencari kata-kata tindakan adalah cara yang berguna untuk mengekstrak ''goal'' dari deskripsi pemangku kepentingan.<ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref> Contohnya, pada menu penjadwalan rapat, pemangku kepentingan mungkin akan menggunakan kata kerja semacam "menjadwalkan" dan "memesan" yang akan menjadi ''goal'' seperti "menjadwalkan rapat" dan "memesan ruang rapat".<ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref>

Selain ''goal'', ada pula agen, pemangku kepentingan, dan batasan (''constraint'') juga harus diidentifikasi. Pendekatan yang paling masuk akal adalah mengidentifikasi sedini mungkin agen yang bertanggung jawab dengan menentukan agen apa yang pada akhirnya bertanggung jawab untuk mencapai dan memelihara suatu ''goal''. Contohnya, ''goal'' "menjadwalkan rapat" merupakan tanggung jawab dari penjadwal rapat. Batasan berguna karena mereka memberikan informasi tambahan mengenai kebutuhan yang harus dipenuhi agar ''goal'' tertentu dapat diselesaikan. Batasan diidentifikasi dengan mencari penghubung temporal, seperti kata "selama", "sebelum", dan "sesudah", atau varian apa pun darinya. Batasan juga dapat diidentifikasi dengan mencari hubungan ketergantungan. Bayangkan goal "Rapat dijadwalkan" pada sistem penjadwalan rapat dengan batasan: Ruang rapat harus tersedia selama rapat berlangsung (tanggal/waktu). Setelah ''goal'', tanggung jawab agen dan pemangku kepentingan diidentifikasi dan ditentukan, goal tersebut kemudian diklasifikasikan sesuai dengan kondisi target mereka dan mulai dikembangkan.<ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref>

== ''Goal Refinement'' ==
Kebutuhan akan berubah-ubah dan terus berubah, banyaknya [[iterasi]] dalam proses penyempurnaan adalah hanya karena kebutuhan tersebut disalahtafsirkan.<ref>A'''.''' M. Davis, "''Software Requirements: Objects, Functions,'' &’ ''Stutes",'' Prentice-Hall, 1993.</ref> Setiap pemangku kepentingan memiliki kebutuhan dan prioritas yang berbeda, dan terkadang saling bertentangan. Sering kali, strategi untuk identifikasi dan penyelesaian konflik tidak memadai.<ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref> ''Goal'' berkembang karena para pemangku kepentingan mengubah pikiran mereka dan memperbaiki serta mengoperasionalkan ''goal'' tersebut menjadi kebutuhan perilaku (''[[:en:Behavior|behavioural]] requirement''). Seiring berjalannya waktu, ''goal'' dari pemangku kepentingan dapat berubah atau, setidaknya, prioritas sasaran mereka cenderung berubah. Perubahan ''goal'' pertama adalah elaborasi (''elaboration'') dan yang kedua adalah penyempurnaan (''refinement'').<ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref> Oleh karena itu, evolusi ''goal'' dipengaruhi melalui ''goal elaboration'' dan ''goal refinement''. Teknik penting dalam ''goal elaboration'' adalah mengidentifikasi hambatan ''goal'', menganalisis [[skenario]] <ref>Colin Potts. [http://dx.doi.org/10.1145/225434.225462 Using schematic scenarios to understand user needs]. ''Proceedings of the conference on Designing interactive systems processes, practices, methods, & techniques - DIS '95''. ACM Press. 1995. doi:10.1145/225434.225462. ISBN 0897916735.</ref> dan batasannya, dan mengoperasikan ''goal''. G''oal refinement'' menyangkut evolusi ''goal'' dari saat mereka pertama kali diidentifikasi hingga saat mereka diterjemahkan ke dalam kebutuhan operasional untuk spesifikasi sistem.<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref>

Kegiatan ini dibagi menjadi:

* Pemangkasan (''Pruning Activities''): Kegiatan pemangkasan seperangkat ''goal'', yaitu menghilangkan ''goal'' yang bermakna sama<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref>
* Penguraian (''Elaborate Activities''): Kegiatan yang merujuk pada proses menganalisis ''goal'' yang ditetapkan dengan mempertimbangkan kemungkinan adanya hambatan <ref>Antoń, Ana I., 1966-. [http://worldcat.org/oclc/37471644 Goal identification and refinement in the specification of software-based information systems].</ref> (perilaku atau ''goal'' lain yang mencegah atau menghalangi pencapaian ''goal'' yang diberikan).<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref> Mengidentifikasi hal yang dapat menghambat ''goal'' untuk mempertimbangkan cara yang mungkin membuat ''goal'' gagal tercapai, memungkinkan seseorang untuk mengantisipasi [[:en:Exception handling|kasus pengecualian (''exception'')]]. Ketika prioritas sasaran berubah, skenario akan memfasilitasi evaluasi prioritas baru ini.<ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref>
* Membangun skenario (deskripsi perilaku dari suatu sistem dan lingkungannya yang timbul dari situasi terbatas) untuk mengungkap ''goal'' dan kebutuhan yang tersembunyi<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref>
* Mengoperasionalkan (''Operationalize Activities''): Kegiatan yang mewakili penerjemahan ''goal'' menjadi kebutuhan operasional.<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref>

''Goal refinement'' terjadi ketika ''goal'' identik direkonsiliasi, ketika ''goal'' digabungkan ke dalam kategorisasi ''sub-goal'', ketika kendala diidentifikasi, dan ketika ''goal'' dioperasionalkan. Dalam GBRAM, ''achievement goal'' digabung dan didaftar sesuai dengan hubungan dan ketergantungan yang mendahuluinya. Susunan ini memungkinkan untuk menentukan kondisi prasyarat (''[[:en:Precondition|precondition]]'') dan kondisi pasca (''[[:en:Postcondition|post-condition]]'') dari sebuah ''goal''.<ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref> Dengan demikian, salah satu kegiatan yang dibutuhkan GBRAM selama fase ''goal refinement'' adalah identifikasi prioritas ''goal''. Hal ini pada dasarnya mewakili kebutuhan untuk mengidentifikasi ''goal'' mana yang harus dicapai sebelum yang lain. Metode ini menyarankan untuk mengajukan pertanyaan seperti “''Goal'' apa yang harus mengikuti ''goal'' ini?” dan seterusnya. Metode lain yang berguna untuk menentukan hubungan prioritas adalah untuk mencari dependensi agen. Begitu prioritas ''goal'' telah ditetapkan, tabel diproduksi dengan ''goal'' yang disusun sesuai dengan urutan prioritas itu.<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref>

Goal disempurnakan dengan menghilangkan [[:en:Redundancy|redudansi]] dan merekonsiliasi goal yang identik. Misalnya, "Rapat diatur" dan "Rapat dijadwalkan" memiliki maksud yang sama dan dapat direkonsiliasi. Pendekatan terbaik untuk menghilangkan redudansi adalah setelah ''goal'' digabung menjadi satu set ''goal'' yang diurutkan. Lebih mudah untuk mengidentifikasi ''goal'' yang identik karena mereka biasanya terdaftar berdekatan satu sama lain dalam set yang disusun karena mereka cenderung berbagi hubungan prioritas yang sama. ''Goal'' yang dioperasionalkan, agen yang bertanggung jawab, pemangku kepentingan, hambatan dan skenario akhirnya dikonsolidasikan ke dalam serangkaian ''goal schema'' yang dapat dengan mudah diterjemahkan ke dalam spesifikasi kebutuhan. [[:en:Artifact (software development)|Artefak]] yang dihasilkan, meskipun tidak formal, memberikan representasi tekstual dari kebutuhan sistem yang diatur sesuai dengan tujuan sistem.<ref>A.I. Anton. [http://dx.doi.org/10.1109/icre.1996.491438 Goal-based requirements analysis]. ''Proceedings of the Second International Conference on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/icre.1996.491438. ISBN 0818672528.</ref>

== Referensi ==
<references />

== Sumber dan atribusi ==

Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Goal-based+Requirement+Analysis+Method+%28GBRAM%29&oldid=28477000 Wikipedia bahasa Indonesia], revisi 28477000 (2025-11-14T05:29:42Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.

<!-- WIKI_UNISSULA_PRESENTATION_V4 -->