Requirements Engineering. Materi 5

Requirements Engineering Materi 5

Requirements Engineering • Problems with requirements practices • Requirements engineering tasks (Inception, Elicitation, Elaboration, Negotiation, Specification, Validation, Requirements management) • Initiating the Requirements Engineering Process • Collaborative Requirement Gathering • Developing Use Case

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

The Problems with our Requirements Practices • • • •

Kesulitan memahami kebutuhan dari pelanggan Persyaratan sering direkam dengan tidak teratur Menghabiskan terlalu banyak waktu memverifikasi data Membolehkan perubahan untuk pengendalian, dari pada membangun mekanisme untuk mengontrol perubahan • Yang paling penting, gagal untuk membangun dasar yang kuat untuk sistem atau membangun perangkat lunak yang diinginkan pengguna

(more on next slide) 3

The Problems with our Requirements Practices (continued) • Banyak pengembang software berpendapat bahwa – Membangun perangkat lunak begitu menarik bahwa sehingga ingin langsung memulai (sebelum memiliki pemahaman yang jelas tentang apa yang dibutuhkan) – Hal akan menjadi jelas saat kita membangun perangkat lunak – Stakeholder proyek akan dapat lebih memahami apa yang mereka butuhkan hanya setelah memeriksa iterasi awal dari perangkat lunak – Banyak hal yang berubah begitu cepatnya bahwa kebutuhan rekayasa adalah buang-buang waktu – Intinya adalah memproduksi program kerja dan bahwa semua yang lain adalah sekunder

• Semua argumen ini mengandung beberapa kebenaran, terutama untuk proyek-proyek kecil yang memakan waktu kurang dari satu bulan untuk menyelesaikan • Namun, sebagai perangkat lunak tumbuh dalam ukuran dan kompleksitas, argumen ini mulai rusak dan dapat 4 menyebabkan proyek software gagal

A Solution: Requirements Engineering • Dimulai selama kegiatan komunikasi dan berlanjut sampai kegiatan modeling. • Membangun jembatan dari sistem Requirements ke dalam desain software dan konstruksi • Memungkinkan kebutuhan engineering untuk memeriksa – – – –

Konteks kerja perangkat lunak yang akan dilakukan Kebutuhan spesifik bahwa desain dan konstruksi harus mengatasi Prioritas yang memandu urutan pekerjaan yang harus diselesaikan Informasi, fungsi, dan perilaku yang akan memiliki dampak yang mendalam pada desain yang dihasilkan

5

Why is Getting Good Requirements Hard?  Stakeholder tidak tahu apa yang mereka inginkan.  Stakeholder mengungkapkan persyaratan dalam istilah mereka sendiri.  Stakeholder yang berbeda mungkin memiliki persyaratan yang saling bertentangan.  Faktor Organisasi dan politik dapat mempengaruhi persyaratan sistem.  Persyaratan berubah selama proses RE. Stakeholder baru mungkin muncul dan perubahan lingkungan bisnis.

Requirements Engineering Tasks Requirements Engineering menyediakan mekanisme untuk memahami keinginan client, menganalisa kebutuhan, menilai fisibilitas solusi, melakukan negosiasi pemilihan solusi yang tepat, menghilangkan ambigu, memvalidasi solusi, “mengelola” kebutuhan agar dapat diubah ke bentuk sistem operasional.

Requirements Engineering Tasks (cont.)

Rekayasa kebutuhan membangun jembatan menuju desain dan pembangunan perangkat lunak dengan menyediakan mekanisme yang tepat untuk memahami apa yang diinginkan klien, menganalisis kebutuhan, menguji kelayakan, bernegosiasi untuk solusi yang masuk akal, menetapkan solusi yang dapat dipahami dua belah pihak, uji spesifikasi dan mengelola kebutuhan yang akan diwujudkan ke sistem operasional.

Requirements Engineering Tasks (cont.)

 Seven distinct tasks 1. 2. 3. 4. 5. 6. 7.

