Memodelkan Kebutuhan Sistem Menggunakan Use-Case

Presentasi berjudul: "Memodelkan Kebutuhan Sistem Menggunakan Use-Case"— Transcript presentasi:

1 Memodelkan Kebutuhan Sistem Menggunakan Use-Case
Perancangan Sistem Informasi Memodelkan Kebutuhan Sistem Menggunakan Use-Case Konsep Sistem untuk Pemodelan dengan Use Case

2 Pembahasan Konsep Analisis Kebutuhan Klasifikasi Kebutuhan
Definisi Use Case (Diagam Use Case) Manfaat use-case modeling Proses Pemodelan Uses Case Notasi Diagram Use Case Menentukan aktor dan use-cases Mengenal 4 tipe aktor Relasi dalam diagram model use-case

3 Tujuan Pembelajaran Mahasiswa mampu memahami konsep, cara atau langkah dalam melakukan analisis kebutuhan sistem inofmasi. Mahasiswa dapat membuat diagram / skema use case

4 Scenarios 4+1 Architecture Model Logical view Development view
System & Environment Process view Physical view

5 Flow of Architecture Process
Logical view Development view Use Case System & Environment Process view Physical view

6 UML Diagram for Architecture Use Case View
Logical view Development view Use Case System & Environment Process view Use Case Diagram Physical view

7 UML Diagram for Architecture Logical View
Sequence Diagram Communication Diagram* Class Diagram Logical view Development view Use Case System & Environment Process view Physical view

8 UML Diagram for Architecture Development View
Component Diagram* Package Diagram Logical view Development view Use Case System & Environment Process view Physical view

9 UML Diagram for Architecture Process View
Logical view Development view Use Case System & Environment Process view Physical view Activity Diagram*

10 UML Diagram for Architecture Physical View
Logical view Development view Use Case System & Environment Process view Physical view Deployment Diagram*

11 Analisis Kebutuhan Sistem
Analisis Kebutuhan merupakan Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan sistem atau perangkat lunak [IEEE93]. suatu proses untuk menetapkan fungsi dan unjuk kerja perangkat lunak, menyatakan antarmuka perangkat lunak dengan elemen- elemen sistem lain, dan menentukan kendala yang harus dihadapi oleh perangkat lunak [PRE01]. Merupakan proses menemukan, memperbaiki, memodelkan dan menspesifikasikan kebutuhan

12 Tujuan Analisis Kebutuhan
benar-benar memahami persyaratan sistem baru mengembangkan sistem yang akan dibuat menetapkan dan menjaga kesepakatan dengan Kustomer dan stakeholder lain tentang apa yang harus dilakukan oleh Sistem memberikan pemahaman yang lebih baik kepada pengembang tentang kebutuhan sistem membuat dasar perencanaan kegiatan & biaya

13 Tantangan dalam analisis kebutuhan
Bagaimana mengumpulkan & mengintegrasikan informasi yang akurat dan bermanfaat Bagaimana menemukan orang yang tepat untuk berpartisipasi

14 Permasalahan pada Analisis Kebutuhan
Pengguna (stakeholders) tidak mengetahui apa yang mereka butuhkan Pengguna menjelaskan kebutuhan dengan cara mereka sendiri sehingga sulit untuk dipahami Pengguna yang berbeda memiliki konflik kebutuhan Faktor politik dan organisasi yang dapat mempengaruhi kebutuhan sistem Perubahan kebutuhan selama proses analisis. Perubahan proses atau lingkungan bisnis

15 Analisis Kebutuhan Analisis kebutuhan dikasifikasikan ke dalam dua kolompok, yaitu: Kebutuhan Fungsional Kebutuhan Non Fungsional

16 Kebutuhan Fungsional Kebutuhan fungsional adalah deskripsi layanan sistem yang harus disediakan, bagaimana sistem beraksi pada input tertentu dan bagaimana perilaku sistem pada situasi tertentu. Didalam analisis kebutuhan fungsional, pemodelan yang akan digunakan adalah pemodelan dengan menggunakan use case. Pemodelan use case adalah proses pemodelan fungsi-fungsi sistem dalam kontak peristiwa- peristiwa bisnis, siapa yang mengawalinya, dan bagaimana sistem itu merespon hal tersebut. (Jeffery L. Whitten, 2006)

17 Kebutuhan Fungsional (lanjutan)
Tujuan dari pembuatan use case adalah untuk mendapatkan dan menganalisis kebutuhan dalam mempersiapkan model yang mengkomunikasikan apa yang diperlukan dari pengguna tentang bagaimana sistem yang akan dibangun dan diimplementasikan. Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem, Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem.

