Engineering and Managing Software Requirements Aybke Aurum Claes

Engineering and Managing Software Requirements Aybüke Aurum · Claes Wohlin (Eds. )

Materi 1. 2. Requirements Engineering Requirements Elicitation: A Survey of Techniques, Approaches and Tools 3. Specification of Requirements Models 4. Requirements Prioritization 5. Requirements Interdependencies: State of the Art and Future 6. Impact Analysis 7. Requirements Negotiation 8. Quality Assurance in Requirements Engineering 9. Modeling Goals and Reasoning with Them 10. Managing Large Repositories of Natural Language Requirements

11. Understanding Ambiguity in Requirements Engineering 12. Decision Support in Requirements Engineering 13. Market-Driven Requirements Engineering for Software Products 14. Requirements Engineering for Agile Methods

Chapter 1 Requirements Engineering

1. 1 Introduction • Tujuan dari bab ini ada dua. Pertama, hal ini bertujuan untuk memberikan pengenalan singkat untuk rekayasa persyaratan, dan kedua hal ini bertujuan untuk menetapkan konteks umum untuk bab-bab lain dari buku ini. • Rekayasa kebutuhan diterima sebagai salah satu tahapan yang paling penting dalam perangkat lunak desain dan pengembangan karena membahas masalah penting merancang lunak yang tepat untuk user. • Pengembangan spesifikasi kebutuhan perangkat lunak secara luas diakui sebagai dasar dari fungsi sistem. Persyaratan perangkat lunak merupakan penentu penting kualitas perangkat lunak, mengingat studi empiris menunjukkan bahwa kesalahan dalam persyaratan yang paling banyak dalam perangkat lunak siklus hidup dan juga yang paling mahal dan memakan waktu untuk memperbaiki.

1. 2 Latar Belakang 1. What is a Requirement? Semua proyek dimulai dengan pernyataan persyaratan. Banyak dikutip IEEE 610, 12 -1990 standar mendefinisikan persyaratan sebagai berikut: 1) Suatu kondisi atau kemampuan yang diperlukan oleh user untuk memecahkan masalah atau mencapai obyektif, 2) Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem atau sistem komponen untuk memenuhi kontrak, standar, spesifikasi, atau lainnya secara resmi dikenakan dokumen, Sebuah representasi didokumentasikan dari suatu kondisi atau kemampuan seperti dalam (1) atau (2).

• Types of requirements • Functional requirements - sistem apa yang akan dilakukan • Non-functional requirements-kendala pada jenis solusi yang akan memenuhi persyaratan fungsional misalnya akurasi, kinerja, keamanan dan modifiability • Goal level requirements - terkait dengan tujuan bisnis • Domain level requirements - terkait dengan bidang masalah • Product level requirements - berkaitan dengan produk • Design level requirements - apa yang harus dibangun

• • Primary requirements — kebutuhan dari stakeholder Derived requirements — berasal dari persyaratan primer Others classifications, e. g. • Bisnis persyaratan terhadap persyaratan teknis • Persyaratan Produk dibandingkan persyaratan proses - yaitu kebutuhan bisnis dibandingkan bagaimana orang akan berinteraksi dengan sistem • Persyaratan berbasis Peran, misalnya persyaratan pelanggan, kebutuhan pengguna, kebutuhan TI, persyaratan sistem, dan persyaratan keamanan

2. Requirements Engineering Process • Rekayasa kebutuhan mengacu pada semua kegiatan siklus hidup yang berkaitan dengan persyaratan. • Hal ini termasuk mengumpulkan, mendokumentasikan dan mengelola persyaratan, dengan meningkatnya kesadaran tentang pentingnya persyaratan dalam proses perangkat lunak, rekayasa persyaratan semakin menjadi area fokus dalam rekayasa perangkat lunak penelitian.

3. The Role of Stakeholders in Requirements Engineering • Pada intinya, rekayasa persyaratan bertujuan untuk mengubah berpotensi tidak lengkap, tidak konsisten dan bertentangan tujuan stakeholder dalam satu set lengkap persyaratan kualitas tinggi. • Peneliti sistem informasi mendefinisikan stakeholder ". . . sebagai orang peserta dalam proses pembangunan bersama-sama dengan orang lain, kelompok atau organisasi tindakan yang dapat mempengaruhi atau dipengaruhi oleh pembangunan dan penggunaan sistem baik secara langsung atau tidak langsung “.

