Goal-oriented requirements engineering: Perbedaan antara revisi

'''''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 name=":0">{{Cite journal|last=van Lamsweerde|first=A.|title=Goal-oriented requirements engineering: a guided tour|url=http://dx.doi.org/10.1109/isre.2001.948567|journal=Proceedings Fifth IEEE International Symposium on Requirements Engineering|publisher=IEEE Comput. Soc|doi=10.1109/isre.2001.948567|isbn=0769511252|access-date=2019-07-12|archive-date=2023-08-06|archive-url=https://web.archive.org/web/20230806223651/https://ieeexplore.ieee.org/document/948567/|dead-url=no}}</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 name=":1">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>{{Cite journal|last=Feather|first=Martin S.|date=1987-03-20|title=Language support for the specification and development of composite systems|url=http://dx.doi.org/10.1145/22719.22947|journal=ACM Transactions on Programming Languages and Systems|volume=9|issue=2|pages=198–234|doi=10.1145/22719.22947|issn=0164-0925}}</ref><ref name=":2">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 name=":3">{{Cite journal|last=Fickas|first=S.|last2=Helm|first2=B.R.|date=1992-06|title=Knowledge representation and reasoning in the design of composite systems|url=http://dx.doi.org/10.1109/32.142870|journal=IEEE Transactions on Software Engineering|volume=18|issue=6|pages=470–482|doi=10.1109/32.142870|issn=0098-5589|access-date=2019-07-12|archive-date=2023-08-06|archive-url=https://web.archive.org/web/20230806223701/https://ieeexplore.ieee.org/document/142870/|dead-url=no}}</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 name=":4">{{Cite journal|last=van Lamsweerde|first=A.|last2=Darimont|first2=R.|last3=Letier|first3=E.|date=1998|title=Managing conflicts in goal-driven requirements engineering|url=http://dx.doi.org/10.1109/32.730542|journal=IEEE Transactions on Software Engineering|volume=24|issue=11|pages=908–926|doi=10.1109/32.730542|issn=0098-5589|access-date=2019-07-12|archive-date=2023-08-06|archive-url=https://web.archive.org/web/20230806223651/https://ieeexplore.ieee.org/document/730542/|dead-url=no}}</ref><ref>{{Cite journal|last=van Lamsweerde|first=A.|last2=Willemet|first2=L.|date=1998|title=Inferring declarative requirements specifications from operational scenarios|url=http://dx.doi.org/10.1109/32.738341|journal=IEEE Transactions on Software Engineering|volume=24|issue=12|pages=1089–1114|doi=10.1109/32.738341|issn=0098-5589|access-date=2019-07-12|archive-date=2023-08-06|archive-url=https://web.archive.org/web/20230806223651/https://ieeexplore.ieee.org/document/738341/|dead-url=no}}</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 name=":5">{{Cite journal|last=van Lamsweerde|first=Axel|date=2000|title=Requirements engineering in the year 00|url=http://dx.doi.org/10.1145/337180.337184|journal=Proceedings of the 22nd international conference on Software engineering - ICSE '00|location=New York, New York, USA|publisher=ACM Press|doi=10.1145/337180.337184|isbn=1581132069|access-date=2019-07-12|archive-date=2003-06-12|archive-url=https://web.archive.org/web/20030612164454/http://dx.doi.org/10.1145/337180.337184|dead-url=no}}</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 name=":1" />

''Goal'' merupakan tujuan yang harus dicapai oleh [[sistem]] yang sedang dipertimbangkan. [https://en.m.wiki-indonesia.club/wiki/Axel_van_Lamsweerde Lamsweerde] {{Webarchive|url=https://web.archive.org/web/20230326205012/https://en.m.wiki-indonesia.club/wiki/Axel_van_Lamsweerde |date=2023-03-26 }} mendefinisikan ''goal'' sebagai tujuan yang harus dicapai oleh [[sistem]] melalui kerja sama agen pada [[perangkat lunak]] yang akan dibuat dan di lingkungannya.<ref name=":5" /> 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 name=":6">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 subyek yang berkepentingan.<ref>M. Jackson, "Software Requirements & Specifications - A Lexicon of Practice, Principles and Pejudices", ACM Press, Addison-Wesley, 1995.</ref><ref>{{Cite journal|last=Zave|first=Pamela|last2=Jackson|first2=Michael|date=1997-01-01|title=Four dark corners of requirements engineering|url=http://dx.doi.org/10.1145/237432.237434|journal=ACM Transactions on Software Engineering and Methodology|volume=6|issue=1|pages=1–30|doi=10.1145/237432.237434|issn=1049-331X|access-date=2019-07-12|archive-date=2023-08-06|archive-url=https://web.archive.org/web/20230806223652/https://dl.acm.org/doi/10.1145/237432.237434|dead-url=no}}</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 name=":0" />

Aspek penting pada [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan]] adalah analisis [[:en:Non-functional requirement|kebutuhan non-fungsional]] (NFR).<ref name=":7">{{Cite book|title=Representing and using non-functional requirements: a process-oriented approach.|url=http://worldcat.org/oclc/219376868|oclc=219376868|last=Chung, Kyungwha Lawrence.|access-date=2019-07-12|archive-date=2023-08-06|archive-url=https://web.archive.org/web/20230806224202/https://worldcat.org/title/219376868|dead-url=no}}</ref> NFR biasanya direpresentasikan dalam model [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan]] sebagai ''softgoal''. ''Softgoal'' terkait dengan gagasan tentang kepuasan.<ref>{{Cite journal|last=Stefik|first=Mark|date=1984-01|title=The sciences of the artificial|url=http://dx.doi.org/10.1016/0004-3702(84)90029-8|journal=Artificial Intelligence|volume=22|issue=1|pages=95–97|doi=10.1016/0004-3702(84)90029-8|issn=0004-3702|access-date=2019-07-12|archive-date=2023-08-06|archive-url=https://web.archive.org/web/20230806224156/https://www.sciencedirect.com/science/article/abs/pii/0004370284900298?via%3Dihub|dead-url=no}}</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 name=":1" />

Identifikasi ''goal'' bukanlah tugas yang mudah.<ref>{{Cite journal|last=van Lamsweerde|first=A.|last2=Darimont|first2=R.|last3=Massonet|first3=P.|title=Goal-directed elaboration of requirements for a meeting scheduler: problems and lessons learnt|url=http://dx.doi.org/10.1109/isre.1995.512561|journal=Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)|publisher=IEEE Comput. Soc. Press|doi=10.1109/isre.1995.512561|isbn=0818670177|access-date=2019-07-12|archive-date=2023-08-06|archive-url=https://web.archive.org/web/20230806224155/https://ieeexplore.ieee.org/document/512561/|dead-url=no}}</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 name=":0" /> ''Goal'' juga dapat diidentifikasi secara sistematis dengan cara mencari kata kunci yang dimaksud pada dokumen awal yang disediakan, transkrip [[wawancara]], dan lain-lain.<ref name=":5" /> Umumnya, dikemukakan bahwa model ''goal'' dibangun selama proses awal.<ref name=":8">{{Cite journal|last=Dardenne|first=A.|last2=Fickas|first2=S.|last3=van Lamsweerde|first3=A.|title=Goal-directed concept acquisition in requirements elicitation|url=http://dx.doi.org/10.1109/iwssd.1991.213081|journal=Proceedings of the Sixth International Workshop on Software Specification and Design|publisher=IEEE Comput. Soc. Press|doi=10.1109/iwssd.1991.213081|isbn=0818623209|access-date=2019-07-12|archive-date=2023-08-06|archive-url=https://web.archive.org/web/20230806223538/https://ieeexplore.ieee.org/document/213081/|dead-url=no}}</ref><ref name=":9">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 name=":10">{{Cite journal|last=Yu|first=E.S.K.|title=Towards modelling and reasoning support for early-phase requirements engineering|url=http://dx.doi.org/10.1109/isre.1997.566873|journal=Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering|publisher=IEEE Comput. Soc. Press|doi=10.1109/isre.1997.566873|isbn=0818677406|access-date=2019-07-12|archive-date=2023-08-06|archive-url=https://web.archive.org/web/20230806224154/https://ieeexplore.ieee.org/document/566873/|dead-url=no}}</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 name=":0" />

* Menjelaskan kebutuhan kepada [[pemangku kepentingan]] merupakan isu penting lainnya. ''Goal'' memberikan dasar bagi kebutuhan, yang mirip dengan ''goal'' desain dalam proses desain.<ref name=":10" /><ref>{{Cite journal|last=Lee|first=J.|title=Extending the Potts and Bruns model for recording design rationale|url=http://dx.doi.org/10.1109/icse.1991.130629|journal=[1991 Proceedings] 13th International Conference on Software Engineering|publisher=IEEE Comput. Soc. Press|doi=10.1109/icse.1991.130629|isbn=0818621400|access-date=2019-07-12|archive-date=2023-08-06|archive-url=https://web.archive.org/web/20230806224656/https://ieeexplore.ieee.org/document/130629/|dead-url=no}}</ref> Kebutuhan muncul karena beberapa ''goal'' mendasar yang menyediakan dasar untuk kebutuhan tersebut.<ref name=":3" /><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>

* ''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 name=":3" /><ref name=":5" /><ref name=":8" /><ref name=":9" /><ref>{{Cite book|title=Object behavior analysis.|url=http://worldcat.org/oclc/926690727|publisher=Association for Computing Machinery|date=1992|oclc=926690727|last=Rubin, Kenneth H.}}</ref><ref>{{Cite journal|last=Anton|first=A.I.|last2=Potts|first2=C.|title=The use of goals to surface requirements for evolving systems|url=http://dx.doi.org/10.1109/icse.1998.671112|journal=Proceedings of the 20th International Conference on Software Engineering|publisher=IEEE Comput. Soc|doi=10.1109/icse.1998.671112|isbn=0818683686|access-date=2019-07-12|archive-date=2023-08-06|archive-url=https://web.archive.org/web/20230806224719/https://ieeexplore.ieee.org/document/671112/|dead-url=no}}</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>