Wikipedia

Goal-oriented requirements engineering

Goal-oriented Requirement Engineering (GORE) adalah salah satu pendekatan rekayasa kebutuhan yang berfokus pada penggunaan goal dalam proses elisitasi, elaborasi, penataan, penentuan, analisis, negosiasi, dokumentasi dan modifikasi kebutuhan.[1] GORE berfokus pada aktivitas yang mendahului perumusan 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.[2] 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, alat, dan perangkat lunak. Berlawanan dengan komponen pasif, komponen aktif memiliki pilihan perilaku.[3][4][5] 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 kebutuhan, sedangkan goal di bawah tanggung jawab satu agen di lingkungan perangkat lunak yang akan dibuat akan menjadi asumsi.[6][7] Pertimbangan berbasis agen ini sangat penting dalam 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 rekayasa kebutuhan.[8] Terdapat beberapa metode dalam pendekatan GORE, di antaranya NFR Network, i*/Tropos, KAOS, dan GBRAM.[2]

Definisi Goal

sunting

Goal merupakan tujuan yang harus dicapai oleh sistem yang sedang dipertimbangkan. Lamsweerde Diarsipkan 2023-03-26 di Wayback Machine. mendefinisikan goal sebagai tujuan yang harus dicapai oleh sistem melalui kerja sama agen pada perangkat lunak yang akan dibuat dan di lingkungannya.[8] 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.[9] 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.[10][11] 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 fungsional yang berhubungan dengan servis yang akan disediakan, dan masalah non-fungsional yang berhubungan dengan kualitas servis, keselamatan, keamanan, ketepatan, kinerja, dan seterusnya.[1]

Aspek penting pada rekayasa kebutuhan adalah analisis kebutuhan non-fungsional (NFR).[12] NFR biasanya direpresentasikan dalam model rekayasa kebutuhan sebagai softgoal. Softgoal terkait dengan gagasan tentang kepuasan.[13] Tidak seperti goal biasa, softgoal jarang dapat dikatakan telah dicapai atau dipenuhi sampai tingkat yang memadai. Kebutuhan non-fungsional tingkat tinggi sangat banyak dalam organisasi dan cukup sering kesuksesan sebuah sistem tergantung pada pemenuhan kebutuhan non-fungsionalnya.[2]

Identifikasi goal bukanlah tugas yang mudah.[14] 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.[1] Goal juga dapat diidentifikasi secara sistematis dengan cara mencari kata kunci yang dimaksud pada dokumen awal yang disediakan, transkrip wawancara, dan lain-lain.[8] Umumnya, dikemukakan bahwa model goal dibangun selama proses awal.[15][16][17] 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 rekayasa kebutuhan.[1]

Tipe dan taksonomi goal

sunting

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.[18] Adapun tipe yang diungkapkan dalam literatur lain, yaitu softgoal yang pemenuhannya tidak didapatkan dengan jelas [12] dan hardgoal yang pemenuhannya didapat dari teknik verifikasi.[15][19] Klasifikasi lainnya berdasarkan keadaan sistem yang diinginkan (positif, negatif, alternatif, masukan, atau pengecualian-perbaikan) dan level goal (level kebijakan, level fungsional, level domain).[20] Anton juga membuat klasifikasi goal antara objective goal, yang merujuk pada objek sistem, dan adverbial goal yang merujuk pada cara mencapai objective goal tersebut.[9]

Atribut goal

sunting

Goal dapat ditandai secara intrinsik menggunakan atribut seperti nama dan spesifikasinya.[1] Prioritas merupakan atribut penting lainnya yang dapat dilekatkan pada goal.[15] Atribut goal lain yang telah diajukan termasuk utilitas goal dan kelayakan goal[21].

Tautan goal (Goal links)

sunting

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 metode reduksi masalah dalam 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.[12] Terdapat banyak sekali usaha untuk menghubungkan goal dan skenario.[5][15] Model goal juga dapat dikaitkan dengan model objek karena formulasi goal merujuk pada objek tertentu, misalnya, entitas, hubungan, atau agen.[15] Beberapa usulan dibuat untuk menghubungkan goal ke agen.[1] Adapun beberapa peneliti juga menganjurkan untuk menghubungkan goal dan kebijakan organisasi.[20][22]

Peran goal dalam Rekayasa Kebutuhan

sunting

Terdapat banyak sekali alasan mengapa goal sangat penting dalam proses rekayasa kebutuhan, di antaranya adalah:

  • Mencapai kelengkapan kebutuhan merupakan fokus utama dalam proses rekayasa kebutuhan, goal memberikan kriteria yang tepat untuk kelengkapan 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.[4]
  • 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.[4]
  • Menjelaskan kebutuhan kepada pemangku kepentingan merupakan isu penting lainnya. Goal memberikan dasar bagi kebutuhan, yang mirip dengan goal desain dalam proses desain.[17][23] Kebutuhan muncul karena beberapa goal mendasar yang menyediakan dasar untuk kebutuhan tersebut.[5][24][25] 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 peranti lunak dengan konteks organisasi dan bisnis.[26]
  • Penyempurnaan goal menyediakan mekanisme alami untuk menyusun dokumen kebutuhan yang kompleks untuk meningkatkan keterbacaan.[1]
  • 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[8]
  • Mengelola konflik di antara berbagai sudut pandang adalah perhatian rekayasa kebutuhan lainnya.[27] Goal telah diakui dapat menyediakan akar untuk mendeteksi konflik di antara kebutuhan dan untuk menyelesaikannya.[6][21]
  • 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.[1]
  • Goal mendorong identifikasi kebuthan untuk mendukungnya; goal telah terbukti berada di antara kekuatan pendorong dasar, bersama dengan skenario, untuk proses penjabaran kebutuhan yang sistematis.[5][8][15][16][28][29][30]

