Teknik Informatika S1 Rekayasa Perangkat Lunak Requirement Engineering

Presentasi berjudul: "Teknik Informatika S1 Rekayasa Perangkat Lunak Requirement Engineering"— Transcript presentasi:

1 Teknik Informatika S1 Rekayasa Perangkat Lunak Requirement Engineering
Disusun Oleh: Egia Rosi Subhiyakto, M.Kom, M.CS Teknik Informatika UDINUS

2 SILABUS MATA KULIAH Pengenalan RPL Pendahuluan
Software Process (1) Software Process (2) Requirement Engineering Analysis Modeling (1) + Quiz Analysis Modeling (2) Pembahasan UTS + Tugas SKPL Presentasi SKPL Design Engineering + Tugas DPPL Presentasi DPPL Software Testing + Quiz Present Tugas Besar

3 Pembahasan Study Kasus – Model Proses

4 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. Model Proses apakah yang tepat digunakan untuk kasus di atas? Dan jelaskan alasannya?

5 Answer ?

6 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 aktifitas 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 apabila diterapkan pada kasus tersebut.

7 REQUIREMENT ENGINEERING
Pengertian Requirement? Pengertian Requirement Engineering? Kenapa Requirement Engineering dibutuhkan? Cara mendapatkan kebutuhan User dan System Engineering Requirement Classification Requirement Engineering Process Requirement Management

8 “The hardest single part of building a software system is deciding precisely what to build”- F. Brooks

9 Pengertian Requirement

10 Pengertian Requirement
All project begin with a statement of requirements Requirements are descriptions of how a software product should perform

11 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).

12 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”.

13 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

14 Requirement Engineering
Sebuah proses yang kompleks dengan aktifitas yang berbelit-belit dan banyak aktor yang terlibat

15 Requirement Engineering Process
Sebuah proses yang kompleks dengan aktifitas yang berbelit-belit dan banyak aktor yang terlibat

16 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

17 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

18 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)

19 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)

20 Kenapa Requirement Engineering dibutuhkan?
“Jika customer tidak senang dengan perangkat lunak yang dibangun maka software developer membangun perangkat lunak yang salah”. Quoted form Head First Software Development

21 Cara Mendapatkan Kebutuhan
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.

22 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.

23 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

24 Requirement Engineering
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.

25 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

26 Contoh User dan System Requirement
User Requirement Sistem bisa melakukan operasi dasar pengolahan data buku yang ada di perpustakaan System Requirement Sistem bisa melayani proses penambahan data buku yang diinput oleh pengguna Sistem bisa melayani pengeditan data buku yang sudah tersimpan dalam basis data Sistem bisa melayani penghapusan data buku yang tidak sedang dipinjam atau dikembalikan

27 Requirement Classifications
Functional versus Non Functional

28 Requirement Classifications
Functional versus Non Functional 1. Kebutuhan fungsional ?

29 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.

30 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

31 Requirement Classifications
Functional versus Non Functional 1. Kebutuhan fungsional Contoh: ?

32 Requirement Classifications
Functional versus Non Functional 1. Kebutuhan fungsional Contoh: dalam sistem informasi akademik Mahasiswa dapat melakukan input KRS

33 Requirement Classifications
Functional versus Non Functional 1. Kebutuhan Non fungsional ?

34 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

35 Requirement Classifications
Functional versus Non Functional 1. Kebutuhan Non fungsional Contoh: ?

36 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.

37 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

38 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 kebutuhan yang sudah dikumpulkan

39 Pengukuran Kebutuhan PROPERTI UKURAN Kecepatan
Transaksi yang diproses per detik Waktu respon pengguna Waktu refresh layar Ukuran Kbytes Jumlah RAM Kemudahan Penggunaan Waktu Pelatihan Jumlah help yang disediakan Reliabilitas Rata-rata waktu kegagalan Kemungkinan untuk tidak bisa diakses Jumlah kegagalan yang terjadi Robustness Waktu restart ketika terjadi kegagalan Presentase dari kegagalan Kemungkinan data hilang ketika terjadi kegagalan Portability 1. Persentase dari statement yang berhasil dieksekusi pada target system

40 Kapan kita memodelkan kebutuhan?

41 Kapan kita memodelkan kebutuhan?
Traditionally : Fase awal dari siklus pembuatan perangkat lunak RUP, (Jacobson98) Inception/ Permulaan Elaboration/ Perluasan Construction/ Pembangunan Transition/ Peralihan Requirements Analysis Design Implementation Tests Life Cycle Objectives Life Cycle Architecture Initial Operational Capability Product Release

42 Dokumen Kebutuhan Definisi “Pernyataan resmi dari apa yang dibutuhkan oleh developer sistem untuk membangun sistem dan berisi penggabungan antara definisidan spesifikasi kebutuhan”

43 Petunjuk Penulisan 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

44 Pengguna Dokumen Kebutuhan
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

45 TERIMA KASIH