Kegiatan Siklus Hidup Perangkat Lunak

Persyaratan Sistem Rincian Pelaksanaan-

Analisis Pengujian
Penggalian Desain Desain tasi

Implemented
Dinyatakan dalam Oleh
Disusun Oleh Direalisasikan Oleh
Syarat Dari Terverifikasi
Oleh

kelas...
class...
kelas... ?
kelas.... ?
Studi Kasus Aplikasi Solusi
Domain Subsistem Sumber Uji
Model Domain
Objects Kode Model Kasus
Objek
 Model
•Model adalah sebuah abstraksi dari
sistem
–Sebuah sistem yang tidak lagi ada
–Sistem yang ada
Sebuah sistem masa depan yang akan dibangun.
Mengumpulkan Kebutuhan
 Topik
•Menentukan kebutuhan
•Penemuan kebutuhan
•Mengklasifikasikan kebutuhan
• Teknik untuk mengungkapkan kebutuhan
•Mengelola persyaratan
•Riwayat kasus Rumah Sakit Walden, yang utama
sumber untuk contoh yang akan kita bahas

4
4- 5
 Pengumpulan Persyaratan
Tugas pengumpulan kebutuhan adalah untuk
kumpulkan dan definisikan semua fitur yang
sistem informasi harus memiliki untuk
memenuhi tujuan yang telah ditetapkan oleh pelanggan.
•Keandalan dan kebenaran dari
persyaratan bergantung pada sumbernya,
tentang teknik yang kami gunakan untuk memunculkan dan
verifikasi mereka, dan pada efektivitas mereka
manajemen.

4- 6
Penemuan Kebutuhan

4- 7
 Penemuan Kebutuhan
•Requirements discovery identifies the scope
dan tujuan utama dari sistem.
Pengumpulan kebutuhan mendefinisikan apa yang
diperlukan untuk mencapai tujuan-tujuan tersebut.

4- 8
4- 9
 Klasifikasi Kebutuhan
•Persyaratan terbagi menjadi dua kategori besar: fungsional (atau
behavioral) and non-functional. Since both relate to the same
produk, mereka saling terkait dan mempengaruhi satu sama lain:
–Functional Requirements
•Persyaratan fungsional menentukan perilaku sistem dan
batasan pada perilaku itu.
–Kebutuhan Non-Fungsional
•Kebutuhan non-fungsional menentukan sifat non-perilaku dari
sistem dan batasan pada sifat-sifat tersebut.

4- 10
 Persyaratan Non-Fungsional
•Usability
Keandalan
Kinerja
•Keterpeliharaan
Keamanan

4- 11
Teknik untuk Menggali Kebutuhan
•Wawancara
•Kuesioner
•Workshop Elicitation
Kunjungan Lapangan dan Observasi
Pemodelan
•Contoh

4- 12
4- 13
 Mengelola Persyaratan
Document and update requirements
Sumber dokumen
Pisahkan persyaratan menjadi unit-unit yang berbeda
Identifikasi setiap persyaratan secara unik
Verifikasi persyaratan dan dokumentasikan
{"verifications":"verifikasi"}
Prioritaskan kebutuhan
Mengklasifikasikan persyaratan secara bermakna

4- 14
Sejarah Kasus: Pusat Medis Walden
Kami akan menggunakan Walden
riwayat kasus sebagai kami
contoh utama.

4-15
 Persyaratan Awal
Konsultan menyimpulkan bahwa untuk mencapai
tujuan proyek perbaikan modal, sebuah
elektronik terintegrasi dan komprehensif
sistem informasi sangat penting.

4- 16
 Selanjutnya: Analisis Domain

•Sementara persyaratan mengidentifikasi fitur dari

analisis domain produk menempatkan mereka
fitur dalam konteks domain bisnis.
Kami akan belajar tentangruang masalah dan
ruang solusi.
• Kami juga akan menjelajahi perbedaan antara
persyaratan, masalah, solusi sebagai
metode, dan solusi sebagai produk.

4- 17
Analisis Domain
 Topik
Tiga komponen pemecahan masalah.
•Ruang masalah vs. ruang solusi.
•Kebutuhan vs. spesifikasi produk.
•Domain dan batasannya.
•Mengidentifikasi konsep domain untuk analisis dan
pemodelan.
•Kamus domain dan katalog domain.
•Mengidentifikasi dan mengorganisir aturan bisnis.

5-19
 Analisis Domain
Analisis domain mengidentifikasi konsep bisnis
itu akan disempurnakan menjadi blok bangunan dari
sebuah model analisis untuk sistem informasi.

5-20
5-21
Masalah, Solusi, dan Metode
Menyelesaikan masalah melibatkan bukan sepasang tetapi sebuah trio
komponen: masalah, solusi sebagai metode
atau proses, dan solusi sebagai jawaban. Masing-masing satu
dapat dipahami hanya dalam kaitannya dengan
utuh.

5- 22
 Masalah, Solusi, dan
Persyaratan
Untuk membangun sistem perangkat lunak - sebuah produk - kam

harus memahami masalahnya. Kita juga harus

memahami apa yang diperlukan untuk menyelesaikan
masalahsebelumkita bisamemutuskanbagaimanasolusiasinya.

5- 23
Masalah, Solusi, dan Metode
Tiga komponen pemecahan masalah: masalah
yang ingin kami selesaikan, jawaban untuk masalah tersebut, dan
metode untuk mencapai jawaban.

5- 24
 Konteks, Metode, dan Solusi
•Hanya mengetahui fitur-fitur solusi adalah
tidak memadai untuk membangunnya dengan benar.
Kita harus memahami konteks untuk:
•temukan metode yang tepat, dan
•merancang solusi yang memperhitungkan konteks.

