ANALISIS KEBUTUHAN PERANGKAT LUNAK. pdf

ANALISIS KEBUTUHAN PERANGKAT LUNAK

Di Susun Oleh :
Linda Liana - 41813120100

Dosen Pengampu :
Wahyu Hari Haji M. Kom

FAKULTAS ILMU KOMPUTER
PROGRAM STUDY SISTEM INFORMASI
UNIVERSITAS MERCU BUANA JAKARTA
2015

ANALISIS KEBUTUHAN PERANGKAT LUNAK
I.

PENGERTIAN KEBUTUHAN
Menurut kamus Webster seperti dikutip oleh Davis [DAV93], kebutuhan adalah

sesuatu yang diisyaratkan, sesuatu yang diinginkan atau diperlukan.
Sedangkan menurut IEEE kebutuhan adalah :




Kondisi atau kemampuanyang diperlukan pemakai untuk menyelesaikan suatu
persoalan atau untuk mencapai tujuan.
Kondisi atau kemampuan yang harus dimiliki atau dipunyai oleh system atau
komponen system untuk memenuhi kontrak, standar, spesifikasi ata dokumen formal
lainnya.
Kebutuhan Perangkat Lunak adalah kondisi, criteria, syarat atau kemampuan yang

harus dimiliki oleh perangkat lunak untuk memenuhi apa yang diisyaratkan atau diinginkan
pemakai.
Secara kategoris, ada tiga buah jenis kebutuhan perangkat lunak [IEE93]:
1. Kebutuhan Fungsional (functional requirement)
Disebut 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.

2. Kebutuhan Antarmuka (interface requirement)
Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat
keras, perangkat lunak, atau basis data.
Sebagai contoh:




Akses ke basis data menggunakan ODBC (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:




Waktu tanggap penyajian informasi maksimal selama satu menit.



transaksi.

Perangkat lunak harus mampu mengolah data sampai 1 juta record untuk setiap

Perangkat lunak harus dapat digunakan secara multi user sesuai otoritas yang
diberikan kepada masing-masing pemakai.

II.

ANALISA KEBUTUHAN
Analisis kebutuhan (requirements analysis) merupakan langkah awal untuk

menentukan gambaran perangkat yang akan dihasilkan ketika pengembang melaksanakan
sebuah proyek pembuatan perangkat lunak. Perangkat lunak yang baik dan sesuai dengan
kebutuhan pengguna sangat tergantung pada keberhasilan dalam melakukan analisis
kebutuhan. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan
dilaksanakan setelah aktivitas sistem information engineering dan software project planning.


Analisis kebutuhan perangkat lunak dapat diartikan sebagai:
 Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan sistem
atau perangkat lunak [IEE93].

 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 [PRE01].
Analisa kebutuhan yang baik belum tentu menghasilkan perangkat lunak yang baik,
tetapi analisa kebutuhan yang tidak tepat menghasilkan perangkat yang tidak berguna.

Mengetahui adanya kesalahan pada analisis kebutuhan pada tahap awal memang jauh lebih
baik, tapi kesalahan analisis kebutuhan yang diketahui ketika sudah memasuki penulisan
kode atau pengujian, bahkan hampir masuk dalam tahap penyelesaian merupakan malapetaka
besar bagi pembuat perangkat lunak. Biaya dan waktu yang diperlukan akan menjadi sia sia.
Analisa kebutuhan adalah suatu proses untuk mendapatkan informasi, mode,
spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Kedua belah pihak,
yaitu klien dan pembuat perangkat lunak terlibat aktif dalam tahap ini. Informasi dari klien
yang akan menjadi acuan untuk melakukan desain perangkat lunak.
Analisis kebutuhan merupakan satu di antara banyak aktivitas kritis pada proses
rekayasa kebutuhan perangkat lunak untuk memahami ranah permasalahan dari sistem yang
berjalan dan ranah solusi dari sistem yang akan dibuat (Yen et.al, 1998).

Ada tiga faktor yang harus dipenuhi ketika melakukan analisis kebutuhan ini, yaitu
lengkap, detail, dan benar. Lengkap artinya semua yang diharapkan oleh klien telah
didapatkan oleh pihak yang melakukan analisis. Detail maksudnya adalah berhasil
mengumpulkan informasi yang terperinci. Semua data dari analisis kebutuhan ini haruslah
benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang dipikirkan oleh
pihak analisis.
Analisis kebutuhan yang dilakukan terhadap perangkat lunak akan menghasilkan
spesifikasi perangkat lunak tersebut. Analisa kebutuhan ini terdiri dari lima langkah pokok:

1) Identifikasi Masalah
2) Evaluasi dan sintesis
3) Pemodelan
4) Spesifikasi


5) Review
Tujuan Analisis Kebutuhan:
 Memahami masalah yang akan dibuat perangkat lunaknya secara menyeluruh
(komprehensif).

 Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi
keinginan pemakai.
Ada tiga tujuan utama dari proses analasis kebutuhan yang dapat diformulasikan sebagai
beriukut :
1) Mengelola hasil elistasi kebutuhan untuk menghasilkan dokumen spesifikasi
kebutuhan yang isi keseluruhannya sesuai dengan apa yang diinginkan pengguna.
(Liu and Yen, 1996).
2) Mengembangkan persyaratan kualitas yang memadai dan rinci, dimana para manajer
dapat membuat pekerjaan proyek yang realistis dan staf teknis dapat melanjutkan

