SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

Pendekatan berorientasi Objek

HAI

“Hospital All In”

untuk:

Rumah Sakit Gatot Subroto

Dipersiapkan oleh:

Grup 8

1. Mauritz Edo (1201150027/ TI-39-03)

2. Ayu Karina Sari (1201150315/ TI-39-03)

3. Shafira Nurlita (1201150303/ TI-39-03)

4. M. Rayes Fitra Gifari (1201154171/ TI-39-03)

Program Studi Teknik Industri

Fakultas Rekayasa Industri
Telkom University

2018
 DAFTAR PERUBAHAN
Revisi Deskripsi

INDEX - A B C D E F G
TGL

Ditulis
oleh

Diperiks
a oleh

Disetujui
oleh
 Daftar Halaman Perubahan

Halaman Revisi Halaman Revisi

 Daftar Isi
1. Pendahuluan............................................................................................................................8
1.1 Tujuan Penulisan Dokumen..........................................................................................8
1.2 Lingkup Masalah...........................................................................................................8
1.3 Definisi, Istilah dan Singkatan.....................................................................................8
1.4 Aturan Penomoran.........................................................................................................9
1.5 Referensi........................................................................................................................9
1.6 Deskripsi umum Dokumen (Ikhtisar)............................................................................9
2 Deskripsi Umum Perangkat Lunak....................................................................................10
2.1 Deskripsi Umum Sistem..............................................................................................10
2.2 Fungsi Produk..............................................................................................................11
2.3 Karakteristik Pengguna................................................................................................11
2.4 Batasan.........................................................................................................................12
2.5 Lingkungan Operasi....................................................................................................12
3 Deskripsi Umum Kebutuhan..............................................................................................12
3.1 Kebutuhan antarmuka eksternal..................................................................................12
3.1.1 Antarmuka pemakai..............................................................................................12
3.1.2 Antarmuka perangkat keras..................................................................................13
3.1.3 Antarmuka perangkat lunak..................................................................................13
3.1.4 Antarmuka komunikasi.........................................................................................13
3.2 Deskripsi Fungsional...................................................................................................13
3.2.1 Context Diagram...................................................................................................13
3.2.1.1 DFD Level 1...................................................................................................14
3.3 Data Requirement.......................................................................................................14
3.3.1 E-R diagram..........................................................................................................15
3.4 Non Functional Requirement......................................................................................15
3.5 Batasan Perancangan...................................................................................................15
3.6 Kerunutan (traceability)...............................................................................................15
3.6.1 Data Store vs E-R.................................................................................................16
3.7 Ringkasan Kebutuhan..................................................................................................16
3.7.1 Functional Requirement Summary.......................................................................16
3.7.2 Non Functional Requirement Summary...............................................................16
4 Deskripsi Perancangan Global...........................................................................................18
4.1 Rancangan Lingkungan Implementasi........................................................................18
 4.2 Deskripsi Data.............................................................................................................18
4.2.1 Definisi Domain/Type..........................................................................................18
4.2.2 Conceptual Data Model........................................................................................19
4.2.3 Physical Data Model.............................................................................................20
4.2.4 Daftar Tabel Aplikasi............................................................................................20
4.3 Dekomposisi Fungsional Modul..................................................................................22
5 Deskripsi Perancangan Rinci.............................................................................................23
5.1 Deskripsi Rinci Tabel..................................................................................................23
5.1.1 Tabel <Nama..>....................................................................................................23
5.1.2 Tabel <Nama>......................................................................................................24
5.2 Deskripsi Fungsional secara Rinci..............................................................................23
5.2.1 Spesifikasi Fungsi/Proses <nama fungsi 1>.........................................................29
5.2.2 Spesifikasi Fungsi/Proses <nama fungsi 2>.........................................................30
5.3 Dekomposisi Fisik Modul...........................................................................................30
5.4 Matriks Kerunutan.......................................................................................................30
6 Pengujian Perangkat Lunak................................................................................................31
6.1 Lingkungan Pengujian.................................................................................................31
6.1.1 Perangkat Lunak Pengujian..................................................................................31
6.1.2 Perangkat Keras Pengujian...................................................................................31
6.2 Material Pengujian.......................................................................................................32
6.3 Sumber Daya Manusia.................................................................................................32
6.4 Prosedur Umum Pengujian..........................................................................................32
6.4.1 Pengenalan dan Latihan........................................................................................32
6.4.2 Persiapan Awal.....................................................................................................32
6.4.2.1 Persiapan Prosedural......................................................................................32
6.4.2.2 Persiapan Perangkat Keras.............................................................................33
6.4.2.3 Persiapan Perangkat Lunak............................................................................33
6.4.3 Pelaksanaan...........................................................................................................34
6.4.4 Pelaporan Hasil.....................................................................................................34
6.5 Identifikasi dan Rencana Pengujian............................................................................34
6.6 Deskripsi dan Hasil Uji................................................................................................35
6.6.1 <Identifikasi kelas pengujian XXXXX>..............................................................35
6.6.1.1 <Identifikasi butir pengujian YYYYY>........................................................35
6.6.1.2 <Identifikasi butir pengujian YYYYY>........................................................35
6.7 Keterunutan Pengujian................................................................................................38
7 Spesifikasi Produk Perangkat Lunak.................................................................................39
7.1 Perangkat Lunak Siap Eksekusi..................................................................................39
7.2 Berkas Sumber.............................................................................................................40
7.3 Syarat Pemaketan........................................................................................................40
7.4 Prosedur Konstruksi....................................................................................................40
8 Panduan Instalasi................................................................................................................42
8.1 Instalasi Program Siap Eksekusi.................................................................................42
8.2 Instalasi Kode Program Sumber..................................................................................44
9 Penutup...............................................................................................................................44
 1. Pendahuluan
Dokumen ini berisikan spesifikasi kebutuhan perangkat lunak (SKPL) untuk sistem informasi
pada rumah sakit.

1.1 Tujuan Penulisan Dokumen

Dokumen spesifikasi kebutuhan perangkat lunak (SKPL) merupakan dokumen perangkat
lunak yang akan dikembangkan untuk disumulasikan dengan tujuan dapat mempermudah
dalam penggambaran sistem pada suatu proses. Dokumen ini digunakan untuk pengembang
perangkat lunak sebagai acuan teknis pengembangan perangkat lunak pada sistem informasi
yang dapat diaplikasikan pada rumah sakit tersebut.

1.2 Lingkup Masalah

Sistem infomasi rumah sakit merupakan aplikasi perangkat lunak yang digunakan dalam
memanaged (mengatur) segala persoalan yang terdapat di rumah sakit. Sistem iniformasi
tersebut dapat mengelola data mengenai proses registrasi pasien, sistem rawat inap,
pembayaran kasir, dan proses penjadwalan segala civitas yang bertugas seperti dokter,
perawat serta staff rumah sakit. Aplikasi ini bertujuan untuk memudahkan pihak administrasi
dalam menangani segala persoalan yang terjadi di setiap sistem yang dijalankan rumah sakit
tersebut. Terdapat beberapa dokumen yang dibutuhkan dalam membangun aplikasi tersebut
seperti :
1. Pembuatan data berupa list dokter
2. Pembuatan data berupa list perawat
3. Pengelolaan pendaftaran pasien
4. Pengelolaan data berupa rekam medis pasien
5. Pengelolaan jadwal jaga dokter
6. Pengelolaan data berupa jenis ruangan rawat inap