5- 25
5- 26
 Ruang Masalah
•Ruang masalah adalah konteks dari mana
masalah muncul dan di mana solusi harus
mengoperasikan.

5-27
 Ruang Solusi
Ruang solusi mendefinisikan wilayah di mana
keputusan konkret tentang informasi
sistem — sebagai lawan dari fitur-fiturnya — adalah
dibuat.

5- 28
 Kebutuhan versus Spesifikasi Produk

•Persyaratan menentukan fitur yang diinginkan dari

produk atau layanan.

•Spesifikasi produk mendefinisikan produk yang

harus menyadari fitur-fitur tersebut.

5-29
Produk Adalah Solusi untuk Masalah Nyata atau yang Dipersepsikan

Masalah
Product Persyaratan
Palukan paku dan tarik keluar paku.

Tonton waktu dan pasang di pergelangan tangan.

Telepon Memungkinkan orang untuk berbicara dengan orang lain

di seluruh jarak yang luas secara real-time.
Film Hibur dengan suara, musik
dan gambar bergerak.
Pesawat Mengoanrkgtlaisdar
ke lokasi.
Roket untuk membawa orang ke luar angkasa.

5- 30
 Produk dan Persyaratan
Kadang-kadang lebih dari satu produk atau layanan
dapat memenuhi suatu persyaratan.

Pilihan tergantung pada banyak faktor.

5- 31
5- 32
 Domain Definition
•Domain bisnis adalah area yang terkait
kegiatan yang beroperasi pada seperangkat aturan bersama
dan konsep:
Domain bisnis adalah domain yang terorganisir.
–Business domains are goal-oriented.
Domain bisnis bisa berubah dengan cepat.

5- 33
 Lingkup Domain
•Lingkup domain mendefinisikan batas-batas yang
pisahkan aktivitas, aturan, dan konsep yang dibagikan
di dalam suatu domain dari mereka yang di luar.

5- 34
5- 35
 Domain dan Subsystem
•Definisi domain menyediakan kerangka kerja untuk
subsystem konseptual di dalam
sistem informasi.

5- 36
 Pusat Medis Walden:
Definisi Domain
(Partial Listing)

Domain Garis Besar Ruang Lingkup

Patient Management: All activities that directly come into contact with patients
jatuh dalam domain ini, termasuk:
. Referensi
. Jadwal
. Pendaftaran, Penerimaan
. Perawatan
. Masalah Penagihan Pasien
Inventaris Obat &. Inventaris Farmasi
Pembelian:. Rantai Pasokan Obat
……
Medical & Lab . Pembelian Peralatan Medis
Teknologi:. Inventaris Peralatan Medis
. Pemeliharaan Peralatan Medis
House Services: . Laundry
. Pembersihan
. Persiapan Makanan & Diet
… …
5- 37
 Lingkup Walden
Patient Management
•Rujukan
Janji Temu
Pendaftaran
Layanan Medis
Rawat Inap
•Biaya & Pencatatan
•Pengeluaran
Tagihan Pasien

5- 38
 Analisis Domain
Analisis domain adalah menganalisis konteks dari
persyaratan. Ini memiliki tugas ganda:
– definisikan konteks di mana sistem informasi akan
beroperasi.
– menemukan dan mendefinisikan konsep yang dimiliki produk harus
menggabungkan atau mempertimbangkan untuk tujuan untuk memenuhi
tujuan.

5 - 39
 Menemukan Konsep Domain
•Konsep domain adalah objek, proses,
orang-orang dan aturan yang membentuk tujuan,
perilaku dan struktur suatu domain.

5- 40
 Menemukan Konsep Domain
Temukan inti dari persyaratan.
Temukan masalah yang menjadi persyaratan
supposed to solve.
Temukan komponen masalah.
Temukan konsep domain terkait.

5- 41
5- 42
 Kamus Domain
Kamuss domain mengatur dan menciptakan merek domain
konsep. Ini adalah tautan antara pemangku kepentingan yang
harus memverifikasi konsep dan para analis yang
akan menggunakannya sebagai dasar untuk membangun sebuah
model konseptual dari sistem.

5- 43
 Kamus Domain
Kamus mengorganisir konsep domain
ruang masalah) yang relevan dengan sistem (yang
ruang solusi).

•Untuk mengisi kamus, kita beralih ke semua

produk pengumpulan informasi:
persyaratan, wawancara, manual.

5- 44
 Kamus Domain
Konsep yang paling menjanjikan adalah:
–Subjek
• "Kata benda, frasa kata benda, atau kata ganti dalam kalimat atau klausa
yang menunjukkan pelaku tindakan tersebut.
–Objek
•"[Link] kata benda atau substantif yang menerima atau dipengaruhi oleh
aksi dari sebuah kata kerja dalam kalimat.b. Sebuah kata benda atau substantif
mengikuti dan diatur oleh sebuah preposisi.
•Kata benda ini adalah calon untuk menjadi objek dalam sebuah
rasa berorientasi objek.
–Kata kerja
•Mereka dapat menunjukkan proses, tetapi mereka juga dapat menyembunyikan kata benda, atau
objek gramatikal: “memesan sebuah buku” adalah varian dari
"memesan buku." Objek "pesanan" tersembunyi di
kata kerja "memesan."

5- 45
 Kamus Domain
Sebuah Contoh

Layanan MedisTergantung pada sifat dari

layanan medis, dokter, perawat, dan laboratorium
teknisi memberikan pasien dengan
layanan (s) yang sesuai untuk yang
Janji temu telah dibuat.

5- 46
 Template Kamus
•Name
•Tipe
•Description
Sumber
•Catatan

5- 47
 TemplateKamus
