Rekaya Kebutuhan Perangkat Lunak

1. 9/28/2016
1
Rekayasa Perangkat Lunak
Rekayasa Kebutuhan
Oleh : Triastana Anang, ST, MT
Jurusan Teknologi Informasi
Politeknik Negeri Malang
Tujuan Pembelajaran
• Memahami konsep kebutuhan user dan kebutuhan
sistem dan bagaimana kebutuhan ini dapat
dituliskan dalam berbagai macam cara.
• Memahami perbedaan kebutuhan fungsional dan
non-fungsional
• Memahami bagaimana kebutuhan disusun/ diatur
dalam dokumen kebutuhan
• Memahami prinsip dasar dan keterkaitan antar
aktivitas rekayasa kebutuhan (elisitasi, analisis dan
validasi)
• Memahami perlunya pengelolaan kebutuhan dan
keterkaitannya dengan aktivitas rekayasa lainnya.

2. 9/28/2016
2
Agenda
Kebutuhan functional dan non-functional
Dokumen kebutuhan perangkat lunak
Proses rekayasa kebutuhan
Spesifikasi kebutuhan
Analisis dan elisitasi kebutuhan
Validasi kebutuhan
Pengelolaan kebutuhan
Alasan Kegagalan dalam Pengembangan Software
incomplete requirements 13.1%
lack of user involvement 12.4%
lack of resources 10.6%
unrealistic expectations 9.9%
lack of executive support 9.3%
changing requirements and specifications8.7%
lack of planning 8.1%
system no longer needed 7.5%
Kenapa Rekayasa Kebutuhan dibutuhkan
50% berhubungan dengan requirement/kebutuhan
> 50%

3. 9/28/2016
3
Siapa saja yang terlibat Rekayasa PL
Use-Case
Specifier
Use-Case
Specification
responsible
for
User-Interface
Designer
User-interface
Specification &
Prototyping
responsible
for
Architect
Architecture
Description
responsible
for
Domain
Analyst
responsible
for
Domain
Specification
System
Analyst
Domain
Model
Actors GlossaryUse-Case
Model
responsible for
Kebutuhan Functional dan Non
Functional

4. 9/28/2016
4
Kebutuhan Fungsional dan Non-Fungsional
Kebutuhan fungsional
• Pernyataan dari layanan apa yang harus disediakan
oleh sistem.
• Bagaimana sistem harus merespon input
• Bagaimana perilaku sistem terhadap situasi tertentu.
Kebutuhan non-fungsional
• Merupakan batasan dari layanan atau fungsi yang
ditawarkan oleh sistem. (waktu, proses
pengembangan, atau standard).
• Umumnya batasan ini dilihat dari perspektif sistem
keseluruhan.
Tipe Kebutuhan non fungsional
Sumber: Sommerville, 2009

5. 9/28/2016
5
Kebutuhan non fungsional
• Terkadang pernyataan kebutuhan non-fungsional perlu
didetailkan dalam bentuk kuantitatif.
• Nantinya akan digunakan pada tahap pengujian (testing).
Kebutuhan
• Kebutuhan user adalah statement, baik dalam
bentuk tertulis maupun diagram, tentang layanan
dari sistem yang diharapkan dan batasan
operasionalnya.
• Kebutuhan sistem adalah pendetailan dari
fungsional, layanan dan batasan operasional dari
sistem.

6. 9/28/2016
6
Notasi Spesifikasi Kebutuhan
Macam-macam notasi untuk menuliskan
spesifikasi kebutuhan:
Bahasa kalimat natural
Bahasa kalimat terstruktur
Notasi grafis (ex: UML)

7. 9/28/2016
7
Notasi Grafis (UML)
• Use Case Diagram
13
Dokumen Kebutuhan PL

8. 9/28/2016
8
Proses rekayasa kebutuhan

9. 9/28/2016
9
Proses Rekayasa Kebutuhan
• Proses rekayasa kebutuhan meliputi 4 aktivitas utama:
– Feasibility study: melakukan penilaian manfaat sistem
bagi bisnis.
– Elisitasi dan analisis: mengidentifikasi dan
mengeksplorasi kebutuhan.
– Spesifikasi: menterjemahkan kebutuhan menjadi
kebutuhan detail yang standard.
– Validasi: melakukan evaluasi untuk memastikan
kebutuhan yang dituliskan benar-benar
menggambarkan apa yang diekspektasikan oleh user
terhadap sistem yang akan dikembangkan.
17
Analisis dan Elisitasi Kebutuhan
• Pada fase ini, perekayasa PL bekerja sama dengan customer untuk
memahami domain sistem, layanan apa yang harus dimiliki dan diberikan,
menentukan ukuran kinerja sistem, batasan sistem dan lain-lain.
18
1. Identifikasi
kebutuhan
2. Klasifikasi
dan penataan
kebutuhan
3. Prioritasi
dan negosiasi
kebutuhan
4. Spesifikasi
kebutuhan
1. Merupakan proses interaksi
stakeholder untuk mengidentifikasi
kebutuhan masing-masing.
2. Aktivitas ini meliputi: mengidentifikasi
keterkaitan dan pengelompokan
kebutuhan.
3. Aktivitas ini meliputi prioritasi
kebutuhan, dan mencari solusi konflik
antar stakeholder.
4. Menghasilkan dokumen kebutuhan
secara formal atau informal.

