A.

Analisis Kebutuhan Perangkat Lunak

Kebutuhan perangkat lunak adalah kondisi, kriteria, syarat atau kemampuan
yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau
diinginkan pemakai.
Ada tiga buah jenis kebutuhan perangkat lunak
1) Kebutuhan fungsional (functional requirement) / kebutuhan operasional
Merupakan 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 dapat membuat laporan penjualan sesuai dengan periode
waktu tertentu.
 Perangkat lunak harus mampu menyajikan informasi jalur pengiriman barang
terpendek.
2) Kebutuhan antarmuka (interface requirement)
Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen
perangkat keras, perangkat lunak, atau basis data.
Sebagai contoh:
 Perangkat untuk memasukkan data dapat berupa keyboard, mouse atau scanner.
 Akses ke basisdata menggunakan ODBC (Open Database Connectivity).

3) Kebutuhan unjuk kerja (performance requirement)

Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh
perangkat lunak, misalnya: kecepatan, ketepatan, frekuensi.
Sebagai contoh:
 Perangkat lunak harus bisa mengolah data sampai 1 juta record untuk tiap
transaksi.
 Perangkat lunak harus dapat digunakan oleh multiuser sesuai dengan otoritas yang
diberikan pada user.
 Waktu tanggap penyajian informasi maksimal selama satu menit.

Pendefinisian kebutuhan merupakan aktivitas yang sangat penting, karena

sangat mempengaruhi sukses atau gagalnya pelaksanaan pengembangan perangkat
lunak. Menurut hasil survey DeMarco, 56% kegagalan proyek pengembangan
perangkat lunak dikarenakan ketidaklengkapan pendefinisian kebutuhan dari
perangkat lunak tersebut. Perhatikan gambar dampak kesalahan kumulatif akibat
kesalahan dalam pendefinisian kebutuhan pada Gambar 4.1.

Dari gambar terlihat bahwa produk perangkat lunak yang tidak sempurna akan
dihasilkan karena kesalahan pada saat menentukan spesifikasi kebutuhan. Jika
kesalahan tersebut diketahui di akhir siklus hidup pengembangan, usaha untuk
memperbaikinya akan sangat mahal.

Gambar 4.1 Dampak Kesalahan Kumulatif

 Selain itu, kesalahan penentuan kebutuhan akan memberikan dampak:
1) Perangkat lunak yang dihasilkan tidak akan memenuhi kebutuhan pemakai yang
sebenarnya.
2) Interpretasi kebutuhan yang berbeda-beda sehingga dapat menyebabkan
ketidaksepakatan antara pelanggan dan pengembang, menyia-nyiakan waktu dan
biaya, dan mungkin akan menghasilkan perkara hukum.
3) Pengujian kesesuaian perangkat lunak dengan kebutuhan yang dimaksud tidak
akan mungkin dilaksanakan dengan sesungguhnya.
4) Waktu dan biaya akan terbuang percuma untuk membangun sistem yang salah.

Analisis Kebutuhan

Analisis kebutuhan perangkat lunak (software requirements analysis)

merupakan aktivitas awal dari siklus hidup pengembangan perangkat lunak. Untuk
proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah
tahap rekayasa sistem/informasi dan software project planning.

Analisis kebutuhan dapat diartikan sebagai berikut :

1) Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan
sistem atau perangkat lunak.
2) Proses untuk menetapkan fungsi dan unjuk kerja perangkat lunak, menyatakan
antarmuka perangkat lunak dengan elemen-elemen sistem lain, dan menentukan
kendala yang harus dihadapi perangkat lunak.

Tujuan pelaksanaan analisis kebutuhan adalah

1) Memahami masalah secara menyeluruh (komprehensif) yang ada pada perangkat
lunak yang akan dikembang seperti ruang lingkup produk perangkat
lunak(product space) dan pemakai yang akan menggunakannya.
2) Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi
keinginan pelanggan.

Tahapan Analisis Kebutuhan

1) Mempelajari dan memahami persoalan
 Pada tahap ini, seorang analis mempelajari masalah yang ada pada perangkat lunak
yang dikembangkan, sehingga dapat ditentukan
o siapa pemakai yang menggunakan perangkat lunak.
o dimana perangkat lunak akan digunakan .
o pekerjaan apa saja dari pemakai yang akan dibantu oleh perangkat lunak.
o apa saja cakupan dari pekerjaan tersebut, dan bagaimana mekanisme
pelaksanaannya.
o apa yang menjadi kendala dilihat dari sisi teknologi yang digunakan atau dari
sisi hukum dan standar.
Cara yang digunakan oleh pengembang khususnya analis dalam memahami
masalah perangkat lunak biasanya dilakukan
o wawancara dengan pemakai
o observasi atau pengamatan lapangan
o kuesioner
o mempelajari referensi atau dokumen-dokumen yang digunakan, seperti
dokumen hasil analisa dan perancangan perangkat lunak.

Hasil dari pemahaman masalah tersebut dapat digambarkan dengan model-model