•Tipe
–Proses
Serangkaian tindakan, perubahan, atau fungsi yang membawa hasil.
Serangkaian operasi yang dilakukan dalam pembuatan atau pengolahan suatu produk.
–Fungsi
• The purpose or the result of one action or a set of actions.
–Peran
• Sebuah pengelompokan entitas apa pun.

–Objek
. Sesuatu yang dapat dianggap oleh satu atau lebih dari indra, terutama melalui penglihatan atau sentuhan.
. Something intelligible or perceptible by the mind. Or we can use Entity instead.
Aturan Bisnis
Akan dibahas secara rinci nanti.
–Formula .
•Sebuah pernyataan, terutama persamaan, dari fakta, aturan, prinsip, atau hubungan logis lainnya.
•Sebuah metode untuk melakukan atau memperlakukan sesuatu yang bergantung pada model atau pendekatan yang telah mapan.
–Pengenal
•Sebuah simbol yang mengidentifikasi sebuah objek.

5- 48
 Manajemen Pasien:
Kamus Domain
Name Tipe Description
Janji Temu Jadwal Proses seorang pasien untuk menerima layanan medis.
Dilakukan oleh petugas janji temu.
Janji temu Objek Tanggal dan waktu yang dijadwalkan untuk memberikan layanan medis
kepada seorang pasien.

Petugas Penjadwalan Peran Menjadwalkan janji temu untuk pasien.

Layanan Medis Objek Setiap layanan yang bersifat medis yang diberikan oleh staf medis kepada seorang
pasien: diagnosis, resep, pemberian obat,
tes laboratorium, dll.

Layanan Medis FungsiTindakan memberikan layanan medis kepada pasien oleh

medical staff.
… … …
Referral Source Peran Seorang dokter umum, seorang pekerja medis darurat atau
rumah sakit luar yang merujuk pasien untuk sebuah
janji untuk menerima layanan medis. Pasien
dirinya sendiri dapat menjadi sumber rujukan.
Pendaftaran Proses dilakukan sebelum serangkaian layanan medis dilakukan.
Proses ini mengumpulkan data pribadi yang baru atau yang telah diubah dan

informasi asuransi untuk pasien baru atau yang sudah ada.

Kartu identitas rumah sakit dapat diterbitkan sebagai bagian dari ini
proses. Dilakukan oleh petugas pendaftaran.
Petugas Pendaftaran Role Melakukan pendaftaran.
5- 49
 Business Rules
•Aturan bisnis adalah seperangkat kebijakan terperinci,
undang-undang, prosedur, pedoman dan standar
di mana sebuah perusahaan beroperasi. A
aturan bisnis adalah pernyataan yang mendefinisikan atau
menuntut kepatuhan terhadap suatu unit dalam rangkaian.

5- 50
 Kamus Aturan
•Persyaratan menentukan fitur-fitur produk,
sementara aturan bisnis berlaku di luar satu fasilitas
solusi.

5- 51
 Manajemen Pasien:
Kuesioner Aturan Bisnis
ID Definisi Benar Komentar
Salah
Seorang pasien adalah siapa saja yang menderita dari suatu kondisi medis
001
kondisi dan dirujuk ke rumah sakit oleh seorang
sumber rujukan — seorang dokter, medis
pekerja darurat atau rumah sakit lainnya.

Seorang pasien yang berusia di bawah 18 tahun harus

003
ditemani oleh orang dewasa terkait atau seorang
emergency medical worker.

006 Jika tagihan pasien tidak dibayar dalam 30 hari, maka yang
tagihan dianggap terlambat.

5- 52
Selanjutnya: Pemodelan Konseptual

5- 53
Pemodelan Perilaku I:
Kasus Penggunaan: Dasar-dasar
 Topik
• Apa itu pemodelan use case dan apa yang bukan.
Empat komponen dari sebuah use case.
•Elemen dasar dari diagram kasus penggunaan.
•Bagaimana mengubah konsep dari domain
analisis menjadi kasus penggunaan.
•Mengidentifikasi aktor-aktor terkemuka.
•Mengidentifikasi kasus penggunaan utama.

•Diagram konteks.

6-55
6-56
6-57
 Pemodelan Kasus Penggunaan

•Kasus penggunaan memodelkan perilaku sebuah sistem

–Skenario penggunaan adalah unit dari perilaku sistem
–Kasus penggunaan adalah kontrak yang memformalkan
interaksi antara pemangku kepentingan dan sistem
–Sebuah kasus penggunaan merinci interaksi seorang aktor dengan
sebuah sistem untuk mencapai tujuan yang bernilai bagi pelaku
–Kasus penggunaan tidak bergantung pada teknologi

6-58
 Apa itu Pemodelan Kasus Penggunaan Bukan

Modeling Use Case dibatasi pada sistem

perilaku eksternal
–Kasus penggunaan tidak memodelkan sistem dari dalam.
–Kasus penggunaan tidak efektif dalam menangkap non-
persyaratan fungsional.
Pemodelan use case tidak sama dengan fungsional
dekomposisi.
Kasus penggunaan tidak secara inheren berorientasi objek.
–Kasus penggunaan menjelaskanapa yang dicapai oleh sistem,
tidak begitu.

6-59
 Komponen Kasus Penggunaan
•Sebuah kasus penggunaan memiliki empat komponen:
–Sebuah tujuan,

–Pemangku kepentingan (Aktor)

-Sistem, dan
–Sebuah skenario.

6-60
6-61
 Tujuan
•Sebuah kasus penggunaan hanya berhasil jika tujuannya yang dinyatakan adalah

sepenuhnya tercapai

•Nama sebuah use case adalah tujuannya. Nama tersebut harus

jadilah aktif, singkat, dan tegas.

•Tujuan adalah yang menentukan relevansi dari

aktivitas dalam suatu use case.

