SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK
Sistem Absensi Online Berbasis Web dengan Verifikasi Lokasi Google Maps
untuk:
Absensi Organisasi
Dipersiapkan oleh:
Kelompok 5
Angga Saputra 2415061071
M. Paundra Napynka Ali 2455061016
Akhmad Faishal Kharisma 2415061054
M. Alfaruq Hasan 2415061083
Program Studi
Teknik Informatika FT Universitas Lampung
Jl. S.
Brojonegoro No. 1 Bandar Lampung
|
|
Program Studi Teknik Informatika
FT - UNILA |
Nomor Dokumen |
Halaman |
|
|
SKPL-W-xx <xx:no grp> |
<#>/<jml # |
|||
|
Revisi |
<nomor revisi> |
Tgl: <isi tanggal> |
||
Control Revisi Dokumen
Seluruh revisi yang
telah dilakukan pada dokumen ini, dapat diikuti sebagaimana tabel berikut.
|
Nomer Revisi |
Tanggal |
Diperiksa oleh |
Keterangan singkat perbaikan |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sistem Penomoran
Ada
beberapa hal/bagian dalam dokumen ini yang perlu diberi nomor. Maksud penomoran
ini untuk mempermudah audience dalam
pengidentifikasian. Adapun aturan penomorannya sebagaimana tabel berikut:
|
Hal/Bagian |
Aturan Penomoran |
|
Tabel/Data Store |
Nomor berbentuk TD99, dimana 99 adalah nomor urut tabel
atau data store Contoh: TD11, TD12, TD29, TD31 dan sebagainya |
|
Kebutuhan Fungsional |
Nomor berbentuk KF999.x, dimana
999 adalah nomor urut struktur butir-butir pada kebutuhan fungsional.
Sedangkan x adalah nomor berupa abjad dan sifatnya sebagai tambahan jika
kebutuhan fungsional tersebut memiliki item turunannya. Contoh: KF101, KF120, KF120.a, KF120.b dan sebagainya |
|
Kebutuhan Non Fungsional |
Nomor berbentuk KnF99.x, dimana 99
adalah nomor urut struktur butir-butir pada kebutuhan non fungsional.
Sedangkan x adalah nomor berupa abjad dan sifatnya sebagai tambahan jika
kebutuhan non fungsional tersebut memiliki item turunannya. Contoh: KnF11, KnF12, KnF12.a, KnF12.b dan sebagainya |
Referensi
Berikut
adalah daftar acuan yang digunakan dalam pendokumentasian spesifikasi kebutuhan
perangkat lunak ini.
●
IEEE Std. 1233, 1998 Edition IEEE Guide for Developing System
Requirements Specifications
●
IEEE, Software Requirements Engineering, Second Edition, IEEE
Computer Society Press, 2002.
●
Bray, Ian K. An Introduction to Requirement Engineering, 1st
published, Addison-Wesley, 2002
●
Kotonya, Gerald and Sommerville, Ian. Requirement Engineering:
Processes and Techniques, John Wiley & Sons Ltd, 1998
●
Holil, Achmad. Template: Spesifikasi Kebutuhan Perangkat Lunak,
Jurusan Sistem Informasi ITS, 2006.
<Tambahkan
textbook, panduan atau dokumen lain yang digunakan sebagai acuan dalam
pengembangan perangkat lunak ini>
Daftar Isi
SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK
1.3 Definisi,
Istilah dan Singkatan
1.5 Deskripsi
umum Dokumen (Ikhtisar)
2 Deskripsi
Umum Perangkat Lunak
3.1.2 Antarmuka
Perangkat Keras
3.1.3 Antarmuka
Perangkat Lunak
3.6.1 Kebutuhan
Fungsional vs Use Case
3.7.2 Kebutuhan
Non Fungsional
Daftar Tabel
Tabel 1 Karakteristik
Pengguna
1. Pendahuluan
1.1 Tujuan Penulisan Dokumen
Dokumen
SKPL ini dibuat untuk merancang dan mendokumentasikan sistem absensi berbasis
lokasi GPS. Sistem ini bertujuan untuk mengurangi kecurangan dalam pencatatan
kehadiran dengan memastikan pengguna hanya dapat melakukan absensi jika berada
di lokasi yang telah ditentukan.
1.2 Lingkup Masalah
Sistem ini adalah aplikasi absensi berbasis GPS yang memungkinkan
karyawan atau mahasiswa melakukan presensi hanya saat berada di lokasi
tertentu. Aplikasi ini akan mendeteksi lokasi pengguna menggunakan GPS dan
memverifikasi keabsahan posisi sebelum mengizinkan absensi. Sistem ini
ditujukan untuk organisasi, perusahaan, atau institusi pendidikan yang ingin
meningkatkan akurasi dan transparansi dalam pencatatan kehadiran.
1.3 Definisi, Istilah dan
Singkatan
· GPS
(Global Positioning System): Teknologi yang digunakan untuk menentukan lokasi
geografis perangkat pengguna.
· Geofencing:
Mekanisme yang membatasi akses absensi hanya dalam radius tertentu dari lokasi
yang diizinkan.
· Presensi:
Proses pencatatan kehadiran karyawan atau mahasiswa dalam sistem.
· Administrator:
Pihak yang memiliki akses untuk mengelola lokasi, jadwal, dan aturan absensi
dalam sistem.
· User:
Pengguna yang melakukan absensi menggunakan aplikasi.
1.4 Referensi
Dedi Purwanto, S.kom.,M.Kom,
2024, Perancangan Sistem Informasi Absensi Online Berbasis GPS
Aip Suprapto Munari,
Muhammad Yusril Helmi Setyawan, Mohamad Nurkamal Fauzan, 2020, Panduan Lengkap
Algoritma Havarisne Formula pada Sistem Monitoring Mahasiswa Intersnship
Berbasis GPS, Kreatif Industri Nusantara
1.5 Deskripsi umum Dokumen
(Ikhtisar)
Dokumen ini berisi rancangan sistem
absensi berbasis lokasi GPS, mencakup tujuan, fitur utama, teknologi yang
digunakan, serta skenario penggunaan. Sistem ini dirancang untuk meningkatkan
transparansi kehadiran dan mengurangi praktik kecurangan dalam absensi.
2
Deskripsi Umum Perangkat Lunak
Sistem absensi berbasis lokasi GPS ini dirancang untuk memastikan
kehadiran karyawan atau mahasiswa secara akurat dengan memanfaatkan teknologi
GPS dan geofencing. Pengguna hanya dapat melakukan absensi jika berada dalam
radius lokasi yang telah ditentukan, seperti kantor atau kampus. Sistem ini
juga menyediakan fitur laporan kehadiran, manajemen lokasi absensi, serta
histori presensi.
Tabel
1Karakteristik Pengguna
|
Kategori Pengguna |
Tugas |
Hak Akses ke aplikasi |
|
Karyawan/Mahasiswa |
Melakukan absensi di
lokasi yang ditentukan |
Akses fitur absensi
dan melihat riwayat kehadiran |
|
Admin |
Mengelola data
pengguna, menentukan lokasi absensi, dan membuat laporan kehadiran |
Akses penuh ke semua
fitur sistem |
|
Dosen |
Melihat laporan
kehadiran mahasiswa |
Akses laporan
absensi dan data statistik |
· Sistem
bergantung pada konektivitas internet dan GPS yang akurat.
· Pengguna
hanya dapat melakukan absensi jika berada dalam radius geofencing yang
ditentukan.
· Tidak
mendukung absensi offline tanpa koneksi internet.
· Sistem
hanya dapat diakses melalui perangkat yang mendukung layanan lokasi
(smartphone, tablet).
· Multi-platform:
berjalan di Android dan iOS.
·
Client: Aplikasi mobile berbasis
Android dan iOS.
·
OS: Android 8.0 ke atas, iOS 12 ke
atas.
·
DBMS: PostgreSQL/MySQL sebagai basis
data utama.
3
Deskripsi Kebutuhan
3.1
Kebutuhan Antarmuka Eksternal
3.1.1 Antarmuka pemakai
<Uraikan
karakteristik logik dari setiap antarmuka antara produk perangkat lunak dan
penggunanya. Bisa berupa contoh gambar screen,
beberapa standar GUI atau arahan bentuk yang harus diikuti, batasan screen layout, standar buttons dan function (misal help) yang akan kelihatan pada
setiap screen, keyboard shortcuts, standart tampilan error message, dan yang lainnya. Tentukan komponen perangkat lunak
yang diperlukan untuk antarmuka pengguna. Detail dari desain antarmuka pengguna
ada pada dokumen terpisah yaitu spesifikasi antarmuka pengguna >
3.1.2 Antarmuka Perangkat Keras
<Gambarkan
karakteristik logik dan fisik dari setiap antarmuka antara produk perangkat
lunak dan komponen perangkat keras dari sistem. Boleh berupa tipe peralatan
pendukung, data alamiah dan kontrol interaksi antara perangkat lunak dan
perangkat keras, dan protokol komunikasi yang digunakan>
3.1.3 Antarmuka Perangkat Lunak
<Jelaskan
koneksi antara perangkat lunak ini dengan komponen perangkat lunak tertentu
lainnya (nama dan versi), termasuk database, sistem operasi, tools, libraries,
dan komponen komersial yang terintegrasi. Tunjukkan item-item data atau pesan
yang datang kepada sistem dan hasilnya dan gambaran dari penggunaan setiap
hasil tersebut. Gambaran kebutuhan servis dan komunikasi. Menunjuk pada dokumen
yang menguraikan detail pemrograman aplikasi interface protocol. Identifikasi
data yang akan dibagi antar komponen perangkat lunak. Jika mekanisme pembagian
data harus terimplementasi dengan cara yang khusus (contoh, penggunaan
lingkungan data global si sistem operasi
multitasking), terutama batasan implementasinya>
3.1.4 Antarmuka Komunikasi
<Uraikan
asosiasi kebutuhan dengan beberapa fungsi komunikasi yang dibutuhkan oleh
perangkat lunak ini, termasuk e-mail, web browser, protokol komunikasi network
server, forms elektronik, dan lain sebagainya. Identifikasi beberapa hal yang
berhubungan dengan format message. Identifikasi beberapa standar komunikasi
yang akan digunakan, seperti FTP atau HTTP. Menetapkan keamanan komunikasi atau
isu tentang encrypsi, kecepatan transfer data, dan mekanisme sinkronisasi>
.
3.2
Kebutuhan Fungsional
Diawali dengan membuat daftar kebutuhan
fungsional P/L, lengkap dengan ID dan penjelasan jika perlu. Bisa dibuat dalam
bentuk tabel.
|
ID |
Kebutuhan |
Penjelasan |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Pada subbab berikutnya, buatlah diagram
konteks dan DFD level berikutnya.
3.3
Model Use Case
3.3.1 Diagram Use Case
Bagian ini diisi dengan diagram use case keseluruhan.
3.3.2 Definisi Actor
Bagian ini diisi dengan daftar actor dan deskripsi role untuk actor
tersebut. Deskripsi role harus menjelaskan wewenang pada role tersebut dalam
perangkat lunak. Bisa dibuat dalam bentuk tabel berikut:
|
No |
Actor |
Deskripsi |
|
1 |
Guest |
Actor dengan role ini mempunyai wewenang untuk
melakukan registrasi serta melihat informasi-informasi yang sifatnya umum seperti profil perusahaan, …. |
3.3.3 Definisi Use Case
Bagian ini diisi dengan daftar use case dan deskripsi singkat mengenai
use case tersebut. Bisa dibuat dalam bentuk tabel berikut:
|
No |
Use Case |
Deskripsi |
|
1 |
Melihat daftar produk |
Sistem menampilkan daftar produk yang boleh
dipilih untuk pengguna. |
|
|
|
|
3.3.4 Skenario Use Case
Bagian ini diisi dengan skenario (flow
of event) untuk beberapa use case utama, yang menggambarkan urutan
interaksi actor dengan use case tersebut, dari awal sampai akhir.
Contoh:
Nama Use Case: Melihat daftar produk Skenario:
|
Aksi Actor |
Reaksi Sistem |
|
Skenario Normal |
|
|
1. Memilih menu Daftar Produk |
|
|
|
2. Menampilkan daftar produk dari
basisdata ke layar |
|
3. Menekan tombol navigasi (next, prev) |
|
|
|
4. Me-refresh tampilan daftar produk |
|
Skenario Alternatif |
|
|
1. Memilih menu Daftar Produk |
|
|
|
2. Menampilkan pesan ‘Tidak ada produk’ |
3.4
Kebutuhan Non Fungsional
Kebutuhan
Kinerja
<Jika
ada kebutuhan kinerja perangkat lunak yang kondisinya bervariasi, nyatakan dan
terangkan dasar pemikirannya, agar dapat membantu pengembang dalam memahami
tujuan dan pemilihan desain yang cocok. Terutama yang berhubungan dengan waktu
untuk sistem real time. Buatlah kebutuhan yang sedemikian jelas dan mungkin.
Pernyataan kebutuhan kinerja untuk satu kebutuhan fungsional atau feature >
Kebutuhan
Keamanan
<Spesifikasikan
kebutuhan yang mementingkan kemungkinan hilang, rusak atau kesalahan akan hasil dari penggunaan
perangkat lunak. Tentukan beberapa usaha perlindungan atau aksi yang harus
dilakukan untuk mencegahnya. Tunjuklah beberapa kebijakan eksternal atau
regulasi isu tentang keamanan yang mempengaruhi penggunaan dan desain perangkat
lunak. Temukan beberapa setifikasi keamanan yang dapat memberikan kepuasan>
Kebutuhan
Perlindungan Keamanan
<Spesifikasikan
kebutuhan yang concern pada keamanan atau isu privasi di sekitar penggunaan
perangkat lunak atau proteksi oleh perangkat lunak pada penggunaan atau
pembuatan data. Tentukan kebutuhan autentifikasi identitas pengguna. Tunjuklah
beberapa kebijakan eksternal atau regulasi yang berisi isu-isu keamanan yang
mempengaruhi penggunaan perangkat lunak. Temukan beberapa setifikasi keamanan
atau privasi yang harus memuaskan>
Atribut
Kualitas Perangkat Lunak
<Spesifikasikan
beberapa tambahan karakteristik kualitas dari perangkat lunak yang penting bagi
pengguna atau pengembang. Pertimbangkan tentang adaptability, availability,
correctness, flexibility, interoperability, maintainability, portability, reliability,
reusability, robustness, testability dan usability. Tuliskan
pertimbangan-pertimbangan tersebut agar menjadi spesifik, kuantitatif dan
memungkinkan untuk diverifikasi. Setidaknya, klarifikasikan preferensi relatif
dari variasi antribut, seperti lebih mudah menggunakannya dari pada
mempelajarinya>
Uraikan dengan ringkas kebutuhan non fungsional dalam tabel
sebagai berikut. Isilah Kolom Kebutuhan dengan kalimat yang jelas dan kelak dapat
ditest untuk dipenuhi.ID adalah nomor kebutuhan yang harus ditelusuri pada saat
test. Tuliskan N/A bila Not Applicable..
|
ID |
Parameter |
Kebutuhan |
|
|
Availability |
|
|
|
Reliability |
|
|
|
Ergonomy |
|
|
|
Portability |
|
|
|
Memory |
|
|
|
Response time |
|
|
|
Safety |
N/A |
|
|
Security |
|
|
|
|
|
|
|
Others 1: Bahasa komunikasi |
Misalnya : semua
tanya jawab harus dalam bahasa Indonesia |
|
|
|
Setiap layar
harus mengandung logo PT Pos Indonesia |
|
|
|
|
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 3 menit”
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 perancangan 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 Kebutuhan Fungsional vs Use
Case
Mapping kebutuhan fungsional dengan use
case terkait
|
ID Kebutuhan Fungsional |
ID Use Case Terkait |
|
|
|
3.7
Ringkasan Kebutuhan
Bab ini berisi ringkasan semua kebutuhan.
Kebutuhan ini mencerminkan semua hal yang harus dipenuhi, dan nantinya akan
menjadi arahan untuk tahapan testing, karena pada dasarnya, semua kebutuhan
harus dapat ditest supaya dapat dibuktikan dipenuhi. Dibagi menjadi dua bagian:
fungsional dan non fungsional.
3.7.1 Kebutuhan Fungsional
|
ID |
Deskripsi |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.7.2 Kebutuhan Non Fungsional
|
ID |
Deskripsi |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 Comments
Wopppp Kerenn
ReplyDelete