dengan perancangan, implementasi dan pengujian (Wiegers, 2003).
3) Membangun pemahaman tentang karakteristik ranah permasalahan dan sekumpulan
kebutuhan untuk menemukan solusi.
Ketiga tujuan tersebut dapat dicapai oleh perekayasa kebutuhan dengan melalui serangkaian
tahapan-tahapan aktivitas. Tahapan aktivitas tersebut dijelaskan sebagai berikut.


Tahap Analisis Kebutuhan
Tahap analisis adalah tahapan pengumpulan kebutuhan-kebutuhan dari semua elemen

sistem perangkat lunak yang akan di bangun.

Tahap kebutuhan perangkat lunak dimulai dengan [DAV93]:
1) Adanya masalah yang membutuhkan penyelesaian:






Orientasi aplikasi, misalnya inventory
Orientasi bisnis, misalnya produk baru, peramalan pendapatan
Orientasi peningkatan produk, misalnya pemeliharaan

2) Munculnya ide untuk membuat sebuah perangkat lunak baru.
Tahap 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 aktivitas:
1) Mempelajari dan memahami persoalan
2) Mengidentifikasi kebutuhan pemakai
3) Mendefinisikan kebutuhan perangkat lunak
4) Membuat dokumen spesifikasi kebutuhan
5) Mengkaji ulang (review) kebutuhan
1. Mempelajari dan Memahami Masalah
Pada tahap ini, masalah yang akan dibuat perangkat lunaknya dipelajari sehingga dapat
ditentukan:




Siapa pemakai yang akan menggunakan perangkat lunak



Pekerjaan apa dari pemakai yang akan dibantu oleh perangkat lunak



pelaksanaannya



Dimana perangkat lunak akan digunakan

Dari dan sampai mana cakupan pekerjaan tersebut, dan bagaimana mekanisme

Apa yang menjadi kendala atau keterbatasannya dilihat dari sisi teknologi yang akan

digunakan atau dari sisi hukum dan standar

Cara yang digunakan untuk dapat memahami masalah biasanya adalah:






Wawancara dengan pemakai
Observasi atau pengamatan lapangan
Kuesioner



Mempelajari referensi atau dokumen-dokumen yang digunakan, seperti dokumen
hasil analisis dan perancangan sistem

Hasil pemahaman masalah tersebut selanjutnya digambarkan dalam bentuk modelmodel 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.
2. Mengidentifikasi Kebutuhan Pemakai
Sebenarnya, tahap identifikasi kebutuhan pemakai (user requirement) ini pada
prakteknya dilaksanakan bersamaan dengan pemahaman masalah. Cara yang digunakan pun
relatif sama. Hanya saja, subtansi yang ditanyakan biasanya adalah:




Data atau informasi apa yang akan diproses



Kelakuan sistem apa yang diharapkan



Fungsi apa yang diinginkan

Antarmuka apa yang tersedia (user interfaces, hardware interfaces, software
interfaces, dan communications interfaces)

Untuk 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

3. Mendefinisikan Kebutuhan Perangkat Lunak
Saat mengidentifikasi kebutuhan pemakai, informasi yang diperoleh belum
terstruktur. Pemakai akan mengungkapkan apa yang dibutuhkannya dengan bahasa seharihari yang biasa digunakan pemakai. Sebagai contoh, ungkapan kebutuhan pemakai di Bagian
Akuntansi, 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 “data yang dimasukkan oleh Bagian
Penjualan dapat langsung dijurnal” setelah dianalisis, diklasifikasikan, dan diterjemahkan,
mungkin memberikan hasil:

1) Kebutuhan fungsional:




entry dan rekam data transaksi penjualan.



diinputkan melalui keyboard).

retrieve nilai transaksi penjualan untuk periode tertentu (sesuai periode yang

rekam nilai akumulasi transaksi penjualan periode tertentu ke jurnal umum
berikut account pasangannya (kas).

2) Kebutuhan antarmuka:




antarmuka pemakai untuk merekam data penjualan.



penjualan periode tertentu.

antarmuka pemakai untuk menyajikan dan menjurnal informasi nilai transaksi

jaringan lokal untuk menghubungkan perangkat lunak aplikasi di Bagian
Penjualan dengan perangkat lunak aplikasi di Bagian Akuntansi.

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:



Data Flow Diagram, kamus data, dan spesifikasi proses jika menggunakan teknik
terstruktur.
Diagram Use Case dan skenario sistem jika menggunakan pendekatan objek.

4. Membuat Dokumen Spesifikasi Kebutuhan
Semua kebutuhan yang telah didefinisikan selanjutnya dibuatkan dokumentasinya,
yaitu Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirements
Specification (SRS). 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.
5. Mengkaji Ulang (Review) Kebutuhan
Proses untuk memeriksa (validasi) SKPL apakah sudah konsisten, lengkap, dan sesuai
dengan apa yang diinginkan pemakai. Proses ini mungkin dilakukan lebih dari satu kali. Dan
sering kali muncul kebutuhan-kebutuhan baru dari pemakai. Untuk itu, diperlukan negosiasi

antara pihak pengembang dengan pemakai sesuai prinsip “win-win solution” sampai
kebutuhan tersebut dapat disepakati kedua belah pihak

III.

TEKNIK KOMUNIKASI