1.3 Definisi, Istilah dan Singkatan

 SKPL adalah spesifikasi kebutuhan perangkat ;unak atau dalam bahasa latinnya
disebut sebagai Software Spesification (SRS) dan merupakan spesifikasi dari
perangkat lunak yang akan dikembangkan
 DFD adalah data flow diagram, diagram dan notas i yang digunakan untuk
menunjukkan aliran data pada perangkat lunak
 ERD adalah respresentasi grafis dari sistem informasi yang menunjukkan hubungan
antara orang, objek, tempat, konsep atau kejadian di dalam sebuah sistem.
  DBMS adalah software yang menangani semua akses ke basis data, software tersebut
memungkinkan untuk menyusun, mengolah dan memperbaharui item-item dalam
suatu basis data atau database. DBMS mempunyai kemampuan untuk mengolah data
dalam jumlah yang besar, selain itu DBMS juga mampu untuk melakukan manipulasi
data dengan mudah dan cepat.
 Microsoft SQL Server adalah perangkat lunak relational database management system
(RDBMS) yang didesain untuk melakukan proses manipulasi database berukuran
besar dengan berbagai fasilitas. Microsoft SQL Server merupakan produk andalan
Microsoft untuk database server. Kemampuannya dalam manajemen data dan
kemudahan dalam pengoperasiannya membuat RDBMS ini menjadi pilihan para
database administrator. Microsoft SQL Server mendukung beberapa tipe data yang
berbeda, termasuk untuk karakter, angga, tanggal (datetime) dan uang (money), SQL
Server digunakan untuk menggambarkan model dan implementasi pada database.
Keuntungan menggunakan SQL Server dapat didefinisikan menjadi dua bagian yaitu
satu bagian untuk menjalankan pada server dan bagian lain untuk client.
Keuntungan Client :
1. Mudah digunakan.
2. Mendukung berbagai perangka keras.
3. Mendukung berbagai aplikasi perangkat lunak.
4. Biasa untuk digunakan
5. Keuntungan Server
6. Dapat diandalkan (Reliable)
7. Toleransi kesalahan (Fault Tolerant)
8. Konkurensi (Concurrent)
9. Performa tingggi dalam perangkat keras (High-performance Hardware)
10. Pengendalian terpusat (Centralized Control)
11. Penguncian yang canggih (Sophisticated Locking).

1.4 Referensi

 Ida Bagus Gede Dwipermana, dkk. Spesifikasi kebutuhan perangkat lunak SIMRS
(sistem informasi manajemen rumah sakit) Jurusan Teknologi Iinformasi, Fakultas
Teknik, Universitas Udayana 2015.
 Alfonsus Pravidy Novan Surya, Spesifikasi Kebutuhan Perangkat Lunak Siperasa