6-62
 Pemangku Kepentingan dan Aktor
Pemangku kepentingan adalah entitas-entitas yang
minat dipengaruhi oleh keberhasilan atau
kegagalan penggunaan kasus.

•Seorang aktor adalah entitas di luar sistem yang

berinteraksi dengan sistem untuk mencapai suatu yang spesifik
tujuan.

•Sebuah kasus penggunaan harus menegakkan kepentingan semua

pemangku kepentingan.
6-63
6-64
 Aktor
•Aktor adalah peran yang dapat dimainkan oleh pengguna yang telah diberikan bagian tersebut.
main.

•Tujuan dariaktor utama ditentukan oleh nama dari

use case.

•Mendukung(atau sekunder) aktor mendukung aktor utama dalam

mencapai tujuan dari kasus penggunaan.

•Seorang aktor diidentifikasi dengan nama unik yang menggambarkan sebuah

peran unik.

6-65
 Sebuah Sistem

•Sistem menentukan batasan penggunaan

kasus
•Dua jenis sistem
Sistem nyata
Toko kelontong "fisik"
Sistem informasi
Sistem Point of Sales (POS)
•Sebuah use case tidak dapat meninggalkan sistem, tetapi dapat
menjangkau di seberang batasnya

6-66
6-67
 Beli Bahan Makanan —
Skenario Sistem Nyata
Seorang pelanggan masuk ke supermarket. Pelanggan mengambil sebuah
keranjang belanja atau keranjang dan berjalan-jalan di supermarket.
Pelanggan memilih barang dari rak dan meletakkannya di
keranjang belanja atau keranjang. Setelah selesai, pelanggan
membawa barang-barang ke kasir. Kasir menghitung
total harga barang. Pelanggan membayar untuk
merchandise. Kasir mengemas barang-barang tersebut, mengeluarkan tanda terima kepada
pelanggan dan, jika perlu, mengembalikan kembalian. Yang
pelanggan mengambil tas dan meninggalkan supermarket.

6-68
 Beli Bahan Makanan—
Sistem Point-of-Sale
• Pelanggan menaruh belanjaan di meja kasir.
kasir memindai setiap barang dan menempatkan barang tersebut di tas
[Link] item terakhir dipindai, kasir membaca
jumlah total dari sistem dan mengumumkannya kepada
pelanggan. Jika pelanggan membayar dengan kartu kredit, kasir
menggesekkan kartu melalui kasir untuk dikenakan biaya
jumlah. Pelanggan kemudian menandatangani cetakan.
pelanggan membayar dengan uang tunai, kasir mengembalikan kembalian, jika ada.
Kasir kemudian memberikan struk kepada pelanggan.

6-69
6-70
Gambar tongkat mengidentifikasi seorang aktor.
Lebih dari satu aktor dapat dikaitkan dengan sebuah
kasus penggunaan, dan satu aktor dapat dikaitkan
dengan lebih dari satu kasus penggunaan.

Persegi panjang adalah batas sistem atau

cakupan. Untuk kasus penggunaan, entitas mana pun di luar
batas ini hanya dapat ada sebagai sebuah aktor.

Elips (oval) mewakili kasus penggunaan.

Ia berada di dalam batas sistem.
diagram

Garis sederhana di sebelah kiri mewakili

asosiasi. Ini menunjukkan komunikasi
antara seorang aktor dan kasus penggunaan.

6-71
 Sebuah Skenario

•Skenario adalah urutan yang teratur dari

interaksi antara aktor dan
sistem untuk mencapai tujuan. It
terdiri dari:
Aliran Normal
–Alur Alternatif
–Sub-Aliran
–Pengecualian

6-72
6-73
 Langkah-langkah dalam Skenario Kasus Penggunaan

•Langkah-langkah dapat diulang

–Satu langkah atau serangkaian langkah dapat diulang hingga kondisi tertentu tercapai.
met. Di Checkout Groceries, kasir memindai barang belanja hingga
tidak ada lagi bahan makanan yang tersisa untuk dipindai.
•Sebuah langkah dapat memanggil kasus penggunaan lain
Setiap langkah dapat memanggil kasus penggunaan lain untuk menyelesaikan fungsinya.
Sebuah langkah adalah sebuah transaksi
-Setiap langkah tampak hanya sebagai interaksi, tetapi sebenarnya ini adalah transaksi
antara aktor dan sistem. Itu berarti bahwa di setiap langkah:
•aktor mengirimkan permintaan ke sistem,
sistem memvalidasi permintaan,
•sistem mengubah statusnya sebagai hasil dari validasi, dan kemudian
sistem merespons.

6-74
 Kasusdalam Spektrum Pemodelan
Gunakan

•Kasus penggunaan berada di dekattepi dinamis dari

spectrum pemodelan.

6-75
 Kembangkan Kasus Penggunaan Awal

•Komponen pemodelan use case adalah

diberikan dengan menganalisis dan mengembangkan konsep
hasil dari analisis domain.

6-76
Rumah Sakit Walden: Tonggak Pencapaian
•Untuk menggambarkan bagaimana konsep domain adalah
ditransformasikan menjadi studi kasus, kita membutuhkan yang konkret

contoh.

•Mari kita, kemudian, rangkum tonggak-tonggak yang telah kita

sejarah kasus utama, proyek Walden, memiliki
yang dicapai hingga saat ini.

6-77
 Rumah Sakit Walden: Tonggak Berhasil Dicapai

