Goal-oriented requirements engineering: Perbedaan antara revisi
Konten dihapus Konten ditambahkan
k Bot: Perubahan kosmetika |
Rachmat-bot (bicara | kontrib) k cosmetic changes |
||
Baris 1:
{{judul miring}}
'''''Goal-oriented Requirement Engineering'' (GORE)''' adalah salah satu pendekatan [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan]] yang berfokus pada penggunaan ''goal'' dalam proses [[:en:
== 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.
Aspek penting pada [[Teknik kebutuhan perangkat lunak|rekayasa kebutuhan]] adalah analisis [[:en:Non-
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" />.
=== 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.
=== Atribut ''goal'' ===
Baris 16:
=== 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:
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 name=":7" />. Terdapat banyak sekali usaha untuk menghubungkan ''goal'' dan skenario<ref name=":
== 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:
* 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 name=":2" />.
* 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}}</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.
* Penyempurnaan ''goal'' menyediakan mekanisme alami untuk menyusun [[:en:
* ''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 name=":5" />
* 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.
* 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 name=":0" />.
* ''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=":
[[Kategori:Teknologi informasi]]
| |||