Merupakan permulaan yang (selalu) perlu dilakukan agar seorang pelanggan memiliki
masalah yang dapat dipertanggung jawabkan melalui pemecahan berbasis computer. Agar
pengembang dapat merespon permintaan bantuan (help) dari pelanggan.
Menurut Gause dan Weinberg [GAU89] menyarankan agar analis memulainya
dengan mengajukan pertanyaan bebas konteks, dimana pertanyaan tersebut berfokus pada
pelanggan, tujuan keseluruhan, dan keuntungan.
Contoh:






Siapa di balik permintaan untuk pekerjaan ini?
Apa keuntungan ekonomi dari pemecahan yang berhasil?
Rangkaian pertanyaan berikutnya memungkinakan analis mendapatkan pemahaman
yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya
terhadap suatu pemecahan.

Contoh:




Masalah apakah yang akan diselesaikan oleh pemecahan ini?
Dapatkah anda memperlihatkan kepada saya atau menjelaskan lingkungan dimana
pemecahan tersebut akan digunakan?

Rangkaian pertanyaan

berikutnya

berfokus pada efektifitas pertemuan.

[GAU89]

memberikan contohnya sebagai berikut:




Apakah ada orang lain yang dapat memberikan informasi tambahan?
Apakah ada hal lain yang harus saya tanyakan kepada anda?
Pertanyaan-pertanyaan tersebut akan membantu anda mengawali komunikasi yang

perlu untuk berhasilnya analisis. Pada dasarnya sesi tanya jawab seharusnya digunakan pada
pertemuan pertama dan kemudian diganti dengan format yang mengkombinasikan elemenelemen pemecahan masalah, negosiasi, dan spesifikasi.


Teknik Spesifikasi Aplikasi yang Terfasilitasi
Adanya teknik pendekatan spesifikasi aplikasi yang teratasi / facilitated aplication

spesification techniques (FAST) dapat mendorong munculnya tim gabungan antara
pengembang dan pelanggan yang bekerjasama untuk mengidentifikasimasalah, mengusulkan
elemen pemecahan, menegosiasi pendekatan yang berbeda, dan mengkhususkan rangkaian

pemecahan awal [ZAH90]. Banyak pendekatan yang berbeda terhadap FAST telah diusulkan.
Masing-masing pendekatan menggunakan skenario yang sangat berbeda, tetapi semuanya
menerapkan beberapa variasi tuntutan dasar seperti: Pertemuan dilakukan di sisi netral dan
dihadiri baik oleh pengembang maupun pelanggan.

Aturan main untuk persiapan dan

partisipasi dibuat.
Sebuah mekanisme definisi (dapat merupakan sebuah lembar kerja, diagram flip,
stiker dinding, atau papan tembok) digunakan. FAST bukanlah obat bagi masalah yang
dihadapi dalam pengumpulan awal berbagai persyaratan, tetapi pendekatan tim memberikan
keuntungan dari banyak sudut pandang, diskusi sesaat, dan penyaringan, serta merupakan
langkah maju konkrit ke arah pengembangan spesifikasi.


Penyebaran Fungsi Kualitas
Disebut juga Quality function deployment (QFD) adalah teknik manajemen kualitas

yang menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat
lunak. QFD mengidentifikasi 3 persyaratan [ZUL92] yaitu:






Persyaratan normal
Sasaran dan
tujuan dinyatakan bagi sebuah produk atau sistem selama pertemuan dengan
pelanggan.
Bila persyaratan ini ada, maka pelanggan akan menjadi puas. Contoh: tipe tampilan

grafis yang diminta, dan tingkat kerja yang didefinisikan.

Persyaratan yang diharapkan:

Persyaratan ini implisit terhadap produk atau sistem dan sangat fundamental sehingga
pelanggan tidak

menyatakannya secara eksplisit.

Ketidakhadirannya

menyebabkan

ketidakpuasan. Contoh: Mudahnya instalasi perangkat lunak.
Exciting requirment: Persyaratan ini sangat diharapkan oleh pelanggan dan terbukti
sangat memuaskan bila ada. Misalnya, perangkat lunak pengolah kata diharapkan dengan
fitur standar. Produk yang disampaikan berisi sejumlah kemampuan layout halaman yang
sangat menyenangkan dan tidak terduga. Dalam kenyataan, QFD mencakup seluruh proses
rekayasa [AKA90]. Tetapi banyak konsep QFD dapat diaplikasikan ke dalam masalah
komunikasi pelanggan yang dihadapi oleh perekayasa perangkat lunak selama tahap awal
analisis persyaratan.

IV.

PRINSIP-PRINSIP ANALISIS
Masing-masing metode analisis memiliki titik pandang yang unik. Tetapi semua

metode analisis dihubungkan oleh serangkaian prinsip operasional:

a) Domain informasi dari suatu masalah harus direpresentasikan dan dipahami.
b) Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
c) Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus
diwakilkan.
d) Model-model yang menggambarkan informasi, fungsi, dan tingkah laku harus
dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan.
e) Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
Dengan mengaplikasikan prinsip-prinsip tersebut, analis mendekati suatu masalah
secarasistematis. Domain informasi diuji sehingga fungsi itu dapat dipahami secara lebih
lengkap. Model-model digunakan sehingga karakteristik fungsi dan tingkah laku dapat
dikomunikasikan dengan cara yang rapi. Pembagian diterapkan untuk mengurangi keruwetan.
Pandangan esensial dan implementasi dari perangkat lunak diperlukan untuk
mengakomodasi batasan logis yang dibebankan oleh persyaratan pemrosesan dan batasan
fisik yang dibebankan oleh elemen sistem yang lain. Perekayasa perangkat lunak yang
mempercayai prinsip tersebut akan dapat lebih mengembangkan spesifikasi perangkat lunak
yang kemudian akan menjadi dasar yang kuat bagi desain.






