Analisis dan Desain

Sistem
Analisis dan Desain Sistem

Pada materi ini akan dibahas tentang analisis

sistem, yaitu bagaimana mendefinisikan kebutuhan
terkait sistem yang akan dikembangkan.
Hasil akhir dari tahap analisis sistem di sini adalah
sebuah dokumen yang menjelaskan mengenai
spesifikasi kebutuhan sistem informasi atau SRS
(Software Requirement Specification).
Desain sistem informasi adalah tahap berikutnya
yang harus dilakukan setelah analisis desain.
 Definisi Analisis Sistem
(Requirement)
 Kegiatan analisis sistem (requirement) adalah
kegiatan melihat sistem yang sudah berjalan, melihat
bagian mana yang bagus dan tidak bagus, dan
kemudian mendukumentasikan kebutuhan yang akan
dipenuhi dalam sistem yang baru.
 Kadang kala untuk beberapa proyek sistem informasi,
kegiatan analisis dan desain berjalan bersama-sama.
 Sering rancu antara bagian mana yang tergolong
analisis dan yang tergolong desain.
...

 Requirement adalah gambaran dari

layanan (services) dan batasan bagi sistem
yang akan dibangun.
 Pernyataan atau gambaran pelayanan yang
disediakan oleh sistem, batasan­batasan
dari sistem dan bisa juga berupa definisi
matematis fungsi­fungsi sistem.
Fungsi Requirement

 Menjadi dasar penawaran suatu kontrak 

harus terbuka untuk masukan.
 Menjadi dasar kontrak  harus didefinisikan
secara detail.
 Requirement Engineering: Proses
menemukan, menganalisis, men
dokumentasikan dan pengujian layanan­
layanan dan batasan.
...

 Requirement tidak hanya ditulis oleh pembangun, tapi

sebelumnya justru ditulis oleh klien yang memesan
software.
 Klien menuliskan requirement dalam bentuk yang
masih abstrak tentang kebutuhannya.
 Kemudian requirement tersebut diserahkan kepada
tim pembangun.
 Saat sudah ada persetujuan pembangun pun kemudian
menuliskan kemampuan sistem yang bisa dipahami
oleh klien, inipun disebut requirement.
Teknik Pengumpulan Data
(Requirement)
 Interviews: Memberi informasi yang terbaik,
mahal.
 Questionnaires: Bagus jika banyak orang
terlibat dan tersebar, respon cenderung
kurang baik.
 Observation: Akurat jika dilakukan dengan
baik, mahal.
 Searching: Informasi terbatas, cenderung
tidak menampilkan hal­hal yang mungkin jadi
masalah.
Teknik Wawancara

 Keuntungan teknik wawancara:

 Lebih mudah dalam menggali bagian sistem mana
yang dianggap baik dan yang kurang baik.
 Jika ada bagian tertentu yang dianggap perlu untuk
digali lebih dalam, kita dapat langsung
menanyakannya kepada narasumber.
 Dapat menggali kebutuhan user dengan lebih bebas.
 User dapat mengungkapkan kebutuhannya dengan
lebih bebas.
...

 Kekurangan teknik wawancara:

 Wawancara akan sulit dilakukan jika
narasumber kurang dapat mengungkapkan
kebutuhannya.
 Pertanyaan dapat menjadi tidak terarah,
terlalu fokus pada hal-hal tertentu dan
mengabaikan bagian lainnya.
...

 Beberapa tips dalam teknik wawancara:

 Buatlah jadwal wawancara dengan narasumber dan beritahu
maksud dan tujuan wawancara.
 Buatlah panduan wawancara yang akan dijadikan arahan agar
pertanyaan dapat fokus ke hal-hal yang dibutuhkan.
 Gunakan pertanyaan yang mudah dipahami.
 Cobalah menggali tentang kelebihan dan kekurangan sistem
yang telah berjalan sebelumnya.
 Bisa melakukan improvisasi untuk menggali hal-hal yang
dianggap penting.
 Catat / rekam proses wawancara tersebut.
Teknik Observasi

 Keuntungan dalam teknik observasi:

 Analis dapat melihat langsung bagaimana
sistem lama berjalan.
 Mampu menghasilkan gambaran lebih baik
jika dibandingkan teknik lainnya.
...

 Kekurangan dalam teknik observasi:

 Membutuhkan waktu yang cukup lama karena
jika observasi dilakukan dalam waktu yang
singkat mana gambaran sistem secara keseluruhan
akan sulit diperoleh.
 Orang-orang yang sedang diamati biasanya
perilakunya akan berbeda dengan perilaku sehari-
hari.
 Dapat mengganggu pekerjaan orang-orang pada
bagian yang sedang diamati.
...

 Tips dalam teknik observasi:

 Tentukan hal-hal apa saja yang akan diobservasi akan