(Sistem Informasi Manajemen padaRumah Sakit Panti Rapih Yogyakarta, Teknik
Infomatika, Fakultas Teknologi Indutsri, Universitas Atma Jaya
1.5 Deskripsi umum Dokumen (Ikhtisar)
Secara umum dokumen SKPL ini terbagi atas 3 bagian utama. Bagian utama berisi penjelasan
mengenai dokumen SKPL tersebut yang mencakup tujuan pembuatan SKPL, ruang lingkup
masalah dalam pengembangan perangkat lunak tersebut, definisi, referensi dan deskripsi
umum tentang dokumen SKPL ini. Bagian kedua berisi penjelasan umum tentang perangkat
lunak yang akan dikembangkan, mencakup perspektif sistem informasi yang akan
dikembangkan, fungsi produk perangkat lunak, karakteristik pengguna, batasan dalam
penggunaan perangkat lunak dan asumsi yang dipakai dalam pengembangan perangkat lunak
tersebut.

2 Deskripsi Umum Perangkat Lunak

2.1 Deskripsi Umum Sistem

Dalam sebuah perusahaan berbasis rumah sakit, terdapat suatu aplikasi bernama HAI
“Hospital All In” bertugas sebagai pengelola data pasien yang mendaftar. Admin dapat
membuat kategori berdasarkan dokter spesialis dan dapat menambahkan pasien sesuai dengan
kategori riwayat penyakit. HAI juga dapat mengupdate serta mendata jenis kamar rawat inap
berdasarkan kategori ruangan serta mengudate ruangan yang tersedia maupun yang belum
terisi berdasarkan dengan kategori jenis kamar.
Pasien harus mendaftar terlebih dahulu untuk menjadi member rumah sakit tersebut. Pasien
dapat mendaftarkan diri secara langsung ke rumah sakit dengan bantuan bagian administrasi
untuk masuk ke akun HAI. HAI akan menginput segala jenis biodata yang dibutuhkan seperti
biodata diri, alamat, riwayat penyakit, umur. Pasien yang sudah menjadi member dapat
melakukan pemeriksaan dengan mengambil nomor antrian secara langsung. Pasien dapat
memilih kategori dokter spesialis berdasarkan riwayat penyakit.
Dokter akan mendapatkan jadwal jaga yang diberikan oleh aplikasi HAI. Dokter juga
akan mendapatkan data pasien yang telah mendaftar berdasarkan nomor antrian serta biodata
diri pasien tersebut. Setiap pasien dapat diperiksa oleh satu atau lebih dokter. Dokter dibantu
oleh seorang perawat untuk dapat mengatur jadwal pemeriksaan yang akan dilakukan oleh
dokter tersebut. Perawat akan memberikan hasil pemeriksaan untuk di update dalam sistem
rekam medis dalam aplikasi HAI.
Setelah pasien melakukan pemeriksaan, Dokter akan memberikan hasil pemeriksaan
apakah pasien tersebut harus melakukan perawatan secara intensif atau tidak. Setelah
dinyatakan oleh dokter perlu adanya perawatan intensif yaitu dengan rawat inap, pasien akan
mendapatkan data berupa ruangan rawat inap yang tersedia untuk dijadikan reverensi, dimana
satu ruang rawat inap dapat ditempati oleh satu pasien atau lebih. Setelah pasien menentukan
ruangan mana yang akan ditempati, HAI akan mengupdate ruangan yang akan digunakan.
Kemudian dalam aplikasi HAI akan memberikan data ruangan pasien kepada pihak kasir
untuk membayar tagihan. Pasien yang telah selesai melakukan pemeriksaan juga akan
mendapatkan data berupa resep obat yang selanjutnya diberikan kepada pihak apotek. Apabila
jenis obat yang diminta tersedia maka pihak apoteker akan memberikan obat tersebut
berdasarkan ketentuan yang telah diberikan oleh dokter.
Apotek merupakan pengelolaan barang berupa jenis obat. Apoteker dapat
mengelompokkan jenis obat berdasarkan kategori macam obat dan dapat mengupdate stok
yang tersedia sesuai dengan kategori yang telah dibuat. Apoteker akan mencari jenis obat
yang tersedia dengan cara memeriksanya menggunakan data yang terupdate dalam sistem.
Data tersebut berisi berbagai macam jenis obat, nama obat, id obat, stok dan juga dosis obat.
Setelah pasien melakukan perawatan maupun pemeriksaan, pasien harus membayar semua
jenis tagihan kepada bagian kasir. Kasir dapat menginput jenis tagihan seperti obat, biaya
pemeriksaan dan rekam medis, biaya konsultasi dan biaya perawatan apabila pasien tersebut
melakukan rawat inap. Pihak kasir akan mendapatkan data pasien yang dirawat berdasarkan
hasil data aplikasi HAI berupa id member pasien. Pihak kasir akan mengakumulasikan
tagihan yang dikeluarkan pada saat pasien tersebut melakukan perawatan. Pihak kasir
memerlukan data berupa id member rumah sakit yang dapat membantu untuk proses
administrasi pembayaran tagihan.
2.2 Fungsi Produk
Fungsi utama dalam adanya aplikasi perangkat lunak ini adalag
1. Aplikasi ini menyediakan segala informasi dari segi administrasi yang dibutuhkan
oleh pasien
2. Aplikasi ini menyediakan informasi berupa jadwal jaga dokter
3. Aplikasi ini dapat berguna untuk mengupdate segala jenis ruang rawat inap yang ada
dalam rumah sakit.
4. Aplikasi ini dapat menyimpan data pasien sesuai dengan rekam medis pasien.
5. Aplikasi ini juga dapat mempermudah para civitas rumah sakit untuk dapat
mengontrol jadwal mereka.

2.3 Karakteristik Pengguna

Kategori Pengguna Tugas Hak Akses ke aplikasi

Pasien Mendaftarkan diri -
Bagian administrasi Mendata dan mengolah Admin
segala jenis sistem yang
berjalan
Dokter Mengontrol schedule jaga Pengguna
Staff Mengontrol kehadiran sesuai Pengguna
dengan jadwal
Manajer Rumah Sakit Mengontrol jalannya sistem Co - Admin

2.4 Batasan
Batasan yang digunakan dalam sistem ini yaitu :
 Konsolidasi pembayaran pada kasir baru dapat dijalankan ketika hasil rekapitulasi biaya
telah dihitung dalam aplikasi yang mencakup biaya pmeriksaan, biaya perawatan, biaya
ruang inap jika diperlukan, biaya obat.
 Data pemeriksaan dokter baru dapat dijalankan apabila pasien telah mendaftar pada
aplikasi.
 Aplikasi hanya bias diakses oleh civitas rumah sakit.
2.5 Lingkungan Operasi
Operating system, DBMS, ...

Aplikasi Client server ini akan berfungsi dengan spesifikasi :

Server : SQL Server
Client : SQL Server
OS : Windows 7/8/10
DBMS : SQL Server

3 Deskripsi Umum Kebutuhan

3.1 Kebutuhan antarmuka eksternal

3.1.1 Antarmuka pemakai

3.2 Deskripsi Fungsional

3.2.1 Context Diagram

3.2.1.1 DFD Level 1
3.2.1.2 DFD Level 2

3.3 Data Requirement

Uraikan dengan ringkas, data apa saja yang harus dikelola oleh aplikasi, disarikan dari
semua kata benda yang ada pada business proces
3.3.1 E-R diagram
3.4 Non Functional Requirement

SRS-Id Parameter Requirement

SRS-01 Availability Harus terus menerus beroperasi dan
tersedia dalam waktu 7x24 jam tanpa
gagal
SRS-02 Reliability Kegagalan yang ditolerir 0.5%
SRS-03 Ergonomy Interface yang mudah dipahami dan
digunakan
SRS-04 Portability Dapat diakses melalui web jika dalam
keadaan mendesak
SRS-05 Memory
SRS-06 Response time Aplikasi harus mampu menampilkan
hasil dalam waktu 5 detik
SRS-07 Safety N/A
SRS-08 Security Kerahasiaan dokumen pasien

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 E-
R.

3.6.1 Data Store vs E-R

Mapping data store pada DFD dengan Entity - Relasi

Data Store Entity Relasi

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
SRS-01 Sistem dapat melakukan log in akun user.
SRS-02 Sistem dapat melakukan input member baru pasien
rumah sakit.
SRS-03 Sistem dapat mencetak kartu member.
SRS-04 Sistem dapat melakukan pendaftaran berobat.
SRS-05 Sistem dapat menampilkan jadwal jaga pegawai
rumah sakit.
SRS-06 Sistem dapat menampilkan jadwal dokter untuk
pasien.
SRS-07 Sistem dapat melakukan transaksi pemesanan
ruangan rawat inap.
SRS-08 Sistem menyediakan fitur yang memungkinkan user
membaca artikel/dokumen dalam rumah sakit.
SRS-09 Sistem dapat melakukan transaksi pembelian obat
pada apotek.
SRS-10 Sistem dapat menghitung total transaksi yang
dilakukan pasien.
SRS-Id Description
SRS-11 Sistem dapat menampilkan laporan rekam medis
pasien (member rumah sakit).

SRS-12 Sistem dapat menampilkan laporan transaksi pasien

rumah sakit.

3.7.2 Non Functional Requirement Summary

SRS-Id Description
SRS-13 Sistem dapat dijalankan oleh beberapa software web
browser diantaranya internet Explore, Google
Chrome dan Mozilla Firefox.
SRS-14 Proses dari pengguna membuka sebuah artikel atau
dokumen untuk dibaca sampai system
mengeluarkan/menampilkan artikel tersebut,
berlangsung tidak lebih dari 10 detik.

SRS-15 Sistem harus dapat memastikan bahwa data yang

digunakan dalam system harus terlindung dari akses
yang tidak berwenang.

SRS-16 Besarnya progrom dari system maksimal sebesar

100 MB.

SRS-17 Sistem memiliki tampilan (antar muka) yang mudah

dipahami.

4 Deskripsi Perancangan Global

4.1 Rancangan Lingkungan Implementasi

Sebutkan Operating system, DBMS, development tools, filing system, bahasa pemrograman
yang dipakai
4.2 Deskripsi Data
Terdapat sepuluh tabel yang digunakan dalam database rumah sakit. Brikut ini nama tabel
yang digunakan.
1. Tabel Pasien
2. Tabel Perawat
3. Tabel Poli
4. Tabel Dokter
5. Tabel Ruangan
6. Tabel Jenis Ruangan
7. Tabel Biaya
8. Tabel Kasir
9. Tabel Resep Obat
10. Tabel Rekam Medis

4.2.1 Definisi Domain/Type

Berikut ini merupakan domain pada database rumah sakit.
Domain Name Power Designer Type (mis)
Rupiah Float
Karakter Text
Tanggal Date
ID/Kode Integer
4.2.2 Conceptual Data Model
Berikut ini merupakan conceptual data model menggunakan power designer.
4.2.3 Physical Data Model

4.2.4 Daftar Tabel Aplikasi

Nama Tabel Primary Key E/R Deskripsi Isi

Pasien ID_Pasien Berisi tentang data-
data pasien seperti ID
pasien, nama pasien,
dan lain-lain.
Perawat ID_Perawat Berisi tentang data-
data perawat yang
merawat pasien,
Seperti ID perawat,
NIP, nama perawat,
dan lain-lain
Poli ID_Poli Berisi tentang data
poli seperti ID poli,
dan nama poli yang
dikunjungi pasien.
Dokter ID_Dokter Berisi tentang data-
data dokter seperti ID
dokter, NIP, nama
dokter dan tarif
dokter.
Ruangan ID_Ruangan Berisi tentang data-
data ruangan seperti
ID ruangan dan nama
ruangan
Jenis Ruangan ID_Jenis_Ruangan Berisi tentang data-
data jenis ruangan
seperti ID jenis
ruangan, nama
ruangan dan lain-
lain.
Biaya ID_Bayar Berisi tentang data-
data biaya seperti
ID_bayar, jumlah
biaya dan lain-lain
Kasir ID_Kasir Berisi tentang data-
data kasir seperti ID
kasir, nama kasir,
dan lain-lain
Resep Obat ID_Obat Berisi tentang data-
data resep obat yang
 diberikan oleh dokter
seperti ID obat, nama
obat, dan lain-lain.
Rekam Medis ID_RM Berisi tentang data-
data rekam medis
seperti ID rekam
medis, Cek fisik,
Diagnosa, dan lain-
lain.

4.3 Dekomposisi Fungsional Modul

Berisi dekomposisi “lojik” dari modul. Minimal berisi tabulasi dengan kolom: Modul,
Proses, Keterangan. Kolom keterangan hanya diisi jika proses tidak tergambarkan dalam
DFD. Misalnya untuk proses-proses yang mewakili suatu library umum

Tabel. XXX. Input-Proses-Output

No. Fungsi diturunkan dari semua hal yang harus diprogram :
- Bubble DFD yang tidak didekomposisi lagi.
- Proses-proses yang “membungkus” proses lain (misalnya menjadi Menu)
Setelah IPO ini, setiap fungsi akan dibuat detailnya. Pada bagian berikutnya
Konvensi : setiap bubble harus menjadi fungsi saja. Jika “menghilang” dan tidak akan
diprogram, maka akan ditulis di bagian keterangan (misalnya Menu yang akan diprogram
dengan Editor VB dan tidak lagi ditulis kodenya, maka pada keterangan akan
ditulis :”Ditangani oleh VB”
Disarankan agar penomoran fungsi dibuat hirarkhis, sehingga jika dijadikan menu akan sekaligus merupakan
Function Tree
No.Fungsi Fungsi/Proses Tabel/Data Tabel /Data Keterangan
Input Output
No.Fungsi Fungsi/Proses Tabel/Data Tabel /Data Keterangan
Input Output

Untuk setiap nomor fungsi, buatlah spesifikasi rincinya pada Deskripsi rancangan Rinci
5 Deskripsi Perancangan Rinci

5.1 Deskripsi Rinci Tabel

Setiap tabel pada rancangan global, dirinci satu per satu

5.1.1 Tabel <Pasien..>

Identifikasi/Nama : Tabel Pasien
Deskripsi Isi : Berisi tentang data-data pasien
Primary Key : ID_Pasien
Id Field Deskripsi Tipe & Boleh Default Keterangan
Length NULL
Id_Pasien Berisi Text NO
tentang
nomor unik
yang
dimiliki
setiap
pasien.
Nama_Pasien Berisi nama Text (50) NO
pasien
Jenis_Kelamin Berisi jenis Text NO
kelamin
pasien
Umur Berisi umur Integer NO
pasien
Kecamatan Berisi Text (50) NO
kecamatan
 alamat
rumah pasien
Kelurahan Berisi Text (50) NO
kelurahan
alamat
rumah pasien
Kota Berisi kota Text (50) NO
alamat
rumah pasien
No_Telp_Pasien Berisi nomor Integer NO
telp pasien
yang dapat
dihubungi

5.1.2 Tabel <Perawat>

Identifikasi/Nama : Tabel Perawat
Deskripsi Isi : Berisi tentang data-data perawat
Primary Key : ID_ Perawat
Id Field Deskripsi Tipe & Boleh Default Keterangan
Length NULL
Id_ Perawat Berisi Text NO
tentang
nomor unik
yang
dimiliki
setiap
perawat.
Nama_ Perawat Berisi nama Text (50) NO
perawat
NIP Berisi nomor Integer NO
induk
pegawai
perawat
Jam_Jaga Berisi waktu Integer NO
jam jaga
perawat
Kecamatan Berisi Text (50) NO
kecamatan
alamat
rumah pasien
Kelurahan Berisi Text (50) NO
kelurahan
alamat
rumah pasien
Kota Berisi kota Text (50) NO
alamat
rumah pasien

5.1.3 Tabel <Poli>

Identifikasi/Nama : Tabel Poli
Deskripsi Isi : Berisi tentang data-data poli
Primary Key : ID_ Poli
Id Field Deskripsi Tipe & Boleh Default Keterangan
Length NULL
Id_ Poli Berisi Text NO
tentang
nomor unik
yang
dimiliki
setiap poli.
Nama_ Poli Berisi nama Text (50) NO
poli

5.1.4 Tabel <Dokter>

Identifikasi/Nama : Tabel Dokter
Deskripsi Isi : Berisi tentang data-data dokter
Primary Key : ID_ Dokter

Id Field Deskripsi Tipe & Boleh Default Keterangan

Length NULL
Id_ Dokter Berisi Text NO
tentang
nomor unik
yang
dimiliki
setiap
dokter.
Nama_ Dokter Berisi nama Text (50) NO
dokter
NIP Berisi nomor Integer NO
induk
pegawai
dokter
Tarif_Dokter Berisi tarif Float (10) NO
dokter
No_Telp_Dokte Berisi nomor Integer NO
r telp dokter

5.1.5 Tabel <Jenis Ruangan>

Identifikasi/Nama : Tabel Jenis Ruangan
Deskripsi Isi : Berisi tentang data-data Jenis Ruangan
Primary Key : ID_ Jenis Ruangan
Id Field Deskripsi Tipe & Boleh Default Keterangan
Length NULL
Id_ Jenis Berisi Text NO
Ruangan tentang
nomor unik
yang
dimiliki
setiap
 ruangan.
Nama_ Ruangan Berisi nama Text (50) NO
dokter
Tarif_Dokter Berisi tarif Float (10) NO
dokter

5.1.6 Tabel <Biaya>

Identifikasi/Nama : Tabel Biaya
Deskripsi Isi : Berisi tentang data-data Biaya
Primary Key : ID_ Biaya
Id Field Deskripsi Tipe & Boleh Default Keterangan
Length NULL
Id_ Biaya Berisi Text NO
tentang
nomor unik
yang
dimiliki
setiap Biaya.
Jumlah_ Biaya Berisi total Float (10) NO
biaya yang
harus
dibayarkan
Tgl_Bayar Berisi Date NO
tanggal
bulan dan
waktu
pemnayaran

5.1.7 Tabel <Kasir>

Identifikasi/Nama : Tabel Kasir
Deskripsi Isi : Berisi tentang data-data Kasir
Primary Key : ID_ Kasir
Id Field Deskripsi Tipe & Boleh Default Keterangan
 Length NULL
Id_ Kasir Berisi Text NO
tentang
nomor unik
yang
dimiliki
setiap kasir.
Nama_ Kasir Berisi nama Text (50) NO
kasir
Jam_Jaga Berisi waktu Integer NO
jam jaga
No_Telp_Kasir Berisi tarif Float (10) NO
dokter

5.1.8 Tabel <Resep Obat>

Identifikasi/Nama : Tabel Resep Obat
Deskripsi Isi : Berisi tentang data-data Resep Obat
Primary Key : ID_ Resep_Obat
Id Field Deskripsi Tipe & Boleh Default Keterangan
Length NULL
Id_Obat Berisi Text NO
tentang
nomor unik
yang
dimiliki
setiap Obat.
Jumlah_ Obat Berisi Integer NO
jumlah obat
yang akan
diambil
Tarif_ Obat Berisi Float NO
tanggal
bulan dan
waktu
 pemnayaran

5.1.9 Tabel <Rekam Medis>

Identifikasi/Nama : Tabel Rekam Medis
Deskripsi Isi : Berisi tentang data-data Rekam Medis
Primary Key : ID_ Rekam_Medis
Id Field Deskripsi Tipe & Boleh Default Keterangan
Length NULL
Id_ RM Berisi Text NO
tentang
nomor unik
yang
dimiliki
setiap rekam
medis
pasien.
Cek_Fisik Berisi hasil Text (50) NO
cek fisik
pasien.
Diagnosa Berisi Integer NO
diagnosa
pasien.
Keluhan Berisi Float (10) NO
keluhan
pasien.

5.1.10 Spesifikasi Fungsi/Proses <nama fungsi 1>

Identifikasi/Nama : ……..
Deskripsi Isi : ……..
Jenis : Form Entry columnar/Tabular/Master-Detail
Report Columnar/tabular/Master-Detail
 Form berisi dialog/button saja
Proses tanpa layar
Tabel input :
Tabel output :
Query : (diisi jika query cukup rumit)
Layar Utama :

Gambarkan layar dan percabangan ke layar lain function key/pilihan yang

dilakukan)
Jika layar mengandung filed dan label, gambarkanlah pada posisi nya,
supaya siap dikoding. Jika ada zoning/frame, gambarkan pula an jelaskan
pada spesifikasi Objek pada layar

Objek

OK

Algoritma : (diisi jika algoritma cukup kompleks)

Layout Report : (diisi jika fungsi menghasilkan report)

5.1.11 Spesifikasi Fungsi/Proses <nama fungsi 2>

Untuk setiap fungsi, buat detailnya seperti di atas

5.2 Dekomposisi Fisik Modul

Berisi dekomposisi “fisik” dari modul. Minimal berisi tabulasi dengan kolom: Sub Aplikasi,
Modul, Nama File, Input, Output. Sub Aplikasi biasanya dibuat per pengguna. Dibuat per
modul
Berisi struktur direktori dan pengumpulan fungsi menjadi file. Minimal berisi tabulasi
dengan kolom: Modul, Proses, Keterangan. Kolom keterangan hanya diisi jika proses tidak
tergambarkan dalam DFD. Misalnya untuk proses-proses yang mewakili suatu library umum

Nama Nama File Nama Modul Nama Fungsi Keterangan

Direktori

5.3 Matriks Kerunutan

Pada bagian ini, diisi dengan tabel, yang memungkinkan pembaca untuk menelusuri
keterkaitan perancangan terhadap spesifikasi kebutuhan.

Diisi dengan tabel yang berisi traceability dari SRS dengan nomor CSU

SRS-Id No. Fungsi Keterangan

6 Pengujian Perangkat Lunak

6.1 Lingkungan Pengujian

Bagian ini akan dibagi menjadi beberapa sub bab, untuk menjelaskan lingkungan yang
dibutuhkan dalam pengujian perangkat lunak. Bagian ini juga menjelaskan rencana
implementasi dan pengendalian sumber daya (perangkat lunak, perangkat keras dan dari sisi
persiapan organisasi) yang akan melakukan pengujian kualifikasi formal.
6.1.1 Perangkat Lunak Pengujian

Bagian ini berisi identifikasi dari nama, nomor dan versi (jika ada atau jika sudah ada), dari
item perangkat lunak (misalnya sistem operasi, kompilator, perangkat komunikasi, paket
aplikasi yang terkait, basisdata, file masukan, code auditor, Tools pengujian) yang diperlukan
untuk melakukan pengujian. Sebutkan pula hak pemakaian atau lisensi dari tiap perangkat
lunak pengujian yang digunakan.

Bagian ini juga akan menjelaskan guna dari setiap item, penjelasan media yang digunakan,
dukungan peralatan (jika ada) dan masalah keamanan yang berhubungan dengan item
perangkat lunak.

6.1.2 Perangkat Keras Pengujian

Bagian ini berisi identifikasi dari nama, nomor dan versi (jika ada) dari perangkat keras yang
dilibatkan dalam pengujian, peralatan khusus (misalnya interface card khusus), peralatan
komunikasi (jaringan dan peralatannya), dan peralatan lain yang mungkin terlibat.

6.2 Material Pengujian

Beberapa material tambahan yang mungkin dibutuhkan dapat diperjelas dibagian ini. Material
ini misalnya manual perangkat lunak, listing program, media yang berisi perangkat lunak
yang akan diuji, contoh tampilan keluaran, formulir terkait, atau instruksi-instruksi khusus.
Material yang dituliskan di sini adalah material yang belum dituliskan di dokumen-dokumen
lainnya.

6.3 Sumber Daya Manusia

Bagian ini menjelaskan jumlah, tingkat keahlian, dan kriteria/prasyarat dari sumber daya
manusia yang terlibat dalam pengujian, termasuk saat dibutuhkan (tipe pengujian).

6.4 Prosedur Umum Pengujian

6.4.1 Pengenalan dan Latihan

Bagian ini menjelaskan pengenalan dan latihan yang akan diberikan sebelum dan selama
pengujian, bila ada. Informasi yang berhubungan dengan orang yang terlibat sudah dijelaskan
di 2.4. Pelatihan ini termasuk instruksi penggunaan perangkat lunak bagi pengguna akhir atau
operator, instruksi perawatan perangkat lunak dan instruksi pengendalian perangkat lunak
berkelompok. Berikan pula jadwal atau waktu kapan dan seberapa lama pengenalan atau
latihan ini dilakukan.

6.4.2 Persiapan Awal

Bagian ini akan dibagi menjadi beberapa sub bab, untuk menjelaskan lingkungan yang
dibutuhkan dalam pengujian perangkat lunak. Bagian ini juga menjelaskan rencana
implementasi dan pengendalian sumber daya (perangkat lunak, perangkat keras dan dari sisi
persiapan organisasi) yang akan melakukan pengujian. Bagian ini dapat dijelaskan secara
terpisah untuk tiap kelas atau butir uji bila ada persiapan awal khusus yang perlu dilakukan
untuk satu kelas atau satu butir uji. Bagian khusus ini dijelaskan pada deskripsi uji di bawah.

6.4.2.1 Persiapan Prosedural

Bagian ini menyatakan persiapan prosedural (manual) yang perlu dilakukan untuk melakukan
pengujian. Contohnya: bila pengujian dilakukan di suatu lingkungan khusus, misalnya di
ruang komputer, maka untuk melakukan pengujian ini perlu ada ijin masuk khusus, ijin
penginstallan perangkat lunak yang akan diujikan, pencatatan log-book dan lain-lain.

6.4.2.2 Persiapan Perangkat Keras

Bagian ini akan menjelaskan prosedur yang perlu untuk menyiapkan perangkat keras untuk
pengujian. Acuan dapat dibuat untuk menerbitkan petunjuk operasi dari setiap prosedur ini.
Pada bagian ini misalnya akan menyatakan hal-hal berikut:

1. Perangkat keras yang akan digunakan, nama dan nomor jika ada
2. Setting dari switch (misalnya untuk printer)
3. Instruksi langkah-langkah untuk penyiapan perangkat keras hingga siap pakai.

Paragraf ini berisi identifikasi dari nama, nomor dan versi (jika ada) dari perangkat keras
yang dilibatkan dalam pengujian, peralatan antarmuka (interface), peralatan komunikasi,
peralatan pengujian waktu (jika diperlukan), dan peralatan lain yang mungkin terlibat.

Contoh:

Perangkat keras yang perlu disiapkan antara lain:

 3 perangkat komputer yang masing-masing dilengkapi dengan:

 1 harddisk dengan kapasitas minimum 500 MB
 1 color monitor VGA pada perangkat yang sama tempat harddisk berada
  32 MB RAM
 1 keyboard
 1 Floppy drive
 1 printer Laser Jet yang terhubung ke salah satu perangkat komputer
 1 Network Hub
 3 NIC , yang terpasang pada masing-masing komputer, dan kabel UTP yang
terhubung ke masing-masing komputer dengan konfigurasi star dan terpusat di
Network Hub

Bila diperlukan suatu konfigurasi yang khusus, dapat dibuat dalam suatu gambar.

6.4.2.3 Persiapan Perangkat Lunak

Bagian ini akan menjleaskan prosedur atau tata cara yang diperlukan untuk menyiapkan item
yang akan diuji, perangkat lunak yang terkait termasuk data untuk pengujian. Informasi yang
mungkin perlu ada antara lain:

1. Perangkat lunak yang diuji (bisa dalam bentuk media penyimpanannya misalnya disket,
cdrom, atau media lain)
2. Perangkat lunak yang digunakan untuk menguji (misalnya simulator, test driver, database)
3. Instruksi untuk mengaktifkan program, termasuk urutan langkah rincinya bila perlu
4. Instruksi untuk inisialisasi umum untuk suatu kasus uji.

6.4.3 Pelaksanaan
Bagian ini menjelaskan strategi pelaksanaan pengujian itu sendiri. Contoh strategi ini adalah
pembagian pengujian menjadi dua tahap: pengujian unit dan pengujian sistem. Contoh lain
adalah: pengujian dilakukan pada lingkungan khusus yang dibangun untuk pengujian dan
tidak dilakukan pada lingkungan operasional sesungguhnya.

6.4.4 Pelaporan Hasil

Bagian ini menjelaskan pada siapa saja dokumen hasil pengujian akan diserahkan baik untuk
diverifikasi maupun penyerahan akhir.
6.5 Identifikasi dan Rencana Pengujian

Subbagian ini akan dibagi menjadi beberapa sub bagian untuk mengenali kondisi umum
pengujian yang dilakukan serta kelas pengujian yang akan dilakukan.

Bagian ini menjelaskan lingkup keseluruhan dari perencanaan pengujian. Dari sejumlah
requirement yang akan diuji yang dituliskan di SKPL, buatlah pengelompokkannya dan
jadikan tabel pada bagian ini.

Contoh:

Kelas Uji Butir Uji Identifikasi Tingkat Jenis Jadwal

SKPL PDHUPL Pengujia Pengujia
n n
Pengujian Pengujian SKPL_Xsoft_ AU_01 Pengujia White 12/01/2000
Antarmuka Pewarnaan 01 n Sistem Box –
Pengguna 15/01/2000
Penataletak SKPL_Xsoft_ AU_02 Pengujia Black 15/01/2000
an Window 02 n Unit Box –
17/01/2000
Pembangkit Pembangkit SKPL_Xsoft_ BK_01 Pengujia Black 18/01/2000
an kode an Kode 03 n Unit Box –
Pelanggan 19/01/2000
Kebenaran BK_02 Pengujia White 19/01/2000
Data n Unit Box –
Pelanggan 20/01/2000

Pada contoh di atas daftar requirement yang akan diuji dituliskan di kolom Butir Uji.

6.6 Deskripsi dan Hasil Uji

Bagian ini diuraikan untuk setiap butir uji yang ada. Setiap butir uji yang ada di sana
dijelaskan rinciannya dalam tabel seperti di bawah ini. Hasil yang didapat baru diisi setelah
pengujian dilakukan. Bila perlu ada penjelasan khusus untuk mendeskripsikan tiap kelas
pengujian, maka tuliskan sebelum merincikan butir ujinya. Bila perlu ada penjelasan khusus
untuk mendeskripsikan tiap butir uji, maka tuliskan sebelum tabel.
6.6.1 <Identifikasi kelas pengujian XXXXX>

6.6.1.1 <Identifikasi butir pengujian YYYYY>

Identifikas Deskripsi Prosedur Masukan Keluaran Kriteria Hasil Kesimpulan

i Pengujian yang Evaluasi yang
Diharapkan Hasil Didapat

6.6.1.2 <Identifikasi butir pengujian YYYYY>

contoh:

Identifi Deskripsi Prosedur Masuka Keluaran yang Kriter Hasil Kesimpula

kasi Pengujian n Diharapkan ia yang n
Evalu Didapa
asi t
Hasil

BK_02 Pengujian  Buka Kode 01<tgl_lahir>0 01<tgl 01<tgl ditolak

_01 hasil File data modus 01 _ _
pemasuka pelanggan pemasu 01<tgl_lahir>0 lahir> lahir><
n data  Cari kan 02 <nom no_
pelanggan rekord operato 01<tgl_lahir>0 or loncat
oleh dengan data r (01) 03 teruru
operator modus dst t>
BK_02 Pengujian pemasukan Kode 02<tgl_lahir>0 02<tgl 02<tgl diterima
_02 hasil yang modus 01 _ _
pemasuka diinginkan pemasu 02<tgl_lahir>0 lahir> lahir><
n data  Lihat kan on- 02 <nom no_
pelanggan tanggal lahir line 02<tgl_lahir>0 or terurut
oleh pelanggan (02) 03 teruru >
pelanggan  Lihat dst t>
secara on- kode
line pelanggan
 Band
ingkan
dengan
rumus
pembangkita
n kode
pelanggan

Penjelasan setiap kolom yang ada di atas diuraikan dalam penjelasan di bawah ini:
 Identifikasi

Bagian ini mengidentifikasi suatu kasus uji dengan suatu kode yang unik. Bagian ini juga
akan berisi guna dari pengujian dan penjelasan singkatnya. Subparagraf berikut ini akan
memberikan deskripsi rinci dari setiap kasus uji.

 Deskripsi
Bagian ini menguraikan deskripsi singkat tentang kasus uji yang dipilih.

 Masukan

Bagian ini akan berisi penjelasan tentang masukan pengujian yang diperlukan untuk suatu
kasus uji. Hal-hal berikut dapat dimasukkan, jika perlu:

1. Nama, guna dan deskripsi dari setiap masukan (termasuk akurasi dan jangkauan nilainya)
2. Sumber masukan pengujian dan metode yang digunakan untuk memiliki masukan
pengujian
3. Apakah masukan untuk pengujian ini adalah masukan yang nyata atau hanya simulasi
4. Waktu atau urutan pemasukan
5. Perilaku dari data masukan yang akan dikendalikan, misalnya
1. Pengujian suatu item dengan jumlah tipe data dan nilai yang minimum atau
secukupnya
2. Mencoba setiap item dengan suatu rangkaian nilai bertipe data yang benar dan pada
setiap pengujian memeriksa efek overflow, underflow dan kondisi-kondisi jelek
lainnya
3. Mencoba setiap item dengan tipe data yang tidak valid dan nilainya untuk setiap
masukan data yang tidak pasti
4. Pengujian ulang jika mungkin

 Keluaran yang Diharapkan

Bagian ini menberisi penjelasan setiap hasil harapan uji untuk setiap kasus uji. Baik nilai hasil
sementara atau hasil akhir dapat dinyatakan.

 Kriteria Evaluasi Hasil

Paragraf yang berikut ini akan mengidentifikasi kriteria yang digunakan untuk mengevaluasi
nilai sementara dan nilai akhir untuk setiap kasus uji. Untuk setiap hasil uji, informasi yang
dihasilkan antara lain misalnya:

1. Keakuratan atau jangkauan nilai keluaran yang masih dapat diterima

2. Jumlah kombinasi minimum atau alternatif kondisi masukan/keluaran yang akan
menunjukkan hasil uji yang dapat diterima
3. Durasi maksimum/minmum pengujian, dalam satuan waktu atau jumlah kejadian
4. Jumlah maksimum interupt, halt atau penyebab lain yang membuat sistem berhenti
5. Batas yang masih dapat diijinkan untuk terjadinya kesalahan
6. Kondisi yang menyebabkan hasil uji tidak memuaskan, sehingga perlu dilakukan
pengujian ulang
7. Kondisi dimana keluaran akan diinterpretasikan sebagai adanya kesalahan di data uji
masukan, pada file data/basisdata, atau pada tata cara uji
8. Indikasi yang masih dapat diijinkan terhadap pengendali, status dan hasil dari pengujian
dan kesiapan untuk kasus uji berikutnya (yang mungkin berupa keluaran tambahan)

 Prosedur Pengujian
Pada bagian ini akan dijelaskan prosedur uji untuk setiap kasus uji. Prosedur uji ini akan
didefinisikan sebagai sekumpulan langkah yang terurut secara sekuensial. Untuk
memudahkan dalam dokumentasinya, prosedur uji ini dapat dimasukkan sebagai lampiran
pada paragraf ini.

Tingkat kerincian dari cocok adalah level dimana tingkat tersebut berguna untuk menentukan
hasil yang diharapkan dan membandingkannya dengan hasil yang nyata. Hal-hal berikut
sebaiknya diberikan dalam prosedur uji (jika mungkin):

1. Operasi pengujian operator dan peralatan yang dibutuhkan pada setiap langkah,
termasuk, misalnya, perintah-perintah untuk

a) Inisialisasi kasus uji dan mencoba masukan pengujian

