Analisis kebutuhan

Materi pembelajaran

Berikut materi yang didapat saya dalam mata kuliah  RPL

Pokok bahasan :

1.      Analisis kebutuhan

2.      Analisis sistem

3.      Tahapan pembuatan sofware

4.      Perancangan

5.      projek

ANALISIS KEBUTUHAN PERANGKAT LUNAK

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

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 non fungsional (non fungctional )

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

b)   Kebutuhan Unjuk Kerja (performance requirement)

Kebutuhan  yang  menetapkan  karakteristik  unjuk  kerja  yang  harus  dimiliki  oleh

perangkat lunak, seperti kecepatan, ketepatan, atau frekuensi.

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.

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

·      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.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 berjalan dan ranah solusi dari sistem yang akan dibuat .

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

sistem perangkat lunak yang akan di bangun. 

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

·         Observasi atau pengamatan lapangan

·         Kuesioner

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

Hasil  pemahaman  masalah  tersebut  selanjutnya  digambarkan  dalam  bentuk  modelmodel 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,

mungkin memberikan hasil:

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

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.

PRINSIP-PRINSIP ANALISIS

Masing-masing  metode  analisis  memiliki  titik  pandang  yang  unik.  Tetapi  semua

metode analisis dihubungkan oleh serangkaian prinsip operasional:

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 (kejadian), keduanya ada pada domain informasi dari suatu masalah.

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.