**Kerangka kerja NFR** (bahasa inggris: NFR Framework) merupakan salah satu metode *goal-oriented requirements engineering* yang diusulkan dalam  dan dikembangkan lebih lanjut dalam. Kerangka kerja NFR berkonsentrasi pada pemodelan dan analisis kebutuhan non-fungsional *(Non-functional requirement)*. Tujuan dari kerangka kerja ini adalah untuk menempatkan kebutuhan non-fungsional dalam pikiran pengembang. Gagasan utama dari pendekatan ini adalah untuk memodelkan secara sistematis dan memperbaiki kebutuhan non-fungsional dan untuk memaparkan pengaruh positif dan negatif dari berbagai alternatif pada kebutuhan ini. Kerangka kerja ini mendukung tiga jenis *softgoals*. NFR *Softgoals* merupakan kebutuhan non-fungsional yang harus dipertimbangkan; *operasionalization softgoals* memodelkan teknik tingkat rendah untuk memuaskan NFR *softgoals*; *claim softgoals* memungkinkan analis untuk merekam *design rationale* untuk penyempurnaan *softgoal*, prioritas *softgoal*, kontribusi *softgoal,* dll. *Softgoals* dapat disempurnakan menggunakan AND atau OR dengan semantik yang jelas. Selain itu, interdependensi *(interdependencies)* *softgoal* dapat ditangkap dengan kontribusi positif ("+") atau negatif ("-").

Kerangka kerja NFR juga mendukung katalogisasi pengetahuan desain ke dalam tiga jenis katalog:

* Katalog **NFR *type*** mencakup konsep tentang jenis NFR tertentu, seperti kinerja *(performance)*.
* Katalog ***method*** menyandikan pengetahuan yang membantu dalam penyempurnaan dan operasionalisasi *softgoal.* Katalog ini dapat memiliki metode generik yang menyatakan bahwa NFR *softgoal* yang diterapkan pada data item dapat didekomposisi menjadi NFR *softgoals* untuk semua komponen item tersebut.
* Katalog ***correlation rule*** memiliki pengetahuan yang membantu dalam mendeteksi interdependensi implisit di antara *softgoals*.

Metode NFR
----------

Tahapan dalam kerangka kerja NFR Ini belum tentu berurutan, dan orang mungkin juga perlu mengulanginya berkali-kali selama proses desain. Pengembang dapat memilih penyempurnaan, dengan mempertimbangkan operasionalisasi; dengan demikian proses pengembangan dapat bergerak naik dan turun, bukannya menjadi *top-down*. Akan sangat membantu, jika pada setiap langkah dalam proses, pengembang dapat memanfaatkan pengetahuan yang tersedia, yang relevan dengan langkah itu dalam proses. Inilah yang ingin disediakan oleh Kerangka NFR. Kerangka kerja ini menawarkan struktur untuk mewakili dan merekam proses desain dan penalaran dalam grafik, yang disebut *softgoal interdependency graphs* (SICs). Kerangka ini juga menawarkan katalog pengetahuan tentang NFR dan pengetahuan desain, termasuk teknik pengembangan. Dengan memberikan SIG dan menggambar pada katalog, informasi kontekstual pada setiap langkah dapat digunakan untuk memicu dan menghasilkan pengetahuan yang tersimpan sebelumnya untuk membantu pengembang melakukan langkah itu.Ada beberapa langkah utama dalam proses desain NFR:

### Memperoleh atau mengakses pengetahuan (*Acquiring or accessing knowledge)*

