PEMODELAN KEBUTUHAN SISTEM DENGAN USECASE

User Centered Development dan Usecase Modelling User Centered Development – Sebuah proses pengembangan sistem berdasarkan pada pemahaman akan kebutuhan dari para pemilik perusahaan dan alasan mengapa sistem harus dikembangkan. Usecase Modelling – Suatu proses pemodelan fungsi-fungsi sistem yang berhubungan dengan kejadian-kejadian bisnis, siapa yang memprakarsai dan bagaimana sistem merespon kejadian-kejadian tersebut. Usecase merupakan cabang dari Object-Oriented Modelling Meraih popularitas karena fungsinya dalam berkomunikasi dengan user Melengkapi peralatan pemodelan tradisional

Usecase Diagram Usecase : suatu narasi yang menggambarkan secara berurutan, langkah-langkah dari tingkah laku sistem, baik otomatisasi maupun manual. Dengan tujuan untuk melengkapi sebuah pekerjaan bisnis Deskripsi fungsi sistem dari sudut pandang user eksternal dalam bentuk yang mudah dimengerti Usecase Diagram : diagram yang menggambarkan interaksi antara sistem dengan sistem eksternal dan pelaku-pelakunya Secara grafis menjelaskan siapa yang akan menggunakan sistem dan dengan cara apa pelaku akan berinteraksi dengan sistem Narasi Usecase : deskripsi teks tentang kegiatan bisnis dan bagaimana sistem berinteraksi dengan user untuk menyelesaikan pekerjaan

USECASE DIAGRAM Diagram use case dibentuk untuk memvisualisasikan hubungan antara aktor dan use case Aktor merupakan seseorang atau sesuatu yang harus berinteraksi dengan sistem yang akan dikembangkan Simbol aktor dan usecase beserta relationnya digambarkan seperti berikut: Aktor Usecase

Empat Tipe Aktor Primary business actor Pihak yang secara utama diuntungkan oleh eksekusi Usecase Cth: karyawan yang menerima pembayaran gaji Primary system actor Pihak yang secara langsung berinteraksi dengan sistem untuk memulai kejadian bisnis atau sistem Cth: Teller bank menginput informasi deposit External server actor Pihak yang merespon permintaan dari usecase Cth: lembaga perkreditan mengotorisasi pembuatan kartu kredit External receiver actor PIhak yang bukan aktor utama tetapi menerima suatu nilai dari Usecase Cth: Bagian gudang menerima slip pengepakan No additional notes.

Sample Use-Case Model Diagram

Extension dan Absract Usecase Extension usecase : usecase tambahan yang merupakan tingkah laku khusus yang lebih spesifik dari suatu usecase, atau disebut juga usecase pengembangan dari usecase lain yang lebih umum. Extension usecase digunakan bila suatu usecase (proses) memiliki beberapa sub-proses yang tidak dapat dijadikan dalam satu usecase. Tanda panah pada Usecase extension biasanya mengarah pada Usecase General (umum) nya dan diberikan tanda <<extends>> Abstract Usecase: usecase yang mengurangi redudansi antara 2 atau lebih usecase lainnya dengan mengkombinasikan langkah-langkah yang ada pada usecase. Tanda panah Abstract digambarkan dari usecase A menuju Usecase B yang artinya proses yang dilakukan A selalu melibatkan proses B (didalam proses A pasti terlebih dahulu melakukan proses B). Disebut juga <<Uses>> atau <<Includes>>

Usecase Depends On Usecase Depends On adalah relasi Usecase mengkhususkan usecase lain harus dilakukan sebelum melakukan usecase lainnya (ketergantungan antara 1 usecase dengan usecase lainnya) - Dapat membantu menentukan urutan usecase yang akan dikembangkan Tanda panah digambarkan dari satu usecase menuju usecase lain yang bergantung pada usecase tersebut Depends On diberi tanda <<Depends on> pada arah panah Usecase nya.

Contoh kasus: Sistem penyewaan VCD memiliki sistem yg digambarkan dengan usecase berikut: Pinjam VCD Daftar Anggota Baru <<extend>> Terima Bukti transaksi Denda Kembalikan Entry Data VCD <<include>> anggota petugas

