Materi UTS Software Requirement Engineering

Salah satu bagian tersulit dalam pembuatan sistem perangkat lunak adalah memutuskan dengan tepat apa yang akan dibuat - F. Brooks

Pengertian Requirement
- Sesuatu pada produk yang harus dilakukan atau sebuah kualitas yang harus dimiliki produk tersebut (Robertson99)
- Sebuah spesifikasi kebutuhan adalah bagaimana tujuan harus sesuai dengan sistem yang diusulkan (Anton96)

Requirement Engineering adalah Proses dimana persyaratan untuk produk perangkat lunak dikumpulkan, dianalisis, didokumentasikan, dan dikelola di seluruh iklus hidup rekayasa perangkat lunak.
Requirement Engineering berkaitan dengan menafsirkan dan memahami tujuan, kebutuhan, dan keyakinan dari pihak yang berkepentingan

Kenapa Requirement Engineering dibutuhkan?
- Requirements yang tidak lengkap adalah sumber utama dari kegagalan (Standish95)
- Banyaknya masalah yang dirasakan terkait dengan spesifikasi kebutuhan (>50%) – (ESI96)
- Kebutuhan yang tidak mencukupi, tidak konsisten, tidak lengkap atau ambigu mempunyai dampak yang kritis terhadap kualitas hasil perangkat lunak tersebut (Bell&Tayer76)
- Keterlambatan koreksi dari kesalahan meningkatkan biaya sampai 200 kali lebih banyak selama proses requirement engineering” (Boehm81)

Requirement Classifications
1. Kebutuhan fungsional
Menunjukkan fasilitas apa yang dibutuhkan serta aktivitas apa saja yang terjadi dalam sistem baru. Kebutuhan fungsional mencakup:
* Fungsi deskripsi kebutuhan
* Laporan baik hardcopy maupun softcopy
* Updating dan query online
* Penyimpanan data, pencarian kembali dan transfer data

2. Kebutuhan Non fungsional mencakup:
* Waktu respon
* Rata-rata waktu untuk kegagalan
* Kebutuhan keamanan
* Akses untuk pengguna yang tidak punya hak

1. Primary requirements – elicited from stakeholders
Requirements yang didapatkan langsung dari client/ pihak yang berkepentingan.
2. Derived requirements – derived from primary requirements
Diperoleh dari kebutuhan primer sebelumnya, biasanya bersifat turunan/ tambahan secara detail dari kebutuhan primer yang ada

Requirements Management

1. Requirements Elicitation, Specification and Modeling
Ini melibatkan memahami kebutuhan para pemangku kepentingan, memunculkan kebutuhan, pemodelan dan mengumpulkan mereka dalam repositori.
2. Prioritization
Kegiatan ini membantu manajer proyek dengan menyelesaikan konflik (di mana pelanggan dan pengembang berkolaborasi pada prioritas kebutuhan), rencana pengiriman bertahap, dan membuat keputusan yang diperlukan
3. Requirements Dependencies and Impact Analysis
Hal ini penting untuk mengakui bahwa perubahan kebutuhan dan ini secara signifikan dapat mempengaruhi proyek software
4. Requirements Negotiation
Rekayasa kebutuhan dasarnya adalah komunikasi dan proses negosiasi kompleks yang melibatkan pelanggan, desainer, manajer proyek dan pengelola.
5. Quality Assurance
Tujuannya adalah untuk memastikan bahwa kebutuhan kualitas tinggi dicatat dalam dokumen spesifikasi.
Tujuan dari jaminan kualitas adalah untuk menetapkan tingkat yang wajar dan realistis saat menyusun dan mengelola persyaratan.

Requirement Elicitation

Requirements Elicitation adalah proses mempelajari dan memahami kebutuhan pengguna dan sponsor proyek dengan tujuan utama berkomunikasi mengenai kebutuhan dengan para pengembang sistem
Bagian penting dari elisitasi didedikasikan untuk mengungkap, menggali, dan memunculkan keinginan dari para pemangku kepentingan potensial.

