REQUIREMENT MODELING SCENARIO & INTRODUCING TO USE CASE

Transkripsi

1 REQUIREMENT MODELING SCENARIO & INTRODUCING TO USE CASE Mata Kuliah Testing & Implementasi Sistem Program Studi Sistem Informasi 2013/2014 STMIK Dumai -- Pertemuan 4 -- This presentation is revised by Hazlinda A., STMIK, 2013

2 Acknowledgement 2 Main materials: [Pressman, 2010] Pressman, Roger S. Software Engineering: A Practitioner s Approach. New York:McGraw-Hill Higher Education, Print Supplements: [Yud, 2012] Yudhoatmojo, Satrio Baskoro. Software & Software Engineering IKI Rekayasa Perangkat Lunak Term /2012. Faculty of Computer Science University of Indonesia Print [Larman, 2005] Larman, Craig. Applying UML and Patterns: an Introduction to Object-oriented Analysis and Design and Iterativ Development. Upper Saddle River, NJ: Pearson Education International, Print

3 Requirement 3 Requirement adalah kapabilitas dan kondisi dimana sistem dan skup proyek sudah harus dikonfirmasi. [Larman, 2005] Secara umum, requirement terbagi atas dua tipe: Fungsional (fungsi sistem) Non-fungsional (diluar fungsi sistem) Rincian tipe requirement

4 Tipe Requirement 4 Requirement Fungsional: Proses-proses yang akan dilakukan oleh sistem Informasi system yang harus ada Mendefinisikan fungsi yang ada pada sistem. Requirement ini langsung berlanjut ke pembuatan use case, proses model, dan data model. Requirement Non-fungsional : Operasional Performa Keamanan sistem Kultur, politik, aturan dari pihak luar dll

5 Menetapkan Requirements 5 Terdapat 3 teknik yang membantu pengguna dalam menemukan kebutuhan mereka untuk sistem yang akan dibuat: Business Process Automation (BPA) Business Process Improvement (BPI) Business Process Reengineering (BPR)

6 6 3 Teknik Analisis Requirement

7 1. Business Process Automation 7 (BPA) Jangan ubah operasional dasar (basic) dari sistem Lakukan otomatisasi untuk bebrapa fungsi (trigger by sistem) Goal: efisiensi untuk user/pengguna

8 2. Business Process Improvement 8 (BPI) Memperhatikan durasi dan harga proyek Meningkatkan performa sistem Goal: Efisiensi dan Efektivitas untuk user/pengguna

9 9 3. Business Process Reengineering Merubah secara pokok (fundamental) bagaimana operasional sistem untuk perusahaan (BPR) Goal: Mendisain ulang secara total proses bisnis dari sistem

10 Perbandingan Teknik Analisis 10 Ketiga teknik analisis BPA, BPI, dan BPR dibandingkan berdasarkan: Nilai bisnis/fungsi (Potential business value) Harga proyek (Project cost) Lebar analisis (Breadth of analysis) Resiko (Risk)

11 Karakteristik Proyek 11 Business Process Automation (BPA) Business Process Improvement (BPI) Business Process Reengineering (BPR) Nilai bisnis/fungsi Menengahkebawah Menengah Tinggi Harga proyek Rendah Menengahkebawah Tinggi Lebar analisis Sempit Menengah-sempit Sangat luas Resiko Menengahkebawah Menengahkebawah Sangat tinggi

12 12 Requirement Engineering

13 Requirement Engineering 13 Requirement engineering adalah proses yang membantu tim konsultan untuk lebih mengerti masalah yang akan mereka selesaikan (dalam bentuk produk software). Proses requirement engineering dilakukan melalui 7 aktivitas: 1. Inception 2. Elicitation 3. Elaboration 4. Negotiation 5. Specification 6. Validation 7. Requirement Management

14 1. Inception (permulaan) 14 Mengajukan pertanyaan yang akan membagun: Pemahaman dasar tentang masalahnya Pihak-pihak yang menginginkan solusinya Bentuk solusi yang diinginkan Keefektivan komunikasi antara tim kustomer dengan tim konsultan. Identify stakeholders Dengan siapa seharusnya kita melakukan requirement? Bekerja dengan berkolaborasi (antara tim kustomer dengan tim konsultan) Pertanyaan awal: Siapa orang dibalik requirement? (Who is behind the request for this work) Siapa yang akan menggunakan solusi yang diberikan? Apakah solusi yang diberikan juga mempertimbangkan sisi ekonomis? Apakah ada alternatif solusi lain?

