Anda di halaman 1dari 16

ANALISIS KEBUTUHAN

Tujuan
Bagian ini menjelaskan tentang pengertian kebutuhan dan analisis kebutuhan, tahap
pelaksanaan analisis kebutuhan, serta dokumen spesifikasi kebutuhan. Setelah
mempelajari bagian ini dengan baik, pembaca diharapkan dapat:
Memahami pengertian kebutuhan perangkat lunak.
Memahami apa yang dimaksud dengan analisis kebutuhan dan tahap
pelaksanaannya.
Mengetahui arti, fungsi, dan sistematika penulisan dokumen Spesifikasi
Kebutuhan Perangkat Lunak.
Pokok Bahasan
Pokok bahasan pada bagian ini meliputi:
Kebutuhan
ahap Pelaksanaan !nalisis Kebutuhan
Spesifikasi Kebutuhan Perangkat Lunak
"PL#.doc$!nalis Kebutuhan % &ersi '($')$*''# 71
4
72 BAGIAN II: PENGEMBANGAN PERANGKAT LUNAK
!nalisis kebutuhan +requirements analysis, merupakan akti&itas yang sangat penting
dalam pengembangan perangkat lunak. !pa dan bagaimana pelaksanaan analisis
kebutuhan ini, berikut adalah penjelasannya.
4.1 Kebutuhan
4.1.1 Apa yang Disebut Kebutuhan?
-engan mengadopsi pengertian.pengertian di atas, dapat dinyatakan bah/a
kebutuhan perangkat lunak adalah kondisi atau kemampuan yang harus dimiliki oleh
perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan pemakai.
Secara kategoris, ada tiga buah jenis kebutuhan perangkat lunak 0122(34:
5. Kebutuhan fungsional +functional requirement,
-isebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan
dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh
perangkat lunak.
Sebagai contoh:
Perangkat lunak harus dapat menyimpan semua rincian data pesanan
pelanggan.
Perangkat lunak harus mampu mencetak laporan penjualan sesuai
periode yang diinputkan.
Perangkat lunak harus mampu menyajikan informasi jalur pengiriman
terpendek.
*. Kebutuhan antarmuka +interface requirement,
Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan
elemen perangkat keras, perangkat lunak, atau basis data.
Sebagai contoh:
!kses ke basis data menggunakan 6-B7 +Open Data Base
Connectivity,.
Perangkat untuk memasukkan data menggunakan keyboard, mouse,
dan scanner.
3. Kebutuhan unjuk kerja +performance requirement,
Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki
oleh perangkat lunak, seperti kecepatan, ketepatan, atau frekuensi.
Sebagai contoh:
8aktu tanggap penyajian informasi maksimal selama satu menit.
Perangkat lunak harus mampu mengolah data sampai 5 juta record
untuk setiap transaksi.
Perangkat lunak harus dapat digunakan secara multi user sesuai
otoritas yang diberikan kepada masing.masing pemakai.
BAB 4: ANALISIS KEBUTUHAN 73
4.1.2 Apa yang Dimaksud Anaisis Kebutuhan?
!nalisis kebutuhan perangkat lunak dapat diartikan sebagai:
Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi
kebutuhan sistem atau perangkat lunak 0122(34.
Proses untuk menetapkan fungsi dan unjuk kerja perangkat lunak,
menyatakan antarmuka perangkat lunak dengan elemen.elemen sistem
lain, dan menentukan kendala yang harus dihadapi oleh perangkat lunak
0P"2'54.
ujuan analisis kebutuhan perangkat lunak adalah:
Memahami masalah yang akan dibuat perangkat lunaknya secara
menyeluruh +komprehensif,.
Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk
memenuhi keinginan pemakai.
4.1.3 !engapa Anaisis Kebutuhan Penting?
Pendefinisian kebutuhan yang baik dapat menjadi faktor sukses pelaksanaan
pengembangan perangkat lunak. Sebaliknya akan menyebabkan banyak kegagalan.
Menurut hasil sur&ey -eMarco, 9:; kegagalan proyek perangkat lunak adalah karena
ketidaklengkapan pendefinisian kebutuhan. Perhatikan gambar dampak kesalahan
kumulatif akibat kesalahan pendefinisian kebutuhan pada <ambar #.5. berikut ini.
-ari gambar terlihat bah/a produk perangkat lunak yang tidak sempurna akan
dihasilkan karena kesalahan pada saat menentukan spesifikasi kebutuhan. =ika
kesalahan tersebut diketahui di akhir siklus hidup pengembangan, usaha untuk
memperbaikinya akan sangat mahal +sekitar )*; dari total biaya perbaikan,.
Selain itu, kesalahan penentuan kebutuhan akan memberikan dampak:
Perangkat lunak yang dihasilkan tidak akan memenuhi kebutuhan pemakai
yang sebenarnya.
1ntepretasi kebutuhan yang berbeda.beda sehingga dapat menyebabkan
ketidaksepakatan antara pelanggan dan pengembang, menyia.nyiakan
/aktu dan biaya, dan mungkin akan menghasilkan perkara hukum.
Pengujian kesesuaian perangkat lunak dengan kebutuhan yang dimaksud
tidak akan mungkin dilaksanakan dengan benar.
8aktu dan biaya akan terbuang percuma untuk membangun perangkat
lunak yang salah.
74 BAGIAN II: PENGEMBANGAN PERANGKAT LUNAK
<ambar #.5. -ampak Kesalahan Kumulatif
+Sumber: !lan M. -a&is, 0-!>(34,
4.2 Tahap Anaisis Kebutuhan
ahap kebutuhan perangkat lunak dimulai dengan 0-!>(34:
5. !danya masalah yang membutuhkan penyelesaian:
orientasi aplikasi, misalnya inventory
orientasi bisnis, misalnya produk baru, peramalan pendapatan
orientasi peningkatan produk, misalnya pemeliharaan
*. Munculnya ide untuk membuat sebuah perangkat lunak baru.
ahap kebutuhan berakhir apabila deskripsi lengkap dari perilaku eksternal
perangkat lunak yang akan dibangun sudah didapat, termasuk dokumentasi seluruh
antarmuka perangkat lunak dengan lingkungannya +perangkat keras, perangkat lunak
lain, pemakai, yang dicatat dalam Spesifikasi Kebutuhan Perangkat Lunak.
Secara teknis pelaksanaan pekerjaan analisis kebutuhan perangkat lunak pada
dasarnya terdiri dari urutan akti&itas:
the real problem
correct
speciicatio!
erro!eo"s
speciicatio!
correct
#esi$!
erro!eo"s
#esi$!
#esi$! base#
o! erro!eo"s
speciicatio!
correct
pro$ram
pro$rammi!$
error
pro$ram base#
o! erro!eo"s
#esi$!
pro$ram base#
o! erro!eo"s
speciicatio!
correct
"!ctio!s
correctable
errors
"!correctable
errors
hi##e!
errors
imperect pro$ram
pro#"cts
Re%"ireme!ts
speciicatio!
&esi$!
Impleme!tatio!
Testi!$
BAB 4: ANALISIS KEBUTUHAN 7"
5. Mempelajari dan memahami persoalan
*. Mengidentifikasi kebutuhan pemakai
3. Mendefinisikan kebutuhan perangkat lunak
#. Membuat dokumen spesifikasi kebutuhan
9. Mengkaji ulang +review, kebutuhan
4.2.1 !empeaja#i dan !emahami !asaah
Pada tahap ini, masalah yang akan dibuat perangkat lunaknya dipelajari sehingga
dapat ditentukan:
siapa pemakai yang akan menggunakan perangkat lunak
dimana perangkat lunak akan digunakan
pekerjaan apa dari pemakai yang akan dibantu oleh perangkat lunak
dari dan sampai mana cakupan pekerjaan tersebut, dan bagaimana
mekanisme pelaksanaannya
apa yang menjadi kendala atau keterbatasannya dilihat dari sisi teknologi
yang akan digunakan atau dari sisi hukum dan standar
7ara yang digunakan untuk dapat memahami masalah biasanya adalah:
/a/ancara dengan pemakai
obser&asi atau pengamatan lapangan
kuesioner
mempelajari referensi atau dokumen.dokumen yang digunakan, seperti
dokumen hasil analisis dan perancangan sistem
?asil pemahaman masalah tersebut selanjutnya digambarkan dalam bentuk model.
model tertentu sesuai dengan jenis masalahnya. Sebagai contoh, untuk masalah
bisnis dapat menggunakan flowmap atau business use case, sementara untuk masalah
matematika dapat mengunakan, misalnya, graf.
4.2.2 !engidenti$ikasi Kebutuhan Pemakai
Sebenarnya, tahap identifikasi kebutuhan pemakai +user requirement, ini pada
prakteknya dilaksanakan bersamaan dengan pemahaman masalah. 7ara yang
digunakan pun relatif sama. ?anya saja, subtansi yang ditanyakan biasanya adalah:
data atau informasi apa yang akan diproses
fungsi apa yang diinginkan
7% BAGIAN II: PENGEMBANGAN PERANGKAT LUNAK
kelakuan sistem apa yang diharapkan
antarmuka apa yang tersedia +user interfaces, hardware interfaces,
software interfaces, dan communications interfaces,
@ntuk dapat menangkap kebutuhan pemakai dengan baik, utamanya kesamaan
persepsi, dibutuhkan:
komunikasi dan brainstorming yang intensif
prototype perangkat lunak, atau screen snapshot
data atau dokumen yang lengkap
4.2.3 !ende$inisikan Kebutuhan Pe#angkat &unak
Saat mengidentifikasi kebutuhan pemakai, informasi yang diperoleh belum
terstruktur. Pemakai akan mengungkapkan apa yang dibutuhkannya dengan bahasa
sehari.hari yang biasa digunakan pemakai. Sebagai contoh, ungkapan kebutuhan
pemakai di Bagian !kuntansi, misalnya:
saya ingin data yang dimasukkan oleh Bagian Penjualan bisa langsung
dijurnal.
informasi neraca bisa saya lihat kapan saja.
Pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut dianalisis,
diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional, antarmuka, dan
unjuk kerja perangkat lunak. Sebagai gambaran, kebutuhan Adata yang dimasukkan
oleh Bagian Penjualan dapat langsung dijurnalB setelah dianalisis, diklasifikasikan,
dan diterjemahkan, mungkin memberikan hasil:
5. Kebutuhan fungsional:
entry dan rekam data transaksi penjualan.
retrieve nilai transaksi penjualan untuk periode tertentu +sesuai periode
yang diinputkan melalui keyboard,.
rekam nilai akumulasi transaksi penjualan periode tertentu ke jurnal umum
berikut account pasangannya +kas,.
*. Kebutuhan antarmuka:
antarmuka pemakai untuk merekam data penjualan.
antarmuka pemakai untuk menyajikan dan menjurnal informasi nilai
transaksi penjualan periode tertentu.
BAB 4: ANALISIS KEBUTUHAN 77
jaringan lokal untuk menghubungkan perangkat lunak aplikasi di Bagian
Penjualan dengan perangkat lunak aplikasi di Bagian !kuntansi.
3. Kebutuhan unjuk kerja:
ada otoritas pemakaian perangkat lunak dan akses data.
proses jurnal hanya dapat dilakukan sekali setelah data transaksi penjualan
direkam.
Selanjutnya, kebutuhan tersebut diubah menjadi model atau gambar tertentu
dengan memanfaatkan teknik analisis dan alat bantu tertentu. Sebagai gambaran,
kebutuhan fungsional dapat dimodelkan dengan menggunakan:
-ata Clo/ -iagram, kamus data, dan spesifikasi proses jika menggunakan
teknik terstruktur.
-iagram @se 7ase dan skenario sistem jika menggunakan pendekatan objek.
7ontoh pemodelan untuk kedua pendekatan di atas secara rinci akan dibahas
tersendiri pada bab 9 dan bab :.
4.2.4 !embuat Dokumen 'pesi$ikasi Kebutuhan
Semua kebutuhan yang telah didefinisikan selanjutnya dibuatkan dokumentasinya,
yaitu Spesifikasi Kebutuhan Perangkat Lunak +SKPL, atau Software Requirements
Specification +S"S,. SKPL yang dibuat harus dapat menyatakan secara lengkap apa
yang dapat dilakukan oleh perangkat lunak, termasuk deskripsi lengkap dari semua
antarmuka yang digunakan. SKPL bisa terdiri dari banyak dokumentasi yang saling
melengkapi. Penjelasan rinci tentang SKPL ini akan dibahas di bagian #.#.
4.2." !engkaji (ang )Review* Kebutuhan
Proses untuk memeriksa +&alidasi, SKPL apakah sudah konsisten, lengkap, dan sesuai
dengan apa yang diinginkan pemakai. Proses ini mungkin dilakukan lebih dari satu
kali. -an sering kali muncul kebutuhan.kebutuhan baru dari pemakai. @ntuk itu,
diperlukan negosiasi antara pihak pengembang dengan pemakai sesuai prinsip Awin-
win solutionB sampai kebutuhan tersebut dapat disepakati kedua belah pihak.
4.3 'pesi$ikasi Kebutuhan Pe#angkat &unak
4.3.1 Apa yang Disebut 'KP&?
SKPL adalah dokumen yang berisi pernyataan lengkap dari apa yang harus dilakukan
atau dipenuhi oleh perangkat lunak, tanpa menjelaskan bagaimana hal tersebut
dilaksanakan oleh perangkat lunak. Selain itu, SKPL pun berisi deskripsi lengkap dari
semua antarmuka yang ada dalam perangkat lunak.
7+ BAGIAN II: PENGEMBANGAN PERANGKAT LUNAK
SKPL dibuat untuk tujuan: 0-!>(34
Sarana komunikasi antara pelanggan, pemakai, analis, dan perancang
perangkat lunak.
-asar untuk merencanakan dan melaksanakan pengujian sistem.
!cuan untuk melakukan perbaikan atau pengubahan perangkat lunak.
Sementara manfaat atau kegunaan dokumen SKPL, seperti dikutip oleh 8itarto
081'#4 dari 1222, adalah:
Memastikan kesamaan antara kebutuhan untuk pengembangan dengan
kebutuhan yang ditulis dalam dokumen.
Mendefinisikan kerangka kerja bersama untuk proses.proses pengembangan
perangkat lunak.
Memperjelas peran dan antarmuka bagi para pihak yang terlibat dalam
proses.proses pengembangan perangkat lunak.
Memperjelas jenis dan isi dari dokumen.
Mengenali tugas.tugas, tahapan.tahapan, baselines, akti&itas kaji ulang,
dan dokumentasinya.
Belajar dari pendekatan praktis yang diterapkan di dunia industri.
Menghilangkan jebakan.jebakan dan persoalan.persoalan seperti yang
dialami di masa lalu.
4.3.2 Apa yang ,a#us Ada daam 'KP&?
Secara umum SKPL harus mencantumkan semua kebutuhan yang harus dipenuhi oleh
perangkat lunak. Selain itu, SKPL pun harus dapat mendefinisikan atribut.atribut
perangkat lunak, seperti: keandalan +reliability,, ketersediaan +availability,,
keamanan +security,, kemampuan untuk dapat dipelihara +maintainability,, dan
portabilitas +portability,.
SKPL tidak harus mencantumkan: 0-!>(34
kebutuhan.kebutuhan proyek, seperti jad/al, biaya, milestone, laporan.
laporan, dan sebagainya.
rancangan perangkat lunak.
rencana jaminan produk, seperti rencana &alidasi dan &erifikasi atau
rencana pengujian.
BAB 4: ANALISIS KEBUTUHAN 7-
Penjelasan rinci dari apa yang harus ada dalam SKPL dapat dilihat pada dokumen
Recommended ractice for Software Requirements Specifications +1222 Std. )3'.
5((),.
4.3.3 Bagaimana Penuisan 'KP& yang Baik?
Menurut !lan M. -a&is 0-!>(34, penulisan SKPL yang baik adalah yang memenuhi
kriteria.kriteria berikut:
5. Benar
Setiap kebutuhan yang dinyatakan dalam SKPL merepresentasikan
kebutuhan dari perangkat lunak yang akan dibangun.
*. idak bias +unambiguous,
Setiap kebutuhan yang dinyatakan dalam SKPL hanya memiliki satu arti
atau satu interpretasi.
3. Lengkap
SKPL dikatakan lengkap jika menyertakan:
semua kebutuhan yang harus dilakukan perangkat lunak.
definisi dari bentuk tanggapan perangkat lunak terhadap semua kelas
data masukan dari berbagai situasi.
identifikasi yang lengkap dari setiap halaman, gambar dan tabel,
penjelasan istilah.istilah yang digunakan, dan rujukan.rujukan.
tidak ada bagian yang dinyatakan dengan Aakan didefinisikan
kemudianB +to be define,.
#. -apat di&erifikasi
Setiap kebutuhan yang dinyatakan dalam SKPL dapat diperiksa dan diuji
kebenarannya.
9. Konsisten
Semua atau sebagian kebutuhan yang dinyatakan dalam SKPL tidak
bertentangan dokumen.dokumen lain yang disusun sebelumnya, seperti
dokumen spesifikasi kebutuhan sistem.
:. -apat dipahami oleh pelanggan
1si SKPL harus dapat dimengerti oleh pelanggan dan pemakai, /alaupun ada
notasi.notasi formal yang digunakan didalamnya.
D. -apat dimodifikasi
Struktur dan gaya penulisan SKPL memungkinkan untuk diubah dengan
mudah jika ada perubahan kebutuhan, tetapi tetap konsisten dan lengkap.
). -apat ditelusuri
SKPL dapat ditelusuri jika ditulis dalam bentuk yang dapat menjelaskan dari
mana asal kebutuhan dan kebutuhan bagaimana direalisasi.
(. Mempunyai keterangan +annotated,
Setiap kebutuhan diurutkan sesuai tingkat kepentingan atau kestabilannya,
dan diberikan keterangan apakah kebutuhan tersebut merupakan
keharusan, disarankan, atau optional.
+. BAGIAN II: PENGEMBANGAN PERANGKAT LUNAK
5'. "ingkas
1si SKPL ditulis dengan kalimat.kalimat yang ringkas dan jelas.
55. erorganisasi
Penulisan kebutuhan diorganisasi dengan tata letak tertentu sehingga
memudahkan untuk mencarinya.
?indari hal.hal berikut saat menulis SKPL:
memberikan penjelasan yang berlebih.lebihan dan berulang.ulang sehingga
menjadi tidak jelas.
menggunakan istilah secara tidak konsisten.
menyatakan keterukuran kebutuhan secara tidak jelas, misalnya dengan
menggunakan kata.kata: minimal, maksimal, optimial, cepat, user-
friendly, mudah, sederhana, normal, efisien, fleksibel, dan$atau, dan lain.
lain, atau dan sebagainya.
menuliskan Amimpi.mimpiB, yaitu hal.hal yang tidak akan dapat dilakukan
oleh perangkat lunak.
4.3.4 'iapa yang Te#ibat daam Pembuatan 'KP&?
!da sembilan kelompok orang yang terlibat dalam pembuatan SKPL:
5. Pemakai
Kelompok orang yang akan mengoperasikan atau menggunakan produk dari
perangkat lunak yang dibuat
*. Pelanggan
1ndi&idu atau perusahaan yang menginginkan dan membiayai pembuatan
perangkat lunak.
3. !nalis Sistem +System !ngineer,
Kelompok orang yang biasanya melakukan kontak teknik pertama kali
dengan pelanggan. Bertugas menganalisis persoalan, mengenali dan
menuliskan kebutuhan.
#. Software !ngineer
Kelompok orang yang akan bekerja sama dengan System !ngineer saat
mendefinisikan kebutuhan perangkat lunak, dan membuat deskripsi
perancangannya.
9. Pemrogram
Kelompok orang yang akan menerima spesifikasi perancangan perangkat
lunak, membuat modul.modul program, menguji, dan memeriksa modul.
:. "est #ntegration $roup
BAB 4: ANALISIS KEBUTUHAN +1
Kelompok orang yang akan melakukan pengujian dan integrasi modul
program.
D. %aintenance $roup
Memantau dan mera/at performansi sistem perangkat lunak yang dibuat
selama pelaksanaan dan pada saat modifikasi muncul +)'; dari pekerjaan,.
). "echnical Support
Kelompok orang, konsultan atau orang yang mempunyai kepandaian lebih
tinggi, yang akan memberikan dukungan teknis kepada pengembang
perangkat lunak.
(. Staf dan Clerical &ork
Kelompok orang yang bertugas mengetik, memasukkan data, dan membuat
dokumen.
4.3." Tata &etak Dokumen 'KP&
!da banyak tata letak atau format dokumen SKPL. Berikut adalah tata letak SKPL
yang sebagian besar diadopsi dari 1222 Std )3'.5(():
A. 'KP& untuk Pendekatan Ai#an Data
5. P2E-!?@L@!E
5.5 Kegunaan
5.* "uang Lingkup
5.3 -efinisi, !kronim, dan Singkatan
5.# "eferensi
5.9 1khtisar
*. -2SK"1PS1 @M@M
*.5 Perspektif Produk
*.* Cungsi Produk
*.3 Karakteristik Pemakai
*.# Batasan.batasan
*.9 !sumsi dan Ketergantungan
3. K2B@@?!E "1E71
3.5 Kebutuhan !ntarmuka 2ksternal
3.5.5 !ntarmuka Pemakai
3.5.* !ntarmuka Perangkat Keras
3.5.3 !ntarmuka Perangkat Lunak
3.5.# !ntarmuka Komunikasi
3.* Kebutuhan Cungsional
3.*.5 -eskripsi Kebutuhan Cungsional
3.*.* -iagram Konteks
3.*.3 -iagram !liran -ata
+2 BAGIAN II: PENGEMBANGAN PERANGKAT LUNAK
3.*.3.5 -iagram !liran -ata Proses '
3.*.3.* -iagram !liran -ata Proses (
.
.
3.*.3.n -iagram !liran -ata Proses n
3.*.# Kamus -ata
3.*.#.5 empat Penyimpanan -ata
3.*.#.* !liran -ata
3.*.9 Spesifikasi Proses
3.*.9.5 Proses '
3.*.9.* Proses (
.
.
3.*.9.m Proses m
3.3 Kebutuhan Performansi
3.# Kendala Perancangan
3.9 !tribut Sistem Perangkat Lunak
3.: Kebutuhan Lain
B. 'KP& untuk Pendekatan /bjek
5. P2E-!?@L@!E
5.5 Kegunaan
5.* "uang Lingkup
5.3 -efinisi, !kronim, dan Singkatan
5.# "eferensi
5.9 1khtisar
*. -2SK"1PS1 @M@M
*.5 Perspektif Produk
*.* Cungsi Produk
*.3 Karakteristik Pemakai
*.# Batasan.batasan
*.9 !sumsi dan Ketergantungan
3. K2B@@?!E "1E71
3.5 Kebutuhan !ntarmuka 2ksternal
3.5.5 !ntarmuka Pemakai
3.5.* !ntarmuka Perangkat Keras
3.5.3 !ntarmuka Perangkat Lunak
3.5.# !ntarmuka Komunikasi
3.* Kebutuhan Cungsional
3.*.5 -eskripsi Kebutuhan Cungsional
3.*.* -iagram @se 7ase
BAB 4: ANALISIS KEBUTUHAN +3
3.*.3 Skenario
3.*.3.5 Skenario @se 7ase '
3.*.3.* Skenario @se 7ase (
.
.
3.*.3.n Skenario @se 7ase n
3.3 Kebutuhan Performansi
3.# Kendala Perancangan
3.9 !tribut Sistem Perangkat Lunak
3.: Kebutuhan Lain
@ntuk penjelasan yang lebih rinci mengenai cara bagaimana menulis SKPL, pembaca
dapat melihatnya pada dokumen Recommended ractice for Software Requirements
Specifications +1222 Std. )3'.5((),, atau pada bagian 9.# dari buku AMemahami
Sistem 1nformasiB karangan 8itarto !di 081'#4.
+4 BAGIAN II: PENGEMBANGAN PERANGKAT LUNAK
0angkuman
5. Kebutuhan perangkat lunak dapat diartikan sebagai sesuatu +kemampuan,
kondisi, kriteria, yang harus ada atau dipenuhi oleh perangkat lunak. !da tiga
jenis kebutuhan, yaitu fungsional, antarmuka, dan unjuk kerja.
*. Kebutuhan perangkat lunak didefinisikan melalui proses analisis kebutuhan. !da
serangkaian tahap yang harus dilaksanakan sebelum dapat mendefinisikan
kebutuhan ini. ?asil dari proses analisis kebutuhan dapat menjadi faktor sukses
pelaksanaan pengembangan perangkat lunak.
3. Kebutuhan perangkat lunak ditulis secara sistematis dalam suatu dokumen yang
disebut Spesifikasi Kebutuhan Perangkat Lunak +SKPL,, sehingga dapat dijadikan
acuan oleh pemakai dan pengembang saat dan setelah pelaksanaan pembuatan
perangkat lunak. @ntuk itu, ada beberapa hal, seperti atribut dan sistematika,
yang harus diperhatikan untuk dapat menuliskan SKPL yang baik.
&atihan
=a/ablah pertanyaan.pertanyaan berikut secara ringkas dan tepat.
5. uliskan kembali pengertian dari kebutuhan perangkat lunakF
*. Berikan beberapa contoh jenis kebutuhan fungsional, antarmuka, dan unjuk
kerja untuk perangkat lunak aplikasi reser&asi kamar hotelF
3. Sebutkan urut.urutan pelaksanaan analisis kebutuhanF
#. erangkan bagaimana cara melaksanakan analisis kebutuhan, jika umpamanya
anda diharuskan membuat perangkat lunak word processorF
9. !pakah manfaat dokumen SKPL sama bagi pemakai dan pengembangG =ika tidak,
coba jelaskan manfaat untuk masing.masing pihak tersebutF
BAB 4: ANALISIS KEBUTUHAN +"
Da$ta# Pustaka
0-!>(34 -a&is, !lan M., ASoft/are "eHuirements: 6bjects, Cunctions and StatesB,
Prentice.?all 1nternational 2ditions, 2ngle/ood 7liffs, Ee/ =ersey, 5((3.
0-6-(#4 @S -epartment of -efense, AM1L.S-.#() Soft/are -e&elopment and
-ocumentation, 5((#.
0122(34 he 1nstitute of 2lectrical and 2lectronics 2ngineers, A1222 Std :5'.5*.5((3
Standard <lossary of S8 2ngineering erminologyB, 5((3.
0122()4 he 1nstitute of 2lectrical and 2lectronics 2ngineers, A11222 Std )3'.5(()
"ecommended Practice for S8 "eHuirements Specifications +S"S,B, 5(().
0P"2'54 Pressman, "oger S., ASoft/are 2ngineering: ! PractionerIs !pproachB, Cifth
2dition, Mac<ra/.?ill 1nternational 2ditions, *''5.
081'#4 8itarto, AMemahami Sistem 1nformasiB, Penerbit 1nformatika, Bandung,
*''#.
+% BAGIAN II: PENGEMBANGAN PERANGKAT LUNAK

Anda mungkin juga menyukai