05 - Konsep Dan Prinsip Analisis Kebutuhan

Rekayasa Perangkat Lunak
(3 SKS)
Semester 3
Tahun Akademik 2019-2020
Sesi 5
Konsep dan Prinsip Analisis Kebutuhan
Hanya dipergunakan untuk kepentingan pengajaran dilingkungan Universitas Informatika dan Bisnis Indonesia-
Pembahasan
• Analisis Persyaratan
• Prinsip-Prinsip Analisis
• Area Kerja Analisis
– Identifikasi dan Perumusan Masalah
– Evaluasi dan Sintesis
– Pemodelan Analisis
– Spesifikasi
– Kajian
Analisis Persyaratan
Adalah sebuah tugas rekayasa perangkat lunak yang
menjembatani jurang antara alokasi perangkat lunak
tingkat sistem dan desain perangkat lunak.
Analisis persyaratan memungkinkan perekayasa

sistem menentukan fungsi dan kinerja perangkat
lunak, menunjukkan interface perangkat lunak
dengan elemen-elemen sistem yang lain, dan
membangun batasan yang harus dipenuhi oleh
perangkat lunak.
Analisis Persyaratan
Rekayasa Sistem
Analisis
Persyarat
an PL
Perangkat Lunak
Elemen Lain
Analisis Desain
Persyarat PL
an PL
Prinsip-Prinsip Analisis
1. Prinsip Operasional
– Domain informasi dari suatu masalah harus
dipahami
– Fungsi-fungsi yang akan dilakukan oleh
perangkat lunak harus didefinisikan
– Perilaku perangkat lunak harus
direpresentasikan
– Model-model yang menggambarkan informasi,
fungsi dan tingkah laku sistem harus dipecah-
pecah secara hirarki
– Proses analisis harus bergerak dari informasi
dasar ke detail implementasi
Prinsip-Prinsip Analisis
2. Prinsip Panduan untuk rekayasa persyaratan
– Memahami masalah sebelum membuat model
analisis
– Mengembangkan prototipe, sehingga pemakai
memahami bagaimana interaksi manusia dan
komputer
– Merekam asal dan alasan untuk setiap
persyaratan
– Menggunakan pandangan persyaratan
bertingkat
– Memprioritaskan persyaratan
– Mengurangi ambiguitas
Area Kerja Analisis
• Analisis persyaratan memberikan model-model
yang akan diterjemahkan ke dalam data, arsitektur,
interface, dan desain prosedural kepada perancang
perangkat lunak.
• Analisis persyaratan perangkat lunak dapat dibagi
menjadi 5 (lima) area kerja:
1) Identifikasi dan Perumusan Masalah
2) Evaluasi dan Sintesis
3) Pemodelan (Analisis dan Data)
4) Spesifikasi
5) Kajian
Kebutuhan (Requirement)
Sesuatu yang diminta , dibutuhkan
Menurut IEEE (the institute of electrical and
electronics engineers)
 Kondisi atau kemampuan yg diperlukan pemakai
untuk menyelesaikan persoalan untuk
mencapai sebuah tujuan
 Kondisi atau kemampuan yang harus dimiliki atau
dipunyai oleh sistem atau komponen sistem untuk
memenuhi kontrak, standar, spesifikasi, atau
dokumen formal lainnya.
Kebutuhan perangkat lunak adalah kondisi, kriteria,
syarat atau kemampuan yang harus dimiliki oleh
perangkat lunak untuk memenuhi apa yang
disyaratkan atau diinginkan pemakai.
3 Jenis Kebutuhan PL [IEEE’93] :
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 atau oleh sistem.
– Sistem harus dapat menyimpan semua rincian data
pesanan pelanggan.
– Sistem harus dapat membuat laporan pembayaran
sesuai dengan periode waktu tertentu.
– Sistem menjamin keamanan pelanggan dalam
melakukan transaksi secara online.
– Sistem memberikan time limit terhadap pembayaran
booking dan jika pembayaran melebihi time limit maka
proses booking akan dibatalkan
– Sistem memiliki kemampuan untuk memberikan
informasi mengenai ketersediaan kamar dan meeting
room apakah sudah penuh atau tidak
2. Kebutuhan antarmuka (interface requirement)