Proses elisitasi kebutuhan melibatkan serangkaian kegiatan yang harus memungkinkan untuk komunikasi, prioritas, negosiasi, dan kolaborasi dengan semua pemangku kepentingan terkait.

Proses Requirement Elicitation

 

1. Understanding the application domain
Hal ini penting ketika memulai proses elisitasi kebutuhan untuk menyelidiki dan memeriksa secara rinci situasi atau "dunia nyata" di mana sistem utama berada (kadang-kadang disebut domain aplikasi). | Lingkungan saat ini perlu benar-benar dieksplorasi, termasuk aspek-aspek politik, organisasi, dan sosial yang berkaitan dengan sistem, di samping setiap kendala yang ada pada sistem dan perkembangannya.

2. Identifying the sources of Requirements
- Kebutuhan dapat tersebar di berbagai sumber dan ada dalam berbagai format
- Dalam semua proyek pengembangan perangkat lunak sejumlah kemungkinan sumber dari kebutuhan dapat diidentifikasi
- Stakeholder merupakan sumber yang paling jelas dari persyaratan untuk sistem
- Sistem dan proses yang ada merupakan sumber lain untuk memunculkan kebutuhan, terutama ketika proyek melibatkan pergantian sistem saat ini atau warisan dari sistem sebelumnya.
3. Analyzing the Stakeholders
Salah satu langkah dalam elisitasi kebutuhan adalah untuk menganalisis dan melibatkan semua pemangku kepentingan yang relevan. Stakeholder adalah orang-orang yang memiliki kepentingan dalam sistem atau yang berpengaruh dalam beberapa pengembangan dan implementasi sistem.
4. Selecting the Techniques, Approaches, and Tool to Use
Pemilihan teknik yang akan digunakan tergantung pada konteks khusus dari proyek ini dan merupakan faktor penting dalam keberhasilan proses elisitasi. Hickey dan Davis telah menyelidiki pemilihan teknik elisitasi dan menyatakan bahwa teknik elisitasi tertentu dapat dipilih untuk berbagai alasan
A. Teknik yang dipilih adalah satu-satunya yang analis tahu
B. Teknik yang dipilih adalah favorit analis
C. Teknik yang dipilih adalah salah satu yang ditentukan oleh metodologi tertentu yang sedang diikuti untuk pengembangan sistem
D. Pilihan teknik diatur sendiri oleh intuisi analis sehingga efektif dalam konteks saat ini

5. Eliciting the Requirements from Stakeholders and Other Sources
Selama kegiatan ini penting untuk menetapkan tingkat lingkup sistem dan menyelidiki secara rinci kebutuhan dan keinginan para pemangku kepentingan, terutama pengguna. Juga penting untuk menentukan masa depan proses dalam sistem yang dilakukan sehubungan dengan operasi bisnis, dan Menelaah cara-cara di mana sistem dapat mendukung untuk memenuhi tujuan utama dan mengatasi masalah utama bisnis

Peran Requirements Engineer selama elisitasi

- Selama elisitasi kebutuhan requirement engineer (analis sistem atau analis bisnis) dapat memainkan berbagai peran dan memikul tanggung jawab yang berbeda.
- Tanggung jawab dan peran ini tergantung pada proyek, orang, konteks dan organisasi yang terlibat

1. Requirements engineers memainkan peran penting sebagai
facilitator
Ketika memunculkan kebutuhan pada sesi kerja kelompok, mereka tidak hanya dituntut untuk mengajukan pertanyaan dan mencatat jawaban, tetapi harus membimbing dan membantu peserta dalam menangani isu-isu yang relevan untuk mendapatkan informasi kebutuhan yang benar dan lengkap.
2. Requirements engineers sebagai mediator
Dalam banyak kasus prioritas kebutuhan dari kelompok pemangku kepentingan yang berbeda adalah sumber dari banyak perdebatan dan perselisihan. Requirements engineers memiliki tanggung jawab untuk untuk mencari resolusi yang sesuai melalui negosiasi dan kompromi.
3. Requirements engineers bertanggungjawab untuk mendokumentasikan kebutuhan yang dimunculkan selama proses elisitasi. Peran ini sangat penting karena merupakan produksi hasil dari
proses elisitasi, dan membentuk dasar untuk proyek fase
berikutnya
4. Semua kebutuhan yang muncul divalidasi terhadap pemangku
kepentingan lainnya, sistem lain, satu sama lain, dan kemudian dibandingkan dengan sasaran yang telah ditetapkan sebelumnya untuk sistem.

