Lihat sumber Goal-oriented requirements engineering

'''''Goal-oriented Requirement Engineering'' (GORE)''' adalah salah satu pendekatan [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan]] yang berfokus pada penggunaan ''goal'' dalam proses [[:en:Requirements elicitation|elisitasi]], [[:en:Elaboration|elaborasi]], penataan, penentuan, [[Analisis kebutuhan|analisis]], negosiasi, [[:en:Software documentation|dokumentasi]] dan modifikasi kebutuhan.<ref>A. van Lamsweerde. [http://dx.doi.org/10.1109/isre.2001.948567 Goal-oriented requirements engineering: a guided tour]. ''Proceedings Fifth IEEE International Symposium on Requirements Engineering''. IEEE Comput. Soc. doi:10.1109/isre.2001.948567. ISBN 0769511252.</ref> GORE berfokus pada aktivitas yang mendahului perumusan [[:en:Requirement|kebutuhan]] [[sistem]] [[perangkat lunak]]. Aktivitas-aktivitas berikut biasanya terdapat pada pendekatan GORE, seperti ''goal elicitation'', ''goal refinement'', dan bermacam tipe analisis ''goal'', serta penugasan tanggung jawab ''goal'' kepada agen.<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref> GORE melihat sistem yang akan dibuat dan lingkungannya sebagai sebuah koleksi dari komponen aktif yang disebut sebagai agen. [[Komponen aktif]] dapat membatasi perilakunya (''behaviour'') untuk memastikan batasan yang diberikan pada mereka. Komponen tersebut berupa [[manusia]] yang memerankan peran tertentu, [[:en:Device|alat,]] dan [[perangkat lunak]]. Berlawanan dengan komponen pasif, komponen aktif memiliki pilihan perilaku.<ref>Martin S. Feather. [http://dx.doi.org/10.1145/22719.22947 Language support for the specification and development of composite systems]. ''ACM Transactions on Programming Languages and Systems''. 1987-03-20. Vol. 9 (2). hlm. 198–234. doi:10.1145/22719.22947.</ref><ref>K. Yue, “What Does It Mean to Say that a Specification is Complete?”, ''Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design'', Monterey, 1987.</ref><ref>S. Fickas. [http://dx.doi.org/10.1109/32.142870 Knowledge representation and reasoning in the design of composite systems]. ''IEEE Transactions on Software Engineering''. 1992-06. Vol. 18 (6). hlm. 470–482. doi:10.1109/32.142870.</ref> Dalam GORE, agen diberikan tanggung jawab untuk mencapai ''goal''. ''Goal'' yang berada di bawah tanggung jawab satu agen pada [[perangkat lunak]] yang akan dibuat menjadi [[:en:Requirement|kebutuhan]], sedangkan ''goal'' di bawah tanggung jawab satu agen di lingkungan perangkat lunak yang akan dibuat akan menjadi asumsi.<ref>A. van Lamsweerde. [http://dx.doi.org/10.1109/32.730542 Managing conflicts in goal-driven requirements engineering]. ''IEEE Transactions on Software Engineering''. 1998. Vol. 24 (11). hlm. 908–926. doi:10.1109/32.730542.</ref><ref>A. van Lamsweerde. [http://dx.doi.org/10.1109/32.738341 Inferring declarative requirements specifications from operational scenarios]. ''IEEE Transactions on Software Engineering''. 1998. Vol. 24 (12). hlm. 1089–1114. doi:10.1109/32.738341.</ref> Pertimbangan berbasis agen ini sangat penting dalam [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan]] karena pemberian tanggung jawab untuk ''goal'' dan batasan antar agen pada [[perangkat lunak]] yang akan dibuat dan di lingkungannya merupakan hasil utama dalam proses [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan]].<ref>Axel van Lamsweerde. [http://dx.doi.org/10.1145/337180.337184 Requirements engineering in the year 00]. ''Proceedings of the 22nd international conference on Software engineering - ICSE '00''. ACM Press. 2000. doi:10.1145/337180.337184. ISBN 1581132069.</ref> Terdapat beberapa metode dalam pendekatan GORE, di antaranya NFR Network, [[:en:I*|i*]]/Tropos, [[:en:KAOS (software development)|KAOS]], dan [[Goal-based Requirement Analysis Method (GBRAM)|GBRAM]].<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref>

== Definisi ''Goal'' ==
''Goal'' merupakan tujuan yang harus dicapai oleh [[sistem]] yang sedang dipertimbangkan. [https://en.m.wikipedia.org/wiki/Axel_van_Lamsweerde Lamsweerde]  mendefinisikan ''goal'' sebagai tujuan yang harus dicapai oleh [[sistem]] melalui kerja sama agen pada [[perangkat lunak]] yang akan dibuat dan di lingkungannya.<ref>Axel van Lamsweerde. [http://dx.doi.org/10.1145/337180.337184 Requirements engineering in the year 00]. ''Proceedings of the 22nd international conference on Software engineering - ICSE '00''. ACM Press. 2000. doi:10.1145/337180.337184. ISBN 1581132069.</ref> Anton menyatakan bahwa ''goal'' merupakan tujuan tingkat tinggi dari sebuah [[bisnis]], [[organisasi]] atau sistem yang menangkap alasan mengapa sebuah sistem dibutuhkan dan memandu keputusan dalam berbagai level dalam [[perusahaan]].<ref>A. Anton, W. McCracken, C. Potts, "Goal Decomposition and Scenario Analysis in Business Process Reengineering", Proc. 6th Conference On Advanced Information Systems Engineering (CAiSE’94), Utrecht, Holland, June 1994.</ref> Dengan demikian, perumusan ''goal'' merujuk pada properti yang ingin dipastikan; mereka adalah pernyataan optatif yang bertentangan dengan pernyataan indikatif, dan dibatasi oleh subjek yang berkepentingan.<ref>M. Jackson, "Software Requirements & Specifications - A Lexicon of Practice, Principles and Pejudices", ACM Press, Addison-Wesley, 1995.</ref><ref>Pamela Zave. [http://dx.doi.org/10.1145/237432.237434 Four dark corners of requirements engineering]. ''ACM Transactions on Software Engineering and Methodology''. 1997-01-01. Vol. 6 (1). hlm. 1–30. doi:10.1145/237432.237434.</ref> ''Goal'' dapat dirumuskan dalam beberapa level abstraksi, mulai dari tingkat tinggi, masalah strategis, hingga tingkat rendah, masalah teknis. ''Goal'' juga mencakup beberapa soal, di antaranya adalah masalah [[:en:Functional requirement|fungsional]] yang berhubungan dengan servis yang akan disediakan, dan masalah [[:en:Non-functional requirement|non-fungsional]] yang berhubungan dengan kualitas servis, keselamatan, keamanan, ketepatan, kinerja, dan seterusnya.<ref>A. van Lamsweerde. [http://dx.doi.org/10.1109/isre.2001.948567 Goal-oriented requirements engineering: a guided tour]. ''Proceedings Fifth IEEE International Symposium on Requirements Engineering''. IEEE Comput. Soc. doi:10.1109/isre.2001.948567. ISBN 0769511252.</ref>

Aspek penting pada [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan]] adalah analisis [[:en:Non-functional requirement|kebutuhan non-fungsional]] (NFR).<ref>Chung, Kyungwha Lawrence. [http://worldcat.org/oclc/219376868 Representing and using non-functional requirements: a process-oriented approach].</ref> NFR biasanya direpresentasikan dalam model [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan]] sebagai ''softgoal''. ''Softgoal'' terkait dengan gagasan tentang kepuasan.<ref>Mark Stefik. [http://dx.doi.org/10.1016/0004-3702(84)90029-8 The sciences of the artificial]. ''Artificial Intelligence''. 1984-01. Vol. 22 (1). hlm. 95–97. doi:10.1016/0004-3702(84)90029-8.</ref> Tidak seperti ''goal'' biasa, ''softgoal'' jarang dapat dikatakan telah dicapai atau dipenuhi sampai tingkat yang memadai. [[:en:Non-functional requirement|Kebutuhan non-fungsional]] tingkat tinggi sangat banyak dalam [[organisasi]] dan cukup sering kesuksesan sebuah [[sistem]] tergantung pada pemenuhan [[:en:Non-functional requirement|kebutuhan non-fungsional]]<nowiki/>nya.<ref>Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.</ref>

Identifikasi ''goal'' bukanlah tugas yang mudah.<ref>A. van Lamsweerde. [http://dx.doi.org/10.1109/isre.1995.512561 Goal-directed elaboration of requirements for a meeting scheduler: problems and lessons learnt]. ''Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)''. IEEE Comput. Soc. Press. doi:10.1109/isre.1995.512561. ISBN 0818670177.</ref> Kadang-kadang ''goal'' tersebut secara eksplisit dinyatakan oleh [[pemangku kepentingan]] (''stakeholder'') atau dalam materi awal yang tersedia untuk ''requirement engineer''. Paling sering, ''goal'' tersebut dinyatakan secara implisit sehingga elisitasi ''goal'' harus dilakukan.<ref>A. van Lamsweerde. [http://dx.doi.org/10.1109/isre.2001.948567 Goal-oriented requirements engineering: a guided tour]. ''Proceedings Fifth IEEE International Symposium on Requirements Engineering''. IEEE Comput. Soc. doi:10.1109/isre.2001.948567. ISBN 0769511252.</ref> ''Goal'' juga dapat diidentifikasi secara sistematis dengan cara mencari [[kata kunci]] yang dimaksud pada dokumen awal yang disediakan, transkrip [[wawancara]], dan lain-lain.<ref>Axel van Lamsweerde. [http://dx.doi.org/10.1145/337180.337184 Requirements engineering in the year 00]. ''Proceedings of the 22nd international conference on Software engineering - ICSE '00''. ACM Press. 2000. doi:10.1145/337180.337184. ISBN 1581132069.</ref> Umumnya, dikemukakan bahwa model ''goal'' dibangun selama proses awal.<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>E. Dubois, E. Yu and M. Petit, "From Early to Late Formal Requirements: A Process-Control Case Study”, ''Proc. IWSSD’98 - 9th International Workshop on Software Specification and Design'', Isobe, IEEE CS Press, April 1998, 34-42.</ref><ref>E.S.K. Yu. [http://dx.doi.org/10.1109/isre.1997.566873 Towards modelling and reasoning support for early-phase requirements engineering]. ''Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/isre.1997.566873. ISBN 0818677406.</ref> Dasar dari pendapat tersebut adalah peran penting ''goal'' dalam proses tersebut; semakin cepat ''goal'' diidentifikasi, semakin baik. Namun, ''goal'' juga terkadang dapat diidentifikasi belakangan dalam proses [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan]].<ref>A. van Lamsweerde. [http://dx.doi.org/10.1109/isre.2001.948567 Goal-oriented requirements engineering: a guided tour]. ''Proceedings Fifth IEEE International Symposium on Requirements Engineering''. IEEE Comput. Soc. doi:10.1109/isre.2001.948567. ISBN 0769511252.</ref>

=== Tipe dan taksonomi ''goal'' ===
''Goal'' fungsional mencakup layanan atau servis dari sistem yang akan diluncurkan, sedangkan ''goal'' non-funsgional merujuk pada kualitas sistem seperti keamanan, keselamatan, kinerja, kemudahan penggunaan, fleksibilitas, interoperabilitas, dan seterusnya.<ref>E. Keller, L.G. Kahn and R.B. Panara, "Specifying Software Quality Requirements with Metrics", in Tutorial: System and Software Requirements Enginering, R.H. Thayer and M. Dorfman, Eds., IEEE Computer Society Press, 1990, 145-163.</ref> Adapun tipe yang diungkapkan dalam literatur lain, yaitu ''softgoal'' yang pemenuhannya tidak didapatkan dengan jelas <ref>Chung, Kyungwha Lawrence. [http://worldcat.org/oclc/219376868 Representing and using non-functional requirements: a process-oriented approach].</ref> dan ''hardgoal'' yang pemenuhannya didapat dari teknik [[verifikasi]].<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>Robert Darimont. [http://dx.doi.org/10.1145/250707.239131 Formal refinement patterns for goal-driven requirements elaboration]. ''ACM SIGSOFT Software Engineering Notes''. 1996-11-01. Vol. 21 (6). hlm. 179–190. doi:10.1145/250707.239131.</ref> Klasifikasi lainnya berdasarkan keadaan sistem yang diinginkan (positif, negatif, alternatif, masukan, atau pengecualian-perbaikan) dan level ''goal'' (level kebijakan, level fungsional, level domain).<ref>A. Sutcliffe and N. Maiden, “Bridging the Requirements Gap: Policies, Goals and Domains”, ''Proc. IWSSD-7 - 7th Intl. Workshop on Software Specification and Design'', IEEE, 1993.</ref> Anton juga membuat klasifikasi ''goal'' antara ''objective goal'', yang merujuk pada objek sistem, dan ''adverbial goal'' yang merujuk pada cara mencapai ''objective'' ''goal'' tersebut.<ref>A. Anton, W. McCracken, C. Potts, "Goal Decomposition and Scenario Analysis in Business Process Reengineering", Proc. 6th Conference On Advanced Information Systems Engineering (CAiSE’94), Utrecht, Holland, June 1994.</ref>

=== Atribut ''goal'' ===
''Goal'' dapat ditandai secara intrinsik menggunakan atribut seperti nama dan spesifikasinya.<ref>A. van Lamsweerde. [http://dx.doi.org/10.1109/isre.2001.948567 Goal-oriented requirements engineering: a guided tour]. ''Proceedings Fifth IEEE International Symposium on Requirements Engineering''. IEEE Comput. Soc. doi:10.1109/isre.2001.948567. ISBN 0769511252.</ref> Prioritas merupakan atribut penting lainnya yang dapat dilekatkan pada ''goal''.<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> Atribut ''goal'' lain yang telah diajukan termasuk utilitas ''goal'' dan kelayakan ''goal<ref>W. N. Robinson. [http://dx.doi.org/10.1145/75200.75232 Integrating multiple specifications using domain goals]. ''ACM SIGSOFT Software Engineering Notes''. 1989-05-01. Vol. 14 (3). hlm. 219–226. doi:10.1145/75200.75232.</ref>.''

=== Tautan ''goal (Goal links)'' ===
Terdapat banyak tipe tautan yang dinyatakan dalam literatur untuk menghubungkan antara ''goal'' dengan ''goal'' dan dengan elemen lain dalam model kebutuhan. Tautan tersebut membentuk dasar untuk mendefinisikan struktur ''goal''. Tautan antar ''goal'' bertujuan untuk menangkap situasi di mana ''goal'' dapat mendukung ''goal'' lainnya secara positif atau negatif. Diambil dari [[:en:And–or tree|metode reduksi masalah]] dalam [[Kecerdasan buatan|Kecerdasan Buatan]], grafik AND dan OR dapat digunakan untuk menangkap tautan penyempurnaan ''goal''. Tautan AND menghubungkan sebuah ''goal'' ke seperangkat ''subgoal''; hal ini berarti untuk mencapai sebuah ''goal'' harus memenuhi semua ''subgoal''. Tautan OR menghubungkan sebuah ''goal'' ke beberapa alternatif perbaikan; hal ini berarti memenuhi salah satu perbaikan saja sudah cukup untuk mencapai sebuah ''goal.''

Di samping tautan antar ''goal,'' secara umum ''goal'' berhubungan juga dengan elemen lain dalam model kebutuhan. Tipe tautan antar ''goal'' diperpanjang untuk menangkap kontribusi positif/negatif dari sebuah kebutuhan ke ''goal''; terdapat juga tautan [[argumentasi]] untuk menghubungkan argumen pendukung ke tautan kontribusi.<ref>Chung, Kyungwha Lawrence. [http://worldcat.org/oclc/219376868 Representing and using non-functional requirements: a process-oriented approach].</ref> Terdapat banyak sekali usaha untuk menghubungkan ''goal'' dan skenario.<ref>S. Fickas. [http://dx.doi.org/10.1109/32.142870 Knowledge representation and reasoning in the design of composite systems]. ''IEEE Transactions on Software Engineering''. 1992-06. Vol. 18 (6). hlm. 470–482. doi:10.1109/32.142870.</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> Model ''goal'' juga dapat dikaitkan dengan model objek karena formulasi ''goal'' merujuk pada objek tertentu, misalnya, entitas, hubungan, atau agen.<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> Beberapa usulan dibuat untuk menghubungkan ''goal'' ke agen.<ref>A. van Lamsweerde. [http://dx.doi.org/10.1109/isre.2001.948567 Goal-oriented requirements engineering: a guided tour]. ''Proceedings Fifth IEEE International Symposium on Requirements Engineering''. IEEE Comput. Soc. doi:10.1109/isre.2001.948567. ISBN 0769511252.</ref> Adapun beberapa peneliti juga menganjurkan untuk menghubungkan ''goal'' dan kebijakan organisasi.<ref>A. Sutcliffe and N. Maiden, “Bridging the Requirements Gap: Policies, Goals and Domains”, ''Proc. IWSSD-7 - 7th Intl. Workshop on Software Specification and Design'', IEEE, 1993.</ref><ref>M. Feather, "Requirements Reconnoitering at the Juncture of Domain and Instance", ''Proc. RE’93 - 1st Intl. IEEE Symp. on Require- ments Engineering'', Jan. 1993, 73-77.</ref>

== Peran ''goal'' dalam Rekayasa Kebutuhan ==
Terdapat banyak sekali alasan mengapa ''goal'' sangat penting dalam proses [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan]], di antaranya adalah:

* Mencapai kelengkapan kebutuhan merupakan fokus utama dalam proses [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan]], ''goal'' memberikan kriteria yang tepat untuk kelengkapan [[:en:Software requirements specification|spesifikasi kebutuhan]] yang cukup; spesifikasi kebutuhan tersebut dikatakan lengkap terkait dengan seperangkat ''goal'' yang apabila semua ''goal'' tersebut terbukti dapat dicapai dari spesifikasi dan properti domain yang diketahui juga ikut dipertimbangkan.<ref>K. Yue, “What Does It Mean to Say that a Specification is Complete?”, ''Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design'', Monterey, 1987.</ref>
* Menghindari kebutuhan yang tidak relevan merupakan fokus utama lainnya dari proses rekayasa kebutuhan. ''Goal'' memberikan kriteria yang tepat untuk ketepatan kebutuhan; sebuah kebutuhan dikatakan tepat terkait dengan seperangkat ''goal'' dalam domain yang dipertimbangkan yang apabila spesifikasinya digunakan sebagai bukti paling tidak dari salah satu ''goal''.<ref>K. Yue, “What Does It Mean to Say that a Specification is Complete?”, ''Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design'', Monterey, 1987.</ref>
* Menjelaskan kebutuhan kepada [[pemangku kepentingan]] merupakan isu penting lainnya. ''Goal'' memberikan dasar bagi kebutuhan, yang mirip dengan ''goal'' desain dalam proses desain.<ref>E.S.K. Yu. [http://dx.doi.org/10.1109/isre.1997.566873 Towards modelling and reasoning support for early-phase requirements engineering]. ''Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering''. IEEE Comput. Soc. Press. doi:10.1109/isre.1997.566873. ISBN 0818677406.</ref><ref>J. Lee. [http://dx.doi.org/10.1109/icse.1991.130629 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.</ref> Kebutuhan muncul karena beberapa ''goal'' mendasar yang menyediakan dasar untuk kebutuhan tersebut.<ref>S. Fickas. [http://dx.doi.org/10.1109/32.142870 Knowledge representation and reasoning in the design of composite systems]. ''IEEE Transactions on Software Engineering''. 1992-06. Vol. 18 (6). hlm. 470–482. doi:10.1109/32.142870.</ref><ref>D.T. Ross and K.E. Schoman, "Structured Analysis for Requirements Definition", ''IEEE Transactions on Software Engineering'', Vol. 3, No. 1, 1977, 6-15.</ref><ref>I. Sommerville and P. Sawyer, "''Requirements Engineering: A Good Practice Guide",'' Wiley, 1997.</ref> Secara lebih eksplisit, pohon penyempurnaan ''goal'' (''goal refinement tree'') menyediakan tautan penelusuran dari sasaran strategis tingkat tinggi hingga kebutuhan teknis tingkat rendah. Khususnya untuk sistem aplikasi bisnis, ''goal'' dapat digunakan untuk menghubungkan [[Perangkat lunak|peranti lunak]] dengan konteks organisasi dan bisnis.<ref>E.S.K. Yu, "Modelling Organizations for Information Systems Requirements Engineering", ''Proc. RE'93 - 1st Intl Symp. on Requirements Engineering'', IEEE, 1993, 34-41.</ref>
* Penyempurnaan ''goal'' menyediakan mekanisme alami untuk menyusun [[:en:Software documentation|dokumen kebutuhan]] yang kompleks untuk meningkatkan keterbacaan.<ref>A. van Lamsweerde. [http://dx.doi.org/10.1109/isre.2001.948567 Goal-oriented requirements engineering: a guided tour]. ''Proceedings Fifth IEEE International Symposium on Requirements Engineering''. IEEE Comput. Soc. doi:10.1109/isre.2001.948567. ISBN 0769511252.</ref>
* ''Requirement engineer'' dihadapkan dengan banyak alternatif untuk dipertimbangkan selama proses elaborasi kebutuhan. Penyempurnaan ''goal'' alternatif memberikan tingkat abstraksi yang tepat di mana para pengambil keputusan dapat terlibat untuk memvalidasi pilihan yang dibuat atau menyarankan alternatif lain yang belum diperhatikan sejauh ini. Penyempurnaan ''goal'' alternatif memungkinkan proposal sistem alternatif untuk dieksplorasi<ref>Axel van Lamsweerde. [http://dx.doi.org/10.1145/337180.337184 Requirements engineering in the year 00]. ''Proceedings of the 22nd international conference on Software engineering - ICSE '00''. ACM Press. 2000. doi:10.1145/337180.337184. ISBN 1581132069.</ref>
* Mengelola konflik di antara berbagai sudut pandang adalah perhatian rekayasa kebutuhan lainnya.<ref>B. Nuseibeh, J. Kramer and A. Finkelstein, "A Framework for Expressing the Relationships Between Multiple Views in Requirements Specifications", ''IEEE Transactions on Software Engineering'', Vol. 20 No. 10, October 1994, 760-773.</ref> ''Goal'' telah diakui dapat menyediakan akar untuk mendeteksi konflik di antara kebutuhan dan untuk menyelesaikannya.<ref>A. van Lamsweerde. [http://dx.doi.org/10.1109/32.730542 Managing conflicts in goal-driven requirements engineering]. ''IEEE Transactions on Software Engineering''. 1998. Vol. 24 (11). hlm. 908–926. doi:10.1109/32.730542.</ref><ref>W. N. Robinson. [http://dx.doi.org/10.1145/75200.75232 Integrating multiple specifications using domain goals]. ''ACM SIGSOFT Software Engineering Notes''. 1989-05-01. Vol. 14 (3). hlm. 219–226. doi:10.1145/75200.75232.</ref>
* Memisahkan informasi tetap dari informasi yang berubah adalah masalah penting lainnya dalam mengelola evolusi kebutuhan. Suatu kebutuhan mewakili satu cara khusus untuk mencapai beberapa ''goal'' tertentu; Oleh karena itu kebutuhan lebih cenderung untuk berkembang, menuju cara lain untuk mencapai ''goal'' yang sama, daripada ''goal'' itu sendiri. Semakin tinggi level ''goal'', semakin stabil ''goal'' tersebut. Ternyata, versi sistem yang berbeda sering berbagi sekumpulan ''goal'' tingkat tinggi yang sama; sistem saat ini dan sistem yang akan dibuat terkait dengan penyempurnaan alternatif dari ''goal'' bersama dalam grafik penyempurnaan ''goal'', dan karenanya dapat diintegrasikan ke dalam satu model tujuan tunggal.<ref>A. van Lamsweerde. [http://dx.doi.org/10.1109/isre.2001.948567 Goal-oriented requirements engineering: a guided tour]. ''Proceedings Fifth IEEE International Symposium on Requirements Engineering''. IEEE Comput. Soc. doi:10.1109/isre.2001.948567. ISBN 0769511252.</ref>
* ''Goal'' mendorong identifikasi kebuthan untuk mendukungnya; ''goal'' telah terbukti berada di antara kekuatan pendorong dasar, bersama dengan skenario, untuk proses penjabaran kebutuhan yang sistematis.<ref>S. Fickas. [http://dx.doi.org/10.1109/32.142870 Knowledge representation and reasoning in the design of composite systems]. ''IEEE Transactions on Software Engineering''. 1992-06. Vol. 18 (6). hlm. 470–482. doi:10.1109/32.142870.</ref><ref>Axel van Lamsweerde. [http://dx.doi.org/10.1145/337180.337184 Requirements engineering in the year 00]. ''Proceedings of the 22nd international conference on Software engineering - ICSE '00''. ACM Press. 2000. doi:10.1145/337180.337184. ISBN 1581132069.</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>E. Dubois, E. Yu and M. Petit, "From Early to Late Formal Requirements: A Process-Control Case Study”, ''Proc. IWSSD’98 - 9th International Workshop on Software Specification and Design'', Isobe, IEEE CS Press, April 1998, 34-42.</ref><ref>Rubin, Kenneth H. [http://worldcat.org/oclc/926690727 Object behavior analysis]. Association for Computing Machinery. 1992.</ref><ref>A.I. Anton. [http://dx.doi.org/10.1109/icse.1998.671112 The use of goals to surface requirements for evolving systems]. ''Proceedings of the 20th International Conference on Software Engineering''. IEEE Comput. Soc. doi:10.1109/icse.1998.671112. ISBN 0818683686.</ref><ref>H. Kaindl, “A Design Process Based on a Model Combining Scenarios with Goals and Functions”, ''IEEE Trans. on Systems, Man and Cybernetic,'' Vol. 30 No. 5, September 2000, 537-551.</ref>

== Lihat juga ==
* [[Kerangka kerja NFR]]

== Referensi ==
<references />

== Sumber dan atribusi ==

Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Goal-oriented+requirements+engineering&oldid=27586078 Wikipedia bahasa Indonesia], revisi 27586078 (2025-07-23T04:33:02Z), 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 -->