4. Different Levels of Requirements • Managements yang efektif dari proses pengembangan perangkat lunak memberikan kontribusi untuk berkelanjutan keunggulan kompetitif bagi perusahaan perangkat lunak. Ini berarti bahwa manajer perlu mempertimbangkan pelanggan dan kebutuhan bisnis, serta peluang teknologi yang mungkin berbeda atau tumpang tindih. • Di era internet telah terjadi perubahan signifikan dalam lingkungan bisnis menciptakan tuntutan yang lebih kompleks pada teknologi yang mendukung bisnis sistem informasi. Akibatnya, pemahaman , analisis , pemodelan dan mengelola persyaratan telah menjadi tugas yang sama rumitnya. • Dalam rangka untuk memberikan sistem perangkat lunak berkualitas tinggi pada waktu dan anggaran , adalah penting untuk memiliki benar spesifikasi persyaratan terstruktur dan terkontrol yang dapat dimengerti , komprehensif dan konsisten.

• Persyaratan klasifikasi dalam tiga tingkatan Strategic Management Tactical Management Operational Management Requirements at organizational level Business strategy Competitiveness Technology Marketing Economic value of the product Planned benefits of the product Tradeoff between technology-push and market-pull Requirements at product level Packaging requirements for a specific release Product architectures Resource management Implementation of a specific release Change management Requirements volatility e. g. whether a particular requirement is subject to a syntactic or semantic change Requirements at project level • Project planning • Feasibility study • Recruiting people • Project management • Quality control Validation in terms of which requirements will go to the next release

a) Requirements at organizational level • • Tim manajemen senior organisasi mungkin memiliki tujuan strategis dan tujuan jangka panjang dalam hal pangsa pasar dan sebagainya. Tujuan dan strategi di tingkat organisasi pasti akan mempengaruhi produk yang organisasi harus mengembangkan. Dengan demikian, persyaratan yang diajukan pada produk pertama harus dievaluasi di tingkat organisasi untuk memastikan bahwa mereka selaras dengan tujuan dan strategi organisasi. Salah satu tantangan utama yang dihadapi ketika berhasil mengembangkan produk perangkat lunak yang menentukan bagaimana produk akhir akan mendukung tujuan bisnis.

b) Requirements at the Product Level • • • Persyaratan produk perangkat lunak harus selaras dengan tujuan bisnis dari organisasi pengembangan perangkat lunak. Salah satu pertanyaan penting adalah bagaimana menyeimbangkan masalah pelanggan dengan pengembang masalah. Teknik pemodelan tujuan dalam rekayasa persyaratan berfungsi sebagai mekanisme mana yang dapat menghubungkan persyaratan untuk tujuan strategis berlabuh dalam konteks model strategi bisnis secara keseluruhan. Persyaratan biasanya baik kebutuhan fungsional dan nonfungsional. Manajemen produk harus memastikan bahwa persyaratan yang selaras dengan tujuan dan sasaran dalam hal produk. Ini mungkin berarti memilih persyaratan untuk produk yang terbaik selaras dengan tujuan-tujuan dan strategi organisasi.

c) Requirements at the Project Level • • • Persyaratan pada tingkat produk harus dikemas menjadi bagian-bagian yang masuk ke proyek atau rilis perangkat lunak tertentu. Adalah penting bahwa persyaratan yang diprioritaskan dipilih berdasarkan pemenuhan mereka kedua produk dan tujuan organisasi dan strategi. Persyaratan dapat dipilih untuk implementasi berdasarkan apakah mereka memenuhi kebutuhan pelanggan tertentu dan penting, atau apakah mereka berpotensi membuka segmen pasar baru bagi organisasi. Persyaratan ini menentukan kondisi di mana proyek ini akan dijalankan, termasuk masalah yang berkaitan dengan perencanaan proyek, manajemen risiko, anggaran dan biaya.

4. Requirements Management • Kualitas produk perangkat lunak sangat ditentukan oleh kualitas pembangunan proses yang digunakan untuk menciptakannya. Banyak proyek gagal karena kesalahan dalam penjelasannya persyaratan, sementara yang lain gagal karena persyaratan menjadi usang pada saat proyek diserahkan [9]. • Ini juga merupakan pengembang tantangan utama untuk menentukan persyaratan perubahan akan menyebabkan masalah besar dalam proyek atau produk itu sendiri [9]. Fase engineering Mengelola persyaratan sangat penting untuk keberhasilan pengembangan produk perangkat lunak. • Dalam rangka untuk memberikan sistem perangkat lunak berkualitas tinggi pada waktu dan anggaran adalah penting untuk memiliki spesifikasi persyaratan benar terstruktur dan terkontrol yang dapat dimengerti, komprehensif dan konsisten.