Domain Informasi
Pemodelan
Domain Informasi
Semua aplikasi perangkat lunak secara kolektif dapat disebut data processing.

Menarik bahwa istilah itu berisi sebuah kunci ke pemahaman terhadap persyaratan perangkat
lunak. Perangkat lunak dibangun untuk memproses data, menstraformasi data dari bentuk
yang satu kebentuk yang lain, yaitu untuk menerima input, memanipulasinya dengan
berbagai cara, dan menghasilkan output. Pernyataan mendasar dari sasaran ini benar bila kita
membangun perangkat lunak batch untuk system daftar gaji atau perangkat lunak real-time
embedded untuk mengontrol aliran bahan bakar ke mesin kendaraan bermotor.
Tetapi sangat penting untuk dicatat bahwa perangkat lunak juga memproses event.
Event mewakili banyak aspek dari control system dan tidak lebih daripada data Boolean –
baik on atau off, true or false, there or not there. Sebagai contoh, sensor tekanan mendeteksi
bahwa tekanan melampaui batas nilai aman dan mengirimkan sebuah sinyal alarm ke
monitoring perangkat lunak. Sinyal alarm tersebut merupakan suatu event yang mengontrol
tingkah laku system. Dengan demikian, data (bilangan, karakter, citra, suara, dll) dan control
(kejadian), keduanya ada pada domain informasi dari suatu masalah.

Prinsip analisis operasional yang pertama membutuhkan suatu pengujian domain
informasi. Domain informasi berisi tiga pandangan yang berbeda dari data dan control ketika
masing – masing dip roses oleh program computer :
1) Muatan dan hubungan informasi
2) Aliran informasi,
3) Struktur informasi.
Untuk benar – benar memahami domain informasi, masing – masing dari pandangan tersebut
harus diperhatikan.
Muatan Informasi mewakili data dan objek control individual yang terdiri dari
beberapa kumpulan informasi yang lebih besar yang di transformasikan oleh perangkat lunak.
Misalnya, objek data paycheck merupakan sebuah gabungan dari sejumlah data yang penting:
nama pembayar, jumlah bersih yang dibayarkan, pembayaran keseluruhan, potongan, dan
seterusnya. Demikianlah, muatan dari paycheck ditentukan oleh atribut – atribut yang
dibutuhkan untuk membuatnya. Dengan cara yang sama, muatan dari suatu objek control
yang disebut status system dapat dibatasi oleh sebuah string dari banyak bit. Masing – masing
bit mewakili jenis informasi yang berbeda yang menunjukkan apakah perangkat tertentu itu
on-line atau off-line.
Objek data dan control dapat dihubungkan dengan objek data dan control lainnya.
Sebagai contoh, objek data paycheck memiliki satu hubungan atau lebih dengan objek
timecard, employee, bank dan lain – lain. Selama analisis domain informasi, hubungan –
hubungan itu harus ditetapkan.
Aliran informasi mewakili cara dimana data dan kontrol berubah pada saat masing –
masing bergerak melalui sebuah system. Spereti diperlihatkan pada Gambar 11.3, objek input
ditransformasikan ke informasi intermediate ( data dan atau control), dan lebih jauh lagi
ditransformasikan ke output. Sepanjang jalur transformasi tersebut, informasi tambahan dapat
dimunculkan dari penyimpanan data yang ada (seperti, file disket atau memory buffer).
Transformasi yang diaplikasikan merupakan fungsi atau subfungsi yang harus dilakukan oleh
sebuah program. Data dan control yang bergerak diantara dua (fungsi) transformasi
menentukan interface dari masing” fungsi.
Struktur informasi mewakili organisasi internal dari berbagai jenis data dan control.
Apakah jenis data akan diorganisasi sebagai sebuah table n-dimensi atau sebagai sebuah
struktur pohon hirarki? Dalam konteks struktur, informasi apa yang dihubungkan dengan
informasi lain? Apakah semua informasi di isikan ke dalam sebuah struktur tunggal atau akan

digunakan struktur yang berbeda? Bagaimana informasi dalam suatu struktur informasi
berhubungan dengan informasi pada struktur yang lain? Pertanyaan – pertanyaan tersebut
dijawab dengan suatu penilaian struktur informasi. Harus dicatat juga bahwa struktur data,
konsep yang berhubungan yang akan di diskusikan pada buku ini, mengacu pada
perancangan dan implementasi informasi.


Pemodelan
Kita menciptakan model untuk memperoleh pemahaman yang lebih baik mengenai