Analisis Bisnis.
Analis bisnis melakukan studi yang luas tentang bisnis Walden Medical Center.
•Definisi Masalah.
–analisis bisnis mengidentifikasi dan merumuskan masalah yang harus diselesaikan rumah sakit untuk menyelamatkannya
bisnis merosot.
•Usulkan Solusi.
Analis tersebut mengusulkan sebuah proyek modal untuk memperbaiki semua aspek operasi Walden.
infrastruktur.
•Inisiasi Proyek.
Rumah sakit menugaskan CIO baru yang dipekerjakan untuk merencanakan strategi IS untuk medis
pusat.
•Definisi Domain.
Bidang bisnis yang membutuhkan layanan sistem informasi adalah: Manajemen Pasien,
Manajemen Rekam Medis, Hukum, Inventaris & Pembelian Obat, Transportasi, Akuntansi, dan
lebih banyak lagi.

•Penentuan Domain.
Rumah sakit memutuskan bahwa domain Manajemen Pasien harus memiliki prioritas tertinggi.
•Analisis Domain & Kamus Domain.
Dalam ruang lingkup Manajemen Pasien, konsep bisnis dieksplorasi, didefinisikan,
dan disusun menjadi kamus domain awal.

6-78
 Identifikasi Aktor Terkenal
Kandidat utama untuk menjadi aktor
apakah konsep domain diklasifikasikan sebagai "peran."
•Discovering actors is a process of consecutive
abstraksi.

6-79
6-80
 Patient Management: Domain Dictionary
Nama Description
Petugas Janji Temu Menjadwalkan janji untuk pasien.

Penyusun Tagihan Menghasilkan tagihan pasien individual berdasarkan permintaan; mencatat pembayaran; menyelesaikan masalah penagihan.

Dokter Memberikan tingkat layanan medis yang khusus kepada pasien: diagnosis, prosedur
and operations, prescriptions and monitoring of medical conditions.

Medis Darurat Merujuk pasien ke ruang gawat darurat. Melakukan layanan medis darurat
sebelum ruang gawat darurat.
Pekerja
Teknisi Laboratorium Melakukan layanan medis uji: Rontgen, tes darah, MRI, dll.

Staf Medis Setiap orang yang memberikan layanan medis kepada pasien: seorang dokter, perawat, lab
teknisi, atau pekerja medis darurat.

Perawat Membantu dokter dalam memberikan layanan medis. Memberikan obat dan memantau
pasien.

Di Luar Rumah Sakit Merujuk pasien untuk janji temu dan layanan medis.

Dokter Perawatan Utama Merujuk pasien ke rumah sakit untuk menerima layanan medis.

Referral Source Dokter perawatan primer, pekerja medis darurat, atau rumah sakit luar yang
merujuk seorang pasien untuk membuat janji temu untuk menerima layanan medis. Pasien itu sendiri atau
dirinya sendiri bisa menjadi sumber rujukan.

Petugas Pendaftaran Melakukan pendaftaran.

6-81
 Identifikasi Kasus Penggunaan Utama

• Kasus penggunaan utama diidentifikasi melalui analisis

proses dan fungsi bisnis

6-82
 Kasus Penggunaan Utama Walden
Manajemen Pasien: Ringkasan Kasus Penggunaan
ID Name Description Aktor

100 Rujuk Pasien Sumber rujukan merujuk pasien ke rumah sakit Dokter Utama
untuk janji temu menerima layanan medis. Medis Darurat
Pekerja
Rumah sakit lain, Pasien.

120 Buat Janji Atas rujukan, petugas jadwal membuat janji Petugas Penjadwalan
layanan medis untuk pasien.

140 Daftar Pasien Sebelum layanan medis, pendaftaran Petugas Pendaftaran

petugas memperbarui informasi pribadi dan asuransi
jika pasien baru atau informasi yang relevan
diubah. Kartu identitas rumah sakit dikeluarkan jika
pasien baru atau telah kehilangan kartu.

160 Layanan Medis Pelacakan Rumah sakit memberikan layanan medis kepada pasien.{"Doctor":"Dokter","Nurse":"Perawat","Lab":"Laboratorium"}
Teknisi, Darurat
Layanan medis mencakup semua aktivitas yang dilakukan
oleh staf medis yang berkaitan dengan pasien, dari Tenaga Medis
kunjungan ke dokter untuk tes laboratorium hingga rawat inap
dan keluarkan. Staf medis mencatat masing-masing
layanan sesuai biayanya.

180 Kelola Penagihan Pasien Atas permintaan, petugas penagihan mengeluarkan sebuah tagihan untuk Petugas Penagihan
pasien. Petugas juga menyelesaikan
akun pasien dan menerima pembayaran.

6-83
 Kembangkan Diagram Konteks
Diagram konteks menggambarkan interaksi
entitas luar dengan sistem sebagai keseluruhan.
•Diagram konteks terdiri dari tiga
elements:
Sistematau subsistem.
–Entitas di luarsistem yang berinteraksi dengannya.
{"text":"Interaksi"}antara entitas luar dan
sistem.

6-84
Selanjutnya: Mengembangkan Kasus Penggunaan

6-86
Modeling Perilaku II
Mengembangkan Kasus Penggunaan
 Topik
•Mengatur dan mengembangkan kasus penggunaan melalui template.
•Kapan dan bagaimana cara menggeneralisasi aktor.

•Kapan dan bagaimana memperluas fungsionalitas dari sebuah use case.

•Kapan dan bagaimana cara menggunakan kembali use case.

•Kapan dan bagaimana menggeneralisasi kasus penggunaan.

•Fitur dan tujuan dari diagram use case.

•Kapan dan bagaimana bergabung atau membagi use case.

•Menggunakan diagram aktivitas untuk menjelaskan alur logis kasus penggunaan.

•Pemodelan kasus penggunaan sebagai kerangka untuk pengembangan
kegiatan.
•Mengelola rincian dengan membuat suplemen untuk kasus penggunaan.

7 - 88
7 - 89
Sebuah Kerangka untuk Pengembangan