10. 9/28/2016
10
Tantangan pada Proses Elisitasi dan
Pemahaman Kebutuhan
• Sering kali stakeholder tidak mengetahui apa yang
diinginkannya.
• Ekspektasi user terkadang tidak realistis karena
mereka belum memahami kapasitas dan batasan TI.
• Stakeholder yang berbeda memiliki kebutuhan yang
berbeda dan disampaikan dengan berbagai macam
cara.
• Lingkungan bisnis dan ekonomi dari organisasi/
industri bisa saja dinamis. Memungkinkan perubahan
kebutuhan tertentu beserta dengan prioritasnya.
19
Teknik Elisitasi Kebutuhan
• Interview: melakukan wawancara untuk mengidentifikasi kebutuhan dari seluruh
stakeholder terkait. Terdapat dua pendekatan pertanyaan dalam wawancara:
– Tertutup: topik pertanyaan yang telah ditentukan secara lebih spesifik.
Contoh:
• Informasi apa saja yang harus ada dilaporan bulanan ?
• Apakah sistem hanya dapat diakses pada jam kerja saja ?
– Terbuka: topik pertanyaan tidak ditentukan secara spesifik.
• Menurut pendapat Anda ...
• Skenario: user menjelaskan kebutuhan berdasarkan aktivitas yang dihadapi sehari-
hari tanpa harus banyak memikirkan sistem harus memiliki fungsionalitas apa saja.
Umumnya skenario yang baik berisi informasi:
– Penjelasan tentang apa yang diharapkan user terhadap sistem pada proses/
aktivitas bisnis tertentu.
– Penjelasan tentang alur proses/ aktivitas bisnis.
– Penjelasan tentang aturan bisnis (kondisi bisnis yang harus diimplementasikan
ke dalam sistem termasuk mekanisme kontrolnya).
– Informasi terkait aktivitas/ proses bisnis lain yang mungkin dijalankan secara
paralel dan masih saling terkait dengan skenario bisnis yang akan dijelaskan.
– Kondisi akhir dari komponen bisnis dan sistem ketika skenario telah selesai.
• Use case: salah satu model UML untuk menotasikan interaksi antara user dengan
sistem.
20

11. 9/28/2016
11
Validasi Kebutuhan
• Adalah proses untuk mengevaluasi dan memastikan
bahwa kebutuhan yang diidentifikasi telah sesuai
dengan gambaran sistem yang diharapkan oleh user.
• Beberapa kriteria yang digunakan pada aktivitas
validasi kebutuhan:
– Validitas: Perlu dipastikan kembali kebutuhan
mana yang benar-benar akan diterapkan di dalam
sistem yang akan dikembangkan.
– Konsistensi: memastikan kebutuhan satu dengan
yang lain tidak saling bertentangan.
21
Validasi Kebutuhan (lanjut..)
• Kelengkapan: kebutuhan (fungsional dan non fungsional)
sistem seharusnya memiliki informasi yang lengkap
meliputi spesifikasi user, spesifikasi sistem serta batasan
yang jelas (yang termasuk dan yang tidak termasuk
fungsionalitas sistem).
• Kerealistisan: memastikan seluruh spesifikasi sistem yang
diturunkan dari seluruh kebutuhan benar-benar dapat
diimplementasikan dan dapat digunakan nantinya
setelah aplikasi dikembangkan.
• Dapat diverifikasi: seluruh kebutuhan dan spesifikasi
sistem tertulis dan memiliki ukuran keberhasilannya
masing-masing
22

12. 9/28/2016
12
Teknik Validasi Kebutuhan
• Evaluasi kebutuhan:
– Kebutuhan dianalisis secara sistematis oleh sebuah tim
penilai untuk memastikan kriteria validasi terpenuhi.
• Prototyping:
– Pendekatan identifikasi dan validasi dengan
mengembangkan purwa rupa dari sistem yang
didemonstrasikan ke user.
• Test-case generation:
– Melakukan pengujian terhadap permasalahan kebutuhan
berdasarkan penjelasan user untuk mencari detail dari
penyebab/ akar permasalahan dan memastikan solusi yang
disusun dan diterapkan pada sistem benar-benar dapat
menyelesaikan permasalahan yang ada.
23
Pengelolaan Kebutuhan

