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
Acknowledgement 2
Main materials: [Pressman, 2010] Pressman, Roger S. Software Engineering: A Practitioner’s Approach. New York:McGraw-Hill Higher Education, 2010. Print Supplements: [Yud, 2012] Yudhoatmojo, Satrio Baskoro. “Software & Software Engineering” IKI30202 - Rekayasa Perangkat Lunak Term 1 2011/2012. Faculty of Computer Science University of Indonesia. 2012. 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, 2005. Print
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
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
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
3 Teknik Analisis Requirement
1. Business Process Automation (BPA) 7
Jangan ubah operasional dasar (basic) dari sistem Lakukan otomatisasi untuk bebrapa fungsi (trigger by sistem) Goal: efisiensi untuk user/pengguna
2. Business Process Improvement (BPI) 8
Memperhatikan durasi dan harga proyek Meningkatkan performa sistem Goal: Efisiensi dan Efektivitas untuk user/pengguna
3. Business Process Reengineering (BPR) 9
Merubah secara pokok (fundamental) bagaimana operasional sistem untuk perusahaan
Goal: Mendisain ulang secara total proses bisnis dari sistem
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)
Karakteristik Proyek 11
Business Process Business Process Automation (BPA) 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
Requirement Engineering
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
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?
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
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.
Eliciting Requirements 17
3. Elaboration 18
Elaborate = menguraikan, merincikan. Merincikan hasil requirement, dan Membuat model analisa yang mengidentifikasikan data, fungsi, dan kebutuhan lainnya.
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)
5. Spesifikasi 20
Specification — dapat berupa: Dokumen
tertulis (narasi) Himpunan model Rumus matematika Kumpulan dari user scenarios (use-cases) Prototipe
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)
7. Manajemen 22
Manajemen Requirement Mengidentifikasi dan
mengatur requirement, termasuk mengatur perubahan terhadap requirement.
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 UseCase Model dan Supplementary Specification, dan mendapatkan visi/gambaran proyek.
Business Rules – Kebutuhan dan kebijakan lain yang penting bagi proyek.
Produk Hasil Requirement 24
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.
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.
Analisis = Jembatan 27
Elemen dari Analisis Requirement 28
29
Modeling berdasarkan SKENARIO (Scenario-Based Modeling)
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?
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).
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
Dari tadi banyak disebut kata “use case”
Ok, sekarang kita mulai berkenalan dengan
USE CASE
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]
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.
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?
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.
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.
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...
Full Dressed Format 40
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”.
Menulis Black-Box Use Cases 42
Contoh: Black-box Style
Not
Sistem merekam data penjualan Sistem menulis data penjualan ke database.. Atau…
Sistem men-generate statement SQL INSERT untuk data penjualan..
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”
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.
Bagaimana Menemukan Use Case 45
Apa saja pertanyaan untuk menemukan aktor dan tujuannya?
Siapa yang membuka dan menutup sistem ?
Adakah yang memonitori proses restart sistem saat sistem bermasalah?
Siapa pengguna dan manajemen sekuritinya?
Bagaimana menangani update software?
Siapa yang melakukan sistem administrasinya?
Adakah software external atau sistem robotik yang juga menggunakan layanan sistem?
Siapa yang akan mengevaluasi aktivitas atau performa sistem?
Bagaimana ketersediaan “waktu” aktor pada saat sistem membutuhkan waktu untuk respon yang lebih banyak untuk kasus tertentu?
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?
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…”
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.
Contoh Daftar Aktor dan Tujuannya 49
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?”
Bagaimana Menemukan Use Case 51
Step 4: Define Use Cases Ingat,
kerja.
mulai nama use case dengan menggunakan kata
(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
Pertemuan ke-5… 54
Use Case Diagram