18 Proses Pemodelan Uses Case
Langkah–langkahnya adalah sebagai berikut: Mengidentifikasi pelaku bisnis Mengidentifikasikan use case persyaratan bisnis Membuat diagram model use case Mendokumentasikan naratif use case persyaratan bisnis

19 Proses Pemodelan (lanjutan)
Mengidentifikasi pelaku bisnis Dengan memusatkan perhatian pada pelakunya, sehingga dapat berkonsentrasi pada bagaimana sistem itu akan digunakan dan bagaimana akan dibangun. Memusatkan perhatian pada pelaku juga membantu menyaring dan mendefinisikan lebih lanjut lingkup dan batasan sistem tersebut. Mengidentifikasikan use case persyaratan bisnis Karena use case menggambarkan bagaimana para pelaku sebenarnya berinteraksi dengan sistem, maka teknik yang bagus untuk mencari usecase persyaratan bisnis adalah dengan menyelidiki para pelaku dan bagaimana mereka akan menggunakan sistem tersebut.

20 Proses Pemodelan (lanjutan)
Membuat diagram model use case Setelah use case dan pelaku teridentifikasi, diagram model usecase pun dapat digunakan untuk menggambarkan secara grafis lingkup dan batasan sistem. Mendokumentasikan naratif use case persyaratan bisnis Pada saat mempersiapkan use case naratif, sebaiknya mendokumentasikan terlebih dahulu pada level tinggi, agar dapat memahami kejadian dan besar sistem. Kemudian, kembali ke tiap use case dan mengembangkannya ke naratif persyaratan bisnis yang terdokumentasi secara lengkap. Use case persyaratan bisnis adalah alat yang bagus, karena mendeskripsikan kejadian yang harus diproses dan direspons oleh perusahaan.

21 Kebutuhan Non Fungsional
Kebutuhan non fungsional merupakan fitur-fitur pelengkap yang menunjang kerja sebuah sistem dan mempunyai pengaruh yang tidak langsung. Kebutuhan non fungsional menentukan kualitas layanan. Terdapat beberapa patokan yang digunakan untuk menentukan kebutuhan non fungsional, diantaranya adalah: Kebutuhan kualitas, Kebutuhan Kinerja, Kebutuhan Keamanan Kebutuhan Pengelolaan Kebutuhan Perawatan

22 Pemodelan Use Case Tantangan terbesar dalam proses perancangan sistem adalah kemampuan untuk mengetahui kebutuhan sistem (system requirements): Model data dan proses, prototipe, spesifikasi kebutuhan Dimengerti oleh perancang tapi tidak dimengerti oleh pengguna Lingkup dan jadwal cenderung rumit dan ‘menakutkan’

23 Use Case : Definsi Use Case adalah deskripsi dari sebuah perilaku sistem sebagai respon dari suatu aksi / permintaan dari luar sistem. Dengan kata lain, use case mendeskripsikan ‘siapa’ bisa melakukan ‘apa’ pada sebuah sistem. 

24 Use case diagram dapat digunakan untuk :
Menyusun requirement sebuah sistem, Mengkomunikasikan rancangan dengan klien, dan Merancang test case untuk semua feature yang ada pada sistem. Tidak cocok digunakan untuk merepresentasikan suatu desain Tidak cocok juga untuk menjelaskan internal dari sistem

25 Pemodelan Use-Case: Definisi
Pemodelan Use-Case : proses modeling fungsi- fungsi sistem dalam terminologi kejadian bisnis (business events) yang memicu peristiwa, dan bagaimana sistem menanggapi kejadian tersebut Use-case modeling berakar dari object-oriented modeling. (pemodelan berorientasi obyek) Merupakan pelengkap dari alat-alat modeling tradisional. (seperti ER Diagram)

26 Use-Case Modelling: Manfaat
Alat mendokumentasikan kebutuhan fungsional. Membantu pembagian lingkup sistem sehingga lebih mudah diatur. Alat mengkomunikasikan fungsionalitas sistem pada pengguna dan stakeholder lain. Usecase memiliki bahasa yang dapat dimengerti oleh berbagai stakeholder. Membantu melakukan estimasi lingkup, upaya, dan jadwal sebuah proyek

27 Use-Case Modelling: Manfaat (cont.)
Dasar untuk melakukan testing (test plans dan test cases) Dasar untuk user help systems, manual dan dokumentasi sistem Alat untuk mengetahui kebutuhan Titik awal untuk identifikasi obyek data atau entitas Spesifikasi fungsional untuk merancang user system interface Alat menentukan kebutuhan akses database (menambah, mengubah, menghapus, membaca) Kerangka untuk mengarahkan proyek pengembangan sistem

28 Use-Case Modelling: Konsep Sistem
Diagram Use-case – diagram yang menggambarkan interaksi antara sistem dan sistem eksternal dengan pengguna (user) Use-case narrative – deskripsi naratif business event dan bagaimana user akan berinteraksi dengan sistem untuk menyelesaikan suatu pekerjaan (task)

