2.1 Introduction Pentingnya persyaratan rekayasa (RE) dalam pengembangan sistem perangkat lunak telah lama diungkapkan dan diakui oleh para peneliti dan.

Presentasi berjudul: "2.1 Introduction Pentingnya persyaratan rekayasa (RE) dalam pengembangan sistem perangkat lunak telah lama diungkapkan dan diakui oleh para peneliti dan."— Transcript presentasi:

1 Chapter 2 Requirements Elicitation: A Survey of Techniques, Approaches and Tools

2 2.1 Introduction Pentingnya persyaratan rekayasa (RE) dalam pengembangan sistem perangkat lunak telah lama diungkapkan dan diakui oleh para peneliti dan praktisi (Bab 1). Persyaratan Elisitasi merupakan awal tapi terus-menerus dan tahap kritis dalam pengembangan sistem perangkat lunak. Persyaratan untuk sistem perangkat lunak dapat tersebar di berbagai sumber. Ini termasuk masalah Kepemilikan, stakeholder, dokumentasi, dan sistem lain yang ada. Karena sifat kaya komunikasi persyaratan kegiatan elisitasi, banyak teknik yang efektif tidak berasal dari wilayah tradisional rekayasa perangkat lunak atau penelitian ilmu komputer. Teknik untuk elisitasi persyaratan yang berasal sebagian besar dari ilmu-ilmu sosial, teori organisasi, dinamika kelompok, pengetahuan teknik, dan sangat sering dari pengalaman praktis.

3 2.2 What is Requirements Elicitation
Saat ini ada sangat sedikit keseragaman dalam penelitian RE dan praktek tentang suatu definisi standar untuk persyaratan elisitasi. Elisitasi persyaratan yang bersangkutan dengan belajar dan memahami kebutuhan pengguna dan sponsor proyek dengan tujuan utama berkomunikasi kebutuhan ini kepada para pengembang sistem. Sebagian besar dari elisitasi didedikasikan untuk mengungkap, penggalian, dan permukaan keinginan stakeholder potensial.

4 The Process of Requirements Elicitation
Proses persyaratan elisitasi melibatkan serangkaian kegiatan yang harus memungkinkan untuk komunikasi, penentuan prioritas, negosiasi, dan kolaborasi dengan semua yang terkait stakeholders. Hal ini juga harus memberikan pondasi yang kuat bagi munculnya, penemuan, dan penemuan persyaratan sebagai bagian dari proses elisitasi yang sangat interaktif. Kebutuhan elisitasi melibatkan kegiatan yang sangat komunikatif. Kegiatan ini semakin penting ketika seseorang mempertimbangkan "perbedaan kultur“ atau perbedaan semantik dasar membagi masalah memiliki dan memecahkan masalah komunitas ketika mencoba untuk terlibat dalam dialog yang bermakna.

5 Sekali lagi ada sangat sedikit keseragaman dalam literatur penelitian dan praktek mengenai nama-nama yang diberikan kepada kegiatan yang sering dilakukan selama elisitasi persyaratan. Namun apa yang berlaku umum adalah bahwa elisitasi adalah tahap awal dalam proses RE meskipun satu berulang dan terpadu. Kegiatan khas dari proses elisitasi persyaratan dapat dibagi menjadi lima jenis dasar seperti yang dijelaskan di bawah ini: Memahami Domain Application - Hal ini penting ketika memulai proses elisitasi persyaratan untuk menyelidiki dan memeriksa secara rinci situasi atau "dunia nyata" di mana sistem akhirnya akan berada (kadang-kadang disebut domain aplikasi) [34, 68]. Lingkungan saat ini perlu benar-benar dieksplorasi termasuk aspek-aspek politik, organisasi, dan sosial terkait dengan sistem, di samping setiap kendala yang mereka dapat memberlakukan atas sistem dan perkembangannya. Ada proses kerja dan masalah terkait yang harus diselesaikan oleh kebutuhan sistem yang akan dijelaskan sehubungan dengan tujuan bisnis utama dan masalah.

