Kerangka kerja NFR

Kerangka kerja NFR (bahasa inggris: NFR Framework) merupakan salah satu metode goal-oriented requirements engineering yang diusulkan dalam ^[1] dan dikembangkan lebih lanjut dalam.^[2] 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.^[2] 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 ("-")^[3].

Kerangka kerja NFR juga mendukung katalogisasi pengetahuan desain ke dalam tiga jenis katalog:^[3]

• Katalog NFR type mencakup konsep tentang jenis NFR tertentu, seperti kinerja (performance).^[3]
• 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.^[3]
• Katalog correlation rule memiliki pengetahuan yang membantu dalam mendeteksi interdependensi implisit di antara softgoals.^[3]

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:^[2]

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.^[2]

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.^[2]

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^[2].

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.^[2]

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.^[2]

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.^[2]

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.^[2]

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^[2].

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.^[2]

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