Langkah-Langkah Membuat Usecase Diagram Identify business actors  menentukan aktor-aktor yang terlibat dengan membuat tabel daftar aktor Identify business use cases  dengan membuat Usecase Glossary (Tabel Glosarium/Deskripsi Usecase) Construct use-case model diagram  membuat Diagram Usecase berdasarkan Glossary dan tabel aktor Documents business requirements use-case narratives  Membuat tabel Spesifikasi Usecase, yang akan menjelaskan keseluruhan pola kerja setiap usecase yang ada

Sample Use-Case Glossary No additional notes continued

Sample Use-Case Glossary (continued) No additional notes continued

Sample Use-Case Glossary (concluded) No additional notes

Construct Use-Case Model Diagram Teaching Notes Note that the use cases have been grouped into business sub-systems. This is key to defining your development strategy – which use cases will be developed first and by whom.

Sample High-Level Version of a Use-Case Narrative Teaching Notes Author – the persons who wrote the use case and provide a point of contact for anyone requiring additional information. Date – the date the use case was last modified. Version – the current version of the use case. Use-case name – the use-case name should represent the goal that the use case is trying to accomplish. Should begin with a verb. Use-case type – Business requirements use cases provide a general understanding of the problem domain and scope but don’t include detail to communicate to developers what the system should do. Use-case ID – A unique identifier for the use case. Priority – The priority communicates the importance of the use case (high, medium, or low). Source – The source defines the entity that triggered the creation of the use case. Primary business actor – The stakeholder that primarily benefits from the execution of the use case. Other participating actors – Other actors that participate in the use case. Interested stakeholders – A person (other than the actor) who has a vested interest in the goal of the use case. Description – A short summary description of the purpose of the use case and its activities.

Sample Expanded Version of a Use-Case Narrative Teaching Notes Precondition – A constraint on the state of the system before the use case can be executed. Trigger – The event that initiates the use case. Typical course of events – The normal sequence of activities performed by the actor(s) and the system to satisfy the goal of the use case. Alternate courses – The behaviors of the use case if an exception or variation to the typical course occurs. Conclusion – When the use case successfully ends. Postcondition – A constraint on the state of the system after the use case has successfully executed. Business rules – Policies and procedures of the business that the system must abide by. Implementation constraints and specifications – Any nonfunctional requirements that may impact the realization of the use case. Assumptions – Assumptions made by the author. Open issues – Issues that need to be resolved before the use case can be finalized. continued

Sample Expanded Version of a Use-Case Narrative (cont) Teaching Notes Precondition – A constraint on the state of the system before the use case can be executed. Trigger – The event that initiates the use case. Typical course of events – The normal sequence of activities performed by the actor(s) and the system to satisfy the goal of the use case. Alternate courses – The behaviors of the use case if an exception or variation to the typical course occurs. Conclusion – When the use case successfully ends. Postcondition – A constraint on the state of the system after the use case has successfully executed. Business rules – Policies and procedures of the business that the system must abide by. Implementation constraints and specifications – Any nonfunctional requirements that may impact the realization of the use case. Assumptions – Assumptions made by the author. Open issues – Issues that need to be resolved before the use case can be finalized. continued

Sample Expanded Version of a Use-Case Narrative (cont) Teaching Notes Precondition – A constraint on the state of the system before the use case can be executed. Trigger – The event that initiates the use case. Typical course of events – The normal sequence of activities performed by the actor(s) and the system to satisfy the goal of the use case. Alternate courses – The behaviors of the use case if an exception or variation to the typical course occurs. Conclusion – When the use case successfully ends. Postcondition – A constraint on the state of the system after the use case has successfully executed. Business rules – Policies and procedures of the business that the system must abide by. Implementation constraints and specifications – Any nonfunctional requirements that may impact the realization of the use case. Assumptions – Assumptions made by the author. Open issues – Issues that need to be resolved before the use case can be finalized.

Usecase Model Diagram dengan beberapa subsystem: Peminjaman Daftar anggota Input vcd Input anggota Input data transaksi Petugas Ubah data anggota Ubah data transaksi Hapus anggota Hapus trsksi Verifikasi Laporan Administrator Login Cetak lap.Vcd Ubah password Cetak lap. trsks