Anda di halaman 1dari 7

KELAS C:

CASE STUDI 1
Lucki Nafia
Oktavia
Uly T.
Ernita
CASE STUDI 2
Kharisma A.
Tanty Rodyawati
Astri Dyahaloka
Faris Tri Utomo

Kelas D
CASE STUDI 1
Bayu Adi Bhaskara
Rochmad Nurdin
Ardeni Bayu
Tri Nugroho
CASE STUDI 2
Ryan Haris
Achmad Zainudin
Anom Sulton
Yoke Panjawi

Pada semua studi kasus di bawah ini buatlah laporan sesuai dengan format pada
lampiran 1. Perhatikan hal-hal di bawah ini:
1. USE CASE DIAGRAM SISTEM YANG AKAN DIBUAT (perhatikan generalisasi dan
batasan sistem)
2. USE CASE SPESIFICATION (basic flow, alternative flow)
3. SEQUENCE DIARAM / COMMUNICATION DIAGRAM (salah satu)
4. VIEW OF PARTICIPATING CLASS (VOPC)

STUDI KASUS 1
Sebuah klinik ingin mengembangkan sistem informasi. Sistem informasi tersebut akan
digunakan untuk menangani rekam medis, resep sekaligus ketersediaan obat yang ada di
dalam klinik. Saat ini, sistem sudah memiliki sebuah sistem yang disebut MANTAP
(Manajemen Kesehatan Pasien). Mantap berisi data no ID pasien dan data pribadi pasien.
Namun, Mantap tidak dapat menyimpan riwayat kesehatan pasien, atau yang sering disebut
sebagai rekam medis.
Sistem Rekam Medis yang baru, disebut sebagai PACAR (Pengelolaan Pasien dan Pencarian
Resep). Agar dapat berfungsi dengan baik, Pacar harus dapat mengambil data dari Mantap.
Seorang dokter akan menyimpan data riwayat kesehatan di Pacar kemudian menuliskan resep
ke sistem. Akan tetapi, dokter diharuskan mencari obat yang tersedia di apotik klinik untuk
dimasukkan ke dalam resep jika ada. Setelah diperiksa, pasien dapat langsung mengambil
obat di apotik klinik. Jika ternyata tidak semua obat tersedia, maka apoteker dapat mencetak
copy resep khusus obat yang tidak ada sesuai dengan permintaan pasien sekaligus mencetak
nota obat yang tersedia serta total pembayaran yang harus dibayar pasien. Sistem
menyimpan data pembelian obat oleh pasien dan memberikan diskon khusus sebesar 5% jika
transaksi dalam 1 bulan terakhir mencapai lebih dari 1 juta rupiah.
Pasien boleh menolak melakukan pembelian di apotek dengan hanya meminta resep ke
bagian resepsionis tanpa datang ke apotek. Jika pasien sudah datang ke apotik, pembelian
juga dapat dibatalkan dengan mekanisme yang sama dengan resepsionis.
STUDI KASUS 2
Sebagai perwujudan usaha peningkatan kualitas pelayanan, AUTO2000 ingin
mengembangkan sebuah sistem pelayanan berbasis internet yang dilengkapi dengan backend offline. Pelanggan AUTO2000 dapat mendaftar antrian service AUTO2000 melalui internet
paling cepat 1 hari sebelumnya, tanggal berapa dan jam berapa yang kosong. Selain itu
pelanggan diminta memasukkan jenis mobil yang akan dirawat. Pelanggan akan
mendapatkan nomor kode booking. Sebuah SMS berisi reminder booking perawatan akan
dikirimkan 2 jam sebelum jam booking. SMS reminder berisi jam booking dan ada berapa
mobil yang saat ini mengantri. Petugas AUTO2000 dapat mengecek jadwal di sistem offline
siapa saja hari ini yang telah booking layanan. Jika pelanggan datang sambil menunjukkan
kode booking, maka petugas akan mencocokkan dengan sistem offline yang dimilikinya
apakah kode booking tersebut sudah sesuai dengan jam datang. Jika sesuai, maka akan
langsung dilayani. Jika pelanggan tidak memiliki kode booking, maka dia harus menunggu
pelanggan lain yang telah memiliki kode booking selesai dilayani terlebih dahulu.
Kode booking akan membantu pelanggan untuk tidak mengantri terlalu lama. Walaupun
begitu, jika pelanggan datang terlambat sampai lebih dari 10 menit, maka orang lain yang
sudah datang akan dilayani terlebih dahulu dan kode booking menjadi hangus. Pelanggan