29 Memodelkan Kebutuhan Sistem Menggunakan Use-Case
Perancangan Sistem Informasi Memodelkan Kebutuhan Sistem Menggunakan Use-Case Konsep Sistem untuk Pemodelan dengan Use Case

30 Notasi-Notasi Dasar Use-Case
Use case – sebuah skenario perilaku untuk menyelesaikan pekerjaan tertentu Digambarkan dalam bentuk elips horisontal Actor – segala sesuatu yang perlu berinteraksi dengan sistem untuk bertukar informasi Contoh: seseorang, organisasi, sistem informasi yang lain, alat eksternal, atau waktu.

31 USE CASE Use case dibuat berdasar keperluan actor, merupakan “apa” yang dikerjakan system, bukan “bagaimana” system mengerjakannya Use case diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor. Use case dinotasikan dengan gambar (horizontal ellipse) Use case biasanya menggunakan kata kerja Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki nama yang sama

32 ACTOR Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan atau menerima informasi dari system Actor menggambarkan sebuah tugas/peran dan bukannya posisi sebuah jabatan Actor memberi input atau menerima informasi dari system Actor biasanya menggunakan Kata benda Tidak boleh ada komunikasi langsung antar actor Indikasi <<system>> untuk sebuah actor yang merupakan sebuah system Adanya actor bernama “Time” yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan) Letakkan actor utama anda pada pojok kiri atas dari diagram

33 Empat Tipe Aktor Primary business actor
Stakeholder yang paling diuntungkan dari terlaksananya use-case dengan menerima sesuatu yang dapat diukur Contoh: karyawan yang menerima pembayaran Primary system actor Stakeholder yang berinteraksi secara langsung dengan sistem untuk memicu kejadian bisnis atau sistem (business or system events) Contoh: teller sebuah bank yang memasukkan informasi deposit External server actor Stakeholder yang menanggapi permintaan dari use-case Contoh: biro kredit melakukan otorisasi charge sebuah credit card External receiver actor Stakeholder yang meski bukan primary actor tapi menerima sesuatu yang bernilai dari use-case Contoh: gudang menerima packing slip1 Actor 1 Actor 3 Actor 2 Use case 1 Use case 2 Use case 3

34

35 Penjelasan Gambar: Customer ingin memesan sesuatu barang dari sebuah toko. Kemudian menelpon customer service dari toko tersebut. Customer service mengecek pembayaran dari customer apakah sudah diterima bagian finance Jika pembayaran selesai kemudian customer service meminta warehouse menyiapkan barang pesanan. Warehouse kemudian melakukan delivery untuk mengirim barang ke customer

36 Use Case Association Relationship
Association – relasi antara actor dengan use-case dimana terjadi interaksi diantara mereka Asosiasi digambarkan dengan garis yang menghubungkan antara actor dengan use-case Asosiasi dengan anak panah menyentuh use-case mengindikasikan bahwa usecase dipicu oleh actor. Asosiasi tanpa anak panah mengindikasikan receiver actor Asosiasi dapat bersifat dua-arah atau multi-arah (bidirectional or unidirectional)

37 Relationship Hubungan yang terjadi antar simbol dalam use case
Menggunakan garis dan tipe simbol yang digunakan untuk menghubungkan garis. Assosiation (gabungan)  hubungan antara aktor dengan use case di mana terjadi interaksi diantara mereka. Anggota Klub Pusat DIstribusi Place New Order Use diiimitasi oleh aktor Interaksi

38 Use Case Extends Relationship
Extension use-case – sebuah use case yang terdiri dari langkah- langkah yang diambil dari use case lain yang lebih rumit untuk mempermudah case aslinya sehingga memperluas fungsionalitasnya Relasi antara extension use case dengan use case yang diperluas disebut sebuah extends relationship Digambarkah dengan garis dengan anak panah, dimulai dari extension use case menuju ke use case yang diperluas. Masing-masing garis extends relationship diberi label “<<extends>>.”

39 Use Case Extends Relationship
Memungkinkan suatu use case secara optional menggunakan fungsionalitas yang disediakan oleh use case lainnya. Use case pemeriksaan kesehatan suatu saat memerlukan tes laboratorium, tapi pada saat lain tidak. Tergantung pada kondisi pasien yang diperiksa.

40 Use Case Uses/ Include Relationship
Abstract use case: use case yang dapat mengurangi redundansi antar dua atau lebih use case dengan mengkombinasikan langkah langkah yang serupa Abstract case dapat digunakan use case lain yang memerlukan fungsionalitasnya Relasi antara abstract use case dan use case yang menggunakannya disebut uses (includes) relationship