15 2. Eliciting Requirements 15 Elicit = mendapatkan, memperoleh. Memperoleh requirement dari semua pihak (stakeholders). Rapat dihadiri oleh kedua belah pihak. Aturan-aturan untuk persiapan sistem ditetapkan. Menyusun jadwal. Ada seorang fasilitator (bisa kustomer, konsultan, atau pihak lain) yang mengontrol rapat. Tujuan yang ingin dicapai: Mengidentifikasi masalah Mengajukan beberapa solusi Menegosiasi jika ada pendekatan solusi lain Menetapkan solusi awal dari requirement

16 Quality Function Deployment (QFD) 16 QFD adalah teknik untuk menerjemahkan kebutuhan konsumen menjadi requirement teknis. QFD mengidentifikasi 3 tipe requirement: Normal Requirement Merefleksikan sasaran dan tujuan pengembangan sistem, sebagaimana dinyatakan oleh konsumen. Expected Requirement Requirement yang implisit dan fundamental, konsumen tidak menyebutkannya secara eksplisit. Jika tidak difasilitasi akan menimbulkan ketidakpuasan konsumen yang signifikan. Misalnya, correctness dan instalasi software yang mudah. Exciting Requirement Fitur diluar harapan (melebihi ekspektasi) konsumen dan akan menimbulkan kepuasan bagi konsumen.

17 17 Eliciting Requirements

18 3. Elaboration 18 Elaborate = menguraikan, merincikan. Merincikan hasil requirement, dan Membuat model analisa yang mengidentifikasikan data, fungsi, dan kebutuhan lainnya.

19 4. Negotiation 19 Menyetujui gambaran umum sistem yang realistis bagi pihak kustomer maupun pihak konsultan. Mengidentifikasi pihak-pihak yang menjadi kunci Orang-orang yang akan melakukan deal harga proyek Negosiasi Mengukur besarnya kebutuhan sistem dan menghasilkan kesepakatan harga yang sesuai (win-win solition)

20 5. Spesifikasi 20 Specification dapat berupa: Dokumen tertulis (narasi) Himpunan model Rumus matematika Kumpulan dari user scenarios (use-cases) Prototipe

21 6. Validasi 21 Validation mekanisme review untuk melihat: Konten error atau kesalahan interpretasi Area/fungsi/wilayah yang butuh klarifikasi Informasi yang masih salah/kurang jelas Tidak konsisten (biasanya terjadi di sistem berskala besar) Requirement yang konlifk/tidak realistis (tidak dapat dicapai)

22 7. Manajemen 22 Manajemen Requirement Mengidentifikasi dan mengatur requirement, termasuk mengatur perubahan terhadap requirement.

23 Produk Hasil Requirement 23 Use-Case Model satu set skenario sistem yang dibuat dalam bentuk use case. Supplementary Specification Spesifikasi lain yang tidak ada dalam use case (hasil requirement non-functional). Glossary Istilah-istilah penting di dalam sistem, termasuk dalam data yang akan digunakan. Vision Menyimpulkan requirement yang sudah dirinci dalam Use- Case Model dan Supplementary Specification, dan mendapatkan visi/gambaran proyek. Business Rules Kebutuhan dan kebijakan lain yang penting bagi proyek.

24 24 Produk Hasil Requirement

25 Analisis Requirement 25 Proses analisis lebih menekankan investigasi masalah dan kebutuhan, daripada solusi [Larman, 2005] Contoh: jika dibutuhkan suatu sistem perdagangan online, akan bagaimana sistem tersebut digunakan? apa fungsinya? Jadi, analisis requirement adalah investigasi requirement.

26 Analisis Requirement 26 Menentukan karakteristik operasional dari sistem. Mengindikasikan interface sistem dengan elemenelemen lain yang ada pada sistem tersebut. Membangun batasan-batasan yang ada pada sistem. Analisis requirement mengizinkan software engineer (analis/modeler) untuk: Merincikan kembali kebutuhan dasar sistem selama masa awal requirement. Membangun model yang menggambarkan skenario user, aktivitas fungsional, class, dan alur data pada sistem.

27 27 Analisis = Jembatan

28 28 Elemen dari Analisis Requirement

29 29 Modeling berdasarkan SKENARIO (Scenario-Based Modeling)