• Sebagaimana disebutkan di atas, adalah penting untuk memiliki pemahaman yang baik tentang stakeholder yang tujuan dan memastikan keterlibatan mereka dalam proses persyaratan rekayasa. • Pengelolaan persyaratan melibatkan membangun pemahaman bersama antara stakeholder dan persyaratan yang mereka telah ditetapkan untuk dimasukkan dalam produk perangkat lunak. • Praktek-praktek penting dari persyaratan manajemen adalah: . • Requirements Elicitation, Specification and Modeling: Ini melibatkan memahami kebutuhan stakeholders, memunculkan persyaratan, pemodelan dan mengumpulkan mereka dalam repositori. Ini merupakan tahap penting dalam pengembangan perangkat lunak. Namun, karena berbagai alasan, termasuk kognitif, komunikatif dan alasan motivasi, persyaratan cenderung tidak lengkap dan tidak konsisten. Oleh karena itu, selalu ada ruang untuk perbaikan dalam kegiatan ini.

• Prioritization: Prioritas: Hal ini tidak selalu mudah bagi pengembang untuk menentukan persyaratan penting bagi pelanggan. Kegiatan ini membantu manajer proyek dengan menyelesaikan konflik (di mana pelanggan dan pengembang berkolaborasi pada persyaratan prioritas), berencana untuk pengiriman bertahap, dan membuat diperlukan trade-off keputusan. • Requirements Dependencies and Impact Analysis: Penting untuk mengakui bahwa perubahan persyaratan dan bahwa ini secara signifikan dapat mempengaruhi proyek software [14]. Beberapa isu seperti keputusan rekaman, memahami dampak perubahan bisnis dan penggunaan model domain yang masih harus ditangani.

• Requirements Negotiation: Rekayasa Kebutuhan dasarnya adalah kompleks komunikasi dan negosiasi proses yang melibatkan pelanggan, desainer, manajer proyek dan pengelola. Orang-orang, atau stakeholders, yang terlibat dalam proses bertanggung jawab untuk memutuskan apa yang harus dilakukan, kapan melakukannya, informasi apa dibutuhkan, dan apa alat harus digunakan. Dalam banyak situasi konflik melekat dalam persyaratan, sehingga mereka perlu dinegosiasikan antara stakeholders. Beberapa alat, seperti Win-Win Groupware, telah dikembangkan untuk mendukung stakeholder selama proses negosiasi. Persyaratan negosiasi Kegiatan merupakan salah satu kegiatan yang paling penting dalam pengembangan perangkat lunak seperti memiliki dampak yang besar pada produk akhir. Pada kenyataannya, kegiatan ini dilakukan di paralel dengan kegiatan yang disebutkan di atas dan berlanjut sampai persyaratan diimplementasikan.

• Quality Assurance: Tujuannya adalah untuk memastikan persyaratan kualitas yang tinggi dicatat dalam dokumen spesifikasi. Tujuan dari jaminan kualitas untuk menetapkan tingkat yang wajar dan realistis kepercayaan saat menulis dan mengelola persyaratan. Adalah penting bahwa baik user dan pengembang yang terlibat dalam kegiatan jaminan kualitas dalam rekayasa persyaratan sebagaimana mereka mempengaruhi keberhasilan proyek. Adalah penting untuk menekankan bahwa jaminan kualitas persyaratan tidak hanya kegiatan pada fase persyaratan dalam proyek. Jaminan kualitas harus ditangani di seluruh siklus hidup perangkat lunak. Kebutuhan harus ditelusuri seluruh pembangunan dan kualitas terjamin, misalnya, melalui inspeksi, ulasan dan pengujian.