Inception (Permulaan) Elicitation Elaboration (Perluasan) Negotiation Specification Validation Management

 Beberapa tugas ini dapat terjadi secara paralel dan semua disesuaikan dengan kebutuhan proyek  Semua berusaha untuk menentukan apa yang pelanggan inginkan  Semua berfungsi untuk membangun dasar yang kuat untuk 9 desain dan konstruksi dari perangkat lunak

Inception  Inception atau permulaan, merupakan awal dari terjadinya pembicaraan tentang kebutuhan akan software. Permulaan ini dapat terjadi karena dari pembicaraan biasa,kebutuhan bisnis yang dirasakan, adanya pasar potensial, atau munculnya layanan potensial yang dapat dilakukan oleh software.  Mengidentifikasi stakeholder    

Siapa yg menginginkan sistem/program? Siapa yg menggunakan solusi? Apa keuntungan ekonomis dari suatu solusi yang sukses ? Apakah dibutuhkan sumber yang lain?

Inception Memahami masalah  Bagaimana karakteristik solusi yg baik ?  Masalah apa yang dipecahkan oleh solusi tsb?  Bagaimana kondisi business environment dimana solusi tersebut diimplementasikan?  Apakah ada masalah dan batasan tertentu yag mempengaruhi pendekatan solusi ?

Elicitation Klien mengungkapkan kebutuhan. Proses ini tidak mudah karena: batasan sistem sering tidak jelas, klien tidak cukup paham apa yang dibutuhkan dan kebutuhan sering berubah.  Problems of scope  Problems of understanding  Problems of volatility

Elicitation Product Request 1. Membuat daftar semua objek yang merupakan bagian dari sistem. 2. Membuat daftar semua obyek yg dihasilkan oleh sistem 3. Membuat daftar semua obyek yg digunakan oleh sistem. 4. Membuat daftar fungsi/piranti/proses yg berinteraksi dg obyek2 tersebut. 5. Membuat batasan dan kriteria performa.

Elaboration  Penjelasan. Apa yang diungkapkan pada proses permulaan dan pengungkapan kebutuhan, dijelaskan panjang lebar.  Fokus pada pemodelan fungsi, fitur dan batasan dari perangkat lunak.  Dalam kasus OOP, maka class, atribute dan hubungan antar class diidentifikasi pada aktifitas ini.

Negotiation  Negosiasi bukanlah suatu kompetisi  Buat suatu strategi (Apa yg kita inginkan? Apa yg client inginkan ?)  Mendengarkan secara aktif.  Fokus pada apa yg menjadi keinginan client.  Jangan anggap ‘personal’  Jadilah kreatif  Komitmen terhadap keputusan yg diambil. Gunakan priority points !!!

Negotiation

Examines the specification to ensure that all software requirements have been stated unambiguosly; that inconsistencies, omissions and errors have been detected and corrected “Memeriksa spesifikasi untuk memastikan bahwa semua persyaratan perangkat lunak telah dinyatakan jelas bahwa inkonsistensi, kelalaian dan kesalahan telah dideteksi dan dikoreksi ”

Specification  Spesifikasi dapat berupa dokumen, model grafik, model matematika, skenario atau prototype yang merupakan produk akhir dari rekayasa kebutuhan.  Apa yang disajikan sebagai spesifikasi merupakan hasil identifikasi kebutuhan melalui aktifitasaktifitas sebelumnya.  Spesifikasi menggambarkan fungsi dan kenerja dari perangkat lunak dan batasan-batasan yang ditentukan.

Validation  Menguji kualitas dari spesifikasi untuk memastikan kebutuhan yang dinyatakan dapat diterima/sepaham, konsisten, lengkap dan bebas kesalahan.  Mekanisme yang dapat dilakukan adalah formal technical review atau pertemuan evaluasi teknis.

Management  mengelola kebutuhan dengan identifikasi, kontrol dan mengikuti perkembangan kebutuhan software yang dikerjakan selama proyek dan perubahanperubahan yang terjadi.

Initiating The Requirements Engineering Process • Identifikasi stakeholders (pemangku kepentingan) • Mengakui keberadaan beberapa sudut pandang stakeholder

