analisa kebutuhan

Luh Made Yulyantari, S.Kom., M.Pd.

Analisa Kebutuhan

Kebutuhan Perangkat Lunak

Kebutuhan perangkat lunak adalah kondisi atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan pemakai.

Jenis Kebutuhan Perangkat Lunak

Kebutuhan FungsionalKebutuhan AntarmukaKebutuhan Unjuk Kerja

Kebutuhan Fungsional (functional requirement)

Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat lunak.Contoh:o Perangkat lunak harus dapat menyimpan semua rincian data

pesanan pelanggan.o Perangkat lunak harus mampu mencetak laporan penjualan

sesuai periode yang diinputkan.o Perangkat lunak harus mampu menyajikan informasi jalur

pengiriman terpendek.

Kebutuhan Antarmuka (interface requirement)

Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data.Contoh:o Akses ke basis data menggunakan ODBC (Open Data Base

Connectivity).o Perangkat untuk memasukkan data menggunakan keyboard,

mouse, dan scanner.

Kebutuhan Unjuk Kerja (performance requirement)

Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak, seperti kecepatan, ketepatan, atau frekuensi.Contoh:o Waktu tanggap penyajian informasi maksimal selama satu

menit.o Perangkat lunak harus mampu mengolah data sampai 1 juta

record untuk setiap transaksi.o Perangkat lunak harus dapat digunakan secara multi user sesuai

otoritas yang diberikan kepada masing-masing pemakai.

Pengertian Analisis Kebutuhan

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

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.

Pentingnya Analisis Kebutuhan

Pendefinisian kebutuhan yang baik dapat menjadi faktor sukses pelaksanaan pengembangan perangkat lunak. Sebaliknya akan menyebabkan banyak kegagalan. Menurut hasil survey DeMarco, 56% kegagalan proyek perangkat lunak adalah karena ketidaklengkapan pendefinisian kebutuhan.

Pentingnya Analisis Kebutuhan (2)

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 (sekitar 82% dari total biaya perbaikan).

the real problem

correctspecification

erroneousspecification

correctdesign

erroneousdesign

design basedon erroneousspecification

correctprogram

programmingerror

program basedon erroneous

design

program basedon erroneousspecification

correctfunctions

correctableerrors

uncorrectableerrors

hiddenerrors

imperfect programproducts

Requirementsspecification

Design

Implementation

Testing

Dampak Kesalahan Penentuan Kebutuhan

Perangkat lunak yang dihasilkan tidak akan memenuhi kebutuhan pemakai yang sebenarnya.Intepretasi kebutuhan yang berbeda-beda sehingga dapat menyebabkan ketidaksepakatan antara pelanggan dan pengembang, menyia-nyiakan waktu dan biaya, dan mungkin akan menghasilkan perkara hukum.Pengujian kesesuaian perangkat lunak dengan kebutuhan yang dimaksud tidak akan mungkin dilaksanakan dengan benar.Waktu dan biaya akan terbuang percuma untuk membangun perangkat lunak yang salah.

Tahap Kebutuhan Perangkat lunak

Adanya masalah yang membutuhkan penyelesaian:o orientasi aplikasi, misalnya inventoryo orientasi bisnis, misalnya produk baru, peramalan pendapatano orientasi peningkatan produk, misalnya pemeliharaan

Munculnya ide untuk membuat sebuah perangkat lunak yang baru

Urutan Aktivitas Analisis Kebutuhan Perangkat Lunak

1. Mempelajari dan memahami persoalan2. Mengidentifikasi kebutuhan pemakai3. Mendefinisikan kebutuhan perangkat lunak4. Membuat dokumen spesifikasi kebutuhan5. Mengkaji ulang (review) kebutuhan

Mempelajari dan Memahami Masalah

Pada tahap ini, masalah yang akan dibuat perangkat lunaknya dipelajari sehingga dapat ditentukan :o siapa pemakai yang akan menggunakan perangkat lunako dimana perangkat lunak akan digunakano pekerjaan apa dari pemakai yang akan dibantu oleh perangkat

lunako dari dan sampai mana cakupan pekerjaan tersebut, dan

bagaimana mekanisme pelaksanaannyao apa yang menjadi kendala atau keterbatasannya dilihat dari sisi