6 Mengidentifikasi Sumber Persyaratan - Persyaratan dapat menyebar di banyak sumber dan ada dalam berbagai format. Dalam semua pengembangan perangkat lunak proyek sejumlah sumber yang mungkin untuk persyaratan dapat diidentifikasi. Stakeholder merupakan sumber yang paling jelas dari persyaratan untuk sistem. Pengguna dan keahlian tertentu yang digunakan untuk memberikan informasi rinci tentang masalah-masalah dan kebutuhan pengguna. Sistem yang ada dan proses mewakili sumber lain untuk memunculkan kebutuhan, terutama ketika proyek melibatkan menggantikan sistem saat ini atau warisan. Dokumentasi yang ada tentang sistem saat ini dan proses bisnis termasuk manual, bentuk, dan laporan dapat memberikan informasi yang berguna tentang organisasi dan lingkungan, serta sebagai persyaratan untuk sistem baru dan alasan yang mendukung mereka dan kepentingan. Menganalisis Stakeholder - Stakeholder adalah orang-orang yang memiliki kepentingan dalam sistem atau terpengaruh dalam beberapa cara oleh pengembangan dan implementasi sistem dan karenanya harus dikonsultasikan selama elisitasi persyaratan. Biasanya para pemangku kepentingan termasuk kelompok dan individu internal dan eksternal untuk organisasi. Pelanggan, dan lebih khusus sponsor proyek, adalah biasanya stakeholder yang jelas dari sistem. Dalam beberapa kasus namun pengguna aktual sistem mungkin yang paling penting.

7 Memilih Teknik, Pendekatan, dan Alat untuk Penggunaan - Meskipun beberapa mungkin menganjurkan bahwa teknik hanya satu elisitasi atau metodologi tunggal sudah cukup dan dapat diterapkan untuk semua kasus, secara umum diterima bahwa seorang individu persyaratan teknik elisitasi atau pendekatan tidak mungkin cocok untuk semua proyek. Memunculkan Persyaratan dari Stakeholder dan Sumber Lainnya – Setelah sumber persyaratan dan pemangku kepentingan spesifik telah diidentifikasi, elisitasi sebenarnya dari persyaratan inti kemudian mulai menggunakan dipilih teknik elisitasi, pendekatan, dan alat-alat.

8 Roles of the Requirements Engineer During Elicitation
Peran Persyaratan Ahli Selama elisitasi Selama elisitasi persyaratan persyaratan engineer (juga kadang-kadang disebut sebagai analis sistem atau analis bisnis) dapat memainkan berbagai peran dan memikul tanggung jawab yang berbeda. Ini tanggung jawab dan peran tergantung pada proyek, pegawai, konteks dan organisasi yang terlibat. Sebagian besar dari elisitasi melibatkan menjelajahi domain masalah dan persyaratan yang terletak di domain tersebut. Selain itu, para ahli persyaratan sering perlu untuk melakukan beberapa aspek khas manajemen proyek. Tidak hanya mereka harus mengelola proses elisitasi, tetapi mereka juga harus berkomunikasi secara efektif kepada para stakeholder. Hal ini melibatkan antara lain, pengambilan keputusan (Bab12), prioritas (Bab 4), dan negosiasi (Bab 7).

9 Techniques and Approaches for Requirements Elicitation
Selama lebih dari dua dekade sekarang banyak penelitian dan praktek dalam RE untuk perangkat lunak sistem sebagian besar telah diarahkan untuk meningkatkan proses kompleks dikenal sebagai elisitasi melalui penerapan dan pengembangan berbagai teknik, pendekatan, dan alat-alat. Banyak dari metode ini telah digunakan dan diadaptasi dari disiplin ilmu lain seperti ilmu-ilmu sosial, dan hanya beberapa orang terpilih telah dikembangkan secara khusus untuk memunculkan persyaratan perangkat lunak [14].

10 Wawancara,mungkin teknik yang paling tradisional dan umum digunakan untuk elisitasi persyaratan. Karena wawancara pada dasarnya berbasis sosial manusia kegiatan, mereka secara inheren informal dan efektivitas mereka sangat tergantung pada kualitas interaksi antara peserta. Wawancara memberikan efisien cara untuk mengumpulkan data dalam jumlah besar secara cepat. Hasil wawancara, seperti kegunaan dari informasi yang dikumpulkan, dapat bervariasi secara signifikan tergantung pada keterampilan pewawancara [23]. Ada dasarnya tiga jenis wawancara yang terstruktur, terstruktur, dan semi-terstruktur, yang terakhir umumnya mewakili kombinasi dari dua mantan.

11 Kuesioner, terutama digunakan selama tahap awal dari persyaratan elisitasi dan dapat terdiri dari pertanyaan terbuka dan / atau tertutup. Agar efektif, istilah, konsep, dan batas-batas domain harus ditetapkan dan dipahami oleh para peserta dan desainer kuesioner. Pertanyaan harus difokuskan untuk menghindari mengumpulkan sejumlah besar informasi yang berlebihan dan tidak relevan. Mereka memberikan cara yang efisien untuk mengumpulkan informasi dari berbagai pemangku kepentingan dengan cepat, tetapi terbatas dalam kedalaman pengetahuan mereka mampu memperoleh. Kuesioner kekurangan kesempatan untuk mempelajari lebih jauh tentang suatu topik, atau mengembangkan ide-ide baru.