dapat mengganti jadwal booking paling cepat 1 hari sebelumnya. Karena sistem online
berbasis internet baru mengirimkan data ke sistem offline setiap hari jam 12 malam.

LAMPIRAN 1

Version <1.0>
PROBLEM STATEMENT
[Note: The following template is provided for use with the Rational Unified Process. Text
enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide
guidance to the author and should be deleted before publishing the document. A paragraph
entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields (which display a gray background when selected), select
File>Properties and replace the Title, Subject and Company fields with the appropriate
information for this document. After closing the dialog, automatic fields may be updated
throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click
on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will
toggle between displaying the field names and the field contents. See Word help for more
information on working with fields.]
[Note: If you are not using RequisitePro then this document template should be used to capture
the actual System Use Case including the workflow, special requirements, and performance
goals of the System Use Case. This file should be linked to the corresponding System use case
in the Rose model.
If you use SoDA then this document is used as input to the System use-case report that
combines this content with use-case diagrams from Rose.]

1.1 Introduction
[The introduction of the System Use-Case Specification should provide an overview of the
entire document. It should include the purpose, scope, definitions, acronyms, abbreviations,
references and overview of this System Use-Case Specification.]

1.2 Purpose
[Specify the purpose of this System Use-Case Specification]

1.3 Scope
[A brief description of the scope of this System Use-Case Specification; what Use Case
model(s) it is associated with, and anything else that is affected or influenced by this
document.]

1.4 Definitions, Acronyms and Abbreviations


[This subsection should provide the definitions of all terms, acronyms, and abbreviations
required to interpret properly the System Use-Case Specification. This information may be
provided by reference to the project Glossary.]

1.5 References
[This subsection should provide a complete list of all documents referenced elsewhere in the
System Use-Case Specification. Each document should be identified by title, report number
(if applicable), date, and publishing organization. Specify the sources from which the references
can be obtained. This information may be provided by reference to an appendix or to another
document.]

1.6 Overview
[This subsection should describe what the rest of the System Use-Case Specification
contains and explain how the document is organized.] System Use Case Name

1.7 Brief Description


[The description should briefly convey the role and purpose of the System use case. A single
paragraph should suffice for this description.]

1.8 Performance Goals


[A specification of the metrics relevant to the System use case and a definition of their goals.]

1.9 <name of performance goal>


[A brief description of the performance goal.]

1.10 USE CASE


1.11 Brief Description
[A textual description of the workflow the System use case represents. The workflow should
describe what the System does to deliver value to a System actor, not how the System solves its
problems.
Only one level of workflow steps is indicated in the subsections below, but you may add more
levels if necessary.]

1.12 Basic Workflow


1.12.1

<name of workflow step>

[A brief description of the workflow step.]

1.13 Alternative Workflows


1.13.1

<name of workflow step>

[A brief description of the workflow step.]

1.14 Special Requirements


[The special requirements of the System use case are included here. These are requirements
not covered by the workflow as it has been described in the sections above.]

1.15 <name of special requirement>


[A brief description of the special requirement.]

2.1 Use Case Realization Diagram


2.1.1 <name of use case>
[Sequence or Communication Diagram.]

2.2 Use Case Realization View of Participating Class (VOPC)


2.2.1 <name of use case>
[Class Diagram.]