teknologi yang akan digunakan atau dari sisi hukum dan standar

Mempelajari dan Memahami Masalah (2)

Cara yang digunakan untuk dapat memahami masalah biasanya adalah:o wawancara dengan pemakaio observasi atau pengamatan lapangano kuesionero mempelajari referensi atau dokumen-dokumen yang digunakan,

seperti dokumen hasil analisis dan perancangan sistemHasil 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.

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:o data atau informasi apa yang akan diproseso fungsi apa yang diinginkano kelakuan sistem apa yang diharapkano antarmuka apa yang tersedia (user interfaces, hardware

interfaces, software interfaces, dan communications interfaces)

Mengidentifikasi Kebutuhan Pemakai (2)

Untuk dapat menangkap kebutuhan pemakai dengan baik, utamanya kesamaan persepsi, dibutuhkan:o komunikasi dan brainstorming yang intensifo prototype perangkat lunak, atau screen snapshoto data atau dokumen yang lengkap

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.

Mendefinisikan Kebutuhan Perangkat Lunak (2)

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.

Hasil Analisa Yang Terstruktur

Kebutuhan fungsional:entry dan rekam data transaksi penjualan.retrieve nilai transaksi penjualan untuk periode tertentu (sesuai periode yang diinputkan melalui keyboard).rekam nilai akumulasi transaksi penjualan periode tertentu ke jurnal umum berikut account pasangannya (kas).

Kebutuhan antarmuka:antarmuka pemakai untuk merekam data penjualan.antarmuka pemakai untuk menyajikan dan menjurnal informasi nilai transaksi penjualan periode tertentu.jaringan lokal untuk menghubungkan perangkat lunak aplikasi di Bagian Penjualan dengan perangkat lunak aplikasi di Bagian Akuntansi.

Hasil Analisa Yang Sudah Terstruktur (2)

Kebutuhan unjuk kerja:ada otoritas pemakaian perangkat lunak dan akses data.proses jurnal hanya dapat dilakukan sekali setelah data transaksi penjualan direkam.

Mendefinisikan Kebutuhan Perangkat Lunak

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.

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.

Spesifikasi Kebutuhan Perangkat Lunak

SKPL adalah dokumen yang berisi pernyataan lengkap dari apa yang harus dilakukan atau dipenuhi oleh perangkat lunak, tanpa menjelaskan bagaimana hal tersebut dilaksanakan oleh perangkat lunak. Selain itu, SKPL pun berisi deskripsi lengkap dari semua antarmuka yang ada dalam perangkat lunak.

Tujuan SKPL

Sarana komunikasi antara pelanggan, pemakai, analis, dan perancang perangkat lunak.Dasar untuk merencanakan dan melaksanakan pengujian sistem.Acuan untuk melakukan perbaikan atau pengubahan perangkat lunak.

Manfaat Dokumentasi SKPL

Memastikan kesamaan antara kebutuhan untuk pengembangan dengan kebutuhan yang ditulis dalam dokumen.Mendefinisikan kerangka kerja bersama untuk proses-proses pengembangan perangkat lunak.Memperjelas peran dan antarmuka bagi para pihak yang terlibat dalam proses-proses pengembangan perangkat lunak.Memperjelas jenis dan isi dari dokumen.Mengenali tugas-tugas, tahapan-tahapan, baselines, aktivitas kaji ulang, dan dokumentasinya.Belajar dari pendekatan praktis yang diterapkan di dunia industri.Menghilangkan jebakan-jebakan dan persoalan-persoalan seperti yang dialami di masa lalu.

Yang Dipaparkan Dalam SKPL

Secara umum SKPL harus mencantumkan semua kebutuhan yang harus dipenuhi oleh perangkat lunak. Selain itu, SKPL pun harus dapat mendefinisikan atribut-atribut perangkat lunak, seperti: keandalan (reliability), ketersediaan (availability), keamanan (security), kemampuan untuk dapat dipelihara (maintainability), dan portabilitas (portability).

Tidak Harus Dicantumkan di SKPL

Kebutuhan-kebutuhan proyek, seperti jadwal, biaya, milestone, laporan-laporan, dan sebagainya.Rancangan perangkat lunak.Rencana jaminan produk, seperti rencana validasi dan verifikasi atau rencana pengujian.