Pengembang akan menggambar pada katalog pengetahuan tentang NFR dan teknik pengembangan terkait. Untuk memberikan terminologi dan klasifikasi konsep NFR, katalog NFR *type* digunakan. NFR *type* diatur dalam bentuk hierarki. NFR yang lebih umum ditunjukkan di atas yang lebih spesifik. Sebagai contoh, *performance* memiliki sub-tipe *time* dan *space*, yang juga memiliki sub-tipe mereka sendiri. NFR *type* menyediakan terminologi untuk mengungkapkan kebutuhan. Misalnya, *security of the account*, atau *response time for sales authorization*. Teknik pengembangan standar, bersama dengan metode penguraian *(decomposition)* NFR, juga diatur dalam katalog *method*. interdependensi antar NFR juga disusun dalam katalog *correlation*. Biasanya, pengembang sistem dapat mengakses katalog yang ada dari awal pengembangan. Katalog dapat diperbarui selama pengembangan, untuk menangani konsep atau teknik pengembangan tambahan yang selanjutnya perlu ditangani.

### Mengidentifikasi NFR *(Identifying particular NFRs for the domain)*

Dalam menggunakan Kerangka NFR, seseorang membuat grafik interdependensi *softgoal* awal dengan mengidentifikasi kebutuhan non-fungsional utama yang harus dipenuhi oleh sistem tertentu yang sedang dikembangkan. Kebutuhan non-fungsional (NFR) kemudian diperlakukan sebagai *softgoal* yang harus dicapai. Jenis *softgoal* khusus ini disebut NFR *softgoal*. Pengembang akan mengidentifikasi kemungkinan teknik pengembangan spesifik. Di antara mereka, pengembang akan memilih solusi dalam sistem target yang memenuhi spesifikasi kebutuhan sumber. Dengan demikian pengembang mulai dengan secara sistematis mendekomposisi NFR *softgoals* awal menjadi *sub-softgoals* (atau *subgoals*) yang lebih spesifik. *Softgoals* memiliki tipe NFR, yang menunjukkan NFR tertentu, seperti *security* atau *performance*, yang ditangani oleh *softgoal*. *Softgoals* juga memiliki subjek atau topik.

### Dekomposisi NFR *(Decomposing NFR)*

Dalam menguraikan NFR *softgoal*, pengembang dapat memilih untuk menguraikan tipe NFR atau topiknya. Misalnya, kedua *softgoal* berbagi topik yang sama, yaitu *account,* tetapi mengatasi NFR yang berbeda, yaitu *performance* dan *security*. Untuk secara efektif menangani kebutuhan yang umum, NFR *softgoal* mungkin perlu dipecah menjadi komponen yang lebih kecil, sehingga solusi yang efektif dapat ditemukan. Selain itu, kebutuhannya mungkin ambigu. Dengan memperlakukan kebutuhan tingkat tinggi ini sebagai *softgoal* yang ingin dicapai, kita dapat menguraikannya menjadi *sub-goal* yang lebih spesifik yang bersama-sama memenuhi *softgoal* tingkat yang lebih tinggi. Misalnya, NFR *softgoal* ‘*Secure accounts*’ dapat didekomposisi menjadi *sub-softgoal* untuk *integrity*, *confidentiality*, dan *availability* dari akun. *Softgoals* berkontribusi, secara positif atau negatif, untuk memenuhi *softgoals* lainnya. Ada berbagai jenis kontribusi. Ketika semua dari beberapa *sub-softgoals* diperlukan bersama untuk memenuhi *softgoal* yang lebih tinggi, itu adalah tipe kontribusi AND. Biasanya, *softgoals* ditampilkan dan disempurnakan ke bawah menjadi *subsoftgoals* *(subgoals)*, dan *subgoals* berkontribusi ke atas ke *softgoals* induk. Selain tipe NFR, *softgoals* juga dapat diuraikan berdasarkan topiknya. Misalnya*, softgoal* *'performance'* untuk *credit card accounts* dapat didekomposisi menjadi *softgoal* '*performance'* untuk *gold accounts* dan untuk *regular accounts**.*

### Mengidentifikasi "operasionalisasi" *(Identifying "operationalizations")*