30 Modeling berdasarkan Skenario 30 *Use case+ membantu mendefinisikan secara sederhana apa yang ada di luar sistem (actors) dan apa yang seharusnya dilakukan oleh sistem (use cases). Ivar Jacobson 1. Apa yang seharusnya ditulis? 2. Bagaimana membuat skenarionya? 3. Sedetil apa deskripsi yang harus dibuat? 4. Bagaimana mengatur deskripsi yang sudah dibuat?

31 Apa yang ditulis? 31 Menyediakan informasi yang dibutuhkan untuk dapat menulis use cases, dengan melakukan: Requirement gathering meetings, QFD, dan mekanisme requirement lainnya digunakan untuk: Mengidentifikasi stakeholders Medefinisikan skup proyek Menentukan tujuan operasional secara umum Membangun prioritas proyek Mengurai semua requirement fungsional Menggambarkan benda (objek) yang berhubungan dengan sistem Untuk memulai pembuatan set of use case, buat daftar fungsi/aktivitas oleh aktor tertentu (spesifik).

32 Sebanyak apa ditulis? 32 Sebagai pembicaraan lanjutan dengan stakeholders, tim requirement gathering membuat use case untuk tiap fungsi yang sudah disepakati. Secara umum, use case ditulis pertama kali dengan bahasa narasi yang informal. Jika dibutuhkan use case yang lebih formal, maka use case yang sama akan ditulis sesuai dengan struktur format use case yang baku.

33 33 Dari tadi banyak disebut kata use case Ok, sekarang kita mulai berkenalan dengan USE CASE

34 Use Case adalah 34 Suatu kumpulan dari hubungan skenario yang sukses dan gagal yang menggambarkan seorang aktor menggunakan sistem untuk mencapai tujuan dari sistem tersebut [Larman, 2005]. Sebuah skenario yang menggambarkan suatu penggunaan dari sebuah sistem [Pressman, 2010]

35 Use Case adalah 35 Skenario adalah suatu urutan aksi (action) yang spesifik dan interaksi antara aktor dengan sistem [Larman, 2005]. Aktor merepresentasikan peran (role) dari orang atau piranti yang akan menggunakan fungsi sistem. Aktor/pengguna dapat memainkan sejumlah peran yang berbeda dari skenario yang ada.

36 Kenapa Use Case? 36 Use case merupakan cara yang baik untuk menerapkan prinsip KIS, dan memungkinkan para pengguna untuk mengerti deskripsi fungsi sistem (yang sesuai dengan requirement mereka) yang tergambar dalam use case. Use case menekankan pada tujuan dan perspektif pengguna; kita (sebagai analis) bertanya ke mereka: Siapa yang akan menggunakan sistem? Tipe skenario apa yang mereka gunakan? Apa tujuan/goal mereka?

37 Format Use Case - [LARMAN, 2005] 37 Brief satu paragraf kesimpulan, berupa skenario utama dari sistem yang sukses. Kapan? Selama masa awal requirement, untuk melihat skup/besaran proyek. Pembuatan brief use case ini biasanya tidak membutuhkan waktu yang lama. Casual- Format paragraf yang informal. Sejumlah paragraf yang mencakupi berbagai skenario. Kapan? Sama dengan brief UC.

38 Format Use Case - [LARMAN, 2005] 38 Fully dressed Semua langkah dari berbagai fungsi ditulis dengan detil, dan ada bagian pendukung seperti prekondisi dan jaminan sukses. Kapan? Setelah use case diidentifikasi dan ditulis dalam format brief, maka selama masa awal requirement, beberapa use case yang signifikan dalam sistem ditulis dengan lebih detil.

39 Contoh dari UC Format Casual 39 Handle Returns Main Success Scenario: Kustomer kembali ke halaman utama dengan barang yang dipilih sebelumnya. Kasir menggunakan sistem POS untuk mendata setiap barang yang dipesan. Alternate Scenarios: Jika kustomer membayar dengan kredit, dan transaksi reimburse untuk kartu kredit tersebut ditolak, maka beri info ke kustomer untuk melakukan pembayaran dengan cash. Jika kode barang yang dipesan tidak ditemukan, maka beritahu kasir untuk memasukkan kode barang secara manual. Jika... Jika...

40 40 Full Dressed Format