Kebutuhan antarmuka yang menghubungkan
perangkat lunak dengan elemen perangkat
keras, perangkat lunak, atau basis data.
– Perangkat untuk memasukkan data dapat berupa
keyboard, mouse atau scanner.
– Akses ke basisdata menggunakan ODBC (Open
Database Connectivity)
3. Kebutuhan unjuk kerja (performance

requirement)
Kebutuhan yang menetapkan karakteristik
unjuk kerja yang harus dimiliki oleh perangkat
lunak,
misalnya: kecepatan, ketepatan, frekuensi.
– Sistem harus bisa mengolah data sampai 1 juta
record untuk tiap transaksi.
– Sistem harus dapat digunakan oleh multiuser
sesuai dengan otoritas yang diberikan pada
user.
– Waktu tanggap penyajian informasi maksimal
selama satu menit.
Requirement penting, karena sangat mempengaruhi

sukses atau gagalnya pelaksanaan pengembangan
perangkat lunak.
Menurut hasil survey DeMarco, 56% kegagalan

proyek pengembangan perangkat lunak dikarenakan
ketidaklengkapan pendefinisian kebutuhan dari
perangkat lunak tersebut.
Produk dan Proses Kebutuhan
• Parameter produk adalah requirement pada
software untuk dikembangkan
– (Contohnya “Software harus memeriksa prasyarat mata
kuliah yang diambil mahasiswa”)
• Parameter proses adalah batasan – batasan dalam

mengembangkan software.
– Contohnya pilihan
teknik verifikasi. Process requirement juga bisa
ditetapkan oleh organisasi pengembang, pelanggan atau
pihak ketiga seperti badan regulator
Kebutuhan Fungsional dan Non
Fungsional
• Kebutuhan fungsional menjabarkan fungsi – fungsi
yang akan dilaksanakan software. Contohnya
memformat teks. Kadang – kadang disebut juga
sebagai kapabilitas.
• Kebutuhan non-fungsional memberikan batasan

terhadap solusi yang akan dihasilkan. Disebut juga
sebagai quality requirement. Requirement jenis ini
masih bisa dibagi lagi menjadi performance
requirements, maintainability requirements,
safety requirements, reliability requirements atau
salah satu software requirements lainnya.
Emergent Properties
Beberapa requirement merupakan perwakilan dari
emergent properties yaitu requirement yang tidak
bisa ditangani oleh satu komponen saja.
Keberhasilan dalam menanganinya juga bergantung

pada interoperasi dari berbagai komponen yang ada.
Emergent properties amat bergantung pada

arsitektur sistem.
Quantifiable Requirements
Software requirement harus bisa dinyatakan dengan
jelas, tidak ambigu dan pada beberapa bagiannya
yang sesuai, kuantitatif.
– Contoh requirement yang memenuhi syarat: Sebuah
perangkat lunak dari suatu call central harus
meningkatkan throughput sebanyak 20% dan sistemnya
hanya menghasilkan kesalahan fatal dengan peluang
kurang.
Kebutuhan Sistem dan PL
Sistem berarti kombinasi dari elemen – elemen yang
berinteraksi untuk mencapai suatu tujuan yang
terdefinisikan. Ini termasuk hardware, software,
firmware, manusia, informasi, teknik, fasilitas,
layanan dan berbagai elemen pendukung lainnya.
System requirement adalah requirement untuk

sistem secara keseluruhan. Dalam sebuah sistem
yang mengandung komponen software, software
requirement diperoleh dari system requirement
Analisis Kebutuhan
• Analisis Kebutuhan PL merupakan aktifitas awal