41 Use Case Uses/ Include Relationship
Memungkinkan satu use case menggunakan fungsionalitas yang disediakan oleh use case lainnya.

42 Use Case Depends On Relationship
Depends On – relasi use case yang menentukan use case lain mana yang harus dilakukan sebelum use case yang bersangkutan Dapat menentukan urutan dimana use case perlu dikembangkan

43 Use Case Inheritance Relationship
Inheritance – relasi use case dimana perilaku dari dua actor yang memulai use case yang sama diekstrapolasi dan ditugaskan pada satu abstract actor untuk mengurangi redundansi Actor-actor lain dapat mewarisi (inherit) interaksi dari abstract actor

44 Association antara actor dan use case
Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda

45 Association antara use case
<<include>> termasuk didalam use case lain (required) / (diharuskan) Pemanggilan use case oleh use case lain, contohnya adalah pemanggilan sebuah fungsi program Tanda panah terbuka harus terarah ke sub use case Gambarkan association include secara horizontal Register for courses <<include>> Logon validation Maintain curriculum

46 Association antara use case (Lanjut)
<<extend>> perluasan dari use case lain jika kondisi atau syarat terpenuhi Kurangi penggunaan association Extend ini, terlalu banyak pemakaian association ini membuat diagram sulit dipahami. Tanda panah terbuka harus terarah ke parent/base use case Gambarkan association extend secara vertical

47 Generalization/inheritance antara use case
Generalization/inheritance digambarkan dengan sebuah garis berpanah tertutup pada salah satu ujungnya yang menunjukkan lebih umum Gambarkan generalization/inheritance antara use case secara vertical dengan inheriting use case dibawah base/parent use case Generalization/inheritance dipakai ketika ada sebuah keadaan yang lain sendiri/perlakuan khusus (single condition)

48 Generalization/inheritance antara actor
Gambarkan generalization/inheritance antara actors secara vertical dengan inheriting actor dibawah base/parent use case

49 Use case System boundary boxes
Digambarkan dengan kotak disekitar use case, untuk menggambarkan jangkauan system anda (scope of your system). Biasanya digunakan apabila memberikan beberapa alternative system yang dapat dijadikan pilihan System boundary boxes dalam penggunaannya optional

50

51

52

53 Use Case Diagram Sistem Informasi Puskesmas

54 Diagram Use Case Sistem Manajemen Penyusunan Anggaran Keuangan Daerah

55 Skenario Use Case

56 Scenario (Story) Suatu skenario adalah suatu cerita atau narasi yang mudah diakses untuk membuat aplikasi lebih hidup. Cerita yang baik haruslah sangat spesifik dan terartikulasi seluruhnya dalam ranah prmasalahan: native world of the users. Fungsi penting dari sebuah cerita adalah untuk memungkinkan diskusi yang spesifik (quantified, relevant, explicit).

57 Kriteria Skenario yang Baik
Mudah diakses dan dimengerti Penting, bernilai,appealing, attractive Kritikal dan menantang Sering (Frequent), no exceptional niche Spesifik

58

59

60 Teknik Pengumpulan data, yaitu: Wawancara Observasi Studi literatur
Diskusi dan presentasi Naratif/ sekenario Use Case Diagram Use Case PIECES – Pernyataan Masalah – Matriks Sebab Akibat Masalah Fugsional Prosedur Sistem yang berjalan Prosedur Sistem yang diusulkan Solusi Kebutuhan Event table Kesempatan Non Fungsional Didokumentasikan dengan model, yaitu: Naratif Rich Picture Data Flow Diagram Logis Flowchart Sistem

61

62

63

64 -tidak memiliki data histori cuti

65

66

67 Teknik Pengumpulan data, yaitu: Wawancara Observasi Studi literatur
Diskusi dan presentasi Naratif/ sekenario Use Case Diagram Use Case PIECES – Pernyataan Masalah – Matriks Sebab Akibat Masalah Fugsional Prosedur Sistem yang berjalan Prosedur Sistem yang diusulkan Solusi Kebutuhan Event table Kesempatan Non Fungsional Didokumentasikan dengan model, yaitu: Naratif Rich Picture Data Flow Diagram Logis Flowchart Sistem

68 Prosedur Sistem dari Sistem yang Diusulkan
Pelaku (pemakai sistem) Dokumen berupa formulir (komuinikasi antar bagian) Kebijakan Proses atau proisedur

69 Membuat Rekap Absen Membuat Rekap Gaji

70 Review Question Apakah yang dimaksud dengan Use Case?
Apakah manfaat pemodelan Use Case untuk memodelkan sistem? Terdapat berapa tipe relationship yang ada pada use case? Apa ciri use case inheritance relationship?