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. 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. 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. 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. 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. Terdapat beberapa metode dalam pendekatan GORE, di antaranya NFR Network, i*/Tropos, KAOS, dan GBRAM.

## Definisi ''Goal''
*Goal* merupakan tujuan yang harus dicapai oleh sistem yang sedang dipertimbangkan. Lamsweerde  mendefinisikan *goal* sebagai tujuan yang harus dicapai oleh sistem melalui kerja sama agen pada perangkat lunak yang akan dibuat dan di lingkungannya. 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. 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. *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.

Aspek penting pada rekayasa kebutuhan adalah analisis kebutuhan non-fungsional (NFR). NFR biasanya direpresentasikan dalam model rekayasa kebutuhan sebagai *softgoal*. *Softgoal* terkait dengan gagasan tentang kepuasan. 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.

Identifikasi *goal* bukanlah tugas yang mudah. 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. *Goal* juga dapat diidentifikasi secara sistematis dengan cara mencari kata kunci yang dimaksud pada dokumen awal yang disediakan, transkrip wawancara, dan lain-lain. Umumnya, dikemukakan bahwa model *goal* dibangun selama proses awal. 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.

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

### Atribut ''goal''
*Goal* dapat ditandai secara intrinsik menggunakan atribut seperti nama dan spesifikasinya. Prioritas merupakan atribut penting lainnya yang dapat dilekatkan pada *goal*. Atribut *goal* lain yang telah diajukan termasuk utilitas *goal* dan kelayakan *goal.*

### 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 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. Terdapat banyak sekali usaha untuk menghubungkan *goal* dan skenario. Model *goal* juga dapat dikaitkan dengan model objek karena formulasi *goal* merujuk pada objek tertentu, misalnya, entitas, hubungan, atau agen. Beberapa usulan dibuat untuk menghubungkan *goal* ke agen. Adapun beberapa peneliti juga menganjurkan untuk menghubungkan *goal* dan kebijakan organisasi.

## Peran ''goal'' dalam Rekayasa Kebutuhan
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.
* 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*.
* Menjelaskan kebutuhan kepada pemangku kepentingan merupakan isu penting lainnya. *Goal* memberikan dasar bagi kebutuhan, yang mirip dengan *goal* desain dalam proses desain. Kebutuhan muncul karena beberapa *goal* mendasar yang menyediakan dasar untuk kebutuhan tersebut. 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.
* Penyempurnaan *goal* menyediakan mekanisme alami untuk menyusun dokumen kebutuhan yang kompleks untuk meningkatkan keterbacaan.
* *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
* Mengelola konflik di antara berbagai sudut pandang adalah perhatian rekayasa kebutuhan lainnya. *Goal* telah diakui dapat menyediakan akar untuk mendeteksi konflik di antara kebutuhan dan untuk menyelesaikannya.
* 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.
* *Goal* mendorong identifikasi kebuthan untuk mendukungnya; *goal* telah terbukti berada di antara kekuatan pendorong dasar, bersama dengan skenario, untuk proses penjabaran kebutuhan yang sistematis.

## Referensi

## Lihat juga
* Kerangka kerja NFR