Penulisan SKPL Yang Baik

BenarSetiap kebutuhan yang dinyatakan dalam SKPL merepresentasikan kebutuhan dari perangkat lunak yang akan dibangun.

Tidak bias (unambiguous)Setiap kebutuhan yang dinyatakan dalam SKPL hanya memiliki satu arti atau satu interpretasi.

Lengkapsemua kebutuhan yang harus dilakukan perangkat lunak.definisi dari bentuk tanggapan perangkat lunak terhadap semua kelas data masukan dari berbagai situasi.identifikasi yang lengkap dari setiap halaman, gambar dan tabel, penjelasan istilah-istilah yang digunakan, dan rujukan-rujukan.tidak ada bagian yang dinyatakan dengan “akan didefinisikan kemudian” (to be define).

Penulisan SKPL Yang Baik (2)

Dapat diverifikasiSetiap kebutuhan yang dinyatakan dalam SKPL dapat diperiksa dan diuji kebenarannya.

KonsistenSemua atau sebagian kebutuhan yang dinyatakan dalam SKPL tidak bertentangan dokumen-dokumen lain yang disusun sebelumnya, seperti dokumen spesifikasi kebutuhan sistem.

Dapat dipahami oleh pelangganIsi SKPL harus dapat dimengerti oleh pelanggan dan pemakai, walaupun ada notasi-notasi formal yang digunakan didalamnya


Dapat dimodifikasiStruktur dan gaya penulisan SKPL memungkinkan untuk diubah dengan mudah jika ada perubahan kebutuhan, tetapi tetap konsisten dan lengkap.

Dapat ditelusuriSKPL dapat ditelusuri jika ditulis dalam bentuk yang dapat menjelaskan dari mana asal kebutuhan dan kebutuhan bagaimana direalisasi.

Mempunyai keterangan (annotated)Setiap kebutuhan diurutkan sesuai tingkat kepentingan atau kestabilannya, dan diberikan keterangan apakah kebutuhan tersebut merupakan keharusan, disarankan, atau optional.

RingkasIsi SKPL ditulis dengan kalimat-kalimat yang ringkas dan jelas.


TerorganisasiPenulisan kebutuhan diorganisasi dengan tata letak tertentu sehingga memudahkan untuk mencarinya.

Hindari Dalam Penulisan SKPL

Memberikan penjelasan yang berlebih-lebihan dan berulang-ulang sehingga menjadi tidak jelas.Menggunakan istilah secara tidak konsisten.Menyatakan keterukuran kebutuhan secara tidak jelas, misalnya dengan menggunakan kata-kata: minimal, maksimal, optimial, cepat, user-friendly, mudah, sederhana, normal, efisien, fleksibel, dan/atau, dan lain-lain, atau dan sebagainya.Menuliskan “mimpi-mimpi”, yaitu hal-hal yang tidak akan dapat dilakukan oleh perangkat lunak.

Orang Yang Terlibat Dalam SKPL

PemakaiKelompok orang yang akan mengoperasikan atau menggunakan produk dari perangkat lunak yang dibuat

PelangganIndividu atau perusahaan yang menginginkan dan membiayai pembuatan perangkat lunak.

Analis Sistem (System Engineer)Kelompok orang yang biasanya melakukan kontak teknik pertama kali dengan pelanggan. Bertugas menganalisis persoalan, mengenali dan menuliskan kebutuhan.

Orang Yang Terlibat Dalam SKPL (2)

Software EngineerKelompok orang yang akan bekerja sama dengan System Engineer saat mendefinisikan kebutuhan perangkat lunak, dan membuat deskripsi perancangannya.

PemrogramKelompok orang yang akan menerima spesifikasi perancangan perangkat lunak, membuat modul-modul program, menguji, dan memeriksa modul.

Test Integration GroupKelompok orang yang akan melakukan pengujian dan integrasi modul program.

Maintenance GroupMemantau dan merawat performansi sistem perangkat lunak yang dibuat selama pelaksanaan dan pada saat modifikasi muncul (80% dari pekerjaan).

Orang Yang Terlibat Dalam SKPL (3)

Technical SupportKelompok orang, konsultan atau orang yang mempunyai kepandaian lebih tinggi, yang akan memberikan dukungan teknis kepada pengembang perangkat lunak.