Pada titik tertentu, ketika kebutuhan non-fungsional telah cukup disempurnakan, dapat diidentifikasi teknik pengembangan yang mungkin untuk mencapai NFR ini *(NFR softgoals)* dan kemudian memilih solusi spesifik untuk sistem target. Namun, penting untuk dicatat bahwa ada "celah" antara NFR *softgoals* dan teknik pengembangan. Untuk sampai ke tujuan, sesuatu harus menjembatani kesenjangan tersebut. Hal ini melibatkan analisis, dan berurusan dengan sejumlah faktor, termasuk ambiguitas, prioritas, *tradeoffs*, dan informasi domain lainnya seperti beban kerja organisasi. Faktor-faktor ini harus diatasi pada berbagai langkah dalam proses. Misalnya, tantangan untuk menyediakan *response time* yang baik untuk *account*. Salah satu alternatif yang mungkin adalah menggunakan pengindeksan *(indexing)*. Dalam hal ini, penggunaan indeks adalah teknik pengembangan yang dapat diterapkan. Teknik ini adalah kandidat untuk memenuhi NFR *response time*. Tapi itu bukan lagi kebutuhan non-fungsional. Kontras dengan *response time*, yang masih merupakan atribut kualitas perangkat lunak. Teknik pengembangan mengoperasionalkan NFR *softgoals.* Pengindeksan mengoperasionalkan *response time* dan NFR *response time* dioperasionalkan dengan pengindeksan. Selain itu, penggunaan format yang tidak terkompresi membuat kontribusi positif untuk memenuhi kebutuhan *response time*. Perhatikan bahwa pada tahap ini belum memilih operasionalisasi mana yang akan digunakan dalam sistem target.

Transisi dari NFR *softgoals* ke *operasionalization softgoals* adalah langkah penting dalam proses ini, karena NFR perlu dikonversi menjadi sesuatu yang dapat diimplementasikan. Namun, ada kejadian di mana mungkin tidak dapat mengubah kebutuhan awal menjadi operasionalisasi konkret dalam satu langkah. Seringkali, perlu ada penyempurnaan dan elaborasi lebih lanjut. Terdapat berbagai cara pula untuk menyempurnakan atau menguraikan *operationalizations softgoal* umum ini.

### Mencari prioritas (*dealing with priorities)*

Grafik interdependensi *softgoal* dapat tumbuh menjadi cukup besar dan kompleks. Untuk fokus pada apa yang penting, salah satu caranya adalah mengidentifikasi prioritas. Perhatian ekstra kemudian dapat dilakukan untuk memenuhi prioritas *softgoals*. Prioritas dapat muncul dari pertimbangan beberapa faktor. Hal ini termasuk informasi domain seperti prioritas organisasi dan beban kerja organisasi. Selain itu, kebutuhan dapat diidentifikasi sebagai prioritas selama berbagai fase pembangunan. Beberapa *softgoal* akan diidentifikasi sebagai kritis, karena sangat penting bagi keberhasilan sistem atau organisasi. *Softgoals* lain akan dianggap dominan, karena mereka berurusan dengan sebagian besar beban kerja organisasi. *Softgoal* prioritas diidentifikasi dengan tanda seru (!). Keturunan prioritas berkontribusi positif ke induk, dan ini ditunjukkan oleh "+". Kontribusi positif ini adalah contoh dari tipe kontribusi, yang menunjukkan dampak dari *softgoals* keturunan pada *softgoal* induknya. Sekarang prioritas diidentifikasi, dapat dianalisis dan ditangani. Sebagai contoh, prioritas dapat digunakan untuk membuat *tradeoff* yang sesuai di antara *softgoals*. Pada setiap langkah dalam proses, ketika kita membuat pilihan untuk mencapai kebutuhan non-fungsional tertentu, sangat mungkin bahwa beberapa kebutuhan non-fungsional lainnya dapat terpengaruh, baik secara positif maupun negatif, pada saat yang sama. Interaksi ini sangat penting karena mereka berdampak pada proses pengambilan keputusan untuk mencapai NFR lain.