entitas actual yang akan dibangun. Bila entitas tersebut berupa sebuah bentuk fisik
(bangunan, pesawat, mesin), kita dapat membangun model yang identik dalam bentuk dan
potongan, tetapi dalam skala yang lebih kecil. Tetapi bila entitas yang akan dibangun adalah
perangkat lunak, maka model harus memakai bentuk yang berbeda. Model harus dapat
memodelkan informasi yang di transformasikan oleh perangkat lunak, fungsi (dan subfungsi)
yang memungkinkan transformasi terjadi, dan tingkah laku system pada saat transformasi
terjadi.
Selama analisis persyaratan perangkat lunak, kita menciptakan model system yang
akan dibuat. Model tersebut berfokus pada apa yang harus dilakukan oleh system, bukan pada
bagaimana system melakukannya. Dalam beberapa kasus, model yang kita buat
menggunakan notasi grafis yang menggambarkan informasi, pemrosesan, tingkah laku
system, dan karakteristik lain sebagai symbol yang berbeda dan dapat dikenali. Bagian lain
dari model dapat benar – benar tekstual. Informasi deskriptif dapat diberikan dengan
menggunakan bahasa natural atau bahasa khusus untuk menggambarkan persyaratannya.
Model dalam perangkat

lunak

harus

dapat

memodelkan

informasi

yang

ditransformasikan oleh perangkat lunak, fungsi (dan subfungsi) yang memungkinkan
transformasi terjadi, dan tingkah laku sistem pada saat transformasi terjadi.
Dalam beberapa kasus, model yang kita buat menggunakan notasi grafis yang
menggambarkan informasi, pemrosesan, tingkah laku sistem, dan karakteristik lain sebagai
simbol yang berbeda dan dapat dikenali. Informasi deskriptif dapat diberikan dengan
menggunakan bahasa natural atau bahasa khusus untuk menggambarkan persyaratannya.
Prinsip analisis operasional mengharuskan kita membangun model fungsi dan tingkah
laku, yaitu:
1) Model Fungsional
Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat
lunak harus melakukan paling tidak tiga fungsi genetik: input, pemrosesan, dan output. Pada

saat model fungsional dari suatu aplikasi dibuat, perekayasa perangkat lunak memfokuskan
diri pada fungsi-fungsi masalah khusus. Model fungsi dimulai dengan sebuah model
tingkat konteks tunggal (yakni nama perangkat lunak yang akan dibuat).
Dengan serangkaian iterasi, maka lebih banyak lagi detail fungsional diberikan, sampai
seluruh rancangan dari semua fungsionalitas sistem terwakili.
2) Model Tingkah Laku
Sebagian besar perangkat lunak merespon kejadiankejadian dari dunia luar. Karakteristik
stimulus-respon ini membentuk dasar dari model tingkah laku. Model tingkah laku
menciptakan representasi pernyataan-pernyataan perangkat lunak dan event-event yang
menyebabkan perangkat lunak mengubah pernyataan. Model yang diciptakan selama analisis
persyaratan melayani sejumlah peran penting:


Model membantu analis dalam memahami informasi, fungsi, dan tingkah laku suatu
sistem, sehingga membuat tugas analisis persyaratan menjadi lebih mudah dan lebih



sistematis.



kelengkapan, konsistensi, dan akurasi dari spesifikasi.

Model menjadi titik fokus bagi kajian sehingga merupakan kunci bagi penentuan

Model menjadi dasar bagi pengerjaan desain, memberi perancang suatu representasi
esensial dari perangkat lunak yang dapat diterjemahkan ke dalam suatu konteks
implementasi.

Meskipun metode pemodelan yang digunakan sering menjadi masalah preferensi personal
atau organisasional, aktivitas pemodelan adalah dasar bagi kerja analisis yang baik.
Pembagian
Masalah sering menjadi terlalu luas atau terlalu rumit untuk dipahami sebagai satu
kesatuan. Karena itulah kita cenderung membagi masalah seperti itu ke dalam bagian-bagian
sehingga dapat dipahami dengan mudah dan kemudian membangun interface antara bagianbagian tersebut, sehingga keseluruhan fungsi dapat dilakukan. Prinsip analisis operasi
keempat menyatakan bahwa domain informasi, fungsional, dan tingkah laku perangkat lunak
dapat dibagi-bagi.
Secara mendasar pembagian mendekomposisi suatu masalah ke dalam bagian
konstituennya. Secara konseptual, kita membangun sebuah representasi hirarki dari informasi
atau fungsi dan kemudian membagi elemen bagian paling atas dengan (1)mengekspos detail
pertambahan dengan bergerak secara vertikal dalam hirarki, (2)mendekomposisi masalah
dengan bergerak secara horisontal dalam hirarki. Contoh: system keamanan safehome

Pandangan esensial dan implementasi
Pandangan esensial persyaratan perangkat lunak menyajikan fungsi yang akan
dikerjakan dan dan di informasikan yg akan diproses tanpa melihat detail implementasinya.
Contoh: Pandangan esensial dari fungsi safehome read sensor status Tidak tergantung dari
bentuk fisik dari data atau type sensor yang di gunakan. Pandangan implementasi persyaratan
perangkat lunak menyajikan manifestasi dunia nyata dari pemrosessan fungsi-fungsi dan
struktur informasi. Contoh: Input safehome dimana perangkat/ element (sensor)
menggunakan pertimbangan pandangan implementasi.
menggunakan pertimbangan pandangan implementasi.

V.

PEMBUATAN MODEL PROTOTYPE PERANGKAT LUNAK
Prototyping

perangkat

lunak (software

prototyping)

adalah

salah

satu

