Analisis Kebutuhan Perangkat Lunak (Software Requirment Analysis)

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.

Pengertian Analisis Kebutuhan

Dengan mengadopsi pengertian tentang kebutuhan pada sub bab sebelumnya, analisis kebutuhan dapat diartikan sebagai berikut :

Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan sistem atau perangkat lunak [EE93].
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 [PRE01],

Tujuan pelaksanaan analisis kebutuhan adalah

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,
Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi keinginan pelanggan.

Tahapan Analisis Kebutuhan

Secara teknis pelaksanaan pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas:

1. Mempelajari dan memahami persoalan

Pada tahap ini, seorang analis mempelajari masalah yang ada pada perangkat lunak yang dikembangkan, sehingga dapat ditentukan

siapa pemakai yang menggunakan perangkat lunak.
dimana perangkat lunak akan digunakan
pekerjaan apa saja dari pemakai yang akan dibantu oleh perangkat lunak.
apa saja cakupan dari pekerjaan tersebut, dan bagaimana mekanisme pelaksanaannya.
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 NA biasanya dilakukan

wawancara dengan pemakai
observasi atau pengamatan lapangan
kuesioner kuesioner
mempelajari referensi atau dokumen-dokumen yang digunakan, seperti dokumen hasil analisa 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) ini pada prakteknya menjadi satu pelaksanaannya dengan pernahaman masalah. Hanya saja substansi yang ditanyakan ada sedikit perbedaan, yaitu

fungsi apa yang diinginkan pada perangkat lunak.
data atau informasi apa saja yang akan diproses.
kelakuan sistem apa yang diharapkan.

antarmuka apa yang tersedia (software interfaces, hardware interfaces, user interfaces, dan communication interfaces)

Untuk menangkap kebutuhan dari pemakai dengan balk,terutama kesamaan persepsi. seorang analis membutuhkan

komunikasi dan brainstorming yang intensif dengan pelanggan,
pembuatan prototype perangkat lunak atau screenshoot.
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.

saya ingin data yang dimasukkan oleh bagian penjualan bisa langsung dijurnal.
informasi neraca keuangan bisa saya lihat kapan saja.

Kemudian pads 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 analisis tertsruktur
Use case diagram dan skenario sistem jika menggunkan analisis berorientasi objek.

Metode analisis terstruktur tersebut akan dibahas secara detail pada bab ini dan bab,16 untuk metode analisis berorentasi 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 Wang (review) kebutuhan

Proses untuk mengkaji Wang (validasi) kebutuhan apakah SKPL sudah konsisten, lengkap, dan sesuai dengan yang diinginkan oleh pernakai. Proses ini blsa dilakukan lebih dari sate kali. Dan sering kali Akan muncul kebutuhan-kebutuhan barn dan 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 [PRE01], analisis kebutuh&n perangkat lunak dapat dibagi menjadi lima area pekerjaan, yaitu: