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

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

Sebagai contoh:

 Waktu tanggap penyajian informasi maksimal selama satu menit.

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

 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

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

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

Cara yang digunakan untuk dapat memahami masalah biasanya adalah:  Wawancara dengan pemakai

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

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

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

 Fungsi apa yang diinginkan

 Kelakuan sistem apa yang diharapkan

 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

sehari-hari 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,

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

2) Kebutuhan antarmuka:

 antarmuka pemakai untuk merekam data penjualan.

 antarmuka pemakai untuk menyajikan dan menjurnal informasi nilai transaksi penjualan periode tertentu.

 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

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

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

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

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

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

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

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.

 Model menjadi titik fokus bagi kajian sehingga merupakan kunci bagi penentuan kelengkapan, konsistensi, dan akurasi dari spesifikasi.

 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

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

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,

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 ketidak-sesuaian 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

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

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

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

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

 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

 Evolusioner : Menyerahkan sistem kepada user untuk menjalankan semua prioritas utama

 Throw-Away : Mem-Validasi dan menurunkan persyaratan sistem.

2. Kelebihan dan Kekurangan

Keunggulan prototyping adalah :

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

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

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

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