7 - 90
 Kembangkan Kasus Penggunaan Dasar

Apa itu kasus penggunaan "basis"?

–Kasus penggunaan dasar adalah kasus penggunaan yang sepenuhnya terbentuk dan terstruktur.
kasus yang berfungsi sebagai dasar untuk mengembangkan yang lain

artefak analisis dan desain.

7 - 91
 Templat
• Struktur templat menggunakan kasus oleh
menyediakan bidang yang terdefinisi dengan baik dan teratur.

7 - 92
 Bidang Template
•Kolom template mewakili blok bangunan
dari kasus penggunaan, bergabung dalam sebuah yang sudah ditentukan,

cara yang teratur.

7 - 93
 Bidang Template
–Name
•mewujudkan tujuan yang ingin dicapai oleh kasus penggunaan
mencapai.
-ID
identifikator numerik unik untuk kasus penggunaan.
–Ruang Lingkup

• batasan penggunaan kasus - ditentukan oleh sistem atau

sub sistem yang menjadi miliknya.
Prioritas
•memutuskan urutan desain dan implementasi untuk digunakan
kasus.

7 - 94
 Bidang Template
•Ringkasan
–a long version of the use case name and a short version of the
skenario.

•Aktor utama
– adalah aktor yang tujuannya mengidentifikasi dan mendorong penggunaan kasus.

Aktor pendukung
– membantu aktor utama dalam mencapai tujuan dari kasus penggunaan.

7 - 95
7 - 96
 Bidang Template
Pemangku kepentingan
–setiap entitas, manusia atau lainnya, yang memiliki kepentingan dalam hasil dari
kasus penggunaan.

Kondisi awal
–menentukan keadaan sistem sebelum kasus penggunaan dapat dimulai; kondisi pasca
mendefinisikan keadaan sistem setelah sebuah kasus penggunaan selesai.

•Pemicu
–peristiwa yang memulai penggunaan.
Sebuah aliran
–seperangkat kegiatan yang teratur yang terjadi saat para aktor dan sistem
usaha untuk mencapai tujuan.

7 - 97
 Aliran Normal
Alur normal adalah skenario terbaik

Melakukan Aliran Normal:

A [Link] memasukkan kartu bank.
T
M [Link] memasukkan kata sandi.
T
r
a
[Link] memverifikasi kata sandi.
n
s [Link] menyajikan daftar jenis transaksi yang
a
c pelanggan dapat melakukan.
ti
o
n
[Link] selects a type of transaction.

7 - 98
 Sub-Aliran
•Sub-aliran mengidentifikasi rincian dari langkah-langkah dalam
aliran normal
Register
Pasien Alur Normal: [Link] pendaftaran memasukkan atau memperbarui data pribadi
data.

Aliran Sub: 1.1Petugas pendaftaran memasukkan Jaminan Sosial

Jumlah pasien baru.
1.2Petugas pendaftaran memasukkan atau memperbarui data pasien
alamat.
1.3 Petugas pendaftaran memasukkan atau memperbarui data pasien
nomor telepon.
1.4 Petugas pendaftaran memasukkan atau memperbarui nama,
alamat dan nomor telepon pasien
kerabat terdekat.

7 - 99
Alur Alternatif dan Pengecualian
•Langkah alternatif mengidentifikasi solusi; pengecualian menunjukkan
kegagalan

Terima
Pasien Alternatif [Link] baru. Petugas resepsi mengarahkan
Alur/pasien ke pendaftaran…
Exceptions: [Link] bukan baru tetapi pribadi atau asuransi
data telah berubah. Petugas penerimaan mengarahkan
pasien ke pendaftaran…
[Link] telah kehilangan kartu ID rumah sakit.
Petugas resepsi mengarahkan pasien ke
pendaftaran...

7 - 100
 Persyaratan Non-Perilaku
Hanya ketika persyaratan non-perilaku
berlaku untuk kasus penggunaan tertentu, persyaratannya
ditentukan dalam template.

7 - 101
 Bidang Template
•Masalah Terbuka
–questions that must be resolved before the use case
dapat dianggap lengkap.
•Bidang audit
–bantu kami untuk memantau perkembangan kasus penggunaan.
•Bidang Kustom
–menentukan atribut atau persyaratan yang spesifik untuk
one use case or a set of use cases within the system.

7 - 102
7 - 103
 Kamus Aktor
Aktor Description Abstrak Kasus Penggunaan

Janji Temu Membuat janji untuk pasien Make

Petugas untuk menerima layanan medis. Janji Temu

Petugas Penagihan Memelihara penagihan pasien. Masukkan Massal

Pembayaran

Petugas Rumah Sakit Menggeneralisasi: Menangani Pasien

. Petugas Janji Temu Masalah Penagihan
. Petugas Penagihan
. Petugas Resepsionis
. Petugas Pendaftaran
Penerimaan menerima pasien saat kedatangan di Menerima Pasien
Petugas rumah sakit. Memverifikasi pendaftaran.
Mengatur untuk pasien agar
menerima layanan medis.
Pendaftaran Memasukkan atau memperbarui pasien Daftar Pasien
Petugas data pribadi dan pembayaran.
Mengeluarkan kartu rumah sakit, jika
perlu.

7 - 104
 KetergantunganTermasuk dan Memperluas
•Hubungan ekstensi adalah hubungan di mana sebuah penggunaan
kasus dibuat untuk memperluas fungsionalitas dari
kasus penggunaan dasar.

Daftar
Pasien Alur Alternatif/
Exceptions: [Link] tidak baru dan data asuransi tidak berubah.
Petugas pendaftaran tidak memperbarui data asuransi dengan
default.
Pasien ingin membayar seluruh tagihan atau pembayaran bersama
dengan kartu kredit. Petugas pendaftaran memverifikasi kartu kredit
(Perpanjang: 142 - Verifikasi Kartu Kredit) dan merekam kartu kredit
informasi.

