GL01

SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

SiPeRaSa
(SISTEM INFORMASI PERANGKAT LUNAK RUMAH SAKIT)

untuk:
IBI Darmajaya

Dipersiapkan oleh:
Ema Nurmaya (1521210015)
Dika Tondo Widakdo (1521210009)
Master Teknologi Informatika IBI Darmajaya
Jl. Z.A. Pagar Alam No.93 Lampung

Jurusan
MTI
IBI Darmajaya

Nomor Dokumen

Halaman

SKPL - SiPeRasa

1 10

Revisi

09 April 2016

DAFTAR PERUBAHAN
Revisi
A

Deskripsi

B
C
D
E
F
G

INDEX
TGL

Ditulis
oleh
Diperiks
a oleh
Disetujui
oleh

Jurusan MTI Darmajaya

SKPL

Halaman 2 dari 12 halaman

Daftar Halaman Perubahan

Halaman

Revisi

Jurusan MTI Darmajaya

Halaman

SKPL

Revisi

Halaman 3 dari 12 halaman

Daftar Isi
1. Pendahuluan............................................................................................................................5
1.1 Tujuan Penulisan Dokumen............................................................................................5
1.2 Lingkup Masalah............................................................................................................5
1.3 Definisi, Istilah dan Singkatan.......................................................................................5
1.4 Aturan Penomoran.........................................................................................................5
1.5 Referensi........................................................................................................................5
1.6 Deskripsi umum Dokumen (Ikhtisar).............................................................................5
2 Deskripsi Umum Perangkat Lunak.......................................................................................5
2.1 Deskripsi Umum Sistem.................................................................................................5
2.2 Fungsi Produk................................................................................................................5
2.3 Karakteristik Pengguna..................................................................................................5
2.4 Batasan...........................................................................................................................5
2.5 Lingkungan Operasi.......................................................................................................6
3 Deskripsi Umum Kebutuhan.................................................................................................6
3.1 Kebutuhan antarmuka eksternal.....................................................................................6
3.1.1 Antarmuka pemakai.................................................................................................6
3.1.2 Antarmuka perangkat keras.....................................................................................6
3.1.3 Antarmuka perangkat lunak....................................................................................6
3.1.4 Antarmuka komunikasi............................................................................................6
3.2 Deskripsi Fungsional......................................................................................................6
3.2.1 Context Diagram.....................................................................................................6
3.2.1.1 DFD Level 1.....................................................................................................6
3.3 Data Requirement.........................................................................................................7
3.3.1 E-R diagram............................................................................................................7
3.4 Non Functional Requirement.........................................................................................7
3.5 Batasan Perancangan.....................................................................................................8
3.6 Kerunutan (traceability).................................................................................................8
3.6.1 Data Store vs E-R...................................................................................................8
3.7 Ringkasan Kebutuhan....................................................................................................8
3.7.1 Functional Requirement Summary..........................................................................8
3.7.2 Non Functional Requirement Summary..................................................................9
Flow map/Prosedur.............................................................................................................10
SW Function Point..............................................................................................................10
Lampiran lain yang dianggap perlu.....................................................................................10
Setelah Daftar Isi Boleh ada Daftar Tabel dan atau Daftar Gambar

Jurusan MTI Darmajaya

SKPL

Halaman 4 dari 12 halaman

1. Pendahuluan
1.1

Tujuan Penulisan Dokumen

Tujuan penulisan ini untuk menganalisis sistem pelayanan pasien pengolahan data pasien
rawat inap yang sedang berjalan pada Rumah Sakit DKT Bandar Lampung untuk menemukan
kelemahan kelemahan dan cara mengatasi permasalahan yang ada.
1.2

Lingkup Masalah
Siperasa ini dibatasi pada proses pengolahan data rawat inap yang terdaftar pada Rumah
Sakit DKT Bandar Lampung.
1.3

Definisi, Istilah dan Singkatan

DFD : Data Flow Diagram, adalah diagram yang menggambarkan proses-proses serta
aliran data antar proses yang terjadi dalam sebuah sistem. DFD dapat digambarkan dalam
beberapa level
Context Diagram : adalah diagram DFD yang terdapat padat level paling atas,
menggambarkan aliran data dasar antara sistem SIPUSSI dengan entitas-entitas di luar sistem
ER Diagram : adalah diagram yang menggambarkan struktur database dalam sebuah
sistem yang meliputi tabel-tabel yang ada serta relasi-relasi yang menghubungkan antar table.
1.4 Aturan Penomoran
Tuliskan jika anda memakai aturan penomoran
1.5

