• Tidak ada hasil yang ditemukan

Software Requirements Specification

N/A
N/A
Protected

Academic year: 2021

Membagikan "Software Requirements Specification"

Copied!
15
0
0

Teks penuh

(1)

Software Requirements Specification

Versi 1.0

Maret 10, 2015

Dental Clinic

Administration Apps

A’isya Nur Aulia Yusuf (40805)

Amalina Kurniasari

(40852)

Nourma Reizky Damayanti (41367)

Fakultas Teknik

Universitas Gadjah Mada

2015

(2)

i

Table of Contents

Table of Contents ... i List of Figures ... ii 1.0. Introduction ... 1 1.1. Purpose ... 1 1.2. Scope of Project... 2 1.3. Glossary ... 3 1.4. References ... 3 1.5. Overview of Document ... 3 2.0. Overall Description ... 5 2.1 System Environment... 5 2.2 Use Cases... 6 2.3 User Characteristics ...8 2.4 Non-Functional Requirements ...8 3.0. Requirements Specification ...9

3.1 External Interface Requirements ...9

3.2 Functional Requirements ...9

3.3 Detailed Non-Functional Requirements ...11

(3)

SRS V 1.0 1 Maret 10, 2015

1.0. Introduction

1.1. Purpose

Aplikasi Denal Clinic Administration adalah sebuah aplikasi untuk desktop yang ditujukan bagi para resepsionis poliklinik gigi. DentistAdministration memberikan sebuah fasilitas bagi resepsionis untuk mengatur jadwal periksa antara pasien dan dokter gigi dengan mudah. Dengan memanfaatkan sistem yang terintegrasi, aplikasi ini dapat menampilkan jadwal periksa antara pasien yang satu dengan pasien lainnya, baik dengan dokter gigi yang sama maupun berbeda. Selain itu, aplikasi ini juga mendigitalisasi rekam medis pasien agar lebih terkoordinir dengan baik.

Sistem akan mendata pasien yang akan berobat menggunakan nomor (sejenis ID) pasien. Nomor ini bisa didapatkan oleh para pasien yang pernah berobat sebelumnya. Bila baru pertama kali berobat, maka sistem akan membuatkan nomor pasien bagi pasien baru. Setelah melakukan registrasi awal, sistem akan mencari dokter mana yang sedang tidak melakukan pemeriksaan pasien. Bila ada dokter yang sedang tidak bekerja, maka sistem akan langsung menyarankan pasien untuk pergi ke dokter tersebut. Tapi bila semua dokter sedang bekerja, sistem akan menyarankan pasien untuk antre di dokter dan menunggu giliran. Ketika pasien akan melakukan pemeriksaan dengan salah satu dokter, sistem akan mengirimi dokter tersebut rekam medis pasien yang bersangkutan. Setelah itu pasien akan melakukan pemeriksaan dengan dokter masing-masing. Selesai pemeriksaan, dokter dapat meminta asistennya untuk mengupdate rekam medis pasien dan menyimpannya dalam database. Kemudian pasien kembali ke resepsionis untuk melakukan pembayaran. Resepsionis akan mencoret pasien yang sudah selesai melakukan pemeriksaan dari antrean, sehingga pasien selanjutnya dapat menjalani pemeriksaan dan begitu seterusnya.

(4)

SRS V 1.0 2 Maret 10, 2015

Aplikasi Dental Clinic Administration bertujuan untuk mengintegrasikan jadwal periksa antara pasien-dokter gigi yang satu dengan lainnya dan memudahkan resepsionis untuk menentuka giliran periksa antar pasien. Sistem database yang tersedia di dalam aplikasi juga membantu resepsionis menjaga data pasien beserta rekam medis yang dimiliki.

1.2. Scope of Project

Aplikasi Dental Clinic Administration dirancang sebagai sebuah software yang user-friendly sehingga mudah dioperasikan oleh resepsionis dokter gigi. Selain pengguna Android, aplikasi ini dapat juga dimanfaatkan oleh asisten dokter gigi untuk mengupdate data rekam medis dan jadwal praktek dokter gigi. Proses penjadwalan praktek yang lebih tekoordinasi dan terorganisir dapat mempercepat waktu registrasi di resepsionis sehingga memudahkan dan mempercepat kinerja resepsionis dokter gigi agar semakin optimal, efektif, efisien dan semakin banyak pasien yang dapat terlayani.