b) Periksa kondisi pengujian

c) Melakukan evaluasi tunggal terhadap hasil uji

d) Pencatatan Data

e) Penghentian suatu kasus uji.

f) Jika diperlukan, instruksi pengambilan data

g) Modifikasi basisdata/file data

h) Ulangi kasus uji jika tidak sukses

i) Lakukan alternatif lain yang dibutuhkan oleh kasus uji

j) Hentikan kasus uji

2. Hasil harapan uji dan kriteria evaluasi untuk setiap langkah

3. Jika kasus uji digunakan untuk beberapa kebutuhan (requirement), berikan
identifikasi yang jelas
4. Aksi yang harus dilakukan bila terjadi program berhenti atau ada kesalahan seperti

a) Pencatatan data kritis sebagai indikator untuk referensi

b) Sistem berhenti pada suatu waktu

c) Berhenti (halt) pada suatu perangkat lunak pendukung pengujian

d) Sekumpulan sistem dan operator yang mencata suatu hasil uji

5. Prosedur yang digunakan untuk mereduksi dan menganalisa hasil uji untuk
mendapatkan kemugkinan-kemungkinan berikut ini:

a) Mengetahui apakah keluaran sudah dihasilkan

 b) Identifikasi meida dan lokasi data yang dihasilkan oleh suatu kauus uji