13. 9/28/2016
13
Pengelolaan Kebutuhan
• Kebutuhan pada rekayasa perangkat lunak skala besar selalu berubah. Hal
ini dikarenakan adanya permasalahan yang tidak dapat diidentifikasi
dengan jelas. Dampaknya adalah spesifikasi sistem menjadi tidak lengkap
sehingga aplikasi yang dikembangkan belum tentu menjawab
permasalahan yang ada.
25
Sumber: Sommerville, 2009
Proses Evolusi Kebutuhan
Pengelolaan Kebutuhan (lanjut..)
• Selama proses rekayasa perangkat lunak, pemahaman tim
perekayasa dan juga customer terhadap permasalahan akan
berubah seiring waktu. Hal ini berdampak kepada perubahan
kebutuhan sistem yang terus berubah mengikuti perubahan
perspektif permasalahan.
• Saat sistem telah di-install dan mulai digunakan, pada
akhirnya kebutuhan baru akan muncul.
• Pengelolaan kebutuhan adalah proses pemahaman dan
pengendalian perubahan kebutuhan dari sistem. Perlu
dilakukan pengawasan terhadap kebutuhan terutama yang
memiliki keterkaitan satu dengan yang lain. hal ini dilakukan
agar dampak perubahan kebutuhan terhadap sistem secara
keseluruhan dapat diidentifikasi.
• Proses pengelolaan kebutuhan harus dilakukan sejak pertama
kali dokumen kebutuhan dituliskan.
26

14. 9/28/2016
14
Pengelolaan Kebutuhan (lanjut..)
• Pengelolaan kebutuhan perlu mempertimbangkan:
– Identifikasi keterkaitan kebutuhan:
• disamping mengidentifikasi kebutuhan dari masing-masing
stakeholder perlu diidentifikasi juga keterkaitan dari masing-masing
stakeholder.
– Pengelolaan tracability:
• Aturan atau kebijakan untuk mencatat riwayat kebutuhan mulai dari
identifikasi, perubahan dan penghapusannya. Sehingga dapat
dimungkinkan pelacakan kembali status kebutuhan.
• Termasuk juga mencatat keterkatainnya dengan spesifikasi sistem.
Sehingga dapat dimungkinkan pelacakan kembali terhadap spesifikasi
sistem berasal dari kebutuhan yang mana.
– Penyimpanan kebutuhan:
• kebutuhan harus disimpan dan dikelola dengan aman, dan harus
dapat diakses dengan mudah bagi para pihak terkait sesuai dengan
kewenangannya masing-masing.
– Pengelolaan perubahan kebutuhan:
27
Pengelolaan Kebutuhan (lanjut..)
• Pengelolaan perubahan kebutuhan: perubahan terhadap kebutuhan harus dikelola
dengan baik. Terdapat proses utama dalam pengelolaan perubahan kebutuhan,
yaitu:
– Analisis permasalahan dan spesifikasi perubahan:
• mengidentifikasi permasalahan, latarbelakang perubahan dalam rangka menjawab
permintaan perubahan. (dapat berupa disposisi dokumen atau meeting antara tim
perekayasa dengan user yang meminta perubahan kebutuhan).
– Pembiayaan dan analisis perubahan:
• Mengidentifikasi dampak dari perubahan menggunakan analisis tracability dan
keterkaitan kebutuhan dengan sistem keseluruhan. Ketika dampak positif diidentifikasi
lebih banyak dari pada dampak negatifnya maka umumnya perubahan disetujui.
– Implementasi perubahan:
• Melakukan perubahan terhadap dokumen kebutuhan atau dokumen analisis dan desain.
28
Sumber: Sommerville, 2009

15. 9/28/2016
15
Ringkasan
• Kebutuhan sebuah sistem perangkat lunak menjelaskan apa yang harus dilakukan
atau kemampuan yang dimiliki oleh sistem termasuk juga batasan pada saat sistem
dijalankan dan diimplementasikan.
• Kebutuhan fungsional adalah pernyataan dari layanan yang harus diberikan oleh
sistem atau penjelasan tentang bagaimana proses komputasi dilakukan oleh
sistem.
• Kebutuhan non-fungsional sering kali adalah batasan kemampuan dari sistem
meliputi kebutuhan dari perspektif produk, organisasi dan eksternal.
• Dokumen kebutuhan perangkat lunak merupakan hasil kesepakatan antara user
dengan tim perekayasa dan harus didokumentasikan dalam bentuk yang dapat
dipahami oleh kedua belah pihak.
• Proses rekayasa kebutuhan meliputi: studi kelayakan, identifikasi dan analisis
kebutuhan, spesifikasi kebutuhan, validasi kebutuhan dan pengelolaan kebutuhan.
• Perubahan bisnis, organisasi dan teknis pada akhirnya berdampak pada perubahan
kebutuhan sistem perangkat lunak. Pengelolaan kebutuhan merupakan proses
pengelolaan dan pengendalian terhadap perubahan tersebut.
29