41 Menulis Black-Box Use Cases 41 Umum digunakan dan direkomendasikan. Tidak mendeskripsikan kerja internal sistem, komponennya, atau disainnya. Namun, mendeskripsikan apa yang menjadi tanggung jawab sistem (responsibilities). Dengan mendefinisikan tanggung jawabnya, kita bisa menspesifikasikan apa yang harus dilakukan sistem (fungsi atau tingkah lakunya) sebelum menentukan bagaimana sistem akan melakukannya. Analisis vs Disain terkadang disimpulkan sebagai Apa vs Bagaimana.

42 Menulis Black-Box Use Cases 42 Contoh: Black-box Style Sistem merekam data penjualan Not Sistem menulis data penjualan ke database.. Atau Sistem men-generate statement SQL INSERT untuk data penjualan..

43 Temukan Aktor dan Tujuannya 43 Sebelum menentukan use case Observasi nilai hasil dari setiap aktor selama requirement dengan melakukan hal berikut: Tulis requirement dengan berfokus ke aktor/user dari sistem, pastikan tujuannya dan tipe situasinya (perannya) Fokus kepada Apa pertimbangan aktor dan apa nilai hasilnya pada sistem

44 Bagaimana Menemukan Use Case 44 Step 1: Tentukan batasan sistem (the System Boundary) Klarifikasi dengan menentukan siapa aktor utama sistem dan siapa aktor pendukung (contoh: pihak pemerintah, pajak). Jika aktor sudah diidentifikasi, batasan sistem akan menjadi kelihatan. Step 2 dan 3: Tentukan aktor utama dan tujuannya Penentuan aktor utama dilakukan untuk mengidentifikasi apa tujuan/perannya terhadap sistem untuk kemudian dicarikan solusinya.

45 Bagaimana Menemukan Use Case 45 Apa saja pertanyaan untuk menemukan aktor dan tujuannya? Siapa yang membuka dan menutup sistem? Siapa pengguna dan manajemen sekuritinya? Siapa yang melakukan sistem administrasinya? Bagaimana ketersediaan waktu aktor pada saat sistem membutuhkan waktu untuk respon yang lebih banyak untuk kasus tertentu? Adakah yang memonitori proses restart sistem saat sistem bermasalah? Bagaimana menangani update software? Adakah software external atau sistem robotik yang juga menggunakan layanan sistem? Siapa yang akan mengevaluasi aktivitas atau performa sistem?

46 Bagaimana Menemukan Use Case 46 Dari pihak admin sistem Siapa yang mengevaluasi log kerja sistem? Siapa pihak yang harus segera tahu apabila sistem mengelami error atau gagal berfungsi?

47 Bagaimana Menemukan Use Case 47 Ciri Bahasa Use Case: Singkat, jelas Hapus kata-kata yang mengganggu Mulai nama use case dengan menggunakan kata kerja Contoh: Batalkan pemesanan, bukan Sistem membatalkan pemesanan

48 Bagaimana Menemukan Use Case 48 Untuk mengatur aktor dan tujuannya, paling tidak ada 2 pendekatan: Setelah menemukan aktor dan tujuannya, gambar aktor di use case diagram sebagai aktornya, dan tujuan sebagai use case-nya. atau Tulis tujuan aktor terlebih dahulu, review dan perbaiki jika perlu, gunakan bahasa use case, kemudian gambar use case diagram-nya.

49 49 Contoh Daftar Aktor dan Tujuannya

50 Bagaimana Menemukan Use Case 50 Setelah mengetahui gambaran besar tentang sistem... Mengapa bertanya tentang aktor-dan-tujuannya lebih baik daripada langsung membuat use case? Karena visi dari membuat use case adalah untuk menemukan aktor dan tujuannya, kemudian membuat solusi yang menjadi nilai dari hasil sistem. Daripada bertanya Apa tugas yang dilakukan sistem?, lebih baik bertanya Siapa yang akan menggunakan sistem dan apa tujuan mereka?

51 Bagaimana Menemukan Use Case 51 Step 4: Define Use Cases Ingat, mulai nama use case dengan menggunakan kata kerja.

52 (Mulai) Membangun Use Case 52 Untuk mendapatkan tujuan aktor, analis memastikan: Apa tugas/fungsi utama yang akan dilakukan oleh aktor? Informasi apa yang bisa didapat, dibuat, atau diubah oleh aktor didalam sistem? Informasi apa yang aktor inginkan ada di dalam sistem? Contoh Use Case Diagram (next slide)

53 53

54 Pertemuan ke-5 54 Use Case Diagram