12 Analisis tugas menggunakan pendekatan top-down di mana tugas-tugas tingkat tinggi didekomposisi ke sub-tugas dan urutan akhirnya rinci sampai semua tindakan dan peristiwa dijelaskan. Tujuan utama dari teknik ini adalah untuk membangun hirarki tugas yang dilakukan oleh pengguna dan sistem, dan menentukan pengetahuan yang digunakan atau dibutuhkan untuk menyelesaikan pekerjaannya. Analisis domain. Meneliti dokumentasi dan aplikasi yang ada dan terkait adalah sangat berguna cara mengumpulkan persyaratan awal serta pemahaman dan menangkap pengetahuan domain, dan identifikasi konsep digunakan kembali dan komponen. Teknik introspeksi, membutuhkan analis untuk mengembangkan persyaratan berdasarkan apa yang dia percaya pengguna dan stakeholder lainnya diinginkan dan dibutuhkan dari sistem. Meskipun digunakan untuk beberapa hal oleh sebagian besar analis, ini Teknik ini terutama digunakan hanya sebagai titik awal untuk persyaratan lain usaha elisitasi.

13 Grid Perbendaharaan, melibatkan meminta stakeholders untuk mengembangkan atribut dan menetapkan nilai untuk satu set entitas domain. Akibatnya sistem dimodelkan dalam bentuk matriks dengan mengelompokkan unsur-unsur dari sistem, merinci kasus kategori tersebut, dan menetapkan variabel dengan nilai-nilai yang sesuai untuk masing-masing. Tujuannya adalah untuk mengidentifikasi dan mewakili persamaan dan perbedaan antara entitas domain yang berbeda. Ini merupakan tingkat abstraksi asing bagi sebagian besar pengguna. Akibatnya, teknik ini biasanya digunakan ketika memunculkan persyaratan dari para ahli domain. Meskipun lebih rinci dari kartu penyortiran, dan yang lebih rendah tingkat laddering, grid perbendaharaan agak terbatas dalam kemampuan mereka untuk mengekspresikan karakteristik khusus dari persyaratan yang kompleks.

14 Card Sorting, membutuhkan stakeholders untuk mengurutkan serangkaian kartu yang berisi nama domain entitas dalam kelompok-kelompok sesuai dengan pemahaman mereka sendiri. Selain itu, stakeholder yang diperlukan untuk menjelaskan alasan untuk cara di mana kartu diurutkan. Hal ini penting untuk kartu efektif menyortir bahwa semua entitas termasuk dalam proses. Bila Menggunakan Laddering, stakeholders diminta serangkaian pendek mendorong pertanyaan, yang dikenal sebagai probe, dan diperlukan untuk mengatur jawaban yang dihasilkan menjadi struktur terorganisir. Asumsi utama ketika menggunakan laddering adalah bahwa pengetahuan akan menimbulkan sebenarnya dapat diatur secara hirarkis. Untuk teknik ini efektif, para stakeholders kepentingan harus dapat mengekspresikan pemahaman mereka dari domain dan kemudian mengaturnya dengan cara yang logis. Pengetahuan ini, yang sering ditampilkan menggunakan diagram pohon, ditinjau dan dimodifikasi secara dinamis sebagai lebih ditambahkan. Seperti kartu penyortiran, laddering terutama digunakan sebagai cara untuk memperjelas persyaratan dan mengkategorikan entitas domain.

15 Group work, seperti pertemuan kolaborasi adalah standar yang sangat umum dan sering teknik untuk elisitasi persyaratan. Grup sangat efektif karena mereka melibatkan dan melakukan stakeholder secara langsung dan meningkatkan kerjasama. Ini jenis sesi bisa sulit untuk mengatur karena jumlah stakeholder yang berbeda yang mungkin terlibat dalam proyek ini. Mengelola sesi ini secara efektif membutuhkan baik keahlian dan pengalaman untuk memastikan bahwa kepribadian individu melakukan tidak mendominasi diskusi. Faktor kunci dalam keberhasilan kerja kelompok adalah makeup peserta dan kohesi dalam kelompok. Stakeholder harus merasa nyaman dan percaya diri dalam berbicara secara terbuka dan jujur​​, dan karenanya kelompok bekerja kurang efektif dalam situasi yang sangat politis.