Referensi

sunting
  1. ^ a b c d e f g h van Lamsweerde, A. "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. Diarsipkan dari versi asli tanggal 2023-08-06. Diakses tanggal 2019-07-12. 
  2. ^ a b c Alexei Lapouchnian, “Goal-oriented Requirements Engineering: An Overview of the Current Research”, Department of Computer Science University of Toronto, 2005.
  3. ^ Feather, Martin S. (1987-03-20). "Language support for the specification and development of composite systems". ACM Transactions on Programming Languages and Systems. 9 (2): 198–234. doi:10.1145/22719.22947. ISSN 0164-0925. 
  4. ^ a b c 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.
  5. ^ a b c d Fickas, S.; Helm, B.R. (1992-06). "Knowledge representation and reasoning in the design of composite systems". IEEE Transactions on Software Engineering. 18 (6): 470–482. doi:10.1109/32.142870. ISSN 0098-5589. Diarsipkan dari versi asli tanggal 2023-08-06. Diakses tanggal 2019-07-12. 
  6. ^ a b van Lamsweerde, A.; Darimont, R.; Letier, E. (1998). "Managing conflicts in goal-driven requirements engineering". IEEE Transactions on Software Engineering. 24 (11): 908–926. doi:10.1109/32.730542. ISSN 0098-5589. Diarsipkan dari versi asli tanggal 2023-08-06. Diakses tanggal 2019-07-12. 
  7. ^ van Lamsweerde, A.; Willemet, L. (1998). "Inferring declarative requirements specifications from operational scenarios". IEEE Transactions on Software Engineering. 24 (12): 1089–1114. doi:10.1109/32.738341. ISSN 0098-5589. Diarsipkan dari versi asli tanggal 2023-08-06. Diakses tanggal 2019-07-12. 
  8. ^ a b c d e van Lamsweerde, Axel (2000). "Requirements engineering in the year 00". Proceedings of the 22nd international conference on Software engineering - ICSE '00. New York, New York, USA: ACM Press. doi:10.1145/337180.337184. ISBN 1581132069. Diarsipkan dari versi asli tanggal 2003-06-12. Diakses tanggal 2019-07-12. 
  9. ^ a b 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.
  10. ^ M. Jackson, "Software Requirements & Specifications - A Lexicon of Practice, Principles and Pejudices", ACM Press, Addison-Wesley, 1995.
  11. ^ Zave, Pamela; Jackson, Michael (1997-01-01). "Four dark corners of requirements engineering". ACM Transactions on Software Engineering and Methodology. 6 (1): 1–30. doi:10.1145/237432.237434. ISSN 1049-331X. Diarsipkan dari versi asli tanggal 2023-08-06. Diakses tanggal 2019-07-12. 
  12. ^ a b c Chung, Kyungwha Lawrence. Representing and using non-functional requirements: a process-oriented approach. OCLC 219376868. Diarsipkan dari versi asli tanggal 2023-08-06. Diakses tanggal 2019-07-12. 
  13. ^ Stefik, Mark (1984-01). "The sciences of the artificial". Artificial Intelligence. 22 (1): 95–97. doi:10.1016/0004-3702(84)90029-8. ISSN 0004-3702. Diarsipkan dari versi asli tanggal 2023-08-06. Diakses tanggal 2019-07-12. 
  14. ^ van Lamsweerde, A.; Darimont, R.; Massonet, P. "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. Diarsipkan dari versi asli tanggal 2023-08-06. Diakses tanggal 2019-07-12. 
  15. ^ a b c d e f Dardenne, A.; Fickas, S.; van Lamsweerde, A. "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. Diarsipkan dari versi asli tanggal 2023-08-06. Diakses tanggal 2019-07-12. 
  16. ^ a b 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.
  17. ^ a b Yu, E.S.K. "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. Diarsipkan dari versi asli tanggal 2023-08-06. Diakses tanggal 2019-07-12. 
  18. ^ 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.
  19. ^ Darimont, Robert; van Lamsweerde, Axel (1996-11-01). "Formal refinement patterns for goal-driven requirements elaboration". ACM SIGSOFT Software Engineering Notes. 21 (6): 179–190. doi:10.1145/250707.239131. ISSN 0163-5948. 
  20. ^ a b 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.
  21. ^ a b Robinson, W. N. (1989-05-01). "Integrating multiple specifications using domain goals". ACM SIGSOFT Software Engineering Notes. 14 (3): 219–226. doi:10.1145/75200.75232. ISSN 0163-5948. 
  22. ^ 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.
  23. ^ Lee, J. "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. Diarsipkan dari versi asli tanggal 2023-08-06. Diakses tanggal 2019-07-12. 
  24. ^ D.T. Ross and K.E. Schoman, "Structured Analysis for Requirements Definition", IEEE Transactions on Software Engineering, Vol. 3, No. 1, 1977, 6-15.
  25. ^ I. Sommerville and P. Sawyer, "Requirements Engineering: A Good Practice Guide", Wiley, 1997.
  26. ^ E.S.K. Yu, "Modelling Organizations for Information Systems Requirements Engineering", Proc. RE'93 - 1st Intl Symp. on Requirements Engineering, IEEE, 1993, 34-41.
  27. ^ 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.
  28. ^ Rubin, Kenneth H. (1992). Object behavior analysis. Association for Computing Machinery. OCLC 926690727. 
  29. ^ Anton, A.I.; Potts, C. "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. Diarsipkan dari versi asli tanggal 2023-08-06. Diakses tanggal 2019-07-12. 
  30. ^ 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.

Lihat juga

sunting
Diperoleh dari "https://wiki-indonesia.club/w/index.php?title=Goal-oriented_requirements_engineering&oldid=25579466"