Software ini juga dapat digunakan sebagai sarana pengaturan jadwal praktek dokter gigi karena memberikan informasi mengenai banyaknya calon pasien yang akan diobati. Harapannya, keberadaan aplikasi DentistAdministration dapat membantu resepsionis, asisten dokter gigi dan dokter gigi untuk saling berkoordinasi mengatur jadwal, mendata rekam medis pasien agar dapat memberikan pelayanan yang maksimal pada pasien.

(5)

1.3. Glossary

Term Definition

Resepsionis Orang yang bertugas sebagai penerima pasien di suatu klinik Asisten dokter Orang yang mendampingi dokter dalam penanganan

pasien

Dokter Dokter adalah orang yang melakukan perawatan medis

Pasien Pasien adalah seseorang yang menerima perawatan medis Odontogram Salah satu pendekatan rekam medis yang menggambarkan

gigi menggunakan visual dan supplemental kode

Rekam medis Rekam medis adalah berkas yang berisi catatan dokumen dan informasi mengenai identitas dan kondid pasien Software Requirements

Specification A document that completely describes all of the functionsof a proposed system and the constraints under which it must operate. For example, this document.

Stakeholder Any person with an interest in the project who is not a developer.

User Reviewer or Author.

1.4. References

IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements

Specifications. IEEE Computer Society, 1998.

1.5. Overview of Document

Pada bab selanjutnya, akan dijelaskan mengenai use case dan dan fungsi rinci dari aplikasi. Selain itu juga akan dijelaskan mengenai informal requirements dan berfungi untuk menjelaskan konteks untuk merancang spesifikasi teknik pada bab-bab

(6)

Chapter ketiga berisi requirement specification yang ditulis untuk para developer dan mendeskripsikan fungsi dari produk. Kedua chapter mendeskripsikan aplikasi secara detail tapi diperuntukan bagi pembaca yang berbeda dan dengan bahasa yang berbeda.

(7)

2.0. Overall Description

2.1 System Environment Resepsionis HS DB Reka m M edi s Asi sten D okter Jadw al D okter Daf tar A ntri an P asi en

(8)

2.2 User interactions with the Web Publishing System (use cases)

Resepsionis dan Asisten Dokter memiliki akses dan kedudukan yang sama dalam penggunaan aplikasi ini.

2.2.1 Resepsionis Use Case

Use case: update daftar antrian pasien

Diagram:

update daftar antrian pasien

resepsionis

Brief Description

Resepsionis mengecek daftar antrian pasien sesuai dengan nomer pasien.

Initial Step-By-Step Description

1. Resepsionis menerima nomor dari pasien yang sudah terdaftar di klinik 2. Resepsionis memasukkan nomor pasien dan keluhan pasien ke dalam sistem 3. Sistem memunculkan jadwal dokter yang sesuai dengan keluhan pasien

4. Resepsionis memverifikasi untuk menginput data pasien pada daftar antrian sesuai dengan jadwal dokter yang bersangkutan dengan keluhan pasien

Xref: Section 3.2.1, Search Article

Use case: Resepsionis Input Data Pasien Baru

Diagram:

Input Data pasien baru

(9)

Rsepsionis

Brief Description

Resepsionis menginput data diri dari pasien baru yang belum pernah melakukan pemeriksaan.

Initial Step-By-Step Description

1. Resepsionis meminta data pasien 2. Resepsionis menginput data pasien

3. Resepsionis men-submit data pasien agar disimpan di database pasien

2.2.2 Asisten Dokter Use Case

In case of multiple authors, this term refers to the principal author, with whom all communication is made.

Use case: Update Rekam Medis

Diagram:

Update Rekam Medis

Asisten Dokter

Brief Description

Asisten dokter menginput dan memperbarui rekam medis pasien

Initial Step-By-Step Description

Sebelum ini, asisten dokter telah membuka aplikasi administrasi klinik dokter gigi. 1. Asisten Dokter melihat daftar pasien yang sedang ditangani dokter

2. Asisten Dokter menginput data pada rekam medis sesuai pemeriksaan dokter 3. Asisten Dokter meminta konfirmasi dokter

4. Asisten Dokter mengupdate rekam medis yang telah dikonfirmasi Dokter.

Xref: Section 3.2.2, Communicate

Use case: Update Jadwal Dokter

Diagram:

Update Jadwal Dokter

(10)

Brief Description

Asisten dokter menginput dan memperbarui jadwal dokter

Initial Step-By-Step Description