16 Brainstorming adalah sebuah proses di mana peserta dari pihak yang berkepentingan kelompok terlibat dalam diskusi informal untuk cepat menghasilkan ide sebanyak mungkin tanpa berfokus pada setiap orang tertentu. Hal ini penting ketika melakukan ini jenis kerja kelompok untuk menghindari menjelajahi atau mengkritisi ide-ide dengan sangat rinci. Hal ini tidak biasanya tujuan dimaksudkan sesi brainstorming untuk menyelesaikan masalah besar atau membuat keputusan penting. Teknik ini sering digunakan untuk mengembangkan misi awal Pernyataan untuk proyek dan target sistem. Salah satu keuntungan dalam menggunakan brainstorming adalah bahwa hal itu mempromosikan pemikiran bebas dan ekspresi, dan memungkinkan penemuan solusi baru dan inovatif untuk permasalahan yang ada.

17 Joint Application Development (JAD), melibatkan semua stakeholders yang tersedia menyelidiki melalui diskusi umum baik masalah yang harus diselesaikan, dan solusi yang tersedia untuk masalah tersebut. Dengan semua pihak diwakili, keputusan dapat dilakukan dengan cepat dan masalah diselesaikan dengan cepat. Perbedaan utama antara JAD dan brainstorming adalah bahwa biasanya tujuan utama dari sistem telah ditetapkan sebelum stakeholders berpartisipasi. Requirements workshop adalah istilah generik yang diberikan untuk sejumlah berbagai jenis pertemuan kelompok di mana penekanannya adalah pada pengembangan dan menemukan persyaratan untuk sistem perangkat lunak. Ada berbagai bentuk persyaratan pelatihan, termasuk lintas fungsional yang melibatkan berbagai stakeholder dari berbagai bidang usaha, Kooperatif Persyaratan Mengambil (CRC) [42] (di mana seperti JAD, ada kegiatan yang ditentukan dan pembangunan masyarakat terutama terlibat), dan Kreativitas [43] yang mendorong inovatif berpikir dan berekspresi.

18 Etnografi [4, 60], menjadi studi tentang pegawai di lingkungan mereka, melibatkan Analis secara aktif maupun pasif berpartisipasi dalam kegiatan normal dari pengguna atas jangka waktu sementara mengumpulkan informasi mengenai operasi yang dilakukan. Teknik ini sangat berguna ketika menangani faktor-faktor kontekstual seperti kegunaan, dan ketika menyelidiki pengaturan kerja kolaboratif di mana pemahaman interaksi antara pengguna yang berbeda dengan sistem yang terpenting. Dalam prakteknya, etnografi sangat efektif ketika kebutuhan untuk baru sistem adalah hasil dari permasalahan yang ada dengan proses dan prosedur, dan dalam mengidentifikasi pola sosial dan hubungan yang kompleks antara stakeholders.

19 Observasi merupakan salah satu yang lebih banyak digunakan teknik etnografi. Sesuai namanya menunjukkan analis mengamati pelaksanaan aktual dari proses yang ada dengan pengguna tanpa campur tangan langsung. Teknik ini sering digunakan bersama dengan lain seperti wawancara dan analisis tugas. Sebagai aturan umum teknik etnografi seperti observasi sangat mahal untuk melakukan dan memerlukan signifikan keterampilan dan upaya pada bagian dari analis untuk menafsirkan dan memahami tindakan yang dilakukan. Efektivitas observasi dan teknik etnografi lainnya dapat bervariasi karena pengguna memiliki kecenderungan untuk menyesuaikan cara mereka melakukan tugas-tugas ketika sadar sedang diawasi.

20 Protocol analysis adalah dimana para peserta melakukan suatu kegiatan atau tugas sementara berbicara melalui suara keras, menggambarkan tindakan yang dilakukan dan pikiran proses di belakang mereka. Teknik ini dapat memberikan analis dengan informasi spesifik dan pemikiran untuk proses sistem target harus mendukung [45]. Di kebanyakan kasus namun berbicara melalui operasi bukan cara normal melakukan tugas, dan sebagai hasilnya belum tentu mewakili proses yang benar-benar atau benar. Demikian juga langkah-langkah kecil yang dilakukan sering dan berulang-ulang sering diambil untuk diberikan oleh pengguna, dan tidak dapat dijelaskan dan kemudian dicatat sebagai bagian dari proses. Apprenticing melibatkan analis benar-benar belajar dan melakukan saat ini tugas-tugas di bawah instruksi dan pengawasan dari pengguna yang berpengalaman. Dalam hal ini Teknik analis diajarkan operasi dan proses bisnis dengan mengamati, mengajukan pertanyaan, dan secara fisik lakukan, bukannya informasi dari mereka, seperti kasus dengan analisis protokol. Mirip dengan Bermain Peran tapi lebih terlibat, magang sangat berguna di mana analis yang berpengalaman dengan domain, dan ketika pengguna mengalami kesulitan dalam menjelaskan tindakan mereka. Teknik kemunculan mengambil magang satu langkah lebih jauh di mana analis menjadi aktif terlibat dalam kegiatan kehidupan nyata bisnis.

