Definisi
Teknik Informatika S1 Rekayasa Perangkat Lunak
Requirement
Requirement Engineering
Pengertian Requirement
Pengertian Requirement Engineering
“Sesuatu pada produk yang harus dilakukan atau sebuah kualitas
yang
harus
dimiliki
produk
?
tersebut”
(Robertson99).
“Sebuah spesifikasi kebutuhan adalah bagaimana tujuan harus sesuai dengan sistem yang diusulkan” (Anton96).
“Requirement
Engineering
adalah
Proses
dimana
persyaratan untuk produk perangkat lunak dikumpulkan, dianalisis, didokumentasikan, dan dikelola di seluruh siklus hidup rekayasa perangkat lunak”. Requirement Engineering berkaitan dengan menafsirkan dan memahami tujuan, kebutuhan, dan keyakinan dari pihak yang berkepentingan
Requirement Engineering Process
Kenapa Requirement Engineering dibutuhkan?
Sebuah proses yang kompleks dengan aktifitas yang berbelit-belit dan banyak aktor yang terlibat
• “Kebutuhan yang tidak mencukupi, tidak konsisten, tidak lengkap atau ambigu mempunyai dampak yang kritis terhadap kualitas hasil perangkat lunak tersebut” (Bell&Tayer76) • “Keterlambatan koreksi dari kesalahan meningkatkan biaya sampai 200 kali lebih banyak selama proses requirement engineering” (Boehm81) • “Jika customer tidak senang dengan perangkat lunak yang dibangun maka software developer membangun perangkat lunak yang salah”.
1
Cara Mendapatkan Kebutuhan
Cara Mendapatkan Kebutuhan
1. Wawancara
3. Observasi
Berupa komunikasi verbal untuk mendapatkan informasi
Peninjauan langsung tim requirement engineer ke tempat customer
langsung dari satu atau sekelompok orang.
untuk merasakan atau memperhatikan prosedur manual secara
2. Kuesioner Berupa alat komunikasi berupa pertanyaan tertulis yang diberikan kepada customer.
langsung dalam rangka mendapatkan kebutuhan.
4. Pencarian Dokumen (Data Sekunder) Pencarian terhadap dokumen-dokumen manual yang berhubungan dengan kebutuhan pembangunan perangkat lunak.
Requirement Engineering
Perbedaan User dan System Requirement
1. User Requirement Pernyataan dalam bentuk bahasa natural ditambah diagram dari layanan sistem dan batasannya. Dibuat untuk customer. 2. System Requirement Dokumen terstruktur yang mengatur detail deskripsi dari layanan
PARAMETER PEMBANDING
USER REQUIREMENT
SYSTEM REQUIREMENT
Kedetailan Informasi
Tidak terlalu detail
Lebih detail
Target Pengguna
Pengguna sistem yang tidak mempunyai pengetahuan teknik yang detail
Developer (terkadang customer ingin mengetahui)
Bentuk Informasi
Bahasa natural dan Model sistem diagram sederhana tentang layanan sistem
sistem. Dibuat sebagai kontrak antara customer dan software developer. 3. Software Spesification Deskripsi perangkat lunak yang detail yang menyajikan informasi untuk perancangan atau implementasi
sistem. Dibuat untuk
software developer.
Contoh User dan System Requirement User Requirement
Requirement Classifications
Sistem bisa melakukan operasi dasar pengolahan data buku yang ada di perpustakaan System Requirement 1.
Functional versus Non Functional
Sistem bisa melayani proses penambahan data buku yang diinput oleh pengguna
2. Sistem bisa melayani pengeditan data buku yang sudah tersimpan dalam basis data 3. Sistem bisa melayani penghapusan data buku yang tidak sedang dipinjam atau dikembalikan
2
Requirement Classifications
Requirement Classifications Functional versus Non Functional 1. Kebutuhan fungsional
Menunjukkan What the system should do.
Functional versus Non Functional 1. Kebutuhan fungsional
Kebutuhan fungsional mencakup: * Fungsi deskripsi kebutuhan
Menunjukkan fasilitas apa yang dibutuhkan serta aktivitas apa saja yang terjadi dalam sistem baru.
* Laporan baik hardcopy maupun softcopy * Updating dan query online * Penyimpanan data, pencarian kembali dan transfer data
Requirement Classifications
Requirement Classifications Functional versus Non Functional
Functional versus Non Functional 1. Kebutuhan fungsional
Contoh: dalam sistem informasi akademik
1. Kebutuhan Non fungsional
Kebutuhan yang mencakup: * Waktu respon * Rata-rata waktu untuk kegagalan
Mahasiswa dapat melakukan input KRS
* Kebutuhan keamanan * Akses untuk pengguna yang tidak punya hak
Requirement Classifications Functional versus Non Functional 1. Kebutuhan Non fungsional
Requirement Engineering Process Requirements engineering melibatkan semua siklus hidup aktivitas yang berhubungan dengan kebutuhan.
Contoh: Meliputi: Website harus easy to access, easy to use, easy to
Gathering Mengumpulkan data kebutuhan
understand dan menjamin keamanan data member dari orang
Documenting Dokumentasi
yang tidak bertanggungjawab.
Managing requirements Mengatur/ memanage kebutuhan yang sudah dikumpulkan
3
Pengukuran Kebutuhan PROPERTI
UKURAN
Kecepatan
1. Transaksi yang diproses per detik 2. Waktu respon pengguna 3. Waktu refresh layar
Ukuran
1. Kbytes 2. Jumlah RAM
Kemudahan Penggunaan
1. Waktu Pelatihan 2. Jumlah help yang disediakan
Reliabilitas
1. Rata-rata waktu kegagalan 2. Kemungkinan untuk tidak bisa diakses 3. Jumlah kegagalan yang terjadi
Robustness
1. Waktu restart ketika terjadi kegagalan 2. Presentase dari kegagalan 3. Kemungkinan data hilang ketika terjadi kegagalan
Portability
1. Persentase dari statement yang berhasil dieksekusi pada target system
Kapan kita memodelkan kebutuhan?
Dokumen Kebutuhan
Kapan kita memodelkan kebutuhan? Traditionally : Fase awal dari siklus pembuatan perangkat lunak RUP, (Jacobson98) Inception/
Permulaan
Elaboration/ Perluasan
Construction/ Pembangunan
Transition/ Peralihan
Requirements
Definisi
“Pernyataan resmi dari apa yang dibutuhkan oleh developer sistem untuk membangun sistem dan berisi penggabungan antara definisi dan spesifikasi kebutuhan”
Analysis Design Implementation Tests
Life Cycle Objectives
Life Cycle Architecture
Initial Operational Capability
Product Release
Pengguna Dokumen Kebutuhan
Petunjuk Penulisan Dokumen Kebutuhan
PENGGUNA 1. Menggunakan format standar untuk semua kebutuhan.
Cutomer
2. Menggunakan bahasa yang konsisten
2. Sarana penyampaian perubahan kebutuhan.
3. Bagian-bagian penting dari seluruh kebutuhan harus ditandai.
Manajer Proyek
1.Dasar perhitungan penawaran biaya sistem. 2.Dasar perencanaan untuk pembangunansistem
System Engineer
Sarana untuk memahami sistem seperti apa yang akan dibangun
System Test Engineer
Dasar untuk melakukanvalidation test pada sistem
System Maintenance Engineer
Sarana untuk memahami sistem dan hubungannya antar bagian-bagiannya
4. Jangan menggunakan bahasa jargon. 5. Complete but not Complicated
KEGUNAAN DOKUMEN 1. Sarana untuk menspesifikasikankebutuhan sistem dan pengecekan apakah sistem yang dibangun sesuai kebutuhan.
4
TERIMA KASIH
5