6. New Trends and the Next Practice: Perbaikan teknologi di pasar global yang erat kaitannya dengan bisnis lingkungan. Konsep baru seperti sistem perusahaan, e-bisnis dan telekomunikasi telah menyebabkan tren baru dalam penelitian bagi para peneliti dan praktisi. Selain itu, kompleksitas bekerja dalam terdistribusi dan heterogen lingkungan yang menyebabkan perubahan besar dalam keterampilan yang dibutuhkan dan teknologi digunakan untuk mengembangkan dan memelihara aplikasi perangkat lunak. Dalam hal ini yang selalu berubah bisnis dan teknologi lingkungan, tren baru sudah mulai muncul dan telah menyebabkan pergeseran mendasar dalam pengembangan perangkat lunak. Dalam cara yang sama, persyaratan rekayasa telah mulai berevolusi dari peran tradisionalnya, sebagai hanya front-end dalam siklus pengembangan perangkat lunak, untuk menjadi fokus utama dalam proses pengembangan perangkat lunak, sebuah proses yang membutuhkan pemahaman yang lebih tepat dari lapangan itu sendiri. Saat ini, definisi apa yang merupakan siklus pengembangan perangkat lunak adalah memperluas dan berkembang sebagai teknologi baru muncul, memaksa software pengembang berebut untuk memposisikan diri dalam lingkungan bisnis yang berubah cepat.

7. Empirical Evidence: Penelitian empiris bertujuan untuk menangkap bukti kuantitatif dan membandingkan teori untuk kenyataannya, membantu kita untuk menarik kesimpulan dan mengevaluasi metode baru dan alat-alat. Penelitian empiris adalah penting untuk bidang persyaratan rekayasa karena hasil dari studi tersebut baik membantu untuk mengkarakterisasi potensi masalah (tentang persyaratan di tingkat bisnis, produk dan proyek) dengan mana lapangan adalah bersangkutan dan mengevaluasi teknik-teknik baru dalam konteks yang relevan. Penelitian empiris memberikan pemahaman yang berharga tentang aspek persyaratan rekayasa. Selain itu, akademisi dan praktisi software perlu bukti pendukung dari studi kasus, studi lapangan dan percobaan sebelum mengadopsi teknologi baru. Mengumpulkan bukti empiris dari industri sering memakan waktu dan dapat menjadi sangat rumit. Namun, hal ini diperlukan untuk mengukur dan menunjukkan mereka manfaat relatif terhadap komunitas persyaratan rekayasa. .

Tergantung pada tujuan dari evaluasi, apakah itu teknik, metode atau alat-alat, dan tergantung pada kondisi untuk penyelidikan empiris, tiga sebagian besar jenis umum dari penyelidikan kuantitatif (strategi) adalah: • Percobaan: Percobaan sering sangat dikontrol (dan karenanya juga kadang-kadang disebut sebagai eksperimen terkontrol) dan sering berjalan di laboratorium. Ketika percobaan, subyek ditugaskan untuk perlakuan yang berbeda secara acak. • Studi-kasus : Studi kasus biasanya dilakukan mempelajari proyek yang nyata dan digunakan untuk proyek-proyek monitoring, kegiatan atau tugas. Data dikumpulkan untuk tujuan tertentu selama penelitian. • Survey : Sebuah survei sering investigasi yang dilakukan dalam retrospeksi, ketika misalnya alat atau teknik, telah digunakan untuk beberapa waktu. Cara utama mengumpulkan data kualitatif atau kuantitatif adalah wawancara atau kuesioner.

7. Conclusion: Bab ini memiliki dua kontribusi utama: (a) dari sudut pandang teoritis, itu memberikan pengenalan singkat ke daerah rekayasa persyaratan, dan (b) dari sebuah sudut pandang praktis, hal ini bertujuan untuk menyediakan para pembaca dengan pedoman untuk beberapa penting aspek persyaratan rekayasa yang diperlukan untuk memperoleh manfaat penuh dari bab-bab lain dari buku ini. Ada tiga bagian dalam buku ini. Bagian 1 berisi "state-of-the-art" bab alamat kegiatan rekayasa persyaratan utama yang disebutkan dalam Sect. 1. 5, yaitu elisitasi persyaratan, spesifikasi dan pemodelan, prioritas, persyaratan dependensi, analisis dampak, persyaratan negosiasi dan kualitas masalah jaminan. Bagian 2 ini dimaksudkan untuk mengatasi tren baru dalam persyaratan rekayasa dan titik-titik keuntungan dan perangkap tren ini. Akhirnya, Bagian 3 berisi bab-bab berfokus pada bukti empiris dari penelitian akademis serta studi kasus industri. .