• Bekerja kolaborasi antara stakeholder • Pertanyaan bebas konteks ini fokus pada pelanggan, stakeholder, tujuan keseluruhan, dan manfaat dari sistem – Siapa yang meminta untuk bekerja? – Siapa yang akan menggunakan solusi? – Apa yang akan menjadi keuntungan ekonomi dari solusi yang sukses? – Apakah ada sumber lain untuk solusi yang dibutuhkan?

Initiating The Requirements Engineering Process • Set pertanyaan berikutnya memungkinkan pengembang untuk lebih memahami masalah dan persepsi pelanggan berdasarkan solusi – Bagaimana ciri output yang bagus untuk solusi yang sukses? – Apa masalah dari solusi ini? – Dapatkah Anda menggambarkan lingkungan bisnis dimana solusi digunakan? – Adakah kendala yang mempengaruhi dalam pendekatan solusi?

• Set pertanyaan terakhir berfokus pada efektivitas komunikasi – Apakah Anda orang terbaik untuk memberikan jawaban “resmi” atas pertanyaan ini? – Apakah pertanyaan saya relevan dengan masalah Anda? – Apakah saya terlalu banyak bertanya? – Dapatkah orang lain memberikan informasi tambahan? – Haruskah saya meminta Anda menjawab apapun?

How would you resolve this? 22

Collaborative Requirement Gathering • Rapat yang dihadiri oleh seluruh pemangku kepentingan. • Aturan ditetapkan untuk persiapan dan partisipasi. • Agenda harus cukup untuk menutup semua poin penting formal, tapi cukup informal untuk mendorong aliran ide. • Seorang fasilitator mengendalikan pertemuan. • Mekanisme definisi (papan tulis, sandal grafik, dll) yang digunakan.. • Dalam pertemuan tersebut: – – – – –

Masalahnya diidentifikasi. Elemen dari solusi yang diusulkan. Pendekatan yang berbeda dinegosiasikan. Seragkaian dari persyaratan solusi diperoleh. Atmosfer kolaboratif dan non-membahayakan..

Collaborative requirement gathering • Dalam pertemuan awal, mendistribusikan "permintaan produk" (didefinisikan oleh stakeholder) untuk semua peserta. • Berdasarkan permintaan produk, masing-masing peserta diminta untuk membuat – Daftar objek (internal atau benda sistem eksternal) – Daftar (Proses atau fungsi) – Daftar kendala (biaya, ukuran, aturan bisnis) dan – kriteria kinerja (kecepatan, ketepatan) yang dikembangkan. • Mengumpulkan daftar dari semua orang dan digabungkan. • Daftar gabungan meniadakan entri berlebihan, menambahkan ide-ide baru, tetapi tidak menghapus. • Tujuannya adalah untuk mengembangkan daftar konsensus di setiap area topik (objects, services, constraints and performance).

Collaborative Requirement Gathering • Berdasarkan daftar, tim dibagi menjadi lebih kecil sub-tim: setiap bekerja untuk mengembangkan mini-spesifikasi untuk satu atau lebih masukan pada setiap daftar.

• Setiap sub-tim hadiah yang mini-spesifikasi untuk semua peserta diskusi. Selain itu, penghapusan dan elaborasi lebih lanjut dibuat. • Sekarang masing-masing tim membuat daftar kriteria validasi untuk produk dan hadir untuk tim. • Akhirnya, satu atau lebih peserta ditugaskan tugas menulis draft spesifikasi lengkap.

Use Cases 26

Developing Use Case • Use Case menggambarkan interaksi antara pengguna dan sistem. • Berfokus pada apa sistem dilakukan untuk pengguna. • Menggambarkan totalitas sistem dan perilaku sistem. • Includes: – – – – –

Actors List Use Case Packages Use Case Diagrams Use Case Text Use Case Views : 27

Activities Involved in Use Cases • Find Actors – – – – –

Project Manager Architect End-Users Customers Development Team

• Find Use Cases • Describe the use case 28

Steps for Developing Use case Diagram 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

Use Abstract Idea Define use case actors Define use case actors goals Identify reuse opportunity for use case Create use case inedx Identify the key components Name and briefly describe the use case Create use case basic view Create use case alternate flows Produre the use case decument Generate a use case model diagram 29

Sample Use Case Diagram

30

Terima Kasih

31