Teknik Informatika S1
Disusun Oleh:
Egia Rosi Subhiyakto, M.Kom, M.CS Teknik Informatika UDINUS
[email protected] +6285640392988
Requirement Engineering
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
Latihan
Latihan
Chelsea Outlet merupakan outlet yang bergerak di bidang penjualan jersey khusus Chelsea. Seiring perkembangan outlet yang semakin maju diikuti persaingan dengan outlet lain. Pengolahan data penjualan di Chelsea outlet masih kurang efektif karena transaksi belum terkomputerisasi. Chelsea outlet memerlukan sebuah perangkat lunak untuk mengolah data penjualan dan laporannya. Perangkat yang dibuat harus sesuai dengan sarana komputer yang ada di Chelsea outlet.
Answer
Answer
Answer
Answer
Model proses yang akan saya terapkan adalah Model Spiral.
Penelitian ini termasuk jenis development system karena akan meneliti dan
mengembangkan suatu rekayasa perangkat lunak aplikasi penjualan yang sesuai dengan kebutuhan tempat studi kasus yaitu Chelsea outlet.
Model yang digunakan dalam proses pengembangan untuk membangun
sistem aplikasi ini yaitu metode Spiral. Model spiral dibagi menjadi sejumlah
aktiftas kerangka kerja, disebut juga wilayah tugas. Model spiral yang berisi
tujuh wilayah tugas : Komunikasi pelanggan, Perancangan, Analisis Masalah,
Rekayasa, Coding, Pengujian dan Evaluasi Pelanggan akan sangat cocok
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
Pengertian Requirement
Pengertian Requirement
• All project begin with a statement of requirements
• Requirements are descriptions of how a software
Pengertian Requirement
“Sesuatu pada produk yang harus dilakukan atau sebuah kualitas yang harus dimiliki produk tersebut” (Robertson99).
Pengertian Requirement Engineering
“Requirement Engineering adalah Proses dimana
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
Requirement Engineering Process
• 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
• 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
• “Kebutuhan yang tidak mencukupi, tidak konsisten,
tidak lengkap atau ambigu mempunyai dampak yang kritis terhadap kualitas hasil perangkat lunak tersebut” (Bell&Tayer76)
• “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”.
Kenapa Requirement Engineering
dibutuhkan?
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.
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.
Teknik dan Pendekatan
cara mendapatkan kebutuhan
1. Interviews2. 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
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.
Perbedaan User dan 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
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
Requirement Classifiations
Requirement Classifications
Functional
versus
Non Functional
1.Kebutuhan fungsional
?
Requirement Classifications
Functional
versus
Non Functional
1.
Kebutuhan fungsional
Menunjukkan
What
the system should do
.
Requirement Classifications
Functional
versus
Non Functional
1. Kebutuhan fungsionalKebutuhan fungsional mencakup:
* Fungsi deskripsi kebutuhan
* Laporan baik hardcopy maupun softcopy * Updating dan query online
Requirement Classifications
Functional
versus
Non Functional
1.
Kebutuhan fungsional
Requirement Classifiations
Functional
versus
Non Functional
1.
Kebutuhan fungsional
Contoh: dalam sistem informasi akademik
Requirement Classifications
Functional
versus
Non Functional
1.
Kebutuhan Non fungsional
Requirement Classifications
Functional
versus
Non Functional
1.Kebutuhan Non fungsional
Kebutuhan yang mencakup:
* Waktu respon
* Rata-rata waktu untuk kegagalan * Kebutuhan keamanan
Requirement Classifiations
Functional
versus
Non Functional
1.
Kebutuhan Non fungsional
Requirement Classifications
Functional
versus
Non Functional
1.
Kebutuhan Non fungsional
Contoh:
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
Requirement Engineering Process
Requirements engineering melibatkan semua siklus hiduo aktivitas yang berhubungan dengan kebutuhan.
Meliputi:
Gathering Mengumpulkan data kebutuhan
Documenting Dokumentasi
Managing requirements Mengatur/ memanage
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
Kapan kita memodelkan kebutuhan?
Traditionally : Fase awal dari siklus pembuatan perangkat lunak Requirements
Permulaan Elaboration/ Perluasan Construction/ Pembangunan Transition/ Peralihan
RUP,
(Jacobson98)
Life Cycle Objectives
Life Cycle Architecture
Initial Operational Capability
Definisi
“Pernyataan resmi dari apa yang dibutuhkan oleh developer sistem untuk membangun sistem dan berisi penggabungan antara definisidan spesifikasi 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
Pengguna Dokumen Kebutuhan
PENGGUNA KEGUNAAN DOKUMEN
Cutomer 1. Sarana untuk menspesifkasikankebutuhan 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