Staf dan Clerical WorkKelompok orang yang bertugas mengetik, memasukkan data, dan membuat dokumen.

1. PENDAHULUAN

1.1 Kegunaan1.2 Ruang Lingkup1.3 Definisi, Akronim, dan Singkatan1.4 Referensi1.5 Ikhtisar

2. DESKRIPSI UMUM

2.1 Perspektif Produk2.2 Fungsi Produk2.3 Karakteristik Pemakai2.4 Batasan-batasan2.5 Asumsi dan Ketergantungan

3. KEBUTUHAN RINCI

3.1 Kebutuhan Antarmuka Eksternal3.1.1 Antarmuka Pemakai3.1.2 Antarmuka Perangkat Keras3.1.3 Antarmuka Perangkat Lunak3.1.4 Antarmuka Komunikasi

3.2 Kebutuhan Fungsional3.2.1 Deskripsi Kebutuhan Fungsional3.2.2 Diagram Konteks3.2.3 Diagram Aliran Data

3.2.3.1 Diagram Aliran Data Proses 13.2.3.2 Diagram Aliran Data Proses 2..3.2.3.n Diagram Aliran Data Proses n

3.2.4 Kamus Data

3.2.4.1 Tempat Penyimpanan Data3.2.4.2 Aliran Data

3.2.5 Spesifikasi Proses3.2.5.1 Proses 13.2.5.2 Proses 2.3.2.5.m Proses m

3.3 Kebutuhan Performansi3.4 Kendala Perancangan3.5 Atribut Sistem Perangkat Lunak3.6 Kebutuhan Lain

PendekatanTerstruktur

PendekatanObjek

1. PENDAHULUAN

1.1 Kegunaan1.2 Ruang Lingkup1.3 Definisi, Akronim, dan Singkatan1.4 Referensi1.5 Ikhtisar

2. DESKRIPSI UMUM

2.1 Perspektif Produk2.2 Fungsi Produk2.3 Karakteristik Pemakai2.4 Batasan-batasan2.5 Asumsi dan Ketergantungan

3. KEBUTUHAN RINCI

3.1 Kebutuhan Antarmuka Eksternal3.1.1 Antarmuka Pemakai3.1.2 Antarmuka Perangkat Keras3.1.3 Antarmuka Perangkat Lunak3.1.4 Antarmuka Komunikasi

3.2 Kebutuhan Fungsional3.2.1 Deskripsi Kebutuhan Fungsional3.2.2 Diagram Use Case3.2.3 Skenario

3.2.3.1 Skenario Use Case 13.2.3.2 Skenario Use Case 2..3.2.3.n Skenario Use Case n

3.3 Kebutuhan Performansi3.4 Kendala Perancangan3.5 Atribut Sistem Perangkat Lunak3.6 Kebutuhan Lain

Verfikasi

Verifikasi statis, dilakukan dengan menginspeksi secara mendalam model dari perangkat lunak yang meliputi model data, objek, ataupun tampilannya, sedangkan secara dinamis dengan melakukan pengujian secara langsung terhadap akurasi dan kemampuan produk yang dihasilkan.Verifikasi dinamis, produk perangkat lunak yang dihasilkan diujji dengan memberikan perlakukan umum dan benar seuai dengan lingkungan pengguna

Validasi

Validasi dibutuhkan untuk memberikan kepastian bahwa rancangan dan dokumen dari sistem yang akan diimplementasikan telah sesuai dengan keinginan dan kebutuhan pemangku kepentingan

Perlu definisi dan pengertian yang menyeluruh terhadap tujuan bisnis yang diinginkan.Penyeimbangan antara rancangan antarmuka pengguna logika program, dan pengujiannya dengan hati-hati.Diperlukan bentuk formalisasi spesifikasi dan melakukan klarifikasi kepada pelanggan apabila terjadi kerancuan pada spesifikasi kebutuhanAdanya acuan reference standar yang bisa dijadikan acuan pelanggan dan pengembangPerlu adanya penawaran yang jelas dalam satu fitur dan prioritas, yang menentukan tingkat prioritas sesuai dengan fungsionalitas, kompleksitas, serta biaya.Dan lain-lain.

Contoh Kamus Data

analisa kebutuhan

Documents