|
SKPL-W-xx |
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 Kebutuhan Antarmuka Eksternal
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 6 Atribut
Kualitas Perangkat Lunak
Tabel 8 Kebutuhan
Fungsional vs Use Case
Tabel 10 Kebutuhan Non
Fungsional
Daftar Gambar
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
·
Tampilan dan Navigasi pada sistem harus menyediakan antarmuka
pengguna yang intuitif dan responsif.
·
Halaman login menyediakan halaman yang memungkinkan semua jenis
pengguna baik mahasiswa, dosen, maupun admin untuk masuk dengan kredensial yang
valid.
·
Setelah login, pengguna diarahkan ke dashboard yang menampilkan
menu absensi, histori kehadiran, serta fitur manajemen yang dikhususkan untuk
admin.
·
Setiap aksi, seperti check-in harus disertai dengan tampilan
notifikasi misalnya “Absensi Berhasil” dan pesan erro yang jelas apabila
terjadi kesalahan.
3.1.2 Antarmuka Perangkat Keras
·
Sistem harus dapat diakses melalui
smartphone dan tablet yang memiliki modul GPS.
·
Perangkat pengguna harus mendukung
pengambilan data lokasi secara real-time yang berguna untuk verifikasi
kehadiran.
3.1.3 Antarmuka Perangkat Lunak
·
Sistem harus terintegrasi dengan google maps untuk mendapatkan
data lokasi dan melakukan verifikasi terhadap radius yang telah ditentukan.
·
Sistem menggunakan database misalnya PostgresSQL/MySQL untuk
menyimpan data absensi, data pengguna dan konfigurasi geofencing.
·
Pengiriman data antara front-end, back-end, dan google maps
dilakukan melalui protokol HTTP/HTTPS.
3.1.4 Antarmuka Komunikasi
·
Pengunaan protokol HTTP/HTTPS untuk komunikasi data yang aman
antara client dan server.
·
Untuk notifikasi otomatis sistem harus mampu mengirim notifikasi
melalui email atau push notification ketika terjadi aksi penting, seperti
absensi berhasil atau gagal.
3.2
Kebutuhan Fungsional
Diawali dengan membuat daftar kebutuhan
fungsional P/L, lengkap dengan ID dan penjelasan jika perlu. Bisa dibuat dalam
bentuk tabel.
Tabel
2 Kebutuhan Fungsional
|
ID |
Kebutuhan |
Penjelasan |
|
KF
101 |
Login
dan Otentikasi |
Sistem
harus menyediakan fitur untuk semua jenis pengguna (Mahasiswa/Karyawan,
Dosen, dan Admin) agar dapat melakukan login dengan memasukkan username dan
password yang valid. |
|
KF
102 |
Check-In/Check-Out
Absensi |
Sistem
memungkinkan pengguna (Mahasiswa/Karyawan) untuk melakukan absensi dengan
cara check-in dan check-out melalui antarmuka berbasis web, termasuk validasi
waktu yang telah ditentukan. |
|
KF
103 |
Verifikasi
Lokasi (Geofencing) |
Sistem
mengambil data koordinat GPS perangkat pengguna dan membandingkannya dengan
radius yang telah ditentukan melalui integrasi Google Maps API untuk
memastikan absensi hanya dilakukan di area yang sah. |
|
KF
104 |
Penyimpanan
Data Absensi |
Sistem
harus menyimpan data absensi secara real-time ke dalam database, mencakup
informasi seperti waktu, lokasi, dan ID pengguna, sehingga data kehadiran
tersimpan dengan akurat. |
|
KF
105 |
Histori
Absensi |
Sistem
menyediakan fitur yang memungkinkan pengguna untuk melihat riwayat kehadiran
mereka secara lengkap, sehingga pengguna dapat memantau absensi yang telah
dilakukan. |
|
KF
106 |
Laporan
Kehadiran |
Sistem
menyajikan laporan kehadiran yang dapat diakses oleh Dosen/Atasan dan Admin
untuk memantau kehadiran pengguna, serta melakukan analisis atau evaluasi
data kehadiran secara menyeluruh. |
|
KF
107 |
Pengiriman
Notifikasi |
Sistem
mengirimkan notifikasi secara otomatis kepada pengguna, baik sebagai
konfirmasi absensi berhasil maupun pemberitahuan error apabila terjadi
kegagalan verifikasi lokasi atau proses lainnya. |
|
KF
108 |
Manajemen
Data Pengguna dan Pengaturan Lokasi |
Sistem
memungkinkan Admin untuk menambah, mengubah, dan menghapus data pengguna
serta mengatur parameter absensi, seperti penentuan lokasi, radius
geofencing, dan jadwal absensi. |
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.
Diagram Use Case
Gambar 1 Diagram Use Case
Diagram Activity
Gambar 2 Diagram Activity
Sequence Diagram
Gambar 3 Sequence Diagram
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:
Tabel
3 Definisi Actor
|
No |
Actor |
Deskripsi |
|
1 |
Mahasiswa atau Karyawan |
Pengguna yang melakukan absensi, melihat histori kehadiran, serta
menerima notifikasi terkait kehadiran. |
|
2 |
Dosen atau Atasan |
Pengguuna yang mengakses laporan kehadiran, memverifikasi kehadiran
dan memonitor statistik kehadiran mahasiswa atau karyawan. |
|
3 |
Admin |
Pengguna dengan hak akses penuh yang bertanggung jawab untuk
mengelola data pengguna, lokasi absesnsi, dan pengaturan sistem secara
keseluruhan. |
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:
Tabel
4 Definisi Use Case
|
No |
Use Case |
Deskripsi |
|
UC 001 |
Login Dan Otentikasi |
Proses dimana pengguna memasukkan kredensial (username dan password)
untuk mendapatkan akses ke sistem sesuai dengan peran masing-masing. |
|
UC
002 |
Check In / Check-Out Absensi |
Proses absensi dimana pengguna melakukan check-in
atau check-out melalui antarmuka web yang terintegrasi dengan verifikasi
lokasi menggunakan data GPS. |
|
UC
003 |
Verifikasi Lokasi (Geofencing) |
Proses di mana sistem mengambil data lokasi
pengguna melalui sensor GPS dan memverifikasi apakah posisi tersebut berada
dalam radius yang telah ditentukan melalui Google Maps API. |
|
UC
004 |
Histori Absesni |
Menampilkan data kehadiran yang telah dicatat,
termasuk waktu, tanggal, dan lokasi absensi, sehingga pengguna dapat memantau
histori kehadiran mereka. |
|
UC
005 |
Laporan Kehadiran |
Menyediakan laporan kehadiran yang dapat diakses
oleh Dosen/Atasan dan Admin untuk memonitor dan menganalisis data kehadiran. |
|
UC
006 |
Manajemen Data Dan Pengaturan Lokasi |
Proses di mana Admin dapat menambah, mengubah,
dan menghapus data pengguna serta mengatur parameter absensi, seperti
pengaturan lokasi (radius geofencing) dan jadwal absensi. |
|
UC 007 |
Pengiriman Notifikasi |
Sistem secara otomatis mengirim notifikasi kepada
pengguna sebagai informasi ketika absensi berhasil dilakukan atau jika
terjadi kesalahan/verifikasi lokasi. |
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:
Tabel
5 Skenario Use Case
|
Aksi Actor |
Reaksi Sistem |
|
Skenario Normal |
|
|
1. Pengguna memilih menu Check-In |
Sistem
menampilkan halaman check-in dan meminta izin akses lokasi. |
|
2.Penguna mengizinkan akses lokasi |
Sistem mengambil data koordinat GPS pengguna
secara real-time |
|
3. Sistem melakukan verifikasi lokasi |
Sistem
membandingkan koordinat GPS dengan batasan radius yang telah ditentukan
melalui Google Maps API. |
|
4. Lokasi pengguna berada dalam area yang
diizinkan |
Sistem menyimpan data absensi ke database dan
menampilkan notifikasi “Absesnsi berhasil” |
|
|
|
|
Skenario Alternatif |
|
|
1. Pengguna Memilih Menu
Check-In |
Sistem
menampilkan halaman check-in dan meminta izin akses lokasi. |
|
2.Pengguan Mengizinkan Akses Lokasi |
Sistem mengambil
data koordinat GPS pengguna secara real-time. |
|
3.Sistem Melakukan Verifikasi Lokasi |
Sistem
mendeteksi bahwa lokasi pengguna berada di luar radius yang telah ditentukan. |
|
4. Lokasi Tidak Valid |
Sistem
menampilkan pesan error “Lokasi Anda berada di luar area yang diizinkan” dan
tidak menyimpan data absensi. |
3.4
Kebutuhan Non Fungsional
Kebutuhan
Kinerja
· Sistem
harus mampus menampilkan respon hasil dari absensi dalam waktu kurang dari 4
detik.
· Database
harus dapat menangani transaksi absensi secara real-time dengan jumlah pengguna
yang banyak.
Kebutuhan
Keamanan
· Semua data yang sensitif misalnya
kredensial penggua dan data absensi harus dienkripsi.
· Sistem harus menerapkan
autentikasi dan otorisasi yang ketat untuk mencegah akses yang tidak sah.
Kebutuhan
Perlindungan Keamanan
·
Sistem harus menerapkan autentikasi multi-faktor untuk memastikan
bahwa hanya pengguna yang benar-benar terverifikasi yang dapat mengakses data
dan fungsi sistem.
·
Sistem harus melakukan validasi dan sanitasi input guna mencega
serangan seperti SQL Injection, XSS dan serangan lain yang dapat mengancam
integritas data.
·
Sistem harus mencatat seluruh aktivitas (audit log) dan
menyediakan mekanisme monitoring untuk mendeteksi aktivtas mencurigakan serta
upaya penyalahgunaan sistem.
Atribut
Kualitas Perangkat Lunak
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..
Tabel
6 Atribut Kualitas Perangkat Lunak
|
ID |
Parameter |
Kebutuhan |
|
AQ101 |
Availability |
Sistem
harus terus menerus beroperasi 24 jam sehari, 7 hari seminggu dengan downtime
minimal, sehingga proses absensi dapat berlangsung tanpa gangguan. |
|
AQ102 |
Reliability |
Sistem
harus memiliki tingkat keandalan minimal 99% dalam memproses transaksi
absensi secara real-time, untuk memastikan data kehadiran akurat dan
konsisten. |
|
AQ103 |
Ergonomy |
Antarmuka
pengguna harus user-friendly, intuitif, dan responsif, sehingga memudahkan
pengguna dalam melakukan absensi dan mengakses histori kehadiran. |
|
AQ104 |
Portability |
Aplikasi
harus kompatibel dan dapat dijalankan pada perangkat Android dan ios, tanpa
mengalami masalah kompatibilitas atau penurunan performa. |
|
AQ105 |
Memory |
Sistem
harus mengoptimalkan penggunaan memori agar tidak terjadi lag atau crash,
terutama saat pengambilan data lokasi dan pemrosesan absensi secara
real-time. |
|
AQ106 |
Response Time |
Waktu
respon sistem untuk setiap transaksi (seperti proses check-in/check-out dan
query data) harus kurang dari 4 detik agar pengalaman pengguna optimal. |
|
AQ107 |
Safety |
Untuk aplikasi absensi ini, aspek safety dianggap tidak
langsung terlibat (N/A), karena fokus utama adalah pada validitas data
kehadiran dan bukan keselamatan fisik. |
|
AQ108 |
Security |
Data
pengguna (misalnya, kredensial dan data absensi) harus dienkripsi dan diakses
dengan mekanisme autentikasi yang kuat untuk mencegah akses tidak sah. |
|
AQ109 |
Others (Bahasa) |
Seluruh
antarmuka dan komunikasi dalam aplikasi harus menggunakan bahasa Indonesia, serta
setiap layar harus mencantumkan logo institusi yang relevan. |
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
·
Ketergantungan pada GPS dan
Internet:
Sistem hanya dapat berfungsi optimal jika perangkat pengguna memiliki akses
internet yang stabil dan sensor GPS yang akurat.
·
Integrasi dengan Google Maps API:
Verifikasi lokasi bergantung pada ketersediaan dan akurasi data dari Google
Maps API.
·
Penggunaan Library dan Framework:
Sistem dirancang dengan memanfaatkan library dan framework yang telah ada, yang
berarti pengembang harus mengikuti standar dan batasan dari teknologi tersebut.
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.
Tabel
7 Kerunutan
|
ID Kebutuhan Fungsional |
ID Use Case Terkait |
Data Store/Entitas (E-R) |
|
KF101 |
UC001 – Login dan Otemtikasi |
Tabel Perngguna |
|
KF102 |
UC002 – Check-In/Check-Out Absensi |
Tabel Absensi |
|
KF103 |
UC003 – Verifikasi Lokasi (Geofencing) |
Tabel Absensi, Log Lokasi (Jika Ada) |
|
KF104 |
UC004 – Penyimpanan Data Absensi |
Tabel Absensi |
|
KF105 |
UC005 – Histori Absensi |
Tabel Absensi |
|
KF106 |
UC006 – Laporan Kehadiran |
Tabel Absensi. Tabel Laporan |
|
KF107 |
UC007 – Pengiriman Notifikasi |
Tabel Motifikasi |
|
KF108 |
UC008 – Manajemen Data dan Pengaturan Lokasi |
Tabel Pengguna Dan Tabel Lokasi |
3.6.1 Kebutuhan Fungsional vs Use
Case
Mapping kebutuhan fungsional dengan use
case terkait
Tabel
8 Kebutuhan Fungsional vs Use Case
|
ID Kebutuhan Fungsional |
ID Use Case Terkait |
|
KF101 |
UC001 – Login dan Otemtikasi |
|
KF102 |
UC002 – Check-In/Check-Out Absensi |
|
KF103 |
UC003 – Verifikasi Lokasi (Geofencing) |
|
KF104 |
UC004 – Penyimpanan Data Absensi |
|
KF105 |
UC005 – Histori Absensi |
|
KF106 |
UC006 – Laporan Kehadiran |
|
KF107 |
UC007 – Pengiriman Notifikasi |
|
KF108 |
UC008 – Manajemen Data dan Pengaturan Lokasi |
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
Tabel 9 Kebutuhan Fungsional
|
ID |
Deskripsi |
|
KF101 |
Sistem
harus menyediakan fitur Login dan Otentikasi untuk semua jenis pengguna
menggunakan username dan password. |
|
KF102 |
Sistem
memungkinkan pengguna melakukan Check-In dan Check-Out absensi melalui antarmuka
berbasis web. |
|
KF103 |
Sistem
melakukan Verifikasi Lokasi dengan mengambil data GPS pengguna dan
membandingkannya dengan radius geofencing yang telah ditentukan melalui
Google Maps API. |
|
KF104 |
Sistem
menyimpan data absensi secara real-time ke dalam database, termasuk informasi
waktu, lokasi, dan ID pengguna. |
|
KF105 |
Sistem
menyediakan fitur Histori Absensi yang memungkinkan pengguna untuk melihat
riwayat kehadiran mereka. |
|
KF106 |
Sistem
menyediakan fitur Laporan Kehadiran yang dapat diakses oleh Dosen/Atasan dan
Admin untuk memonitor kehadiran pengguna. |
|
KF107 |
Sistem
mengirimkan Notifikasi secara otomatis kepada pengguna saat absensi berhasil
atau gagal. |
|
KF108 |
Sistem memungkinkan
Admin untuk melakukan Manajemen Data Pengguna dan Pengaturan Lokasi,
seperti menambah, mengubah, menghapus data pengguna serta pengaturan jadwal. |
3.7.2 Kebutuhan Non Fungsional
Tabel 10 Kebutuhan Non Fungsional
|
ID |
Deskripsi |
|
KnF101 |
Sistem
harus memiliki waktu respon kurang dari 4 detik untuk setiap transaksi
absensi dan update data, guna memberikan pengalaman pengguna yang optimal. |
|
KnF102 |
Data
sensitif seperti kredensial dan data absensi harus dienkripsi untuk menjaga
keamanan sistem dari akses tidak sah. |
|
KnF103 |
Sistem harus tersedia 24 jam sehari, 7 hari seminggu dengan
downtime minimal agar operasional absensi tidak terganggu. |
|
KnF104 |
Aplikasi
harus kompatibel dengan perangkat Android dan iOS serta dirancang dengan
antarmuka yang user-friendly dan intuitif untuk memudahkan penggunaan. |
|
KnF105 |
Sistem
harus mengoptimalkan penggunaan memori agar tidak terjadi lag atau crash
selama proses pengambilan data lokasi dan transaksi absensi secara real-time. |
|
KnF106 |
Protokol
HTTP/HTTPS harus diterapkan untuk menjamin keamanan dan kecepatan transfer
data antara client dan server. |
0 Comments