ANALISIS SISTEM

By : Fatimah Nur Ar ifah, M.Kom, MTA

 KONSEP DASAR ANALISIS

 1 penyelidikan thd suatu peristiwa (karangan, perbuatan, dsb)

untuk mengetahui keadaan yg sebenarnya (sebab-musabab,
duduk perkaranya, dsb);
 2 penguraian suatu pokok atas berbagai bagiannya dan
penelaahan bagian itu sendiri serta hubungan antarbagian
untuk memperoleh pengertian yg tepat dan pemahaman arti
keseluruhan;
 3 penjabaran sesudah dikaji sebaik-baiknya;
 4 pemecahan persoalan yg dimulai dengan dugaan akan
kebenarannya;
 Tahapan Analisis merupakan tahapan yang kritis pada
pengembangan suatu sistem informasi. 

Perlukah sw
dikembangkan
Apa
? alasannya?

Layakkah
Seperti apa
dikembangkan
sw tsb? ?
 LANGKAH-LANGKAH ANALISIS SISTEM :

1.Identify (identifikasi masalah)

2.Understand (memahami kerja dari sistem yang ada)
3.Analyze (menganalisa sistem)
1.Needs/Requirements
2.Feasibility
4.Report (membuat laporan hasil analisis)
 ILUSTRASI

 Lembaga kursus yang sudah berdiri lama dan sekarang memiliki

banyak siswa dan program kursus.
 Yayasan menginginkan adanya laporan progres kemajuan
lembaga kursus, siswa, dan tentornya. Bisa diakses dari jauh.
 Proses administrasi dikelola oleh karyawan dengan sistem
pencatatan pada buku lalu direkap ke dalam file MSoffice di
komputer. Berkas-berkas asli dan salinan disimpan secara fisik
dan membutuhkan ruang khusus.
 Materi kursus disimpan dalam ruang khusus.
 Proses penggajian dilakukan oleh karyawan dibantu dengan
aplikasi MsOffice.
 Lokasi kursus ada di pinggiran jalan di tengah kota, dengan
potensi bencana alam seperti banjir dan angin.
 Lembaga kursus lain juga sedang tumbuh.
 Apa analisis anda ?
 Motif pengembangan
 Masalah
 Peluang
 Instruksi
 seperti apa konsep sistem/software yang dirancang?
 Untuk scope kecil, kegiatan analisis bisa saja tidak perlu
terlalu detail
 Bagaimana bila scope luas?
 Bagaimana bila pengembangan software butuh
pertanggungjawaban dan kelanjutan?
 Cukupkah analisis untuk projek semacam ini dilakukan
dengan sederhana?
 Potensi permasalahan selama pengembangan software?
Masalah teknis, budget, tim,
HAL PENTING DALAM PENGEMBANGAN
SOFTWARE

Analisis
kebutuhan
 BAGAIMANA MELAKUKANNYA?

 Developer datang
 System analyst mengidentifikasi
 Kombinasi developer dan client
 Client datang
 Client sudah memiliki IT staf dan sudah membuat daftar kebutuhan
 Client meng-hire konsultan
 Terkadang client ambigu dalam membuat daftar kebutuhan
 ANALISIS KEBUTUHAN

 Kebutuhan perangkat lunak adalah kondisi atau kemampuan

yang harus dimiliki oleh perangkat lunak
untuk memenuhi apa yang disyaratkan atau diinginkan oleh
pemakai
 Tujuan analisis kebutuhan perangkat lunak adalah:
 Memahami masalah yang akan dibuat perangkat lunaknya secara
komprehensif.
 Mendefinisikan apa yang harus dikerjakan oleh perangkat lunak
untuk memenuhi keinginan pemakai.
 Analisis kebutuhan dilakukan untuk menghasilkan spesifikasi
kebutuhan
 Spesifikasi kebutuhan adalah spesifikasi yang rinci tentang
hal-hal yang akan dilakukan sistem ketika
diimplementasikan.
 Dipakai untuk membuat kesepahaman antara pengembang
sistem dengan pemakai yang kelak menggunakan sistem
 PERBEDAAN CARA PANDANG CLIENT
DENGAN DEVELOPER
 Ada developer yang lebih merasa efektif dalam
menyelesaikan project dengan membuat spesifikasi
kebutuhan dan desain yang benar di awal
 Client melihat progress dari sisi seberapa jauh kebutuhan
tadi sudah terealisasi.
 BAGAIMANA MELAKUKANNYA

Memahami masalah Research Permasalahan

Identifikasi kebutuhan Research Kebutuhan

Mendefinisikan kebutuhan Kebutuhan fungsional Non Fungsional

 MEMAHAMI
PERMASALAHAN
 Inti Masalah

Research

Request
 Pada tahap ini, masalah yang akan dibuat perangkat
lunaknya dipelajari sehingga dapat ditentukan:

Siapa Dimana sw
pemakai sw akan dipakai

Pekerjaan apa yang

akan dilakukan
Bagaimana
dengan sw pekerjaan tsb

Apa masalah
Langkah yang dilakukan analis sistem:

 Wawancara
 Riset terhadap sistem sekarang
 Observasi lapangan
 Kuesioner
 Pengamatan terhadap sistem serupa
 Prototype
MENGIDENTIFIKASI
KEBUTUHAN
 Langkah dalam mengidentifikasi kebutuhan mirip dengan
