Memahami kebutuhan

Tujuan Perkuliahan 2

Mahasiswa mengetahui pentingnyakebutuhan perangkat lunak

Mahasiswa mengetahui tujuan dilakukannya rekayasa kebutuhan perangkat lunak

Mahasiswa dapat melakukan tujuh tugas (task) dalam rekayasa kebutuhan melalui studi kasus yang diberikan.

Agenda

Kebutuhan Perangkat Lunak

Rekayasa Kebutuhan

Tujuan Rekayasa Kebutuhan

Tugas-tugas (Tasks) dalam rekayasa kebutuhan

Kebutuhan PL

Permasalahan memahami kebutuhanadalah tugas paling sulit bagi seorang insinyur perangkat lunak.

Seringkali pelanggan tidak dapat mendefinisikan dengan jelas apa yang mereka butuhkan

Jikalau pelanggan dapat mendefinisikan kebutuhannya, maka seringkali kebutuhan ini selalu berubah-ubah sepanjang pengembangan perangkat lunak

Rekayasa Kebutuhan

5

Spektrum yang luas dari tugas-tugas dan teknik yang digunakan untuk memahami kebutuhan disebut rekayasa kebutuhan (requirementengineering).

Dari sudut pandang prosesperangkat lunak, rekayasa kebutuhan adalah aksi rekayasa perangkat lunak yang utama yang dilakukan selama aktivitas komunikasi dan berlanjut hingga ke aktivitas pemodelan (modelling).

Rekayasa kebutuhan disesuaikandengan kebutuhan proses,proyek, produk dan people (orang) yang melakukan pekerjaan.

Tujuan Rekayasa Kebutuhan

6

Rekayasa Kebutuhan menyediakanmekanisme untuk 

1. Memahami apa yang diinginkan pelanggan

2. Menganalisa kebutuhan 

3. Menilai kelayakan

4. Merundingkan solusi yang cocok 

5. Menetapkan solusi yang tepat 

6. Memvalidasi spesifikasi

7. Mengelola kebutuhan untuk ditransformasikan menjadi operasi sistem (fitur2 perangkat lunak)

Tugas2 dalam RekayasaKebutuhan

Ada 7 tugas dalam rekayasa kebutuhan yaitu: 

1. Permulaan (Inception)

2. Perolehan(Elicitation)

3. Penguraian (Elaboration) 

4. Negosiasi (Negotiation)

5. Spesifikasi (Specification)

 6. Validasi (Validation)

7. Manajemen (Management)

1.Permulaan (Inception)

Permulaan—tanya beberapa pertanyaan yang menjelaskan

Pemahaman dasar dari masalah Orang yang membutuhkan solusi Keadaan dari solusi yang diinginkan

Efektivitas komunikasi dan kolaborasi awal antara konsumen dengan developer

2.Perolehan (Elicitation)

Perolehan—memperoleh kebutuhan dari semua stakeholder

Jangkauan (Scope) masalah: kejelasan batas sistem

Memahami masalah:

Fakta::Pelanggan tidak lengkap dalam mendefinisikan kebutuhan. Perlu komunikasi yang intens antara pengembang dan pelanggan agar tidak terjadi kebutuhan yang ambigu (tidak jelas) atau tidak bisa diuji.

Perubahan masalah: Kebutuhan berubah setiap saat

Memperoleh Kebutuhan