tertentu sesuai dengan jenis permasalahannya. Sebagai contoh jika masalah bisnis
dapat digambarkan dengan flowmap atau bussiness use case untuk analisa berorientasi
objek. Sedangkan untuk masalah matematika dapat digambarkan dengan graf.

2) Mengidentifikasi kebutuhan pemakai

Pada tahap identifikasi kebutuhan pemakai (user requirement) in pada prakteknya
menjadi satu pelaksanaannya dengan pemahaman masalah. Hanya saja substansi yang
ditanyakan ada sedikit perbedaan, yaitu
o fungsi apa yang diinginkan pada perangkat lunak.
o data atau informasi apa saja yang akan diproses.
o kelakuan sistem apa yang diharapkan.
o antarmuka apa yang tersedia (software interfaces, hardware interfaces, user
interfaces, dan communication interfaces)

Untuk menangkap kebutuhan dari pemakai dengan baik,terutama kesamaan persepsi.

seorang analis membutuhkan
 o komunikasi dan brainstorming yang intensif dengan pelanggan.
o pembuatan prototype perangkat lunak atau screenshoot.
o Data atau dokumen yang lengkap.

3) Mendefinisikan kebutuhan perangkat lunak

Saat melakukan pengidentifikasian kebutuhan pemakai, informasi yang
diperoleh masih belum terstruktur. Biasanya pemakai akan mengungkapkan apa yang
diinginkan dengan bahasa sehari-hari yang biasa mereka gunakan. Sebagi contoh,
ungkapan kebutuhan pemakai dibagian akutansi.
o saya ingin data yang dimasukkan oleh bagian penjualan bisa langsung
dijurnal.
o Informasi neraca keuangan bisa saya lihat kapan saja.
Kemudian pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut akan
akan dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional,
antarmuka dan unjuk kerja perangkat lunak. Sebagai contoh, kebutuhan “data yang
dimasukkan oleh bagian penjualan bisa langsung dijurnal” setelah dianalisis,
diklasifikasikan dan diterjemahkan, mungki akan menghasilkan pendefinisian
kebutuhan sebagai berikut.
a. Kebutuhan fungsional
 Entri dan rekam data transaksi penjualan.
 Retrieve data transaksi penjualan untuk periode tertentu (periode sesuai
dengan inputan periode yang diinputkan pada keyboard).
 Rekam data akumulasi transaksi penjualan periode tertentu ke jurnal
umum berikut account pasangannya (kas).
b. Kebutuhan antarmuka
 Antarmuka pemakai untuk memasukkan dan merekam data penjualan.
 Antarmuka pemakai untuk menyajikan dan menjurnal informasi
transaksi penjualan pada periode tertentu.
 Antarmuka untuk jaringan lokal yang menghubungkan perangkat lunak
aplikasi dibagian penjualan dengan perangkat lunak aplikasi dibagian
akutansi.
c. Kebutuhan unjuk kerja
  proses jurnal hanya bisa dilakukan sekali setelah data transaksi penjualan
direkam.
 Adanya otoritas pemakaian perangkat lunak dan akses data sesuai dengan
bagian pekerjaan masing-masing.

Kemudian kebutuhan tersebut akan dimodelkan atau digambarkan dengan teknik

analisis dan alat bantu tertentu. Sebagai contoh kebutuhan fungsional dapat
dimodelkan dengan menggunakan
- Data flow diagram,kamus data,dan spesifikasi proses jika menggunakan anlisis
tertsruktur
- Use case diagram dan skenario sistem jika menggunkan analisis berorientasi
objek.
4) Membuat dokumen spesifikasi kebutuhan perangkat lunak (SKPL)
Semua kebutuhan yang telah didefinisikan selanjutnya dibuat dokumentasinya yaitu
Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirement
Specification (SRS). Dokumen ini dibuat untuk menyatakan secara lengkap apa yang
dapat dilakukan oleh perangkat lunal, termasuk deskripsi lengkap semua antarmuka
yang akan digunakan.

5) Mengkaji ulang (review) kebutuhan

Proses untuk mengkaji ulang (validasi) kebutuhan apakah SKPL sudah konsisten,
lengkap, dan sesuai dengan yang diinginkan oleh pemakai. Proses ini bisa dilakukan
lebih dari satu kali. Dan sering kali akan muncul kebuthan-kebutuhan baru dari
pemakai. Oleh karena itu, diperlukannya negosiasi antara pengembang dengan
pelanggan sesuai dengan prinsip “win win solution” sampai kebutuhan tersebut
disetujui oleh kedua belah pihak.
Sedangkan menurut Pressman, analisis kebutuhan perangkat lunak dapat
dibagi menjadi lima area pekerjaan, yaitu:
a) Pengenalan masalah
b) Evaluasi dan sistesis
c) Pemodelan
d) Spesifikasi
e) Tinjau ulang (review)
B. Teknik Komunikasi dan Prinsip – Prindip Analisis