Sebelum use case dilaksanakan, asisten dokter sudah terkoneksi dengan aplikasi.

1. Asisten Dokter menerima jadwal dokter bersangkutan 2. Asisten Dokter menginput dan mengupdate jadwal dokter

2.3 User Characteristics

Resepsionis mengharapkan suatu aplikasi yang memudahkan mencari data pasien, jadwal dokter dan menginputkan pasien pada jadwal dokter bersangkutan secara cepat tanpa harus mencarinya secara manual pada berkas-berkas.

Asisten Dokter menginginkan kemudahan dalam mengakses rekam medis dan mengupdate rekam medis secara rinci melalui aplikasi tanpa harus menuliskan secara manual.

2.4 Non-Functional Requirements

Aplikasi ini membutuhkan koneksi internet yang cukup cepat agar dapat mengakses database dan menghubungkan beberapa database. Resepsionis dan asisten dokter membutuhkan koneksi internet yang baik agar dapat mengakses beberapa database. Resepsionis dan Asisten Dokter memerlukan sebuah akses pada PC untuk dapat masuk ke database masing-masing.

(11)

3.0. Requirements Specification

3.1 External Interface Requirements

Pada software ini tidak terdapat hubungan dengan jaringan luar karena beberapa database diatur oleh pengguna sendiri yaitu resepsionis dan asisten dokter. Kedua pengguna masuk ke dalam environment, berinteraksi satu sama lain melalui database yang mereka miliki.

Resepsionis menggunakan use case cek jadwal dokter dengan memasukkan nomor ID dari pasien dan akan menghasilkan jadwal dokter yang sesuai dengan nomor serta keluhan pasien. Use case input data pasien baru menerima data diri dari pasien yang kemudian disimpan di database rekam medis.

3.2 Functional Requirements

The Logical Structure of the Data is contained in Section 3.3.1.

3.2.1 Update Daftar Antrian Pasien

Use Case Name Update Daftar Antrian Pasien

XRef Section 2.2.1, Search Article SDD, Section 7.1

Trigger Adanya pasien yang akan melakukan pemeriksaan

Precondition Terdapat pasien yang terdaftar pada daftar antrian

Basic Path 1. Resepsionis menerima nomor dari pasien yang sudah terdaftar di klinik

2. Resepsionis memasukkan nomor pasien dan keluhan pasien ke dalam sistem

3. Sistem memunculkan jadwal dokter yang sesuai dengan keluhan pasien

4. Resepsionis memverifikasi untuk menginput data pasien pada daftar antrian sesuai dengan jadwal dokter yang bersangkutan dengan keluhan pasien

5. Resepsionis melakukan konfirmasi pada data pasien yang sudah hadir

(12)

Alternative Paths Apabila terdapat pasien yang terlebih dahulu membuat janji, data pasien dapat diinputkan ke dalam daftar antrian. Setelah pasien yang bersangkutan dating, resepsionis mengkonfirmasi kedatangan pasien tersebut pada daftar antrian.

Postcondition Data pasien telah diinputkan pada daftar antrian pasien

Exception Paths None

Other None

3.2.2 Input data pasien baru

Use Case Name Input data pasien baru

XRef

Trigger Pasien yang hendak melakukan pemeriksaan belum terdaftar dalam sistem

Precondition Data pasien belum ada pada system

Basic Path 1. Resepsionis meminta data pasien 2. Resepsionis menginput data pasien

3. Resepsionis men-submit data pasien yang telah diinputkan untuk disimpan pada database pasien

Alternative Paths If the user prefers to use his or her own email directly, sufficient information will be contained on the Web page to do so.

Postcondition Data pasien telah disimpan pada database pasien

Exception Paths The attempt may be abandoned at any time.

Other None

3.2.3 Update Rekam Medis

Use Case Name Update rekam medis

XRef

Trigger Dokter melakukan pemeriksaan terhadap pasien

Precondition Rekam medis pasien telah tersedia. Asisten dokter mebuka rekam medis pasien yang akan ditangani Dokter. Dokter membaca rekam medis yang akan ditangani.

Basic Path 5. Asisten Dokter melihat daftar pasien yang sedang ditangani dokter

6. Asisten Dokter menginput data pada rekam medis sesuai pemeriksaan dokter

7. Asisten Dokter meminta konfirmasi dokter

8. Asisten Dokter mengupdate rekam medis yang telah dikonfirmasi Dokter.