Pertemuan diadakan dan dihadiri baik oleh software engineer maupun konsumen Aturan persiapan dan partisipasi dibuat Agenda ditawarkan Seorang fasilitator (bisa konsumen, developer atau orang luar) mengendalikan pertemuan

 Mekanisme definisi digunakan (bisa berupa kertas kerja, grafik, bulletin 

board elektronik, forum virtual dsb

Tujuannya adalah Menemukan permasalahan

Mengajukan elemen-elemen solusi 

Menentukan sekelompok kebutuhan solusi awal

3.Penguraian (Elaboration)

Penguraian—membuat model analisis yang mampu melakukan identifikasi kebutuhan data, fungsi dan perilaku

Informasi yang sudah didapatkan pada saat inception dan elicitation akan diperluas selama elaboration. Tugasnya fokus pada penghalusan model kebutuhan yang mengidentifikasi berbagai aspek seperti fungsi-fungsi perangkat lunak, tingkah laku dan informasi.

Membuat skenario pemakai yang menggambarkan bagaimana pemakai akhir berinteraksi dengan sistem.

Dari elaboration akan ditemukanentitas, atribut, obyek,class, relasi antar class.

4.Negosiasi (Negotiation)

Negosiasi—menyepakati sistem penyajian yang realistis bagi konsumen dan developer

Dimungkinkan antar stakeholder ada konflik kebutuhan, diperlukanperdamaian untuk mengatasi konflik ini dengan melakukan negosiasi dimana:

Pelanggan, pengguna dan stakeholder yang lain duduk bersama untuk mendiskusikan konflik tersebut dan melakukan skala prioritas dari kebutuhan-kebutuhan yang ada dengan emperkirakan biaya dan resiko.

Dengan mengurangi konflik internal, jumlah kebutuhan bisa dikurangi, dikombinasikan dan atau dimodifikasi agar setiap pihak tercapai beberapa ukuran yang memuaskan.

Kebutuhan Negosiasi

Mengenali stakeholder kunci

Orang-orang ini yang akan dilibatkan negosiasi Menentukan “kondisi menang” setiap stakeholder

Kondisi kemenangan tidak selalujelas Negosiasi

Bekerja menuju sekumpulan kebutuhan yang merupakan win-win solution

5.Spesifikasi (Specification)

Spesifikasi—

salah satu dari berikut ini : 

Dokumen tertulisSekelompok model Matematika formal Sekumpulan skenario user (use-cases) Prototipe

Beberapa model (dalam bentuk grafis) keluaran dari perincian: Pendekatan terstruktur: ERD,DFD,STD

Pendekatan berorientasi obyek: Usecase Diagram dan Class Diagram

Membangun Model Analisis

Elemen-elemen model analisis Elemen-elemen berbasis skenario

Fungsional—memproses narasi untuk fungsi PL

Use-case—gambaran interaksi antaraaktor dan sistem Elemen-elemen berbasis Class

Dipengaruhi oleh skenario

Elemen-elemen Perilaku/Behavioral State diagram

Elemen-elemen berorientasi aliran Data flow diagram

6.Validasi (Validation)

 Validasi—memeriksa mekanisme yang memuat Kesalahan isi atau interpretasi

Area dimana klarifikasi dibutuhkan  

Informasi yang hilang

inkonsistensi (masalah utama ketika produk atau sistem besar direkayasa)

Kebutuhan yang konflik atau tidak realistis.

Salah satu mekanisme dengan technical review. Tim review yang mencakup insinyur perangkat lunak, pelanggan, pengguna dan stakeholder lain melakukan validasi dengan memeriksa spesifikasi untuk melihat kesalahan dari sisi isi atau interpretasi, kehilangan informasi atau tidak konsistenan

Daftar Pertanyaan padaTask Validasi (I)

1.      Apakah setiap kebutuhan konsisten dengan tujuan keseluruhan sistem/produk?

2.      Apakah semua kebutuhan telah dispesifikasikan pada tingkat abstraksi yang tepat ? Apakahbeberapa kebutuhan pada tingkatakan detail teknis tidak tepat pada level ini ?

3.      Apakah kebutuhan benar-benar diperlukan ataukah dia hanya merupakan fitur tambahan yang tidak esensial bagi tujuan sistem ?

4.      Apakah setiap kebutuhan terbatasi dengan baik dan tidak ambigu ?

5.      Apakah setiap kebutuhan mempunyai atribut ? Apakah sebuah sumber tercatat untuk setiap kebutuhan ?

6.      Apakah setiap kebutuhan konflik dengan kebutuhan lain ?

Daftar Pertanyaan padaTask Validasi (II)

18   7. Apakah setiap kebutuhan dapatditerima dalam lingkungan teknik yang menjadi rumah bagi sistem/produk?

8. Apakah setiap kebutuhan dapat diuji, setelah diimplementasi ?

9. Apakah model kebutuhan mencerminkan informasi, fungsi, dan

perilaku sistem yang dibangun dengan baik.

10. Apakah model kebutuhan telah dipartisi sedemikian sehingga menampilkan secara progresif informasi yang lebih detail tentang sistem ?

11.Apakah pola kebutuhan telah digunakan untuk mempermudan model kebutuhan ? Apakah semua pola telah divalidasi? Apakah pola konsisten dengan kebutuhan konsumen ?

7.Manajemen (Management)

19   Kebutuhan (requirement) untuk sistem bebasis perangkat lunak dapat berubah dan keinginan untuk merubah kebutuhan berlangsung selama siklus hidup sistem.

Requirement management adalah sekumpulan aktivitas yang membantu tim proyek untuk mengidentifikasi, mengontrol dan menelusuri kebutuhan danperubahan kebutuhan sebagai hasil dari kemajuan proyek. Beberapa aktivitasnya adalah Software ConfigurationManagement (SCM)

Penilaian Kualitas

20   Penyebaran fungsi menemukan “nilai” (dalam persepsi konsumen) dalam setiap fungsi yang diperlukan sistem

Penyebaran Informasi menentukan event dan objek data

Penyebaran Tugas memeriksa perilaku sistem

Analisis Nilai menentukan prioritas relatif dari kebutuhan

Mendapatkan Produk Kerja 21

Sebuah pernyataan kebutuhan dan kemungkinan dikerjakan.

Pernyataan terbatas tentang lingkup sistem atau produk.

Daftar konsumen, pengguna dan stakeholder lain yang berpartisipasi dalam pengumpulan kebutuhan

Deskripsi lingkungan teknis sistem.

Daftar kebutuhan (disarankan dikelompokkan berdasar fungsi) dan batasan domain yang diterapkan pada masing-masing kebutuhan.

Sekelompok skenario penggunaanyang menyediakan wawasan pada penggunaan sistem atau produk dalam kondisi operasi yang berbeda.

Beberapa prototype yang dikembangkan untuk definisi kebutuhan yang lebih baik.

Use Case

Sekelompok skenario pengguna yang menggambarkan alur penggunaan sistem

Setiap skenario digambarkan dari sudut pandang “aktor”, seseorang atau piranti yang berinteraksi dengan PL dalam berbagai cara

Setiap skenario menjawab pertanyaan-pertanyaan berikut ::

Siapa aktor primer dan sekunder ?

Apa tujuan aktor ?

Prekondisi apa yang harus ada sebelum cerita dimulai?

 Apa tugas atau fungsi utama yang dilakukan oleh aktor ?

Ekstensi apa yang harus diperhatikan ketika cerita digambarkan? Variasi apa yang mungkin pada interaksi aktor?

Sistem informasi apa yang dibutuhkan, diproduksi atau diubah aktor ?

Apakah aktor harus menginformasikan kepada sistem tentang perubahan di lingkungan luar ?

Informasi apa yang diharapkan aktor dari sistem ?

Apakah aktor berharap diinformasikan tentang perubahan yang tidak terduga ?

DaftarPustaka 

Pressman, R. S., Software Engineering: A Practitioner's Approach, 7th Edition, McGraw-Hill, 2008