Komunikasi adalah proses penyampaian suatu pesan oleh seseorang kepada

orang lain untuk memberi tahu atau untuk mengubah sikap, pendapat, atau perilaku,
baik langsung secara lisan, maupun tak langsung melalui media.

Menurut Gause dan Weinberg menyarankan agar analis memulainya dengan

mengajukan pertanyaan bebas konteks, dimana pertanyaan tersebut berfokus pada
pelanggan, tujuan keseluruhan, dan keuntungan.

Rangkaian pertanyaan berikutnya memungkinkan analis mendapatkan

pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan
persepsinya terhadap suatu pemecahan.

 Masalah apakah yang akan diselesaikan oleh pemecahan ini?

 Dapatkah anda memperlihatkan kepada saya atau menjelaskan lingkungan dimana
pemecahan tersebut akan digunakan

Teknik Komunikasi

 Mengawali Proses

Gause dan Weinberg [GAU89] menyarankan agar analis memulainya dengan

mengajukan pertanyaan bebas konteks, dimana pertanyaan tersebut berfokus pada
pelanggan, tujuan keseluruhan, dan keuntungan.

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 analisi persyaratan.

Prinsip – Prinsip Analisis

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

semua metode analisis dihubungkan oleh serangkaian prinsip operasional:

 Domain informasi dari suatu masalah harus direpresentasikan dan dipahami.

 Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
 Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus
diwakilkan.
 Model-model yang menggambarkan informasi, fungsi, dan tingkah laku harus
dipecah-pecah dalam suatu cara yang membongkar suatu detail dalam bentuk
lapisan.
 Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
 Prinsip analisis operasional mengharuskan kita membangun model fungsi dan
tingkah laku, yaitu:
 Model Fungsional: Perangkat lunak mentransformasi informasi, dan untuk
melakukannya, perangkat lunak harus melakukan paling tidak tiga fungsi
genetik: input, pemrosesan, dan output.

Dengan mengaplikasikan prinsip – prinsip tersebut, analis mendekati suatu

masalah secara sistematis. Domain informasi diuji sehingga fungsi itu dapat di pahami
secara lebih lengkap. Model – model digunakan sehingga karakteristik fungsi dan
tingkah laku dapat dikomunikasikan dengan cara yang rapi. Pembagian diterapkan
untuk mengurangi keruwetan. Pandanagan esensial dan implementasi dari perangkat
lunak diperlukan untuk mengakomodasi batasan logis yang dibebankan oleh
persyaratan pemrosesan dan batasan fisik yang dibebankan oleh elemen system yang
lain.
Sebagai tambahan untuk prinsip analisis operasional tersebut, Davis [DAV95a]
mengusulkan serangkaian5 prinsip panduan untuk “rekayasa persyaratan”:

 Mengembangkan prototype yang memungkinkan seorang pemakai

memahami bagaimana interaksi manusia dengan mesin terjadi. Karena
persepsi mengenai
 kualitas prangkat lunak sering di dasarkan pada persepsi “friendliness”
interface, maka prototyping (dan terasi yang dihasilkan) sangatlah dianjurkan.
 Merekam asal dan alas an untuk setiap persyaratan. Hal ini merupakan
langkah pertama dalam membangun kemampuan penelusuran kembali ke
pelanggan.
 Menggunakan pandangan persyaratan bertingkat. Pembangunan data,
fungsional, dan model tingkah laku member perekayasa perangkat lunak
tiga pandangan berbeda. Hal ini mengurangi kemungkinan bahwa
inkonsistensi akan diketahui.
 Memprioritaskan persyaratan. Batas waktu yang tegas dapat menghalangi
implementasi setiap persyaratan perangkat lunak. Bila model proses
inkremental (Bab2) diaplikasikan, maka persyaratan yang disampaikan
dalam inkremental pertama harus di identifikasi.
 Berusaha mengurangi ambiguitas. Karena sebagian besar persyaratan di
gambarkan dalam bahasa natural, kemungkinan untuk terjadinya ambiguitas
selalu ada. Penggunaan kajian teknis formal merupakan satu – satunya cara
untuk mengurangi ambiguitas tersebut.

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
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.

C. Pembuatan Model Prototype Perangkat Lunak

Dahulu, rancangan fisik merupakan proses yang menggunakan kertas dan

pinsil. Seorang analis mengambarkan tata letak atau struktur dari output, input, basis
data, dan aliran hubungan dan prosedur. Ini merupakan proses yang memakan waktu
yang memiliki kemungkinan terjadinya kesalahan. Biasanya hasil dari rancangan
kertas ini adalah tidak lengkap dan tidak akurat. Sekarang, banyak analis dan
perancang memilih Prototyping, sebuah pendekatan berbasis rekayasa (engineering)
untuk merancang. 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.
Gambar 1 Prototype Paradigma

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 pembuatan
prototype;
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. 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
system-sehingga 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 adanya
feedback 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 sistem;
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:

1. 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.
2. 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.
3. Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan
developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan
kebutuhan software.