### Memilih operasionalisasi *(Selecting operationalizations)*

Proses penyempurnaan berlanjut sampai pengembang mempertimbangkan bahwa solusi yang mungkin untuk sistem target dirinci dengan cukup, dan tidak ada alternatif lain yang perlu dipertimbangkan. Sepanjang jalan, pengembang telah mempertimbangkan NFR, informasi domain, dan membahas ambiguitas, prioritas, dan *tradeoffs.* Pengembang kemudian mempertimbangkan kemungkinan operasionalisasi, dasar pemikiran desain, dan interdependensi antar softgoals, menggunakan keahlian dari pengembang dan dari katalog. Semua informasi ini direkam dalam grafik, dan tersedia untuk membantu pengembang memilih di antara alternatif. Dalam memperluas grafik interdependensi softgoal, pengembang dapat menjelaskan kemungkinan sub-bagian dan alternatif yang ingin dipertimbangkan sebagai sarana untuk mencapai *softgoals* tingkat tinggi awal. Grafik dengan demikian mewakili ruang desain di mana keputusan desain harus dibuat. Saat *softgoals* sedang disempurnakan, pengembang akhirnya akan mencapai beberapa *softgoals* yang cukup detail. Pengembang dapat menerima atau menolaknya, sebagai bagian dari sistem target. Sekarang saatnya untuk memilih dari antara kemungkinan operasionalisasi, untuk menghasilkan sistem target. Selain itu, *design rationale* yang tepat harus dipilih.

### Membuat *design rationale*

Premis penting dari kerangka ini adalah bahwa keputusan desain harus didukung oleh argumen yang masuk akal atau disebut juga sebagai *design rationale*. Alasan dapat dinyatakan untuk melakukan penyempurnaan, untuk memilih alternatif untuk sistem target, dll. Sebagai contoh, alasan untuk memprioritaskan *accurate account*, tulis klaim *"Accuracy is vital"* yang disebut sebagai *claim softgoals**.*

### Mengevaluasi dampak keputusan *(Evaluating the impact of decisions)*

Evaluasi *softgoals* dan interdependensi menentukan dampak keputusan. Ini menunjukkan apakah *softgoals* tingkat tinggi terpenuhi. Untuk menentukan dampak keputusan, keputusan saat ini dan sebelumnya dipertimbangkan. Pertimbangan dan keputusan sebelumnya telah tercermin dalam grafik, sebagai tujuan dan interdependensi. Untuk mencerminkan sifat pemikiran desain, evaluasi dan penyebaran keputusan desain berfokus pada pertanyaan apakah alternatif yang dipilih "cukup baik,". Gaya penalaran ini sesuai untuk berurusan dengan kebutuhan non-fungsional karena memenuhi kebutuhan ini sering kali masalah derajat, bukan keputusan benar-salah. Proses evaluasi dapat dipandang sebagai *bottom-up*, dimulai dengan keputusan, yang sering kali merupakan daun pada grafik, dan sering di bagian bawahnya. Kemudian prosedur evaluasi (atau pelabelan algoritma) bekerja menuju bagian atas grafik, menentukan dampak pada *softgoals* utama tingkat lebih tinggi. *Softgoals top* ini mencerminkan kebutuhan non-fungsional keseluruhan seperti yang dinyatakan oleh pengembang dan orang-orang di organisasi di mana sistem sedang dikembangkan.

1. ↑  Chung, Kyungwha Lawrence. *Representing and using non-functional requirements: a process-oriented approach*. OCLC 219376868.
2. 1 2 3 4 5 6 7 8 9 10 11 12  L. Chung, B. Nixon, E. Yu, J. Mylopoulos. Non-Functional Requirements in Software Engineering. Kluwer. 2000.
3. 1 2 3 4 5  Alexei Lapouchnian. Goal-oriented Requirements Engineering: An Overview of the Current Research. Department of Computer Science University of Toronto, 2005.