memahami masalah, pada prakteknya bisa dilaksanakan
bersamaan dengan tahap memahami permasalahan.
 Hanya saja, subtansi yang ditanyakan biasanya adalah:
 data atau informasi apa yang akan diproses,
 fungsi apa yang diinginkan,
 Perilaku/kerja sistem apa yang diharapkan,
 antarmuka apa yang tersedia (user interfaces, hardware interfaces,
software interfaces).
 karena kita menggunakan Unified Process,
 kebutuhan yang berhasil diidentifikasi pada tahap ini dapat
digambarkan dengan tools
 Tujuannya:
 Agar lebih mudah dipahami saat proses verifikasi kebutuhan dengan
client
 Tools yang kita pakai:
 UML (use case, activity diagram)
MENDEFINISIKAN
KEBUTUHAN
“saya harus  Saat mengidentifikasi kebutuhan
bisa melihat pemakai, informasi yang
informasi diperoleh belum terstruktur.
neraca Butuh analisis untuk
kapanpun saya menerjemahkannya.
mau”  Pemakai akan mengungkapkan
apa yang dibutuhkannya dengan
bahasa sehari-hari yang biasa
“saya ingin agar digunakan pemakai.
setiap transaksi  Sebagai contoh, ungkapan
simpan pinjam kebutuhan pemakai di Bagian
dapat terjurnal Akuntansi, misalnya:
dengan otomatis”
 TERJEMAHKAN KE BAHASA KEBUTUHAN
FUNGSIONAL
 Kebutuhan fungsional: “saya ingin agar
 Fasilitas transaksi simpan- setiap transaksi
pinjam. simpan pinjam
 Posting tiap transaksi simpan dapat terjurnal
pinjam ke dalam transaksi jurnal dengan otomatis”
secara otomatis dengan
pasangan akun sbb:
 Simpanan : Kas (D) – Simpanan
Anggota (K)
 Pinjaman : Piutang Pinjaman
Anggota (D) – Kas (K)
 Kebutuhan Sistem Informasi dibagi menjadi 2 (dua):
 Kebutuhan Fungsional
 Kebutuhan Non Fungsional
 FUNGSIONAL

 Fungsional:
 Mendeskripsikan layanan sistem secara fungsional.
 Bisa jadi high-level statements (user) atau detailed descriptions
(system)
 Harus dijelaskan secara komplit dan konsisten.
Contoh:
 Sistem Pencari lokasi buku
 Kebutuhan fungsional :
 Sistem mempu menunjukkan lokasi buku setelah item buku
di klik.
 Statement di atas ambigu.
 Maksud user adalah peta/jalan menuju rak buku
 Developer menerjemahkan hanya gambar rak buku dan posisi saja.
 Revisi: Sistem mampu menunjukkan lokasi buku dalam
bentuk peta/jalan menuju lokasi rak buku setelah item buku
di klik
 CONTOH KEB FUNGSIONAL

 Sistem mampu melakukan pencarian data buku berdasarkan

judul, penerbit, pengarang, isi ringkasan buku.
 Sistem menampilkan data buku yang meliputi gambar sampul,
judul, penerbit, pengarang, tahun, sisa buku di rak
 Sistem mampu menunjukkan lokasi buku dalam bentuk
peta/jalan menuji lokasi rak buku setelah item buku di klik
 NON-FUNGSIONAL

 Non-fungsional
 Deskripsi dari system properties dan constraints :
 reliability, response time, storage requirements, I/O device capability, dll.
 Non-fungsional Bisa saja lebih kritis daripada fungsional. Jika tidak
terpenuhi, bisa saja sistem akan useless.
 Satu kebutuhan non-fungsional dapat mempengaruhi munculnya
kebutuhan fungsional baru
Product requirements
 Kinerja produk secara khusus
Operational requirements
 Kebutuhan hardware, software
Organisational requirements
 Menyesuaikan Kebijakan organisasi
External requirements
 Lingkup luar sistem, misal legal, undang-undang
Goals and requirements dalam kebutuhan non-
fungsional
 Goal
 Tujuan akhir dari fungsi tertentu
 Verifiable non-functional requirement
 Statement yang mengindikasikan tercapainya goal. Harus dapat ditest
secara objektif dengan ukuran tertentu.
 EXAMPLE

 Sistem e-credit untuk food court

 Pengunjung datang dan diberi kartu yang dapat digunakan untuk
membeli makanan dan minuman. Goalnya adalah sistem ini mampu
memberikan kecepatan dan kemudahan transaksi pemesanan dan
pembayaran makanan/minuman
 PRODUCT REQUIREMENTS

 Kecepatan transaksi
 Software harus mampu menangani 1 transaksi pesanan dalam batas
waktu 30 detik
 1 Transaksi pembayaran harus dapat dilakukan dalam batas waktu
45 detik
 Kapasitas transaksi
 Sistem harus mampu melayani hingga minimal 1000 transaksi
pesanan dalam satu hari
 Robustness/ketahanan
 Saat terjadi error dalam transaksi, sistem mampu merestart dan
kembali siap dalam waktu 1 menit.
 Sistem mampu menangani 30 transaksi bersamaan dengan delay
waktu maksimal 20 detik.
ORGANIZATIONAL REQUIREMENTS
 Transaksi hanya dapat dilayani oleh karyawan dengan ID Card
 Satu kartu dapat berlaku untuk individu maupun rombongan
 Limit transaksi untuk satu kartu adalah 300rb
 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.
 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).
 KASUS

 Referensi : Analisa dan Perancangan Sistem Informasi : Hanif

Al Fatta : Andi Offset