Methodology Based Requirements Elicitation

1. Structured Analysis and Design (SAD)
Terdiri dari kumpulan teknik seperti Data Flow Diagram (DFD) dengan detail dekomposisi fungsional yang menekankan pada data masuk dan keluar dari sistem dan komponen terkait. Entity Relationship Diagram (ERD) yang memfasilitasi representasi entitas sistem, atribut mereka, dan hubungan mereka satu sama lain.
2. Object Oriented (OO) Approaches
Khususnya Unified Modeling Language (UML) berisi beberapa teknik yang sering digunakan untuk elisitasi kebutuhan ang ditetapkan dengan notasi namun fleksibel dan format seperti Use Case diagrams, Use Case descriptions, and Class Diagrams.

Perbedaan antara modeling dan spesifikasi:
Modeling sesuai dengan aktivitas memilih meta-model untuk meresmikan pada tingkat konseptual/ tampilan sistem ertentu, sedangkan
Spesifikasi berkaitan dengan penerapan bahasa untuk membuat model sistem nyata.

Meta-Models Categories

1. State Oriented Meta-Models adalah State oriented meta-models memungkinkan pemodelan sistem sebagai set of states dan satu set transisi. Contoh : Contoh: Finite State Machines (FSMs), Finite State Machines with Data paths (FSMDs), State Charts, Petri nets
2. Activity Oriented Meta-Models Meta-models berorientasi aktivitas memungkinkan pemodelan sistem sebagai erangkaian kegiatan yang berkaitan dengan data atau dengan eksekusi yang berkaitan. contoh : Data Flow Diagram (DFD), Flowcharts
3. Structured Oriented Meta-Models Structured oriented meta-models memungkinkan deskripsi sistem modul fisik dan interkoneksi mereka. Meta-model yang didedikasikan untuk karakterisasi komposisi fisik dari suatu sistem, bukan fungsinya.
Contoh: Block Diagram/ Component-Connectivity Diagrams (CCDs), UML’s deployment dan component diagram didasarkan pada meta-model ini.
4. Data Oriented Meta-Models Data oriented meta-models memungkinkan pemodelan sistem sebagai kumpulan data yang berhubungan dengan beberapa jenis atribut. biasanya digunakan dalam metodologi berdasarkan analisis struktur tradisional dan teknik desain. Ex ERD, JSDs
5. Heterogeneous Meta-Models Heterogeneous meta-models memungkinkan penggunaan dalam representasi sistem yang sama, beberapa karakteristik dari meta-model yang berbeda, yaitu empat kategori yang dijelaskan sebelumnya
Contoh :
- Control/ Data Flow Graphs (CDFGs)
- Object Process Diagram (OPDs)
- Program State Machines (PSMs)

6. Multiple-View Approach
Dengan meningkatnya kompleksitas sistem, penggunaan meta-model yang berbeda untuk mewakili berbagai jenis karakteristik sistem menjadi hal yang umum.

Complexity Control

1. Representational complexity
Pada dasarnya tergantung pada bahasa spesifikasi, dan jika dikelola dengan benar memungkinkan diperoleh spesifikasi yang ringkas dan mudah dipahami.
- Pendekatan grafis biasanya lebih mudah dipahami daripada yang tekstual. Dengan demikian meningkatkan pembacaan dan understandability pandangan sistem.
- UML mengadopsi pendekatan grafis
2. Development complexity
Dimensi kedua kontrol kompleksitas (development complexity) mengacu pada kontrol dari evolusi spesifikasi sistem dari konseptualisasi awal kebutuhan.

