Kerangka kerja NFR

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.