metode siklus hidup sistem yang didasarkan pada konsep model bekerja (working model).
Pendekatan Prototyping adalah proses iterative yang melibatkan hubunan kerja yang dekat
antara perancang dan pengguna. Pressman (2001) menyatakan bahwa seringkali seorang
pelanggan mendefinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak
mengidentifikasi kebutuhan input, pemrosesan, ataupun output detail. Pada kasus yang lain,
pengembang mungkin tidak memiliki kepastian terhadap efisiensi algoritme, kemapuan
penyesuaian dari sistem operasi, atau bentuk-bentuk yang harus dilakukan oleh interaksi
manusia dan mesin. Dalam situasi seperti ini salah satu model yang cocok digunakan adalah
model prototype (Prototyping paradigm). Model Prototype dapat dilihat pada gambar
dibawah ini.

Pendekatan Prototyping melewati tiga proses, yaitu pengumpulan kebutuhan, perancangan,
dan evaluasi Prototype. Proses-proses tersebut dapat dijelaskan sebagai berikut:

1) Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum,
kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan
berikutnya.
2) Perancangan: perancangan dilakukan cepat dan rancangan mewakili semua
aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatanprototype.
3) Evaluasi Prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk
memperjelas kebutuhan software.
Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan
terpenuhi. prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk
memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan kembali
untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan.
Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien
mendapat gambaran awal dari Prototype.
Prototipe mendukung dua kegiatan proses rekayasa persyaratan

 Elisitasi persyaratan: user bereksperimen untuk melihat bagaimana sistem dapat
mendukung pekerjaan mereka dan memberikan usulan atau ide-ide baru.

 Validasi persyaratan: Prototipe dapat menunjukkan kesalahan-kesalahan atau ketidaksesuaian yang mungkin terjadi.
 Bentuk Prototipe
Berdasarkan karakteristiknya prototipe sebuah sistem dapat berupa low fidelity dan
high fidelity. Fidelity mengacu kepada tingkat kerincian sebuah sistem (Walker et al, 2003).
Low fidelity prototype tidak terlalu rinci menggambarkan sistem. Karakteristik dari low
fidelity prototype adalah mempunyai fungsi atau interaksi yang terbatas, lebih
menggambarkan kosep perancangan dan layout dibandingkan dengan model interaksi, tidak
memperlihatkan secara rinci operasional sistem, mendemostrasikan secara umum feel and
look dari antarmuka pengguna dan hanya menggambarkan konsep pendekatan secara umum
(Walker et al, 2003).
High fidelity protoype lebih rinci menggambarkan sistem. Prototipe ini mempunyai
interaksi penuh dengan pengguna dimana pengguna dapat memasukkan data dan berinteraksi
dengan dengan sistem, mewakili fungsi-fungsi inti sehingga dapat mensimulasikan sebagian
besar fungsi dari sistem akhir dan mempunyai penampilan yang sangat mirip dengan produk
sebenarnya (Walker et al, 2003).

Fitur yang akan diimplementasikan pada prototipe sistem dapat dibatasi dengan teknik
vertikal atau horizontal. Vertical prototype mengandung fungsi yang detail tetapi hanya untuk
beberapa fitur terpilih, tidak pada keseluruhan fitur sistem. Horizontal prototype mencakup
seluruh fitur antarmuka pengguna namun tanpa fungsi pokok hanya berupa simulasi dan
belum dapat digunakan untuk melakukan pekerjaan yang sebenarnya (Walker et al, 2003).
 Proses Pembuatan Prototipe
Proses pembuatan prototipe merupakan proses yang interaktif dan berulang-ulang
yang menggabungkan langkah-langkah siklus pengembangan tradisional. Prototipe dievaluasi
beberapa kali sebelum pemakai akhir menyatakan protipe tersebut diterima. Gambar di
bawah ini mengilustrasikan proses pembuatan prototipe :

Langkah-Langkah Prototyping
a) Analisis Kebutuhan Sistem
Pembangunan sistem informasi memerlukan penyelidikan dan analisis mengenai
alasan timbulnya ide atau gagasan untuk membangun dan mengembangkan sistem informasi.
Analisis dilakukan untuk melihat berbagai komponen yang dipakai sistem yang sedang
berjalan meliputi hardware, software, jaringan dan sumber daya manusia. Analisis juga
mendokumentasikan aktivitas sistem informasi meliputi input, pemrosesan, output,
penyimpanan dan pengendalian (O'Brien, 2005).
Selanjutnya melakukan studi kelayakan (feasibility study) untuk merumuskan
informasi yang dibutuhkan pemakai akhir, kebutuhan sumber daya, biaya, manfaat dan
kelayakan proyek yang diusulkan (Mulyanto, 2009).

Analisis kebutuhan sistem sebagai bagian dari studi awal bertujuan mengidentifikasi
masalah dan kebutuhan spesifik sistem. Kebutuhan spesifik sistem adalah spesifikasi
mengenai hal-hal yang akan dilakukan sistem ketika diimplementasikan (Mulyanto, 2009).
Analisis kebutuhan sistem harus mendefinisikan kebutuhan sistem yang spesifik antara lain :
1)

Masukan yang diperlukan sistem (input)

2)

Keluaran yang dihasilkan (output)

3)

Operasi-operasi yang dilakukan (proses)

4)

Sumber data yang ditangani

5)

Pengendalian (kontrol)

