Transcript bahan 3 – requirement

Requirement
Definisi


Requirement adalah gambaran dari layanan
(services) dan batasan bagi sistem yang akan
dibangun.
Pernyataan atau gambaran pelayanan yang
disediakan oleh sistem, batasanbatasan dari
sistem dan bisa juga berupa definisi matematis
fungsifungsi sistem.
Fungsi


Menjadi dasar penawaran suatu kontrak 
harus terbuka untuk masukan
Menjadi dasar kontrak  harus didefinisikan
secara detil
Requirement Engineering

Proses menemukan, menganalisis, men
dokumentasikan dan pengujian layanan
layanan dan batasan.
Catatan




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.
Pengumpulan 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 halhal yang mungkin jadi masalah
Macam requirement (1)

User requirement (kebutuhan pengguna) :


Pernyataan tentang layanan yang disediakan
sistem
dan
tentang
batasanbatasan
operasionalnya.
Pernyataan ini dapat dilengkapi dengan
gambar/diagram yang dapat dimengerti dengan
mudah.
Macam requirement (2)

System requirement (kebutuhan sistem) :


Sekumpulan layanan/kemampuan sistem dan
batasanbatasannya yang ditulis secara detil.
System requirement document sering disebut
functional specification (spesifikasi fungsional),
Dijelaskan dengan tepat dan detil.
 Bisa berlaku sebagai kontrak antara klien dan
pembangun.

Macam requirement (3)

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 (1)
1. Functional Requirement :

Merupakan penjelasan tentang :
layanan yang perlu disediakan oleh sistem,
 bagaimana
sistem menerima dan mengolah
masukan, dan
 bagaimana sistem mengatasi situasisituasi tertentu.



Menentukan apa yang tidak dikerjakan oleh
sistem.
Functional requirement menggambarkan system
requirement secara detil seperti input, output dan
pengecualian yang berlaku.
Contoh kasus peminjaman buku





Pengguna bisa mencari semua informasi
tentang buku atau bisa memilih salah satu dari
informasi tentang buku.
Semua peminjam memiliki pengenal yang unik
Sistem mampu mencatat transaksi peminjaman,
pengembalian dan denda secara lengkap
Hari libur bisa diset sejak awal, dan bisa
menerima perubahan dengan otoritas khusus
Harus komplit (kebutuhan layanan jelas dan
lengkap) dan konsisten (tidak kontradiksi
dengan yang didefinisikan)
Kategori software system requirement (2)
2. Nonfunctional Requirement


Secara umum berisi batasanbatasan pada
pelayanan atau fungsi yang disediakan oleh
sistem.
Termasuk di dalamnya adalah batasan waktu,
batasan proses pembangunan, standarstandar
tertentu.
Cakupan NonFunctional requirement
Non-functional requirement dibagi 3 tipe

Product req. berkaitan dengan kehandalan,
kecepatan, kemudahan digunakan, kapasitas
memori yang dibutuhkan dan efisiensi sistem

Organisational req. berkaitan dengan standar,
bahasa pemrograman dan metode rancangan
yang digunakan.

External req. berkaitan dengan masalah etika
penggunaan, interoperabilitas dengan sistem
lain, legalitas, dan privasi.
Kategori software system requirement (3)
3. Domain requirement
 Berasal dari domain aplikasi sistem. Misalnya
karena masalah hak cipta maka beberapa
dokumen dalam perpustakaan tidak boleh
diakses oleh orang lain yang tidak berhak.
Dokumen kebutuhan
(requirement document)

Dokumen kebutuhan merupakan pernyataan
resmi dari apa yang dibutuhkan dari pembangun
sistem,
berisi
definisi
dan
spesifikasi
requirement dan bukan dokumen desain.

Sebisa mungkin berupa kumpulan dari APA
yang harus dikerjakan sistem, BUKAN
BAGAIMANA sistem mengerjakannya.
Dokumen kebutuhan sebaiknya






Menjelaskan perilaku eksternal sistem
Menjelaskan batasan pada implementasi
Mudah diubah
Sebagai alat referensi untuk pemelihara
sistem
Mencatat peringatan awal tentang siklus dari
sistem
Menjelaskan bagaimana sistem merespon
halhal yang tidak diperlukan
Contoh
(Pertanyaan fokus pd pengertian

permasalahan)
Menemukan yang membutuhkan software
tersebut :
Siapa yang membutuhkan sistem (serta
personal di belakangnya) ?
Siapa yang akan menggunakan solusi
Apa
yang akan menjadi keuntungan
ekonomis dari solusi yang baik
Adakan sumber lain dari solusi yang
dibutuhkan
Contoh
(Pertanyaan fokus pd pengertian

permasalahan)
Bentuk solusi yang diinginkan :
Bagaimana
user
mengkarakteristikkan
suatu output sistem yang baik yang akan
dihasilkan oleh solusi yang benar
Masalah-masalah apa yang akan dicarikan
solusinya?
Lingkungan solusi yang akan digunakan
Adakah isu atau kendala khusus yang
berdampak kepada solusi
Contoh
(Pertanyaan fokus pd pengertian

permasalahan)
Efektifitas :
Mendapatkan person yang benar/berhak
atas jawaban pertanyaan,
Apakah pertanyaan yang diajukan relevan
dengan permasalahan
Adakah
personal
lain
yang
dapat
menambah informasi
Adakah hal lain yang perlu ditambahkan?
Contoh
(Pertanyaan fokus pd implementasi Studi Kelayakan )






Apa yang akan terjadi apabila sistem tidak
diimplementasikan?
Masalah proses apa yang ada ?
Apa yang dapat dibantu oleh sistem ?
Masalah apa yang akan muncul pada proses
Integrasi ?
Adakah teknologi baru yang dibutuhkan? Skill yang
dibutuhkan ?
Fasilitas apa yang harus didukung oleh sistem ?
The end