analisa kebutuhan
Post on 15-Jul-2016
28 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
Penulisan SKPL Yang Baik (3)
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.
Penulisan SKPL Yang Baik (4)
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
top related