29
ANALISIS KEBUTUHAN ©Afijal, M.Kom

RPL (Pertemuan 3)

Embed Size (px)

DESCRIPTION

rpl

Citation preview

Page 1: RPL (Pertemuan 3)

ANALISIS KEBUTUHAN

©Afijal, M.Kom

Page 2: RPL (Pertemuan 3)

21/04/23 -ap- 2

Tujuan Instruksional Umum

• Bagian ini menjelaskan tentang pengertian kebutuhan dan analisis kebutuhan, tahap pelaksanaan analisis kebutuhan, serta dokumen spesifikasi kebutuhan.

• Setelah mempelajari bagian ini dengan baik, pembaca diharapkan dapat:– Memahami pengertian kebutuhan

perangkat lunak.– Memahami apa yang dimaksud dengan

analisis kebutuhan dan tahap pelaksanaannya.

Page 3: RPL (Pertemuan 3)

21/04/23 -ap- 3

Pokok Bahasan

•Pokok bahasan pada bagian ini meliputi:– Definisi dan konsep Kebutuhan

perangkat lunak– Tahap Pelaksanaan Analisis

Kebutuhan

Page 4: RPL (Pertemuan 3)

21/04/23 -ap- 4

Definisi Kebutuhan

Kebutuhan perangkat lunak adalah kondisi atau kemampuan yang

harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan oleh

pemakai

Page 5: RPL (Pertemuan 3)

21/04/23 -ap- 5

Jenis Kebutuhan

• Secara kategoris, ada tiga buah jenis kebutuhan perangkat lunak [IEE93]:– Kebutuhan fungsional (functional

requirement)– Kebutuhan antarmuka (interface

requirement)– Kebutuhan unjuk kerja (performance

requirement)• Kebutuhan antarmuka dan unjuk kerja

sering disebut Non-functional Requirement

Page 6: RPL (Pertemuan 3)

21/04/23 -ap- 6

Kebutuhan fungsional

• Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat lunak.

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

Page 7: RPL (Pertemuan 3)

21/04/23 -ap- 7

Kebutuhan antarmuka

• Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data.

• Contoh: Akses ke basis data menggunakan ODBC

(Open Data Base Connectivity). Perangkat untuk memasukkan data

menggunakan keyboard, mouse, dan scanner.

Page 8: RPL (Pertemuan 3)

21/04/23 -ap- 8

Kebutuhan unjuk kerja

• Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak, seperti kecepatan, ketepatan, atau frekuensi.

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

Page 9: RPL (Pertemuan 3)

21/04/23 -ap- 9

Analisis Kebutuhan

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

Page 10: RPL (Pertemuan 3)

21/04/23 -ap- 10

Analisis Kebutuhan

• Tujuan analisis kebutuhan perangkat lunak adalah:

–Memahami masalah yang akan dibuat perangkat lunaknya secara menyeluruh (komprehensif).

–Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi keinginan pemakai.

Page 11: RPL (Pertemuan 3)

21/04/23 -ap- 11

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.

Page 12: RPL (Pertemuan 3)

21/04/23 -ap- 12

Pentingnya Analisis Kebutuhan

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

Page 13: RPL (Pertemuan 3)

21/04/23 -ap- 13

Tahap Analisis Kebutuhan

• Tahap kebutuhan perangkat lunak dimulai dengan [DAV93]:– Adanya masalah yang membutuhkan

penyelesaian:• orientasi aplikasi, misalnya inventory• orientasi bisnis, misalnya produk baru, peramalan

pendapatan• orientasi peningkatan produk, misalnya pemeliharaan

– Munculnya ide untuk membuat sebuah perangkat lunak baru.

Page 14: RPL (Pertemuan 3)

21/04/23 -ap- 14

Tahap Analisis Kebutuhan

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 (SKPL).

Page 15: RPL (Pertemuan 3)

21/04/23 -ap- 15

Tahap Analisis Kebutuhan

• Secara teknis pelaksanaan pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas:– Mempelajari dan memahami persoalan– Mengidentifikasi kebutuhan pemakai– Mendefinisikan kebutuhan perangkat lunak– Membuat dokumen spesifikasi kebutuhan– Mengkaji ulang (review) kebutuhan

Page 16: RPL (Pertemuan 3)

21/04/23 -ap- 16

Proses Analisis Kebutuhan

Page 17: RPL (Pertemuan 3)

21/04/23 -ap- 17

Mempelajari dan memahami persoalan .. (1)

• 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

Page 18: RPL (Pertemuan 3)

21/04/23 -ap- 18

Mempelajari dan memahami persoalan .. (2)

• Cara yang digunakan untuk dapat memahami masalah biasanya adalah:– wawancara dengan

pemakai– observasi atau

pengamatan lapangan

– kuesioner

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

Page 19: RPL (Pertemuan 3)

21/04/23 -ap- 19

Mempelajari dan memahami persoalan .. (3)

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

Pemesanan Makanan

Pembayaran MakananPembeli

Penyerahan Makanan

Page 20: RPL (Pertemuan 3)

21/04/23 -ap- 20

Mengidentifikasi Kebutuhan Pemakai .. (1)

• Sebenarnya, tahap identifikasi kebutuhan pemakai (user requirement) ini pada prakteknya dilaksanakan bersamaan dengan pemahaman masalah.

• Cara yang digunakan pun relatif sama.

Page 21: RPL (Pertemuan 3)

21/04/23 -ap- 21

Mengidentifikasi Kebutuhan Pemakai .. (2)

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

Page 22: RPL (Pertemuan 3)

21/04/23 -ap- 22

Mengidentifikasi Kebutuhan Pemakai .. (3)

• 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

Page 23: RPL (Pertemuan 3)

21/04/23 -ap- 23

Mendefinisikan Kebutuhan Perangkat Lunak .. (1)• 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”

Page 24: RPL (Pertemuan 3)

21/04/23 -ap- 24

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.

Fungsional Unjuk Kerja

Antarmuka

Pemakai

Page 25: RPL (Pertemuan 3)

21/04/23 -ap- 25

Mendefinisikan Kebutuhan Perangkat Lunak .. (3)

• Kebutuhan pemakai (di Bagian Akuntansi)

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

“saya ingin data yang dimasukkan

oleh Bagian Penjualan bisa

langsung dijurnal”.

Page 26: RPL (Pertemuan 3)

21/04/23 -ap- 26

Mendefinisikan Kebutuhan Perangkat Lunak .. (4)

• 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

• Kebutuhan unjuk kerja:– ada otoritas

pemakaian perangkat lunak dan akses data.

– proses jurnal hanya dapat dilakukan sekali setelah data transaksi penjualan direkam.

Page 27: RPL (Pertemuan 3)

21/04/23 -ap- 27

Mendefinisikan Kebutuhan Perangkat Lunak .. (5)

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

Page 28: RPL (Pertemuan 3)

21/04/23 -ap- 28

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.

Page 29: RPL (Pertemuan 3)

21/04/23 -ap- 29

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 sering kali muncul kebutuhan-kebutuhan

baru dari pemakai. • Untuk itu, diperlukan negosiasi antara pihak

pengembang dengan pemakai sesuai prinsip “win-win solution” sampai kebutuhan tersebut dapat disepakati kedua belah pihak.