Referensi
Dokumen spesifikasi kebutuhan perangkat lunak ini disusun berdasarkan saduran dari
makalah skripsi Rancang Bangun Sistem Informasi Pengolahan Data Pasien Pada Rumah Sakit
Detasemen Kesehatan Tentara Bandar Lampung, dan e-joernal teknik informatika volume 6 no
1 (2015,) isn : 2301-8364, program studi teknik informatika universitas samratulangi. Ada
beberapa data yang dihilangkan atau yang digabungkan dengan bagian lainnya. Sistematika
rencana pengembangan perangkat lunak yang digunakan adalah sistematika yang digunakan
oleh jurusan teknih informatika fakultas teknologi industri universitas Atma Jaya Yogyakarta.
1.6 Deskripsi umum Dokumen (Ikhtisar)
Pembahasan Dokumen ini menggunakan metodologi sebagai berikut:
Bab I, pendahuluan berisi pengenalan dokumen ini terhadap pembaca, meliputi tujuan
penulisan, lingkup masalah, referensi, dan lainnya.
Bab II membahas deskripsi umum perangkat lunak, berisi spesifikasi-spesifikasi
perangkat lunak secara umum, meliputi penjelasan sistem, fungsi produk, karakteristik
pengguna, batasan lingkup perangkat lunak, serta lingkungan operasi perangkat lunak.
Bab III membahas spesifikasi kebutuhan terhadap perangkat lunak secara lebih
lengkap, diantaranya Antarmuka Eksternal, Data Flow Diagram, serta E-R Diagram

Deskripsi Umum Perangkat Lunak

2.1

Deskripsi Umum Sistem

Siperasa adalah sebuah sistem yang menjadi media untuk mengusulkan suatu sistem
informasi pengolahan data pasien rawat inap, serta untuk mempermudah pegawai dalam
pengolahan data pasien rawat inap seperti pencarian data, penyimpanan maupun pengecekan
Jurusan MTI Darmajaya

SKPL

Halaman 5 dari 12 halaman

data pasien serta pembuatan surat eligibilitas yang dapat meningkatkan kinerja pegawai dalam
meningkatkan pelayanannya kepada pasien yang membutuhkan.
2.2

Fungsi Produk
Merancang dan membangun suatu perangkat lunak pengolahan data pasien rawat inap
pada Rumah Sakit DKT Bandar Lampung, agar dapat mengurangi kesalahan dan
keterlambatan penyampaian informasi untuk keluarga pasien yang membutuhkan informasi.
Mempermudah bagian pelayanan dalam hal pencarian maupun penyimpanan data
sehingga kesalahan yang terjadi dapat segera diatasi.
Memberikan kemudahan dalam pembuatan laporan dan pengolahan data pada bagian
pelayanan.
2.3

Karakteristik Pengguna
Untuk pengguna dari sistem ini adalah petugas pendaftaran pasien selaku administrator
dan operator sistem dan user pasif yang hanya akan melihat informasi tanpa melakukan
transaksi, user pasif ini bisa dokter maupun perawat
Kategori Pengguna
User (Dokter, Perawat)
Adminitrator
Operator Sistem

Tugas
Mencari informasi yang
dibutuhkan
Memasukkan data pasien

Hak Akses ke aplikasi

Melihat dan mencari data
pasien
Penginputan data pasien

Perbaikan teknis dan

operasionl

Akses penuh teknis dan

operasional

2.4

Batasan
Dalam sistem ini tidak ada batasan khusus, karena database maupun data lain sudah
tersedia dalam sistem
2.5

Lingkungan Operasi
Aplikasi Sipussi ini akan berfungsi dengan spesifikasi :
Server :
Operating System
: Microsoft Windows 7 / 8
DBMS
: MySQL Server 2.5.9
Client :
Operating System
: Bebas
Browser
: Bebas
3

Deskripsi Umum Kebutuhan

3.1

Kebutuhan antarmuka eksternal