dari siklul hidup pengembangan PL. Untuk proyek
besar analisis kebutuhan dilaksanakan setelah
aktifitas sistem information engineering dan
software projek planning.
• 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 perangkat lunak [PRE01].
Tujuan Analisis Kebutuhan
Tujuan pelaksanaan analisis kebutuhan adalah
1. Memahami masalah secara menyeluruh
(komprehensif) yang ada pada perangkat lunak
yang akan dikembang seperti ruang lingkup
produk perangkat lunak(product space) dan
pemakai yang akan menggunakannya.
2. Mendefinisikan apa yang harus dikerjakan oleh
perangkat lunak untuk memenuhi keinginan
pelanggan.
Tahapan Analisis Kebutuhan
Secara teknis pelaksanaan pekerjaan analisis kebutuhan
PL pada dasarnya terdiri dari urutan aktivitas:
1. Mempelajari dan memahami persoalan
2. Mengidentifikasi kebutuhan pemakai
3. Mengidentifikasi kebutuhan PL
4. Membuat dokumen spesifikasi kebutuhan PL
5. Mengkaji ulang (review) kebutuhan
Sedangkan menurut Pressman [PRE01], analisis

kebutuhan perangkat lunak dapat dibagi menjadi
lima area pekerjaan, yaitu:
1. Pengenalan masalah
2. Evaluasi dan sistesis
3. Pemodelan
4. Spesifikasi
5. Tinjauan Ulang
1. Identifikasi & Perumusan Masalah
Identifikasi bisa diawali dengan mempelajari
spesifikasisistem dan atau rencana proyek perangkat
lunak. Contohnya :
Pemasok besar suku cadang kendaraan bermotor
membutuhkan sistem kontrol inventaris. Analis
merumuskan masalah yang berhubungan dengan
sistem manual yang ada sbb :
– Ketidakmampuan untuk dengan cepat
memperoleh status suatu komponen.
– Dua atau tiga hari berkali-kali memperbarui suatu
file kartu.
– Pemesanan kembali secara bertingkat kepada
penjual yang sama karena tidak ada cara untuk
menghubungkan para penjual dengan komponen,
dsb.
2. Evaluasi dan Sintesis
• Dalam melakukan analisis, fokus utama analis
adalah pada ‘apa’? bukan ‘bagaimana?’. Data
apakah yang diproduksi dan dikonsumsi, batasan
apakah yang dipakai?
• Selama aktivitas sintesis, evaluasi, dan solusi analis
menciptakan model-model sistem untuk memahami
aliran data dan kontrol, operasi behavioral dan
pemrosesan fungsional, serta muatan informasi.
• Model tersebut berfungsi sebagai dasar bagi desain
perangkat lunak dan untuk membuat spesifikasi
perangkat lunak.
• Spesifikasi lengkap belum bisa didapatkan pada
tahap ini, pendekatan alternatif pada analisis
persyaratan adalah prototyping.
3.1 Pemodelan Analisis
• DD (Data Dictionary) : mendeskripsikan Struktur Model
Analisis semua objek data yang dikonsumsi PL
• ERD (Entity Relationship Diagram): menggambarkan
hubungan antar objek data
• DFD (Data Flow Diagram): merepresentasikan
transformasi data dan fungsi-fungsi tranformasi
• STD (State Transition Diagram): menunjukkan perilaku
sistem akibat kejadian eksternal
• DOD (Data Object Description) : Deskripsi atribut dari
setiap obyek data pada ERD
• PSPEC (Process Specification): mendeskripsi setiap
fungsi / proses pada DFD
• CSPEC (Control Specification): deskripsi aspek kontrol PL
Struktur
Pemodelan
Analisis
DD
(Data
Dictionary)
3.2 Pemodelan Data
Model data terdiri dari tiga informasi yang saling tergantung:
1. Objek data adalah representasi dari semua informasi
gabungan yang harus dipahami oleh perangkat lunak
– Objek data dapat berupa entitas eksternal (semua sumber
data atau yang mengkonsumsi informasi), suatu benda
(laporan atau tampilan), peristiwa (sambungan telepon)
atau event (sebuah alarm), peran (tenaga penjualan), unit
organisasi (bagian akuntansi), atau suatu struktur (file).
2. Atribut adalah properti suatu objek data.
Atribut digunakan untuk:
• menamai sebuah contoh dari objek data,
• menggambarkan contoh,
• membuat referensi ke contoh yang lain pada tabel yang
lain
3. Hubungan adalah relasi antara objek data yang satu dengan
yang lainnya.
Misal: Sensor dan Pintu  hubungan : Sensor menggerakkan
Pintu
Obyek Data, Atribut & Hubungan
Obyek : Atribut : Hubungan :
Nama
Alamat
Nomor SIM
Memiliki
No Registrasi
Merk
Type
Warna
4. Spesifikasi
• Pada prinsipnya Spesifikasi merupakan representasi persyaratan
dari perangkat lunak yang akan dibangun. Diperlukan
pendekatan sbb.
– Teknik spesifikasi yang terfasilitasi (Facilitated Aplication
Specification Techniques = FAST)
– Pertemuan dilakukan di tempat netral yang dihadiri oleh
pengembang maupun pelanggan.
– Tujuannya : identifikasi masalah, pemecahan, negosiasi,
membentuk persyaratan PL.
– Ada fasilitator (sebaiknya konsultan) yang bertugas
mengontrol pertemuan.
– Penyebaran fungsi kualitas
– Quality Function Deployment (QFD) adalah teknik
manajemen kualitas yang menterjemahkan kebutuhan
pelanggan ke dalam persyaratan teknis bagi perangkat
lunak
– QFD berkonsentrasi pada pemaksimalan kepuasan pelanggan
Hasil proses spesifikasi dituangkan dalam Dokumen Spesifikasi PL
(atau SRS).
5. Kajian
Kajian digunakan untuk memastikan Spesifikasi sudah
lengkap, konsisten, dan akurat. Contoh pertanyaan kajian :
• Apakah tujuan dan sasaran yang dinyatakan bagi PL
tetap konsisten dengan tujuan dan sasaran sistem?
• Apakah interface ke semua elemen sistem sudah
digambarkan?
• Apakah aliran informasi dan struktur telah didefinisikan
dengan tepat bagi domain masalah?
• Apakah diagram telah dipresentasikan dengan jelas?
• Apakah fungsi mayor tetap ada dalam ruang lingkup
dan sudah digambarkan dengan tepat?
• Apakah perilaku PL konsisten dengan informasi yang
harus diproses dan fungsi yang harus dilakukannya?
5. Kajian
• Apakah batasan desain realistis?
• Apakah risiko teknologis pengembangan sudah
dipertimbangkan?
• Apakah kriteria validasi dinyatakan secara detil dan memadai
untuk menggambarkan sebuah sistem yang berhasil?
• Apakah ada inkonsistensi, penghilangan, atau redundancy?
• Apakah kontak dengan pelanggan sudah lengkap?
• Apakah pemakai sudah mengkaji manual atau prototype?
Introduction (Cont)
Ada
Yang INGIN
Ditanyakan ?

05 - Konsep Dan Prinsip Analisis Kebutuhan

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

05 - Konsep Dan Prinsip Analisis Kebutuhan

Diunggah oleh

Hak Cipta:

Format Tersedia

Rekayasa Perangkat Lunak

Analisis persyaratan memungkinkan perekayasa

2. Kebutuhan antarmuka (interface requirement)

3. Kebutuhan unjuk kerja (performance

Requirement penting, karena sangat mempengaruhi

Menurut hasil survey DeMarco, 56% kegagalan

• Parameter proses adalah batasan – batasan dalam

• Kebutuhan non-fungsional memberikan batasan

Keberhasilan dalam menanganinya juga bergantung

Emergent properties amat bergantung pada

System requirement adalah requirement untuk

• Analisis Kebutuhan PL merupakan aktifitas awal

Sedangkan menurut Pressman [PRE01], analisis

Anda mungkin juga menyukai