Requirements Transformation 4SRS Technique
Step 1 – Object creation
Setiap use case harus ditransformasikan ke dalam 3 objek (One interfaces, one data, and one control)
Step 2 – Object elimination
Ini harus diputuskan mana dari tiga obyek harus dijaga untuk sepenuhnya mewakili dengan mempertimbangkan seluruh sistem
Step 3 – Object packaging and aggregation
Objek yang tersisa (dari step 2) yang ada keuntungan dalam diperlakukan dengan cara yang terpadu harus memberikan asal ke agregasi atau paket objek yang konsisten
Step 4 – Object association
Mendukung asosiasi di dalam model objek

Requirements Prioritization

Penjelasan tentang teknik untuk menentukan prioritas kebutuhan untuk produk perangkat lunak untuk mengidentifikasi kebutuhan yang paling berharga dengan membedakan hal yang kritis daripada yang biasa.

Tujuan Requirements Prioritization-
- Para pemangku kepentingan dapat menentukan kebutuhan inti untuk sistem
- Untuk merencanakan dan memilih set optimal kebutuhan perangkat lunak untuk implementasi dalam rilis yang berturut-turut
- Untuk lingkup proyek yang diinginkan kadang-kadang bertentangan dengan kendala seperti jadwal, anggaran, sumber
daya, waktu rilis ke pasaran, dan kualitas.
- Untuk menyeimbangkan manfaat bisnis terhadap biaya
- Untuk menyeimbangkan akibat dari kebutuhan pada arsitektur perangkat lunak dan evolusi masa depan produk dan biaya yang terkait
- Untuk memilih hanya sebagian dari kebutuhan dan masih menghasilkan sebuah sistem yang akan memuaskan pelanggan
- Untuk memperkirakan kepuasan pelanggan yang diharapkan
- Untuk mendapatkan keunggulan teknis dan mengoptimalkan peluang pasar
- Untuk meminimalkan kerja ulang dan jadwal (stabilitas rencana)
- Untuk menangani kebutuhan yang bertentangan, fokus pada proses negosiasi, dan menyelesaikan perbedaan pendapat antara para pemangku kepentingan
- Untuk menentukan kepentingan relatif dari setiap kebutuhan untuk memberikan nilai terbesar pada biaya terendah

Kategori Requirements Prioritization
- Metode didasarkan pada jumlah menempatkan nilai ke aspek yang
berbeda dari kebutuhan, sementara pendekatan negosiasi fokus
pada memberikan prioritas untuk kebutuhan dengan mencapai
kesepakatan antara para pemangku kepentingan yang berbeda.
- Pendekatan negosiasi didasarkan pada ukuran subjektif dan
biasanya digunakan ketika analisis kontekstual dan ketika variabel
keputusan yang saling terkait.

Aspek Prioritas