Spesifikasi Kebutuhan Sistem
Tahap analisis kebutuhan sistem memerlukan evaluasi untuk mengetahui kemampuan
sistem dengan mendefinisikan apa yang seharusnya dapat dilakukan oleh sistem tersebut
kemudian menentukan kriteria yang harus dipenuhi sistem. Beberapa kriteria yang harus
dipenuhi adalah pencapaian tujuan, kecepatan, biaya, kualitas informasi yang dihasilkan,
efisiensi dan produktivitas, ketelitian dan validitas dan kehandalan atau reliabilitas
(Mulyanto, 2009).
b) Desain Sistem
Analisis sistem (system analysis) mendeskripsikan apa yang harus dilakukan sistem
untuk memenuhi kebutuhan informasi pemakai. Desain sistem (system design) menentukan
bagaimana sistem akan memenuhi tujuan tersebut. Desain sistem terdiri dari aktivitas desain
yang menghasilkan spesifikasi fungsional. Desain sistem dapat dipandang sebagai desain
interface, data dan proses dengan tujuan menghasilkan spesifikasi yang sesuai dengan produk
dan metode interface pemakai, struktur database serta pemrosesan dan prosedur pengendalian
(Ioanna et al., 2007).
Desain sistem akan menghasilkan paket software prototipe, produk yang baik
sebaiknya mencakup tujuh bagian :

1) Fitur menu yang cepat dan mudah.
2) Tampilan input dan output.
3) Laporan yang mudah dicetak.
4) Data dictionary yang menyimpan informasi pada setiap field termasuk panjang field,
pengeditan dalam setiap laporan dan format field yang digunakan.
5) Database dengan format dan kunci record yang optimal.
6) Menampilkan query online secara tepat ke data yang tersimpan pada database.
7) Struktur yang sederhana dengan bahasa pemrograman yang mengizinkan pemakai
melakukan pemrosesan khusus, waktu kejadian, prosedur otomatis dan lain-lain.
c) Pengujian Sistem
Paket software prototipe diuji, diimplementasikan, dievaluasi dan dimodifikasi
berulang-ulang hingga dapat diterima pemakainya (O'Brien, 2005). Pengujian sistem
bertujuan menemukan kesalahan-kesalahan yang terjadi pada sistem dan melakukan revisi
sistem. Tahap ini penting untuk memastikan bahwa sistem bebas dari kesalahan (Mulyanto,
2009).
Menurut Sommerville (2001) pengujian sistem terdiri dari :
1) Pengujian unit untuk menguji komponen individual secara independen tanpa
komponen sistem yang lain untuk menjamin sistem operasi yang benar.
2) Pengujian modul yang terdiri dari komponen yang saling berhubungan.
3) Pengujian sub sistem yang terdiri dari beberapa modul yang telah diintegrasikan.
4) Pengujian sistem untuk menemukan kesalahan yang diakibatkan dari interaksi antara
subsistem dengan interfacenya serta memvalidasi persyaratan fungsional dan non
fungsional.
5) Pengujian penerimaan dengan data yang dientry oleh pemakai dan bukan uji data
simulasi.
6) Dokumentasi berupa pencatatan terhadap setiap langkah pekerjaan dari awal sampai
akhir pembuatan program.
Pengujian sistem informasi berbasis web dapat menggunakan teknik dan metode
pengujian perangkat lunak tradisional. Pengujian aplikasi web meliputi pengujian tautan,
pengujian browser, pengujian usabilitas, pengujian muatan, tegangan dan pengujian malar
(Simarmata, 2009).

Penerimaan pengguna (user) terhadap sistem dapat dievaluasi dengan mengukur
kepuasan user terhadap sistem yang diujikan. Pengukuran kepuasan meliputi tampilan sistem,
kesesuaian dengan kebutuhan user, kecepatan dan ketepatan sistem untuk menghasilkan
informasi yang diinginkan user. Ada beberapa model pengukuran kepuasan user terhadap
sistem, diantaranya adalah Technology Acceptance Model (TAM), End User Computing
(EUC) Satisfaction, Task Technology Fit (TTF) Analysis dan

Human Organizational

Technology (HOT) Fit Model.
Salah satu model pengukuran yang telah diterjemahkan ke dalam beberapa bahasa
berbeda dan tidak menunjukkan perbedaan hasil pengukuran yang signifikan adalah End User
Computing (EUC) Satisfaction. Model ini menekankan kepuasan user terhadap aspek
teknologi meliputi aspek isi, keakuratan, format, waktu dan kemudahan penggunaan sistem
(Chin & Mathew, 2000).
d) Implementasi
Setelah prototipe diterima maka pada tahap ini merupakan implementasi sistem yang
siap dioperasikan dan selanjutnya terjadi proses pembelajaran terhadap sistem baru dan
membandingkannya dengan sistem lama, evaluasi secara teknis dan operasional serta
interaksi pengguna, sistem dan teknologi informasi.
 Pemilihan prototyping
Paradigma prototyping terbatas dan tidak terbatas. Pendekatan terbatas sering disebut:
throw away prototyping. Dengan menggunakn pendekatan tersebut, prototyping sebagai
sebuah demonstrasi kasar dari sebuah persyaratan.Kemudian prototype dikesampingkan dan
perangkat lunak direkayasa dgn menggunakan suatu paradigma yang berbeda.Pendekatan
tidak terabatas sering disebut evolusionary prototyping,menggunakan prototyping sebagai
bagian utama dari aktivitas analisis yang akan diteruskan ke dalam desain dan konstruksi.
Sebelum perangkat terbatas atau tidak terbatas dipilih, perlu ditentukan apakah system yang
akan

