Goal-oriented requirements engineering: Perbedaan antara revisi
Konten dihapus Konten ditambahkan
k Menambah Kategori:Teknologi informasi menggunakan HotCat |
|||
Baris 2:
== Definisi ''Goal'' ==
''Goal'' merupakan tujuan yang harus dicapai oleh [[sistem]] yang sedang dipertimbangkan. [https://en.m.wiki-indonesia.club/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 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}}</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.}}</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}}</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}}</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}}</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}}</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" />.
| |||