1. Tingkat Kepentingannya
Ketika memprioritaskan kepentingan, para pemangku kepentingan harus memprioritaskan mana persyaratan yang paling penting bagi sistem. Namun, penting bisa menjadi konsep yang sangat beragam karena sangat tergantung pada
perspektif yang dimiliki pemangku kepentingan.
2. Hukuman
Hal ini dimungkinkan untuk mengevaluasi hukuman yang diperkenalkan jika persyaratan tidak terpenuhi. Misalnya, gagal untuk menyesuaikan diri dengan standar akan dikenakan penalti tinggi bahkan jika itu sangat rendah bagi
pelanggan (yaitu pelanggan tidak merasa senang jika kebutuhannya tidak terpenuhi).
3. Biaya
Biaya pelaksanaan biasanya diperkirakan oleh organisasi pengembang. Tindakan yang mempengaruhi biaya meliputi:
kompleksitas kebutuhan, kemampuan untuk menggunakan kembali kode yang ada, jumlah pengujian dan dokumentasi
yang diperlukan, dll
4. Waktu
Biaya dalam pengembangan perangkat lunak sering berhubungan dengan jumlah jam staf. Namun, dipengaruhi oleh banyak faktor lain seperti tingkat paralelisme dalam pembangunan, kebutuhan pelatihan, perlu mengembangkan infrastruktur pendukung, standar industri yang lengkap, dll
5. Resiko
Setiap proyek membawa beberapa jumlah risiko. Dalam manajemen proyek, manajemen risiko digunakan untuk mengatasi baik internal (teknis dan risiko pasar) dan risiko eksternal (misalnya peraturan, pemasok). Manajemen risiko juga dapat digunakan ketika merencanakan persyaratan menjadi produk dan rilis dengan mengidentifikasi risiko yang cenderung menyebabkan kesulitan selama pengembangan. Risiko tersebut bisa mencakup misalnya risiko kinerja, risiko proses, risiko jadwal dll
6. Volatilitas (Hal yang berubah-ubah)
Volatilitas persyaratan dianggap sebagai faktor risiko dan kadang-kadang ditangani sebagai bagian dari aspek risiko. Orang lain berpikir bahwa volatilitas harus dianalisis secara terpisah dan volatilitas persyaratan harus diperhitungkan secara terpisah dalam proses prioritas. Misalnya: perubahan pasar, kebutuhan bisnis berubah, perubahan
legislatif yang terjadi, pengguna berubah.
7. Aspek Lain
Dari daftar di atas aspek telah dianggap penting dalam literatur tetapi tidak berarti lengkap. Contoh aspek lain adalah: keuntungan finansial, manfaat strategis, pesaing, kompetensi/ sumber daya, rilis tema, kemampuan untuk menjual, dll Bagi perusahaan, disarankan agar para pemangku kepentingan mengembangkan daftar aspek penting untuk digunakan dalam pengambilan keputusan. Adalah penting bahwa para pemangku kepentingan memiliki penafsiran yang sama dari aspek serta persyaratan.
8. Menggabungkan Aspek yang berbeda-beda
Dalam prakteknya, penting untuk mempertimbangkan beberapa aspek sebelum memutuskan apakah persyaratan harus dilaksanakan secara langsung, kemudian, atau tidak sama sekali. Sebagai contoh, dalam pendekatan Cost-Value, baik value
(penting) dan biaya diprioritaskan untuk melaksanakan persyaratan yang memberikan nilai untuk uang

Prioritization Techniques

1. Analytical Hierarchy Process (AHP)
Penelitian telah menunjukkan bahwa AHP tidak cocok untuksejumlah besar kebutuhan.Para peneliti telah mencoba untuk menemukan cara untukmengurangi jumlah perbandingan dan varian teknik telah ditemukan untuk mengurangi jumlah perbandingan sebanyak 75 persen.
2. Cumulative Voting, the 100-Dollar Test
Tes 100-dolar adalah teknik prioritas yang sangat mudah di mana para pemangku kepentingan diberikan 100 unit imajiner (uang, jam, dll) untuk mendistribusikan antara kebutuhan. Hasil prioritas disajikan pada skala rasio.
3. Numerical Assignment (Grouping)
Numerical assignment adalah teknik prioritas yang paling umum dan disarankan baik di RFC 2119 dan IEEE Std. 830-1998. Pendekatan ini didasarkan pada pengelompokan kebutuhan ke dalam kelompok prioritas yang berbeda. Jumlah kelompok dapat bervariasi, tetapi dalam prakteknya, tiga kelompok yang sangat umum.
3. Numerical Assignment (Grouping)
Bila menggunakan tugas numerik, adalah penting bahwa masing-masing kelompok mewakili sesuatu yang para pemangku kepentingan dapat berhubungan dengan (misalnya kritis, standar, opsional), untuk klasifikasi handa.
4. Ranking
Setiap kebutuhan memiliki peringkat yang unik (dibandingkan dengan tugas numerik) tetapi tidak mungkin untuk melihat perbedaan relatif antara item peringkat (seperti dalam AHP atau tes 100 dolar).
5. Top-Ten Requirements
Dalam pendekatan kebutuhan top-sepuluh, para pemangku kepentingan memilih kebutuhan mereka sepuluh paling atas (dari satu set yang lebih besar) tanpa menetapkan perintah internal antara kebutuhan.