c) Evaluasi keluaran sebagai dasar untuk melanjutkan urutan pengujian

d) Evaluasi keluaran pengujian terhadap keluaran

6.7 Keterunutan Pengujian

Bagian ini akan berisi:

1. Keterunutan (traceability) dari setiap kasus uji ke kebutuhan sistem. Jika suatu kasus uji
terdiri dari banyak kebutuhan, keterunutan harus dibuat dari setiap kumpulan prosedur uji
hingga kebutuhan yang diuji
2. Keterunutan dari setiap kebutuhan sistem yang dicakup hingga ke kasus ujinya. Untuk
pengujian sistem secara keseluruhan, keterunutan dari setiap kebutuhan sistem secara
keseluruhan dari dokumen SKPL. Untuk pengujian sistem, keterunutan dari setiap
kebutuhan dalam spesifikasi sistem/subsistem. Jika suatu kasus uji digunakan untuk
menangani beberapa kebutuhan, maka isi dari keterunutan ini harus dapat menunjukkan
suatu langkah pengujian yang khsusu untuk menangani setiap kebutuhan.

7 Spesifikasi Produk Perangkat Lunak

7.1 Perangkat Lunak Siap Eksekusi

Bagian ini menyebutkan rujukan pada berbagai lampiran atau media elektronik dan juga
memuat daftar perangkat lunak yang siap dieksekusi, berkas batch (batch files), berkas
perintah (command files), berkas data atau berkas-berkas lain yang diperlukan untuk instalasi
perangkat lunak pada komputer target.