7 - 105
 Termasuk Hubungan
•Hubungan include adalah hubungan di mana satu penggunaan
kasus menggunakan fungsionalitas yang lain,
mandiri, kasus penggunaan.
Terima
Pasien Alur Normal: …
3. Petugas resepsionis memverifikasi bahwa pasien
telah terdaftar dan pendaftaran adalah
sah.
…

Alur Alternatif/ Pengecualian: [Link] baru. Petugas penerimaan mengarahkan

pasien ke pendaftaran. (Sertakan:
140 - Daftar Pasien.)
…

7 - 106
 Diagram Kasus Penggunaan untuk Ketergantungan

Dalam diagram kasus penggunaan, jenis ketergantungan adalah

ditunjukkan oleh arah panah.

7 - 107
7 - 108
 Basis UC Arah Panah Dirujuk UC

UC yang Diperpanjang Memperpanjang

Daftar Pasien UC
Verifikasi Kredit
Kartu

Termasuk UC Termasuk UC
Menerima Pasien Register
Pasien

7 - 109
 Generalisasi Kasus Penggunaan

Kami menggeneralisasi kasus penggunaan ketika mereka

mencapai tujuan yang sama dengan cara yang berbeda.

7 - 110
7 - 111
 Diagram Kasus Penggunaan

•Diagram kasus penggunaan adalah meta-model yang

menggambarkan asosiasi di antara aktor, kasus penggunaan
dan sistem.

7 - 112
7 - 113
 Diagram Aktivitas
Diagram aktivitas menggambarkan aliran dari aktivitas
ke aktivitas. Ini menyajikan tampilan visual yang dinamis
sistem dan komponennya.

7 - 114
7 - 115
 Penggunaan Kasus Penggunaan

Kasus penggunaan menyediakan kerangka kerja yang penting untuk

analysis, design, implementation and

kegiatan penyebaran.

7 - 116
 Penggunaan Kasus Penggunaan

Pengumpulan Kebutuhan
Kasus penggunaan menyediakan alat dasar untuk mengumpulkan
persyaratan dalam konteks yang bermakna.
•Jejak Keterlacakan Kebutuhan
–Kasus penggunaan dan dokumen pendukungnya adalah
sumber utama untuk melacak kebutuhan.
•Aturan Bisnis
–Use cases are the framework for gathering business
aturan.
•System Behavior
Perilaku eksternal dari sistem terbuka manapun dapat di
ditangkap secara efektif melalui penggunaan kasus.

7 - 117
7 - 119
 Studi Kasus #1
•Gambarlah diagram use-case untuk proses membeli kacamata dari
pandangan pasien. Langkah pertama adalah menemui dokter mata yang akan
memberikan resep kepada Anda. Setelah Anda memiliki resep, Anda pergi ke sebuah
toko optik, tempat Anda memilih bingkai Anda dan melakukan pemesanan untuk
kacamata Anda. Setelah kacamata dibuat, Anda kembali ke toko
untuk pengukuran dan membayar untuk kacamata.

120
•Gambarkan Diagram USE-CASE UML

??
 Studi Kasus #2
•Gambarlah diagram kasus penggunaan untuk sistem berikut. Sebuah Toko Video (AVS)
mengoperasikan serangkaian toko video standar. Sebelum sebuah video dapat dipasang di
rak, itu harus dicatat dan dimasukkan ke dalam basis data video.
Setiap pelanggan harus memiliki kartu pelanggan AVS yang valid untuk menyewa
video. Pelanggan menyewa video selama tiga hari sekaligus. Setiap kali
pelanggan menyewa video, sistem harus memastikan bahwa mereka tidak memiliki
video yang terlambat. Jika ada, video yang terlambat harus dikembalikan dan sebuah
biaya keterlambatan dibayar sebelum pelanggan dapat menyewa lebih banyak video. Demikian pula, jika
pelanggan telah mengembalikan video yang terlambat, tetapi belum membayar biaya keterlambatan,
biaya harus dibayarkan sebelum video baru bisa disewa. Setiap pagi,
the store manager prints a report that lists overdue videos. If a video is
lebih dari dua hari terlambat, manajer menghubungi pelanggan untuk mengingatkan
mereka untuk mengembalikan video. Jika sebuah video dikembalikan dalam kondisi rusak,
manajer menghapusnya dari basis data video dan terkadang mungkin
kenakan biaya kepada pelanggan.

122
•Gambarkan Diagram USE-CASE UML

??
 Studi Kasus #3
•Gambarlah diagram kasus penggunaan untuk sistem keanggotaan klub kesehatan. Ketika anggota bergabung dengan klub kesehatan,
mereka membayar biaya untuk jangka waktu tertentu. Sebagian besar keanggotaan adalah satu tahun, tetapi keanggotaan sebagai
sependek dua bulan tersedia. Sepanjang tahun, klub kesehatan menawarkan berbagai diskon
pada harga keanggotaan reguler mereka (misalnya, dua keanggotaan seharga satu untuk Hari Valentine).
Adalah hal yang umum bagi anggota untuk membayar jumlah yang berbeda untuk durasi keanggotaan yang sama. Klub
ingin mengirim surat pengingat kepada anggota yang meminta mereka untuk memperbarui keanggotaan mereka satu bulan
sebelum keanggotaan mereka berakhir. Beberapa anggota telah menjadi marah ketika diminta untuk memperbarui pada suatu
tarif yang jauh lebih tinggi daripada kontrak keanggotaan asli mereka, jadi klub ingin melacak harga yang dibayar
sehingga manajer dapat mengganti harga reguler dengan harga khusus ketika anggota diminta untuk
perbarui. Sistem harus melacak harga baru ini agar perpanjangan dapat diproses dengan akurat. Salah satu dari
masalah di industri klub kesehatan adalah tingkat perputaran anggota yang tinggi. Sementara beberapa anggota
Tetap aktif selama bertahun-tahun, sekitar setengah anggota tidak memperpanjang keanggotaan mereka. Ini adalah
masalah besar, karena klub kesehatan mengeluarkan banyak biaya untuk iklan guna menarik setiap anggota baru. The
manajer ingin sistem untuk melacak setiap kali seorang anggota datang ke klub. Sistem kemudian akan
identifikasi pengguna berat, dan buat laporan agar manajer dapat meminta mereka untuk memperbarui
keanggotaan lebih awal, mungkin menawarkan mereka tarif yang lebih rendah untuk pembaruan awal. Begitu juga, sistem
should identify members who have not visited the club in more than a month, so the manager can
hubungi mereka dan coba untuk menarik minat mereka kembali ke klub