dibangun

dapat

menerima

prototyping

atau

tidak.Sejumlah

factor

calon

prototyping[BOA84] dapat ditentukan: area aplikasi, kompleksitas aplikasi, krakteristik
pelanggan, dan karakteristik proyek.

 Proses Pengembangan Prototipe

 Metode dan Peranti Prototyping
Agar prototyping perangkat lunak efektif, maka harus dikembangkan suatu prototype
dengan cepat sehingga pelanggan dengan dapat menilai hasil dan perubahan yang di
rekomendasikan. Untuk melakukan prototyping dengan tepat ada tiga kelas metode dan
peranti generik misal: (AND 92,TAN 92) : teknik generasi keempat komponen perangkat
lunak reusable, spesifikasi normal,dan lingkungan prototyping.
 Prototipe Pada Proses Perangkat Lunak

Tujuan Pemrograman Evolusioner dan Throw-away



2.

Evolusioner : Menyerahkan sistem kepada user untuk menjalankan semua prioritas
utama
Throw-Away : Mem-Validasi dan menurunkan persyaratan sistem.

Kelebihan dan Kekurangan

Keunggulan prototyping adalah :
1)

Adanya komunikasi yang baik antara pengembang dan pelanggan.

2)

Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan.

3)

Pelanggan berperan aktif dalam pengembangan sistem.

4)

Lebih menghemat waktu dalam pengembangan sistem.

5)

Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya

Sedangkan kelemahan prototyping adalah :
1)

Pelanggan tidak melihat bahwa perangkat lunak belum mencerminkan kualitas

perangkat lunak secara keseluruhan dan belum memikirkan peneliharaan dalam jangka waktu
yang lama.
2)

Pengembang biasanya ingin cepat menyelesaikan proyek sehingga menggunakan

algoritma dan bahasa pemrograman sederhana.
3)

Hubungan pelanggan dengan komputer mungkin tidak menggambarkan teknik

perancangan yang baik.
Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih
cepat, namun tidak semua prototype bisa dimanfaatkan. Sekalipun prototype memudahkan
komunikasi

antar developer dan

klien,

membuat

klien

mendapat

gambaran

awal

dari Prototype. Pendekatan ini memiliki beberapa keuntungan :
1. Pemodelan membutuhkan partisipasi aktif dari end-user. Hal ini akan meningkatkan
sikap dan dukungan pengguna untuk pengerjaan proyek. Sikap moral pengguna akan
meningkat karena system berhubungan nyata dengan mereka.
2. Perubahan dan iterasi merupakan konsekuensi alami dari pengembangan systemsehingga end user memiliki keinginan untuk merubah pola pikirnya.Prototyping lebih
baik menempatkan situasi alamiah ini karena mengasumsikan perubahan model
melalui iterasi kedalam system yang dibutuhkan.
3. Prototyping mematahkan folosofi “end user tidak mengetahui secara detail apa yang
dibutuhkan sampai mereka melihat implementasinya”
4. Prototyping adalah model aktif, tidak pasif, sehingga end user dapat melihat,
merasakan, dan mengalaminya.
5. Kesalahan yang terjadi dalam prototyping dapat dideteksi lebih dini
6. Prototyping dapat

meningkatkan

kreatifitas

karena

membolehkan

adanyafeedback dari end user. Hal ini akan memberikan solusi yang lebih baik.
7. Prototyping mempercepat beberapa fase hidup dari programmer.
McLeod dan Schell (2001) mengemukakan bahwa alasan-alasan pemakai maupun spesialis
informasi menyukai model prototype adalah:

1. Komunikasi antara analis sistem dan pemakai membaik
2. Analis dapat bekerja dengan lebih baik dalam menemukan kebutuhan pemakai
3. Pemakai berperan lebih aktif dalam pengembangan system
4. Spesialis informasi dan pemakai menghabiskan lebih sedikit waktu dan usaha dalam
mengembangkan sistem;
5. Implementasi menjadi lebih mudah karena pemakai mengetahui sistem yang
diharapkan.
Tetapi, terdapat beberapa kelemahan dari prototyping, kelemahan tersebut antara lain :
1. Prototyping memungkinkan terjadinya pengembalian terhadap kode, implementasi,
dan perbaikan siklus hidup yang dugunakan untuk mendominasi sistem informasi.
2. Prototyping tidak menolak kebutuhan dari fase analisis sistem. Prototype hanya dapat
memecahkan masalah yang salah dan memberi kesempatan sebagai sistem
pengembangan konvensional.
3. Perancangan issu numerik tidak dialamaykan oleh prototyping. Isu tersebut dapat
dilupakan jika pengguna tidak berhati-hati.
4. Prototyping dapat mengurangi kreatifitas perancangan.
Prototyping terkadang dapat memberikan performansi yang lambat, membantu mendapatkan
kebutuhan detil lebih baik namun demikian Prototype juga menimbulkan masalah:
a) Dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas,
kemudahan dipelihara/dikembangkan, dan kecocokan dengan lingkungan yang
sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras
terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan
produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya.
b) Developer biasanya melakukan kompromi dalam beberapa hal karena harus
membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai,
bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana.
c) Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan
developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan
kebutuhan software.