Bagian ini juga menguraikan atau memberi rujukan pada dokumen panduan/prosedur
instalasi program eksekusi (penggunaan gambar akan sangat membantu).

Perangkat lunak merupakan otomasi dari proses bisnis pada sebuah organisasi, untuk
menghasilkan operasi bisnis (organisasi) yang efektif (akurat) dan efisien (cepat dan murah).
Spesifikasi perangkat lunak menjelaskan ketentuan atau batasan tentang apasaja yang harus
diberikan oleh sebuah perangkat lunak.
 Spesifikasi menggambarkan kebutuhan atau persyaratan (requirement) apa saja yang
harus dipenuhi oleh sistem perangkat lunak dan menentukan batasan pada operasi serta
implementasinya. Ada dua jenis kebutuhan sistem, yaitu fungsional dan non fungsional.
Kebutuhan fungsional menetapkan layanan sistem yang harus disediakan.

Kebutuhan nonfungsional berkaitan dengan ketentuan yang harus dipenuhi semua

layanan pada sistem, menyangkut kinerja, kehematan, keamanan dan mutu informasi.
Kebutuhan pengguna akhir menetapkan data dan informasi apasaja yang perlu di akses dari
sistem. Kebutuhan pengguna harus ditulis dalam tabel bahasa alami atau diagram. Persyaratan
sistem dapat ditulis dalam bahasa alami terstruktur, PDL atau dalam bahasa formal.
Sedangkan dokumen persyaratan perangkat lunak adalah pernyataan yang disepakati oleh
pengguna dan pengembang, tentang persyaratan sistem yang dibangun.