(13)

Alternative Paths None

Postcondition Rekam medis pasien telah ter-update

Exception Paths None

Other None

3.2.4 Update Jadwal Dokter

Use Case Name Update Jadwal Dokter

XRef

Trigger Dokter menginginkan perubahan jadwal jaga

Precondition Jadwal Dokter telah tersedia.

Basic Path 1. Asisten Dokter menerima jadwal dokter bersangkutan 2. Asisten Dokter menginput dan mengupdate jadwal dokter

Alternative Paths None

Postcondition Jadwal Dokter telah ter-update

Exception Paths None

Other None

3.3 Detailed Non-Functional Requirements

3.3.1 Logical Structure of the Data

The logical structure of the data to be stored in the internal Article Manager database is given below.

Rese psioni s update Asi sten dokt er add update Reka m m edi s Daf tar ant ria n pasi en Jadw al dokt er aff ect ed

(14)

The data descriptions of each of these data entities is as follows:

Resepsionis Data Entiti

Data Item Type Description Comment

Name Text nama dari resepsionis Resepsionis-ID number Nomor id resepsionis

Daftar Antrian Pasien

Data Item Type Description Comment

Nama Dokter Text Nama dokter yang

Nama Pasien Text Nama pasien yang terdaftar ID Pasien Integer Nomor ID pasien yang

terdaftar Konfirmasi

kedatangan Boolean Konfirmasi kedatangan pasien yang terdaftar Konfirmasi

pembayaran Boolean Konfirmasi pembayaran pasien yang telah selesai ditangani

Jadwal Dokter Data Entity

Data Item Type Description Comment

Nama Text Ama dari dokter ID Integer ID dari dokter

Nama Pasien Text Nama pasien yang diampu oleh dokter

Spesialisasi Text Spesialisasi dokter

Asisten Dokter Data Entity

Data Item Type Description Comment

Nama Asisten

Dokter Text Nama dari asisten dokter Nama Dokter Text Nama dokter yang diasisteni ID Integer ID dari dokter

Rekam Medis Pasien Data Entity

Data Item Type Description Comment

Nama Pasien Text Nama dari pasien

Hari dan tanggal Text Hari dan tanggal pemeriksaan

Nama Dokter Text Nama dkter yang menangani Null

(15)

Diagnosis Text Hasil diagnosis pemeriksaan Rencana Penatalaksanaan Text Rencana penanganan

Pengobatan Text Pengobatan yang dibutuhkan Tindakan Text Tindakan yang dilakukan

for publication Odontogram Klinik Text

Persetujuan dokter Boolean Persetujuan dari dokter yang menangani untuk kemudian dapat diinputkan ke dalam sistem

3.3.2 Security

Referensi

Dokumen terkait

melalui suatu use case atau menggambarkan berbagai alir aktivitas dalam sistem Tampilan Pesan Rahasia Konfirmasi Password Menginput Teks Menginput Password Menginput Gambar Proses

Cari Pengguna (Search User) Masukkan ID Pengguna dalam kolom lalu tekan OK Catatan (Record) Tekan untuk melihat catatan pengguna yang ada Edit Pengguna (Edit User)

Hal tersebut dapat terlihat dari dilaksanakannya tahap-tahap audit yang memadai, adanya standar kualitas yang ditetapkan untuk dijadikan pedoman dalam menghasilkan produk,

 .. Kaum muslimin telah bersepakat. Syaikhul Islam mengatakan : "Berkurban adalah lebih utama dari bersedekah senilai harganya, jika ia memiliki harta dan dia ingin

PT PP Tbk (PTPP) memperkirakan laba bersih hingga akhir 2010 mencapai Rp201 miliar naik 23% dibandingkan periode yang sama tahun lalu dan pendapatan perseroan pun tumbuh 7,1%

Sedangkan Sasaran merupakan penjabaran dari Tujuan Dinas Bina Marga Sumber Daya Air Energi dan Sumber Daya Mineral Kabupaten Cilacap, yaitu hasil yang akan dicapai secara

Berdasarkan hasil analisis, diketahui bahwa polutan yang terkandung dalaro air kondensasi memiliki senyawa yang bersifat asaro, sehingga dapat disimpulkan bahwa

Kesimpulan kegiatan penelitian ”Teknologi Effiensi Ekonomi Usaha Tambak Udang di Kecamatan Muara Jawa Kabupaten Kutai Kartanegara adalah rata- rata petambak udang