124
•Gambarkan Diagram USE-CASE UML

??
 Studi Kasus #4
•Gambarkan diagram use-case untuk sistem berikut. Picnics R Us (PRU) adalah sebuah perusahaan katering kecil dengan
lima karyawan. Selama akhir pekan musim panas yang biasa, PRU menyelenggarakan lima belas piknik dengan dua puluh hingga lima puluh
orang masing-masing. Bisnis ini telah tumbuh pesat selama tahun lalu dan pemiliknya ingin memasang yang baru
computer system for managing the ordering and buying process. PUR has a set of ten standard
menu. Ketika pelanggan potensial menelepon, resepsionis menjelaskan menu kepada mereka. Jika yang
pelanggan memutuskan untuk memesan piknik, resepsionis mencatat informasi pelanggan (misalnya, nama,
alamat, nomor telepon, dll.) dan informasi tentang piknik (misalnya, tempat, tanggal, waktu, yang mana
dari menu standar, total harga) pada sebuah kontrak. Pelanggan kemudian dikirimi faks salinan kontrak tersebut.
dan harus menandatangani dan mengembalikannya bersama dengan setoran (seringkali menggunakan kartu kredit atau cek) sebelum piknik dilakukan
resmi dipesan. Uang sisa dikumpulkan ketika piknik diserahkan. Terkadang,
pelanggan menginginkan sesuatu yang istimewa (misalnya, kue ulang tahun). Dalam hal ini, resepsionis mengambil
informasi dan memberikannya kepada pemilik yang menentukan biaya; kemudian resepsionis menelepon
pelanggan kembali dengan informasi harga. Terkadang pelanggan menerima harga, di lain waktu,
pelanggan meminta beberapa perubahan yang harus dikembalikan kepada pemilik untuk estimasi biaya baru.
Setiap minggu, pemilik melihat melalui piknik yang dijadwalkan untuk akhir pekan itu dan memesan persediaan.
(misalnya, piring) dan makanan (misalnya, roti, ayam) yang diperlukan untuk membuatnya. Pemilik ingin menggunakan
sistem untuk pemasaran juga. Ini harus dapat melacak bagaimana pelanggan mengetahui tentang PUR, dan
identifikasi pelanggan yang berulang, sehingga PUR dapat mengirimkan penawaran khusus kepada mereka. Pemilik juga ingin melacak
piknik yang PUR mengirimkan kontrak, tetapi pelanggan tidak pernah menandatangani kontrak tersebut dan sebenarnya
memesan piknik.

126
Gambarkan Diagram Kasus Penggunaan UML

??
 Studi Kasus #5
•Gambarlah diagram use-case untuk sistem berikut. Of-the-Month Club (OTMC) adalah sebuah inovasi muda
perusahaan yang menjual keanggotaan kepada orang-orang yang memiliki minat pada produk tertentu. Orang-orang membayar
biaya keanggotaan untuk satu tahun dan setiap bulan menerima produk melalui pos. Misalnya, OTMC memiliki sebuah
klub kopi-bulan yang mengirim anggota satu pon kopi spesial setiap bulan. OTMC
saat ini memiliki enam keanggotaan (kopi, anggur, bir, cerutu, bunga, dan permainan komputer) masing-masing dari
yang biayanya berbeda-beda. Pelanggan biasanya hanya tergantung pada satu, tetapi beberapa tergantung pada dua atau
lebih. Ketika orang bergabung dengan OTMC, operator telepon mencatat nama, alamat surat, nomor telepon
number, e-mail address, credit card information, start date, and membership service(s) (e.g., coffee).
Beberapa pelanggan meminta keanggotaan ganda atau triple (misalnya, dua pon kopi, tiga kotak dari
Anggota permainan komputer beroperasi sedikit berbeda dari yang lain. Dalam hal ini,
member must also select the type of game (action, arcade, fantasy/ science-fiction, educational, etc.)
dan tingkat usia. OTMC berencana untuk memperluas jumlah keanggotaan yang ditawarkannya secara besar-besaran (misalnya, video
permainan, film, mainan, keju, buah, dan sayuran) sehingga sistem perlu mengakomodasi masa depan ini
perluasan. OTMC juga berencana untuk menawarkan keanggotaan 3 bulan dan 6 bulan.

128
•Gambar Diagram Penggunaan UML

??
OutdoorPowerEquipmentDepot – Studi Kasus

•Buat Diagram Use-Case lengkap untuk Pelanggan

??
OutdoorPowerEquipmentDepot – Studi Kasus

•Buat Diagram Kasus Penggunaan untuk Manajer & Spesialis Akun

??
OutdoorPowerEquipmentDepot – Studi Kasus

•Buat Diagram Kasus Penggunaan YANG LENGKAP

??