Pengembangan sistem informasi dan aplikasi perangkat lunak perlu dilakukan

mengingat pentingnya otomatisasi pengolahan data agar proses pengolahan data
pengamatan dapat berjalan dengan cepat dan akurat. Segala sesuatu yang dikembangkan
seharusnya memiliki kerangka dan langkah -langkah yang terstruktur dimana sistem
informasi dan aplikasi yang akan dihasilkan dapat sesuai dengan harapan pengguna.
Pada kerangka kerja pengembangan sistem informasi terdapat tahap awal yaitu
perencanaan ( planning ) yang menyangkut tentang kebutuhan pengguna ( user
spesification ) , kelayakan ( feasibility study ) baik secara teknis ataupun teknologi.

Requirement ( kebutuhan ) adalah pernyataan yang mengidentifikasikan kebutuhan

penting dalam sistem dan didalamnya mencakup aspek kebenaran, realistis, dibutuhkan, tidak
membingungkan, dan teukur. Tujuan pengembangan ini adalah untuk mengkaji proses
Spesifikasi Kebutuhan Perangkat Lunak yang sesuai dengan aspek penting pengembangan
sistem informasi dan aplikasi perangkat lunak dengan merubah pengguna menjadi jelas,
ringkas, dan dapat diverifikasi.

