Teknik Informatika S1
Disusun Oleh: Egia Rosi Subhiyakto, M.Kom, M.CS Teknik Informatika UDINUS [email protected] +6281329571612
Requirement Engineering
Rekayasa Perangkat Lunak
SILABUS MATA KULIAH
8. Pembahasan UTS + Tugas SKPL
9. Presentasi SKPL
10. Design Engineering + Tugas DPPL
11. Presentasi DPPL
12. Software Testing + Quiz
13. Present Tugas Besar
14. Present Tugas Besar
1. Pendahuluan
2. Pengenalan RPL 3. Software Process (1)
4. Software Process (2)
5. Requirement Engineering
6. Analysis Modeling (1) + Quiz
7. Analysis Modeling (2)
REQUIREMENT ENGINEERING
1. Pengertian Requirement?
2. Pengertian Requirement Engineering?
3. Kenapa Requirement Engineering dibutuhkan?
4. Cara mendapatkan kebutuhan
5. User dan System Engineering
6. Requirement Classification
7. Requirement Engineering Process
8. Requirement Management
“The hardest single part of building a software system is
deciding precisely what to build”- F. Brooks
Pengertian Requirement
Requirement ?
Pengertian Requirement
• All project begin with a statement of requirements
• Requirements are descriptions of how a software product should perform
Pengertian Requirement
“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).
Pengertian Requirement Engineering
“Requirement Engineering adalah Proses dimana
kebutuhan untuk produk perangkat lunak dikumpulkan,
dianalisis, didokumentasikan, dan dikelola di seluruh
siklus hidup rekayasa perangkat lunak”.
Pengertian Requirement Engineering
“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
Sebuah proses yang kompleks dengan aktifitas yang berbelit-
belit dan banyak aktor yang terlibat
Requirement Engineering Process
Sebuah proses yang kompleks dengan aktifitas yang berbelit-
belit dan banyak aktor yang terlibat
• Requirements yang lemah/ tidak lengkap adalah
sumber utama dari kegagalan (Standish95)
8000 projects, 350 US companies:
1/3 dari projek tidak pernah selesai dan 50% berhasil
hanya sebagian
Kenapa Requirement Engineering
dibutuhkan?
• Requirements yang lemah/ tidak lengkap adalah sumber utama
dari kegagalan (Standish95)
8000 projects, 350 US companies:
1/3 dari projek tidak pernah selesai dan 50% berhasil hanya
sebagian
• Banyaknya masalah yang dirasakan terkait dengan spesifikasi
kebutuhan (>50%) – (ESI96)
3800 organisasi di 17 negara eropa
Kenapa Requirement Engineering
dibutuhkan?
• “Kebutuhan yang tidak mencukupi, tidak konsisten,
tidak lengkap atau ambigu mempunyai dampak yang
kritis terhadap kualitas hasil perangkat lunak
tersebut” (Bell&Tayer76)
Kenapa Requirement Engineering
dibutuhkan?
• “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)
Kenapa Requirement Engineering
dibutuhkan?
“Jika customer tidak senang dengan perangkat lunak
yang dibangun maka software developer membangun
perangkat lunak yang salah”.
Kenapa Requirement Engineering
dibutuhkan?
Quoted form Head First Software Development
1. Wawancara
Berupa komunikasi verbal untuk mendapatkan informasi
langsung dari satu atau sekelompok orang.
2. Kuesioner
Berupa alat komunikasi berupa pertanyaan tertulis yang
diberikan kepada customer.
Cara Mendapatkan Kebutuhan
3. Observasi
Peninjauan langsung tim requirement engineer ke tempat
customer untuk merasakan atau memperhatikan prosedur
manual secara langsung dalam rangka mendapatkan
kebutuhan.
4. Pencarian Dokumen (Data Sekunder)
Pencarian terhadap dokumen-dokumen manual yang
berhubungan dengan kebutuhan pembangunan perangkat
lunak.
Cara Mendapatkan Kebutuhan
Teknik dan Pendekatan
cara mendapatkan kebutuhan
1. Interviews
2. Questionnaires
3. Task Analysis
4. Domain Analysis
5. Introspection
6. Repertory Grids
7. Card Sorting
8. Laddering
9. Group Work
10. Brainstorming
11. Joint Application Development
12. Requirements Workshops
13. Ethnography
14. Observation
15. Protocol Analysis
16. Apprenticing
17. Prototyping
18. Goal Based Approach
19. Scenarios
20. Viewpoints
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
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.
Requirement Engineering
Perbedaan User dan System Requirement
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 diagram sederhana tentang layanan sistem
Model sistem
Contoh User dan System Requirement
User Requirement
Sistem bisa melakukan operasi dasar pengolahan data buku yang ada
di perpustakaan
System Requirement
1. 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
Requirement Classifications
Functional versus Non Functional
Requirement Classifications
Functional versus Non Functional
1. Kebutuhan fungsional
Menunjukkan What the system should do.
Menunjukkan fasilitas apa yang dibutuhkan serta
aktivitas apa saja yang terjadi dalam sistem baru.
Requirement Classifications
Functional versus Non Functional
1. Kebutuhan fungsional
Kebutuhan fungsional mencakup:
* Fungsi deskripsi kebutuhan
* Laporan baik hardcopy maupun softcopy
* Updating dan query online
* Penyimpanan data, pencarian kembali dan transfer data
Requirement Classifications
Functional versus Non Functional
1. Kebutuhan fungsional
Contoh: ?
Requirement Classifications
Functional versus Non Functional
1. Kebutuhan fungsional
Contoh: dalam sistem informasi akademik
Mahasiswa dapat melakukan input KRS
Requirement Classifications
Functional versus Non Functional
1. Kebutuhan Non fungsional
Kebutuhan yang mencakup:
* Waktu respon
* Rata-rata waktu untuk kegagalan
* Kebutuhan keamanan
* Akses untuk pengguna yang tidak punya hak
Requirement Classifications
Functional versus Non Functional
1. Kebutuhan Non fungsional
Contoh: ?
Requirement Classifications
Functional versus Non Functional
1. Kebutuhan Non fungsional
Contoh:
Website harus easy to access, easy to use, easy to
understand dan menjamin keamanan data member dari
orang yang tidak bertanggungjawab.
Requirement Classifications
Functional versus Non Functional
Functional Requirements What the system should do
Non functional Requirements Constraints on the types of
solutions that will meet the functional requirements
e.g. Accuracy, Performance, Security, and Modifiability
Requirement Engineering Process
Requirements engineering melibatkan semua siklus hidup
aktivitas yang berhubungan dengan kebutuhan.
Meliputi:
Gathering Mengumpulkan data kebutuhan
Documenting Dokumentasi
Managing requirements Mengatur/ memanage
kebutuhan yang sudah dikumpulkan
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?
Kapan kita memodelkan kebutuhan?
Traditionally : Fase awal dari siklus pembuatan perangkat lunak
Requirements
Analysis
Design
Implementation
Tests
Inception/
Permulaan Elaboration/
Perluasan
Construction/
Pembangunan
Transition/
Peralihan
RUP,
(Jacobson98)
Life Cycle
Objectives
Life Cycle
Architecture
Initial Operational
Capability
Product
Release
Definisi
“Pernyataan resmi dari apa yang dibutuhkan oleh developer
sistem untuk membangun sistem dan berisi penggabungan
antara definisidan spesifikasi kebutuhan”
Dokumen Kebutuhan
1. Menggunakan format standar untuk semua kebutuhan.
2. Menggunakan bahasa yang konsisten
3. Bagian-bagian penting dari seluruh kebutuhan harus
ditandai.
4. Jangan menggunakan bahasa jargon.
5. Complete but not Complicated
Petunjuk Penulisan Dokumen Kebutuhan
Pengguna Dokumen Kebutuhan
PENGGUNA KEGUNAAN DOKUMEN
Cutomer 1. Sarana untuk menspesifikasikankebutuhan sistem dan pengecekan apakah sistem yang dibangun sesuai kebutuhan. 2. Sarana penyampaian perubahan kebutuhan.
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
TERIMA KASIH