Kebutuhan antar muka eksternal pada perangkat lunak SIPERASA meliputi kebutuhan
antarmuka pemakai, antarmuka perangkat keras, antarmuka perangkat lunak, antarmuka
komunikasi.

Jurusan MTI Darmajaya

SKPL

Halaman 6 dari 12 halaman

3.1.1 Antarmuka pemakai

Pengguna berinteraksi dengan antarmuka yang ditampilkan dalam bentuk keyboard,
mouse dan touch screen.
3.1.2 Antarmuka perangkat keras
Antarmuka perangkat keras yang digunakan dalam perangkat lunak SIPERASA adalah
Personal Computer (PC)
3.1.3 Antarmuka perangkat lunak
Perangkat lunak yang dibutuhkan untuk mengoperasikan perangkat lunak SIPERASA
adalah :
1. Nama
: MySQL
Sumber
: Oracle
Sebagai database management system (DBMS) yang digunakan untuk penyimpan data di sisi
server.
2. Nama
: Windows 7 Ultimate
Sumber
: Microsoft.
Sebagai sistem operasi untuk perangkat PC dan web based.
3. Nama
: Visual Studio 2010 (C# ASP .NET)
Sumber
: Microsoft.
Sebagai integrated development environment (IDE) dalam pembuatan aplikasi web ini.
3.1.4 Antarmuka komunikasi
Pada antarmuka komunikasi ini tidak membutuhkan alat komunikasi khusus

3.2

Deskripsi Fungsional
Awali dengan Context diagram dan sedikit penjelasan berupa narasi jika perlu

Jurusan MTI Darmajaya

SKPL

Halaman 7 dari 12 halaman

3.2.1 Context Diagram

3.2.1.1 DFD Level 1

Chapter- nya dapat dibuat dengan luwes. Awali dengan Context diagram dan sedikit
penjelasan berupa narasi jika perlu. Perhatikan kaidah perancangan :
- Pilih notasi sehingga proses yang didekomposisi atau tidak didekomposisi dapat dibaca
dengan mudah
Jurusan MTI Darmajaya

SKPL

Halaman 8 dari 12 halaman

Nama Bubble harus terdiri dari kata kerja dan kata benda
Nama yang dipakai untuk Bubble, data store, dataflow harus konsisten (identitas perlu)
Setiap level harus konsisten aliran datanya dengan level sebelumnya
Usahakan agar external entity pada setiap level konsisten peletakannya
Banyaknya bubble yang disarankan pada setiap level tidak melebihi 7 bubble
Dekomposisi berdasarkan kelompok data lebih disarankan (memudahkan aliran data ke
storage yang sama)
Nama Proses yang umum hanya untuk bubble yang masih akan didekomposisi
Nama Proses spesifik (Add, Update, Delete,Calculate, Compare, Merge, ..) pada CASE
tools harus disertai dengan Pspec yang jelas walaupun Pspec tidak diprint di dokumen ini
Pada Proses yang sudah tidak didekomposisi, nama Proses dan nama Data harus sudah
spesifik
Aliran ke storage harus melalui proses, tidak boleh langsung dari external entity
Aliran data untuk Proses Report .. : harus ada aliran keluar. Akan ada aliran masuk
jika perlu parameter untuk mengaktifkan report
Aliran data yang tidak ada datastorenya harus diteliti, apakah memang tidak
mencerminkan persisten entity (perlu disimpan dalam file/tabel) , yaitu kelak hanya akan
menjadi variabel dalam program.

Dst sampai level terendah

3.3 Data Requirement
Uraikan dengan ringkas, data apa saja yang harus dikelola oleh aplikasi, disarikan dari
semua kata benda yang ada pada business process
3.3.1 E-R diagram
Gambar E-R diagram yang benar-benar konseptual, dengan VISIO. Minimal ada nama
Entity, Relasi dan Key (Skema relasi). Sudah dijelaskan apa bedanya E-R konseptual dengan
Conceptual Data Model pada Case Tools, karena E-R diagram ini tidak mungkin digambar
dengan Case Tools. Keterbatasan CASE Tools biasanya adalah:
- tidak mungkin mempunyai relasi dengan atribut non-key
- tidak mungkin mempunyai relasi bukan biner (terner, dan lebih tinggi)
sehingga akibatnya, relasi dijadikan entity. Kenapa E-R konseptual disarankan untuk
digambar, adalah karena E-R ini sebenarnya lebih mencerminkan abstraksi perancang
3.4 Non Functional Requirement
Uraikan dengan ringkas kebutuhan non fungsional dalam tabel sebagai berikut. Isilah Kolom
Requirement dengan kalimat yang jelas dan kelak dapat ditest untuk dipenuhi. SRS-Id
adalah nomor requirement yang harus ditelusuri pada saat test. Tuliskan N/A bila Not
Applicable..
SRS-Id

Parameter
Availability
Reliability
Ergonomy
Portability
Memory
Response time
Safety
Security

Jurusan MTI Darmajaya

Requirement

N/A
SKPL

Halaman 9 dari 12 halaman

SRS-Id

Parameter
Requirement
Others
1: Misalnya: semua tanya jawab harus dalam
Bahasa
bahasa Indonesia
komunikasi
Setiap layar harus mengandung logo ITS

Catatan:
Availability: ketersediaan aplikasi, misalnya harus terus menerus beroperasi 7 hari
perminggu, 24 jam per haritanpa gagal
Reliability: keandalan, misalnya tidak pernah boleh gagal(atau kegagalan yang ditolerir
adalah %) sehingga harus dipikirkan fault tolerant architecture. Biasanya hanya perlu
untuk Critical Application yang jika gagal akan berakibat fatal.
Ergonomy: kenyamanan pakai bagi pengguna
Portability: kemudahan untuk dibawa dan dioperasikan ke mesin/sistem operasi/platform
yang lain
Memory: jika perhitungan kapasitas memori internal kritis (misalnya untuk SW yang harus
dijadikan CHIPS dan ukurannya harus kecil
Response time: Batasan waktu yang harus dipenuhi. Sangat penting untuk aplikasi Real Time.
Contoh: Aplikasi harus mampu menampilkan hasil dalam 4 detik, atau ATM harus
menarik kembali kartu yang tidak diambil dalam waktu 30 detik
Safety: yang menyangkut keselamatan manusia, misalnya untuk SW yang dipakai pada sistem
kontrol di pabrik
Security: aspek keamanan yang harus dipenuhi.
3.5 Batasan Perancangan
Sebutkan batasan design jika ada. Contoh : harus memakai library yang ada, harus memakai
sepotong kode yang sudah pernah dikembangkan, harus memperhatikan hal-hal tertentu
3.6 Kerunutan (traceability)
Diisi dengan tabel yang berisi traceability dari hasil analisis. Gunanya untuk menilai apakah
hasil analisis runut dan lojik. Untuik sementara, baru didefinisikan Data-store versus ER.
3.6.1 Data Store vs E-R
Mapping data store pada DFD dengan Entity - Relasi
Data Store

Entity

Jurusan MTI Darmajaya

Relasi

SKPL

Halaman 10 dari 12 halaman

3.7 Ringkasan Kebutuhan

Bab ini berisi ringkasan semua Requirement item. Requirement item ini mencerminkan
semua hal yang harus dipenuhi, dan nantinya akan menjadi arahan untuk tahapan testing,
karena pada dasarnya, semua requirement harus dapat ditest supaya dapat dibuktikan
dipenuhi. Dibagi menjadi dua bagian: functional dan non functional
3.7.1 Functional Requirement Summary
SRS-Id

Description

3.7.2 Non Functional Requirement Summary

SRS-Id

Description

Jurusan MTI Darmajaya

SKPL

Halaman 11 dari 12 halaman

LAMPIRAN
Flow map/Prosedur
Jika PL menyangkut prosedur manual, atau proses-proses manual
SW Function Point
Isilah tabel sebagai berikut, sehingga dari rancangan ini didapatkan gambaran besarnya
ukuran aplikasi
Item
Subitem
Function
Entry/Updat
(bubble yang e
tidak
didekomposisi
lagi)
Process
Delete
Proses
Level 1
Level 1.1
Level 2
Menu
DataSore
E-R

Jumlah total

Keterangan

Entity
Realsi

Lampiran lain yang dianggap perlu

Jika ada lampiran lain yang perlu disertakan, dan berhubungan dengan Analisis dan
Perancangan

Jurusan MTI Darmajaya

SKPL

Halaman 12 dari 12 halaman