7.2 Berkas Sumber

Bagian ini menyebutkan rujukan pada berbagai lampiran atau media elektronik dan juga
memuat daftar berkas sumber, berkas batch (batch files), berkas perintah (command files),
berkas data atau berkas-berkas lain yang diperlukan untuk membangun ulang perangkat lunak
yang siap dieksekusi.
7.3 Syarat Pemaketan

Bagian ini menyatakan syarat yang mungkin diperlukan untuk memaketkan dan menandai
keabsahan duplikat perangkat lunak.

7.4 Prosedur Konstruksi

Spesifikasi perangkat lunak merupakan proses untuk menentukan pelayanan (servis) apa yang
dibutuhkan dan kendala-kendala pengoperasian sistem serta pengembangannya. Berikut ini
tahapannya:
1. Proses Rekayasa Kebutuhan
2. Studi Kelayakan
3. Analisis kebutuhan
4. Validasi Kebutuhan

1) Proses Rekayasa Kebutuhan

Rekayasa kebutuhan mencangkup beberapa proses mengenai fakta ini, proses rekayasa
kebutuhan adalah sekumpulan aktivitas-aktivitas yang terstruktur untuk diperoleh,
memvalidasi dan memelihara dokumen kebutuhan system (Thayer. 1997).

Pada umumnya tugas rekayasa digambarkan sebagai penciptaan dari solusi keaktivan biaya
untuk masalah kehidupan yang nyata dengan menerapkan pengetahuan keilmuan. Rekayasa
kebutuhan juga dapat digambarkan sebagai tugas untuk memenuhi aktivitas aktivitas
pengembangan untuk masalah dunia nyata sehingga ketepatan dan keefektifan biaya dari
solusi dapat dianalis (Nuseibeh, 2000).

2) Studi Kelayakan
Untuk semua sistem baru, proses rekayasa persyaratan harus dimulai studi kelayakan.
Input dari studi kelayakan adalah deskripsi garis besar sistem dan bagaimana sistem akan
digunakan di dalam organisasi. Hasil studi kelayakan berwujud laporan.Studi Kelayakan
memutuskan apakah sistem software yang akan dibuat sudah mencakup seluruh aspek
permasalahan. Melakukan studi kelayakan mencakup penilaian informasi, pengumpulan
informasi,dan penulisan laporan. Melakukan studi untuk menguji apakah sistem:
 Sudah sesuai dengan tujuan organisasi
 Dapat dikembangkan dengan teknologi terkini dan dana yang tersedia
 Dapat diintegrasikan dengan sistem lain yang sudah digunakan
3) Implementasi Studi Kelayakan
Implementasi menurut kamus besar indonesia, diartikan sebagai pelaksanaan atau
penerapan, artinya yang dilaksanakan dan diterapkan adalah kurikulum yang telah dirancang
atau didesain untuk kemudian dijalankan sepenuhnya.Berbasiskan pada penilaian informasi
(apa yg dibutuhkan), pengumpulan informasi dan penulisan laporan Pertanyaan ke personal di
organisasi:
1. Apa yang akan terjadi apabila sistem tidak diimplementasikan?
2. Masalah proses apa yang ada ?
3. Apa yang dapat dibantu oleh sistem ?
4. Masalah apa yang akan muncul pada proses Integrasi ?
5. Adakah teknologi baru yang dibutuhkan? Skill yang dibutuhkan ?
6. Fasilitas apa yang harus didukung oleh sistem ?

4) Validasi kebutuhan 
Validasi adalah suatu tindakan pembuktian dengan cara yang sesuai dengan tiap bahan proses,
prosedur, kegiatan, sistem, perlengkapan atau mekanisme yang digunakan dalam produksi
dan pengawasan yang akan senantiasa mencapi hasil yang diinginkan. Validasi dibutuhkan
untuk memberikan kepastian bahwa rancangan dan dokumen dari sistem yang akan
diimplementasiakn telah sesuai dengan keinginan dan kebutuhan pemangku kepentingan baik
pemesan, pengguna maupun pihak pengembang. Tujuan dari validasi kebutuhan adalah :
 Bertujuan untuk meyakinkan bahwa kebutuhan yang sudah didefinisikan sesuai
dengan yang diinginkan pengguna.
 Menghindari Kesalahan pendefinisian kebutuhan karena akan menyebabkan
penambahan biaya yang besar.

8 Panduan Instalasi

8.1 Instalasi Program Siap Eksekusi

Sistem minimum yang disarankan dalam pengimplementasian perangkat lunak ini tersaji
sebagai berikut :
a. Komputer Server
Platform Single CPU Tower Server

Processor Type Intel Xeon Processor

#1 Processor Onboard Intel® Xeon® Processor E3-1220v3 (8M Cache, 3.10

GHz)
CPU Chipset
Intel® C222 Series Chipset
Standard Memory
4GB (1x 4GB) PC3-12800 1600Mhz ECC DDR3 UDIMM
Video Type
Integrated Matrox G200e 16 MB
1. Controller
ServeRaid C100 (RAID -0, -1)
1. Optical Drive
DVD-ROM
Standard Bays
4x 3.5″ Simple Swap Serial ATA (SATA) or 8x 2.5″ Hot-
Slot Provided
Swap SAS/SATA

Chassis Form Factor

Up to four PCIe expansion slots

Power Supply Type

Tower Chassis

System Management
350w

Integrated Management Module 2 (IMM2) standard with

IMPI 2.0 and Serial over LAN, optional upgrade to remote
presence via IBM Feature on Demand, IBM System
O/S Director

Validated System Windows 8

Microsoft Windows Server 2012/2008/R2, SBS 2011, Red

Hat Enterprise Linux, SUSE Linux, VMware
 b. Komputer Client

- CPU SPEED: 1.2 GHz

- RAM: 512 MB

- OS: Windows XP

- FREE DISK SPACE: 65 MB

c. Penginstallan di PC Server

d. Penginstallan di PC Client

8.2 Instalasi Kode Program Sumber

Bagian ini menjelaskan:

- Cara penyalinan program sumber (nama direktori khusus jika ada)

- Lingkungan pengembangan yang harus disiapkan (kompilator yang digunakan,
environment variable yang harus ada)
- Data yang harus disiapkan, letak direktori.

9 Penutup

Berisi catatan lain yang dirasakan perlu.