21 Prototyping. Menyediakan stakeholders dengan prototipe sistem untuk mendukung penyelidikan solusi yang mungkin adalah cara yang efektif untuk mengumpulkan informasi rinci dan relevan umpan balik [60]. Adalah umum bahwa prototipe digunakan dalam hubungannya dengan teknik elisitasi lain seperti wawancara dan JAD. Prototip biasanya dikembangkan dengan menggunakan persyaratan awal atau contoh yang sudah ada sistem yang sama. Goal Based Approaches. Dasar pemikiran pemodelan tujuan (Bab 9) dan pendekatan berbasis tujuan adalah bahwa tujuan tingkat tinggi yang mewakili tujuan untuk sistem didekomposisi (misalnya biasanya menggunakan AND dan OR hubungan) dan diuraikan (misalnya dengan "Mengapa“ dan "Bagaimana" questioning) ke dalam sub tujuan dan kemudian lebih disempurnakan sedemikian rupa sehingga kebutuhan individu ditimbulkan. Hasil dari proses ini secara signifikan lebih rumit dan lengkap dibandingkan dengan metode tradisional sistem mewakili tujuan menggunakan diagram struktur pohon.

22 Skenario yang banyak digunakan dalam elisitasi persyaratan dan, seperti namanya, adalah narasi dan deskripsi spesifik proses saat ini dan masa depan termasuk tindakan dan interaksi antara pengguna dan sistem. Seperti kasus penggunaan, skenario tidak biasanya mempertimbangkan struktur internal dari sistem, dan memerlukan tambahan dan pendekatan interaktif untuk perkembangan mereka. Tentu, penting ketika menggunakan skenario untuk mengumpulkan semua pengecualin potensial untuk setiap langkah. Pendekatan Viewpoint bertujuan untuk memodelkan domain dari perspektif yang berbeda dalam rangka untuk mengembangkan deskripsi yang lengkap dan konsisten dari sistem target. Sebagai contoh, sistem dapat digambarkan dalam hal pengoperasiannya, implementasi dan antarmuka. Dengan cara yang sama sistem dapat dimodelkan dari sudut pandang pengguna yang berbeda atau dari posisi sistem terkait.

23 3.1 Comparison of Techniques and Approaches
Dua pertanyaan penting yang perlu ditangani selama persyaratan elisitasi adalah: (1) teknik dan pendekatan yang harus digunakan untuk persyaratan yang diberikan kegiatan elisitasi? dan (2) Manakah dari teknik dan pendekatan ini saling melengkapi atau dapat digunakan sebagai alternatif? Pada akhirnya, setiap situasi adalah unik dan jawaban atas pertanyaan-pertanyaan ini sangat tergantung pada konteks proyek dan sistem.

24 Table 2.1 Teknik dan pendekatan untuk kegiatan elisitasi

25 Teknik dan pendekatan untuk kegiatan elisitasi
Kita telah melihat bahwa teknik dan pendekatan yang berbeda memiliki berbeda dan relatif kekuatan dan kelemahan, dan mungkin lebih atau kurang cocok untuk jenis tertentu situasi dan lingkungan. Demikian juga, beberapa teknik dan pendekatan yang lebih tepat untuk kegiatan elisitasi tertentu dan jenis informasi yang perlu diperoleh selama kegiatan tersebut. Tabel 2.1 di bawah ini menyajikan dipilih kelompok inti dari teknik dan pendekatan yang paling cocok (ditandai dengan "X") untuk kegiatan elisitasi persyaratan khusus yang dijelaskan sebelumnya di Sect. 2.2 bab..

26 Table 2.2 Complementary and alternative techniques and approaches

27 Teknik Komplementer dan Alternatif dan Pendekatan
Dalam sebagian besar proyek lebih dari satu persyaratan teknik elisitasi dan pendekatan akan perlu digunakan, oleh karena itu berguna untuk memilih orang-orang teknik dan pendekatan yang saling melengkapi untuk mencapai hasil yang terbaik dari persyaratan Proses elisitasi. Dengan cara yang sama persyaratan alternatif elisitasi teknik dan pendekatan memungkinkan fleksibilitas yang lebih besar untuk proses, dan lebih pilihan bagi para analis dan stakeholder. Tabel 2.2 di bawah ini menyediakan beberapa petunjuk sehubungan dengan yang dari kelompok inti yang dipilih dari teknik dan pendekatan dapat digunakan dalam kerjasama (ditandai dengan "C"), dan yang dapat digunakan sebagai alternatif (ditandai dengan "A")..

28 Methodology Based Requirements Elicitation
Metodologi dan berbasis Model pendekatan (Bab 3) menyediakan cara untuk mewakili proses dan sistem yang menggunakan teknik analisis dengan ada atau masa depan niat menyelidiki karakteristik dan batasan-batasannya. Goal, skenario, dan berbasis agent teknik pemodelan seperti yang dijelaskan nanti dalam bab ini juga digunakan untuk elisitasi persyaratan di samping dua pendekatan yang dijelaskan di bawah. Terstruktur Analisis dan Desain (SAD) [19, 66] telah ada sejak pertengahan 1970-an dan telah banyak menulis tentang, dipromosikan, dan digunakan. Pendekatan ini sebagian besar berorientasi fungsi. Ini terdiri dari kumpulan teknik seperti Data Flow Diagram (DFD) yang detail dekomposisi fungsional dengan penekanan pada data masuk dan keluar dari sistem dan komponen terkait, dan Entity Relationship Diagram (ERD) yang memfasilitasi representasi entitas sistem , atribut mereka, dan hubungan satu sama lainnya. Teknik lain yang digunakan selama SAD elisitasi persyaratan meliputi Kamus Data dan Event Lists.

29 Pendekatan Object Oriented (OO), dan secara khusus Unified Modeling Language (UML) berisi beberapa teknik yang sering digunakan untuk elisitasi persyaratan dengan mendirikan notasi namun fleksibel dan format seperti Gunakan Kasus diagram, Gunakan deskripsi kasus, dan Class Diagram. Gunakan Kasus [12] pada dasarnya abstraksi dari skenario yang menggambarkan perilaku fungsional dari sistem, dan telah menjadi sangat diterima dalam penelitian dan praktek meskipun kekurangan mereka seperti impreciseness. Representasi diagram dan tabel membuat mereka mudah untuk memahami dan cukup untuk menampung beberapa informasi konteks tertentu fleksibel. Teknik-teknik ini sangat efektif dalam proyek-proyek di mana ada tingkat ketidakpastian yang tinggi atau ketika analis tidak ahli dalam tertentu domain.

30 Tool Support for Requirements Elicitation
Berbagai macam alat yang ada yang telah dikembangkan dan digunakan untuk mendukung elisitasi persyaratan. Ini berkisar dari kedalaman sampai dalam sehubungan dengan tingkat detail dan formalitas, dan dari umum untuk spesifik dalam tujuan dan operasi. Alat dapat mendukung teknik atau proses tertentu, dan dapat memiliki berbagai tingkat otomatisasi tugas dan bantuan.

31 Issues and Pitfalls of Requirements Elicitation
Ada sedikit keraguan di masa lalu tentang kompleksitas dan kesulitan persyaratan elisitasi dalam banyak situasi, tetapi pertanyaannya adalah: mengapa ini masih kasus hari ini? Sebagian alasannya adalah jumlah masalah yang mungkin perlu ditangani dan mengatasi selama proses elisitasi persyaratan. Umumnya istilah ada sejumlah besar konteks, manusia, ekonomi, dan pendidikan faktor yang mempengaruhi dan dapat menghambat persyaratan elisitasi efektif. Untuk demi penjelasan kami telah dikategorikan beberapa yang lebih sering terjadi masalah dan kesulitan dalam persyaratan elisitasi dihadapi baik oleh praktisi dan peneliti sesuai dengan aspek persyaratan elisitasi bahwa mereka yang paling berhubungan untuk. Ini telah dikumpulkan dari berbagai sumber dalam literatur [11, 28,49] serta dari pengalaman praktis dan observasi..

32 Process and Project Setiap proyek adalah unik dan tidak ada dua situasi elisitasi persyaratan yang pernah persis sama. Proses ini dapat dilakukan sebagai bagian dari pengembangan perangkat lunak Custome proyek, kegiatan seleksi COTS, definisi lini produk, dan sistem yang ada operasi pemeliharaan. Communication and Understanding Adalah umum bahwa para stakeholder mengalami kesulitan mengartikulasikan kebutuhan mereka. Di beberapa kasus ini mungkin akibat dari analis dan stakeholder tidak berbagi pemahaman umum dari konsep dan istilah, atau analis tidak familiar dengan masalah. Seringkali stakeholders akan memiliki kesulitan melihat cara-cara baru dalam melakukan sesuatu, atau tidak tahu konsekuensi dari persyaratan mereka dan dengan demikian mungkin tidak tahu apa yang layak atau realistis. Quality of Requirements Persyaratan menimbulkan mungkin tidak layak, hemat biaya, atau mudah untuk memvalidasi. Dalam kasus lain, mereka dapat kurang jelas, kurang spesifik, dan tidak terwakili dalam suatu cara seperti dapat diukur atau diuji. Selain itu, persyaratan dapat didefinisikan pada tingkat yang berbeda dan cukup detail.

33 Stakeholders Konflik antara stakeholder dan kebutuhan mereka yang umum dan hampir tidak bisa dihindari. Selain itu, stakeholders mungkin tidak mau kompromi atau memprioritaskan mereka persyaratan ketika konflik ini terjadi. Kadang-kadang stakeholders tidak benar-benar tahu apa yang mereka inginkan atau apa kebutuhan riil mereka, dan karena itu terbatas dalam mereka kemampuan untuk mendukung penyelidikan solusi yang mungkin. Demikian juga, stakeholder yang dapat menjadi negatif terhadap perubahan sistem baru dapat memperkenalkan dan karena itu memiliki berbagai tingkat komitmen dan kerjasama terhadap proyek. Analyst Analis mungkin tidak dilengkapi dengan keahlian implementasi yang memadai dan pengalaman untuk mempersiapkan dan melakukan persyaratan elisitasi yang efektif termasuk pemilihan teknik yang tepat dan identifikasi semua sumber persyaratan. Hal ini mungkin sebagai akibat dari kurangnya pendidikan dalam hal teori di balik teknik dan pendekatan, atau praktek menggunakan soft skill seperti mendengarkan, berkomunikasi, dan mempertanyakan.

34 Research Dapat dikatakan bahwa banyak teknik yang tersedia tidak cukup berguna atau praktis, dan transfer pengetahuan yang diperlukan untuk memperkenalkan metode ini dan pendekatan untuk industri terlalu sulit. Bahkan, jumlah proses rinci pedoman dengan dukungan alat yang tepat sangat terbatas, terutama berkenaan dengan Temukan teknik dan mengatasi faktor-faktor kontekstual dalam situasi yang berbeda. Practice Secara umum masih kurangnya kesadaran yang cukup, pemahaman, dan keahlian dalam persyaratan praktek elisitasi. Kesenjangan besar ada di antara persyaratan teori elisitasi dan praktek, serta pemula dan ahli analis. Itu Hasil yang adalah bahwa banyak yang masih membuat waktu kesalahan yang sama dan waktu lagi sehubungan dengan persyaratan elisitasi dan tidak mengakui permasalahan yang sebenarnya dan efek mereka berikutnya.

35 Trends and Challenges in Requirements Elicitation
Selama bertahun-tahun sejumlah tren penting dan tantangan telah muncul dalam bidang elisitasi persyaratan dalam penelitian dan praktek meskipun tidak selalu sama untuk keduanya. Untuk alasan itu kami telah membagi bagian berikut ke empat bidang, yaitu (1) tren dalam penelitian, (2) kecenderungan dalam praktek, (3) tantangan dalam penelitian, dan (4) tantangan dalam praktek. Kecenderungan ini dan tantangan menunjukkan bagaimana lapangan telah berkembang dan berubah, dan apa yang masih perlu dilakukan untuk lebih berkembang Proses ini dalam penelitian dan praktek.

36 7.1 Trends in Requirements Elicitation Research
Sebagai bidang RE mulai berkembang, peneliti dan praktisi mengidentifikasi bahwa elisitasi persyaratan untuk sistem berbasis software memiliki beberapa yang unik dan karakteristik yang rumit, dan karena itu perlu ditangani sebagai yang baru dan topik yang terpisah dari akuisisi pengetahuan tradisional .

37 7.2 Trends in Requirements Elicitation Practice
Sayangnya, RE tidak universal dipraktekkan sebagai fase yang berbeda dalam pengembangan perangkat lunak; Namun adopsi telah di peningkatan yang stabil khususnya atas dekade terakhir atau lebih. Banyak organisasi perangkat lunak telah menemukan bahwa di kepentingan terbaik mereka dan kepentingan pelanggan mereka untuk menginvestasikan waktu yang dibutuhkan dan usaha dalam fase ini dengan menerapkan tingkat yang cukup struktur dan ketelitian pada proses. Namun, untuk sebagian besar ini hanya berlaku untuk yang lebih besar dan lebih matang secara teknis organisasi.

38 7.3 Trends in Requirements Elicitation Practice
Salah satu tantangan utama bagi para peneliti tetap pengembangan cara untuk mengurangi kesenjangan yang terkenal [57] antara penelitian dan praktek dalam hal kesadaran, penerimaan, dan adopsi. Hal ini hanya dapat dicapai dengan membentuk hasil dalam berlatih dan membuat pendekatan yang lebih menarik, sehingga memberikan bukti dan motivasi bagi para praktisi untuk menggunakannya. Dalam rangka untuk membuat hal ini terjadi, para peneliti perlu mengurangi kompleksitas pendekatan dan keahlian yang dibutuhkan untuk mengintegrasikan mereka ke dalam praktek..

39 7.4 Challenges in Requirements Elicitation Practice
Perindustrian, seperti akademisi, juga harus mencari cara untuk mengurangi kesenjangan antara para ahli dan siswa dengan menginvestasikan waktu dan usaha dalam pendidikan pada apa yang saat ini tersedia, dan mengembangkan prosedur baru dan proses transfer pengetahuan dari analis senior untuk junior. Mengetahui kapan dan dimana teknik, pendekatan dan alat-alat untuk menggunakan dikombinasikan dengan pengetahuan tentang bagaimana, pada akhirnya akan meningkatkan kemungkinan kepuasan pelanggan dan keberhasilan proyek.

40 Future Directions in Requirements Elicitation Research
Meskipun keberhasilan dan kemajuan sampai saat ini, banyak topik penting tetap terbuka untuk investigasi sehubungan dengan memberikan teknik yang tepat, pendekatan, dan alat untuk elisitasi persyaratan, termasuk bantuan khusus bagi para analis pemula, dukungan kognitif melalui alat yang cerdas, dan metode yang melibatkan interaksi langsung dengan para pemangku kepentingan. Di bawah ini kami telah mendaftarkan beberapa persyaratan potensial daerah penelitian elisitasi tidak sepenuhnya diselesaikan sampai saat ini yang kami percaya layak perhatian yang memadai di tahun-tahun mendatang:

41 Mengurangi kesenjangan antara teori dan praktek, dan ahli dan pemula
Meningkatkan kesadaran dan pendidikan analis dan stakeholder dalam industri Mengembangkan pedoman untuk pemilihan teknik dan mengelola dampak dari faktor pada proses Investigasi cara mengumpulkan dan menggunakan kembali pengetahuan tentang persyaratan pendatangan Integrasi dan penggunaan teknologi baru termasuk web dan agen arsitektur berbasis ke generasi berikutnya alat pendukung Memproduksi dan studi kasus penerbitan dan laporan pengalaman industri tentang bagaimana elisitasi persyaratan kontribusi terhadap keberhasilan dan kegagalan proyek Menjelajahi bagaimana kegiatan elisitasi persyaratan berkaitan dengan baru dan berkembang bidang rekayasa perangkat lunak seperti sistem berbasis agent pengembangan cerdas metodologi, dan sistem web

42 Summary Proses elisitasi persyaratan, termasuk pemilihan teknik-teknik, pendekatan, atau alat untuk digunakan ketika memunculkan persyaratan, bergantung pada banyak faktor termasuk jenis sistem sedang dikembangkan, panggung dari proyek, dan domain aplikasi untuk hanya beberapa nama. Karena relatif kekuatan dan kelemahan dari metode yang tersedia dan jenis informasi mereka berikan, kenyataannya adalah bahwa di hampir semua proyek gabungan dari beberapa yang berbeda teknik akan diperlukan untuk mencapai hasil yang sukses.

43

44 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

45 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

46 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.

47 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 “.

48 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.

49 Tactical ManagTactical Managementement Operational Management
Persyaratan klasifikasi dalam tiga tingkatan Strategic Management Tactical ManagTactical Managementement 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 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 project level Project planning Feasibility study Recruiting people Project management Quality control Validation in terms of which requirements will go to the next release

50 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.

51 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 non-fungsional. 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.

52 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 dan 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.

53 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.

54 Praktek-praktek penting dari persyaratan manajemen adalah:.
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.

55 Requirements Dependencies and Impact Analysis:
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.

56 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.

57 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.

58 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 .

59 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. .

60 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.

61 Bab ini memiliki dua kontribusi utama:
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. .