kegiatan observasi dapat menghasilkan hasil yang
maksimal.
 Mintalah ijin pada orang yang berwewenang pada
bagian yang akan diobservasi.
 Berusaha agar tidak mengganggu pekerjaan orang lain
di tempat observasi.
 Jika ada hal yang tidak jelas, cobalah bertanya dan
jangan membuat asumsi sendiri.
Teknik Kuisioner

 Keuntungan dalam teknik wawancara:

 Hasilnya lebih obyektif, karena kuisioner dapat
dilakukan kepada banyak orang sekaligus.
 Waktunya lebih singkat.
 Kelemahan dalam teknik wawancara:
 Responden cenderung malas untuk mengisi kuisioner.
 Sulit untuk membuat pertanyaan yang singkat, jelas
dan mudah untuk dipahami.
...

 Tips dalam teknik kuisioner:

 Hindari pertanyaan isian, lebih baik pilihan ganda,
karena responden biasanya malas untuk menulis
banyak, dan jika menuliskan sesuatu kadang susah
untuk dipahami. Pilihan ganda memudahkan
dalam proses rekapitulasi.
 Buatlah pertanyaan yang tidak terlalu banyak.
 Buatlah pertanyaan yang singkat, padat dan jelas.
Macam Requirement

 User requirement (kebutuhan pengguna)

 Pernyataan tentang layanan yang disediakan sistem dan
tentang batasan­batasan operasionalnya.
 Pernyataan ini dapat dilengkapi dengan gambar / diagram
yang dapat dimengerti dengan mudah.
 System requirement (kebutuhan sistem)
 Sekumpulan layanan / kemampuan sistem dan batasan­
batasannya yang ditulis secara detil.
 System requirement document sering disebut functional
specification (spesifikasi fungsional).
...

 A software design specification

(spesifikasi rancangan PL) :
 Gambaran abstrak dari rancangan software.
 Dasar bagi perancangan dan implementasi
yang lebih detil.
Pembaca Requirement
Kategori Software System
Requirement
 Fungsional Requirement
kebutuhan yang terkait dengan fungsi produk,
misalnya sistem informasi harus mampu mencetak
laporan, menampilkan grafik, notifikasi, dan lainnya.
 Development Requirement
kebutuhan yang terkait dengan tools untuk
pengembangan sistem informasi, baik perangkat
keras maupun perangkat lunak. Misalnya sistem
informasi dikembangkan dengan IDE Netbeans dan
StarUML untuk pemodelannya.
...

 Deployment Requirement
kebutuhan terkait dengan lingkungan di
mana sistem informasi akan digunakan
baik perangkat keras maupun perangkat
lunak. Misalnya sistem informasi berjalan
pada server dengan minimal RAM 4GB,
SO Ubuntu Server 9.
...

 Performance Requirement
kebutuhan terkait dengan ukuran kualitas
maupun kuantitas, khususnya terkait
dengan kecepatan, skalabilitas dan
kapasitas. Misalnya sistem informasi
harus mampu diakses oleh minimal 1000
user pada waktu yang bersamaan.
...

 Documentation Requirement
kebutuhan ini terkait dengan dokumen apa
saja yang akan disertakan dengan produk
akhir. Dokumen yang biasanya dihasilkan
pada tahap akhir pengembangan sistem
informasi antara lain dokumen teknis
(dimulai dari dokumen perencanaan proyek,
analisis, desain, sampai pengujian sistem),
user manual dan dokumen pelatihan.
...

 Support Requirement
kebutuhan terkait dukungan yang
diberikan setelah sistem informasi
digunakan. Dukungan teknis tersebut
antara lain adanya pelatihan bagi calon
pengguna.
...

 Miscellaneous Requirement
kebutuhan ini adalah kebutuhan-
kebutuhan tambahan lainnya yang belum
tercakup pada beberapa kategori
kebutuhan yang telah terdefenisi diatas.
Definisi Desain Sistem

 Desain atau perancangan dalam pembangunan

perangkat lunak merupakan upaya untuk
mengkonstruksi sebuah sistem yang memberikan
kepuasan akan spesifikasi kebutuhan fungsonal,
memenuhi target, memenuhi kebutuhan secara
implisit atau eksplisit penggunanya.
 Analisis dan desain sistem akan dijelaskan lebih
detail mulai dari analisis dan desain basis data,
pemrograman terstruktur dan berorientasi obyek.
Terima Kasih
Soal Latihan
Buatlah sebuah dokumen SRS (Software
Requirement Specification) untuk pengembangan
system informasi :
1.Apotek
2.Rumah Sakit
3.Koperasi
4.Bank
5.Sekolah
6.Perguruan Tinggi