Requirements

Engineering
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
langsung memulai (sebelum memiliki pemahaman yang jelas tentang apa
ingin
yang dibutuhkan)
– Hal akan menjadi jelas saat kita membangun perangkat lunak
– Stakeholder proyekakan dapat lebih memahami apa yang
butuhkan hanya setelahmereka
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 ini mengandung beberapa
terutama
argumen untuk proyek-proyek
kebenaran, kecil yang memakan waktu
kurang dari satu bulan untuk menyelesaikan
• Namun, sebagai perangkat lunak tumbuh dalam ukuran
dan kompleksitas, argumen ini mulai rusak dan dapa4t
menyebabkan proyek software gagal
 A Solution: Requirements
Engineering
• Dimulai kegiatan komunikasi dan sampai
selama modeling.berlanjut
kegiatan
• Membangun dari sistem Requirements ke dalam
jembatan
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 yang
dampak 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 memahami keinginan
untuk
menganalisa client,
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
memahami
untuk apa yang diinginkan klien,
menganalisis kebutuhan, menguji kelayakan,
bernegosiasi untuk yang masuk akal,
menetapkan solusi 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. Inception (Permulaan)
2. Elicitation
3. Elaboration (Perluasan)
4. Negotiation
5. Specification
6. Validation
7. 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
desain
untuk dan konstruksi dari perangkat lunak 9
 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/ yg berinteraksi dg
proses 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 aktifitas-
aktifitas sebelumnya.
 Spesifikasi menggambarkan fungsi dan kenerja
dari perangkat lunak dan batasan-batasan yang
ditentukan.
 Validatio
n
 Menguji kualitas dari spesifikasi untuk
memastikan kebutuhan dinyatakan
yang konsisten, lengkap dandapat
diterima/sepaham,
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 perubahan-
perubahan yang terjadi.
 Initiating The Requirements
Engineering Process
• Identifikasi stakeholders (pemangku kepentingan)
• Mengakui keberadaan beberapa sudut pandang stakeholder
• Bekerja kolaborasi antara stakeholder
• Pertanyaan bebaskonteks 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 solusi
dimana 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.
grafik, dll)
• Mekanisme definisi (papan tulis, yang
sandal 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
 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.
Analisis dan Desain
Berorientasi Objek

26
 Analisis Berorientasi Objek
1. Berpedoman pada Kebutuhan Pemakai Sistem
2. Mengidentifikasikan Skenario Pemakaian atau
Use-Case
3. Memilih Kelas-Kelas dan Objek-Objek
Menggunakan Kebutuhan Sebagai Penuntun
4. Mengidentifikasi Atribut dan Operasi untuk
Masing-masing Kelas Objek
5. Mengidentifikasi Struktur dan Hirarki Kelas-kelas
6. Membangun Model Keterhubungan Kelas dan
Objek
Desain Berorientasi Objek
• Use Case Diagram
• Activity Diagram
• Statechart Diagram
• Sequence Diagram
• Collaboration Diagram
• Class Diagram
• Component Diagram
• Deployment Diagram