DOKUMEN GL- 01

TOPIK SUBSISTEM PRESENSI MAHASISWA

Program Studi

Teknik Informatika – DRPL RD

Kelompok 3

Dimas Aqshal Primadaffa 119140140

Khoirun Nisa Samrotul Z 119140202
Pipit Nizaria 119140155
Salsabilla Putri Dyani 119140065
Joy Aloita Sembiring 119140036

Tanggal

09 Maret 2021

TEKNIK INFORMATIKA
INSTITUT TEKNOLOGI SUMATERA
LAMPUNG SELATAN
2020/2021
 Daftar Isi

BAB I .............................................................................................................................................. 5

PENDAHULUAN .......................................................................................................................... 5

1.1 Tujuan ................................................................................................................................... 5

1.2 Lingkup Masalah .................................................................................................................. 5

1.3 Definisi, Akronim, dan Singkatan ........................................................................................ 6

1.4 Referensi ............................................................................................................................... 7

1.5 Deskripsi umum (Overview)................................................................................................. 7

BAB II............................................................................................................................................. 9

DESKRIPSI KESELURUHAN ...................................................................................................... 9

2.1 Prespektif Produk .................................................................................................................. 9

2.2 Fungsi Produk ...................................................................................................................... 9

2.3 Karakteristik Pengguna ....................................................................................................... 10

2.4 Batasan-batasan................................................................................................................... 11

2.5 Asumsi dan Ketergantungan ............................................................................................... 11

BAB III ......................................................................................................................................... 12

KEBUTUHAN KHUSUS ............................................................................................................. 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 Kebutuhan Fungsional ........................................................................................................ 13

3.2.1 User Class 1 ................................................................................................................. 13

3.2.2 User Class 2 ................................................................................................................. 14

3.2.3 User Class 3 ................................................................................................................. 15

3.2.4 Kebutuhan Non-Fungsional ......................................................................................... 16

3.3 Kebutuhan Performansi ...................................................................................................... 17

3.4 Batasan Perancangan .......................................................................................................... 17

3.5 Atribut Sistem Perangkat Lunak ......................................................................................... 18

3.6 Model Analisis .................................................................................................................... 19

3.6.1 Diagram Use case ........................................................................................................ 19

3.6.2 Diagram Kelas ............................................................................................................. 22

3.6.3 Diagram Sekuens ......................................................................................................... 23

3.7 Data Flow Diagram ............................................................................................................. 24

3.7.1 DFD Diagram Konteks ................................................................................................ 25

3.7.2 DFD Level 0 ................................................................................................................ 25

3.7.3 DFD Level 1 ................................................................................................................ 26

3.7.4 DFD Level 2 ................................................................................................................ 27

Lampiran ....................................................................................................................................... 28
Indeks ............................................................................................................................................ 29
 BAB I

PENDAHULUAN

1.1 Tujuan

Dikumen ini berisi Spesifikasi Kebutuhan Perangkat Lunak (SKPL) untuk aplikasi Sistem
Presensi mahasiswa ITERA. Penulisan dokumen ini bertujuan sebagai binformasierikut :

1. Mendefinisikan dan menjelaskan hal-hal yang diperlukan dalam pengembangan aplikasi

presensi mahasiswa.
2. Memperjelas detail Spesifikasi kebutuhan perangkat lunak dan urnag lingkup kerja yang
akan dilakukan dalam pengembangan aplikasi presensi beserta kendala-kendala yang
mungkin dihadapi.
3. Mendefinisikan dan mendeskripsikan secara global aplikasi presensi mahasiswa yang akan
dikembangkan, yang menggambarkan fungsionalitas, performanis, batasan perancangan,
atribut, serta antarmuka eksternal aplikasi yang akan diimplementasikan.
4. Mempermudah proses pengembangan aplikasi presensi mahasiswa pada tahap-tahap
berikutnya.
Adapaun pihak-pihak yang berkepentingan dan berhak menggunakan dokumen SKPL ini
adalah :
1. Anggota kelompok DRPL 3 sebagai developer. Dokumen ini akan digunakan sebagai
acuan dan pedoman dalam mengembangkan aplikasi presensi mahasiswa.
2. Bagian Administrasi ITERA sebagai admin yang akan melakukan validasi dan pengecekan
terhadap kebutuhan-kebutuhan user yang akan diimplementasikan oleh pengembang.

1.2 Lingkup Masalah

Permasalahan yang diangkat adalah sebagai berikut :

1. Bagaimana mengatasi sistem presensi manual.

 2. Bagaimana menampilan informasi jadwal matakuliah, presensi selama smeinggu, dan
peringatan ketika mahasiswa melewati toleransi keetidakhadiran.
3. Bagaimana manfaat, cara kerja, dan pemakaian aplikasi yang akan dibuat.

1.3 Definisi, Akronim, dan Singkatan

Tabel 1.3.1 Definisi, Singkatan,dan Akronim

Istilah, Akronim, dan Singkatan Keterangan

SKPL Spesifikasi Kebutuhan Perangkat Lunak

adalah dokumen hasil analisis yang berisi
spesfifikasi kebutuhan user.

IEEE Institute of Electrical and Electronics

Engineers adalah standar internasional untuk
pengembangan dan rancangan perangkat
lunak.

QR Code QR Code merupakan kode matriks atau

barcode dua dimensi yang berasal dari kata
“Quick Response”, dimana isi kode dapat
diuraikan dengan cepat dan tepat.
1.4 Referensi

Template SKPL

Spesifikasi Kebutuhan Perangkat Lunak Sistem Absensi Mahasiswa STMIK Sumedang

berbasis RFID

(https://www.academia.edu/36740180/SPESIFIKASI_KEBUTUHAN_PERANGKAT_LUN
AK_Sistem_absensi_mahasiswa_STMIK_Sumedang_berbasis_RFID)

Jurnal Metodologi Penelitian

( http://digilib.uinsby.ac.id/355/5/Bab%203.pdf )

Pengertian QR Code

( https://www.jaringanprima.co.id/id/mengenal-qr-code )

1.5 Deskripsi umum (Overview)

Dokumen SKPL ini dibuat untuk memberikan informasi mengenai Spesifikasi aplikasi
presensi berbasis Android. Dokumen ini berisikan informasi sebagai berikut :

1. Deskripsi Umum Aplikasi

Deskripsi umum aplikasi meliputi deskripsi umum aplikasi presensi berbasis android
yang akan dikembangkan, fungsi utama aplikasi yang akan digunakan oleh user.
2. Deskripsi Umum Kebutuhan Aplikasi yang Akan Diimplementasikan
Deskripsi umum kebutuhan aplikasi yang akan diimplementasikan meliputi semua
informasi yang bersifat teknis yang menjaadi acuan dalam pengembangan aplikasi.
Informasi dalam dokumen SKPL ini disajikan dan diorganisasikan sesuai standard IEEE
830-1998 dengan struktur sebagai berikut :
• BAB I.
 Berisi informasi umum yang merupakan bagian pendahuluan,yang meliputi tujuan
penulisan dokumen, lingkup masalah, definisi, istilah dan akronim, referensi, serta
deskripsi umum dokumen.
• BAB II.
Berisi deskripsi umum dari aplikasi presensi mahasiswa yang akan dikembangkan,
yang meliputi deskripsi umum aplikasi dan fungsi aplikasi presensi mahasiswa ITERA
berbasisi Android.
• BAB III.
Berisi informasi mengenai deskripsi umum kebutuhan perangkat lunak yang akan
dikembangkan. Bagian ini meliputi informasi mengenai kebutuhan antarmuka,
deskripsi fungsional, data requirement, non-fungsional requirement, Batasan
perancangan, kerunutan (tracebility), dan ringkasan kebutuhan.
 BAB II

DESKRIPSI KESELURUHAN

2.1 Prespektif Produk

Aplikasi Presensi Mahasiswa adalah perangkat lunak yang berfungsi untuk melakukan
presensi perkuliahan pada mahasiswa.Perangkat lunak ini melakukan presensi perkuliahan
dengan cara menscan kode QR perkuliahan yang telah diberi oleh dosen.Perangkat lunak ini
juga dapat menampilkan jadwal perkuliahan yang akan di manjemen oleh admin,serta
memberikan informasi terkait presensi,seperti pemberitahuan keberhasilan presensi dan
peringatan jika melakukan absen melebihi batas presensi. Aplikasi ini akan melaporkan
presensi yang telah berhasil dilakukan ke dosen,melalui perangkat smartphone.

Perangkat lunak ini dibangun berbasis android,perangkat lunak ini digunakan oleh
mahasiswa,dosen,dan terhubung dengan admin,yang akan mengolah data dan informasi pada
aplikasi ini.

2.2 Fungsi Produk

Fungsi utama pada aplikasi ini adalah sebagai berikut :

1. Melakukan presensi perkuliahan mahasiswa ,dengan melakukan scan kode QR.

2. Memudahkan dosen dalam mendata mahasiswa yang hadir dalam perkuliahan.
3. Menampilkan jadwal mata kuliah.
4. Menampilkan informasi terkait presensi,seperti memberikan peringatan jika melakukan
absen melebihi batas presensi.
2.3 Karakteristik Pengguna

Tabel 2.3.1. Kategori Karakteristik Pengguna Subsistem Presensi Kehadiran Mahasiswa

Kategori Tugas Hak Akses

Dosen Melaporkan hasil rekap • Dapat melihat daftar mahasiswa

presensi ke admin. yang presensi maupun tidak.
• Mengetahui informasi data
mahasiswa yang terdaftar
dikelasnya.
• Menyebarluaskan presensi berbasis
QR code ke kelas yang diampunya.

Mahasiswa Tepat pada waktunya saat • Scanning QR code agar dinyatakan

kegiatan presensi (tidak telat). hadir.
• Mengetahui jadwal kelas atau
matakuliah yang telah berhasil
presensi.
• Mengisi data mahasiswa

Admin Bertanggung jawab atas data • Mempunyai hak akses penuh

presensi mahasiswa dan dosen. terhadap subsistem presensi
mahasiswa.

Pada tabel 2.3.1 menjelaskan kategori karakteristik pengguna dalam menggunakan sistem
dan menjelaskan batasan terkait apa saja yang bisa mereka lakukan dan tidak lakukan terhadap
subsistem.

Berdasarkan Tabel 2.3.1 diatas,kita dapat mengetahui alasan mengapa kebutuhan

subsistem presensi diperlukan,yaitu agar mempermudah pengguna dalam menyatakan
kehadiran pada saat KBM berlangsung,maksudnya pengguna dapat mengetahui jadwal kelas
 mana saja yang telah dihadirinya dalam waktu sepekan,dan ketika presensi telah melewati
batas waktu maka pengguna mendapat notice akan hal itu.

2.4 Batasan-batasan

Pembahasan Batasan Perancangan dalam Pengembangan Perangkat Lunak ini bertujuan

untuk membatasi Pembahasan pada pokok perancangan penelitian saja, yaitu :

1. Tidak dilakukan analisa pengadaan biaya hardware dan perangkat lunak.

2. Pada tahap implementasi hanya bersifat usulan.
3. Pembatasan hanya pada perancangan data berupa jadwal mata kuliah, status kehadiran
perminggu, dan peringatan apabila melebihi batas toleransi tidak masuk kelas

2.5 Asumsi dan Ketergantungan

Ada perangkat lunak hanya bisa di jalankan di satu sistem operasi mobile ,dan ada juga di
dua bahkan lebih sistem oprasi,dalam aplikasi sistem presensi ini hanya bisa di jalankan di
sistem operasi Android hal ini akan menjadi pertimbangan supaya aplikasi bisa di jalankan di
sistem operasi lain,dan jika menggunakan aplikasi berbasis web,aplikasi bisa berjalan di semua
sistem operasi.

Aplikasi presensi ini bisa beroperasi jika smartphon memiliki koneksi internet,selain itu
karena sistem presensi yang berbasis QR maka penggunaan camera smartphon sangat di
butuhkan, penggunaan camera ini tidak lain untuk menangkap/menscan QR yang akan di beri
oleh dosen dan data hasil scanan otomatis langsung di transfer dan akan menjadi bukti
kehadiran mahasiswa.
 BAB III

KEBUTUHAN KHUSUS

3.1 Kebutuhan Antarmuka Eksternal

Sistem presensi kehadiran mahasiswa yang akan dibangun dengan aplikasi yang
berbasis smartphone/android. Kebutuhan dari pengembangan perangkat lunak
ini membutuhkan proses dengan perangkat lain. Perangkat lunak yang dikembangkan akan
dioperasikan oleh mahasiswa,dosen dan admin yang akan memanejemen fungsi dalam
perangkat lunak.

3.1.1 Antarmuka Pemakai

Perangkat lunak yang akan dikembangkan membutuhkan pengoperasian dari user sebagai
pemakai perangkat lunak.Pengoperasian yang dimaksud adalah mahasiswa menggunakan
perangkat lunak untuk presensi,dosen menyediakan kode presensi,dan admin memanejemen
data hasil presensi, mengolah jadwal perkuliahan untuk ditampilkan,serta memberikan
penjelasan terkait presensi,seperti aturan pelanggaran jika melebihi batas presensi.

Perangkat tersebut adalah sebagai berikut:

Perangkat smartphone, dibutuhkan sebagai perangkat untuk menampilkan aplikasi kepada

pemakai, smartphone mempunyai spesifikasi diantaranya:

• Smartphone mampu menginstal aplikasi presensi .

• Menampilkan tampilan perangkat lunak.
• Menscan kode presensi.
• Menampilkan informasi terkait presensi dan pemberitahuan tertentu.

Untuk dosen, smartphone yang diinstal aplikasi ini :

• Dapat mengirim dan menampilkan kode presensi ke mahasiswa.

• Menyimpan data hasil presensi yang telah dilakukan mahasiswa.
 Sedangkan untuk admin yaitu :

• Mengolah data hasil presensi mahasiswa.

• Menampilkan jadwal mata kuliah.
• Membuat serta menampilkan informasi terkait presensi mahasiswa.

3.1.2 Antarmuka Perangkat Keras

Antarmuka perangkat keras yang dibutuhkan dalam perangkat lunak ini yaitu dari
smartphone itu sendiri berupa :

• Kamera smartphone, yang akan digunakan untuk men-scan kode presensi yang telah
diberikan dosen, sehingga kamera harus dapat digunakan dengan baik agar tidak
terjadi kesalahan dalam scan kode presensi, yang mengakibatkan kegagalan presensi.

3.1.3 Antarmuka Perangkat Lunak

Antarmuka perangkat lunak yang dibutuhkan dalam perangkat lunak ini meliputi:

• Sistem Operasi Android.

3.1.4 Antarmuka Komunikasi

Antarmuka komunikasi perangkat lunak pada presensi mahasiswa ini yaitu berbasis
android.

3.2 Kebutuhan Fungsional

3.2.1 User Class 1

Fitur pertama yang dibuat adalah fitur yang dapat digunakan oleh admin.

3.2.1.1 Pendahuluan / Guna Dari Purpose

Fitur ini berfungsi untuk admin dapat mendata mahasiswa yang ada di Itera, mendata
nama-nama dosen Itera, mendata jadwal mata kuliah, mendata kehadiran mahasiswa,
3.2.1.2 Urutan Stimulus/Response

a) Pemberitahuan mahasiswa telah absen

b) Menampilkan jadwal matakuliah mahasiswa berkaitan
c) Menampilkan daftar kehadiran mahasiswa bersangkutan
d) Menampilkan peringatan jika mahasiswa yang telah presensi tersebut melewati
batas toleransi kehadiran

3.2.1.3 Kebutuhan Fungsional Yang Berhubungan

3.2.1.3.1 Kebutuhan fungsional 1

Mendata nama mahasiswa

3.2.1.3.2 Kebutuhan fungsional 2

Mendata mata kuliah

3.2.1.3.3 Kebutuhan fungsional 3

Mendata nama dosen

3.2.1.3.4 Kebutuhan fungsional 4

Mendata kehadiran mahasiswa

3.2.1.4 Pesan (komunikasi yang diterima/dikirim)

Ketika mahasiswa telah melakukan presensi dengan QR Code dan berhasil, akan
dikeluarkan data berupa jadwal matakuliah, daftar kehadiran selama seminggu, serta peringata jika
mahasiswa sudah melewati batas toleransi.

3.2.2 User Class 2

Fitur kedua yang dibuat adalah fitur yang dapat digunakan oleh dosen
3.2.2.1 Pendahuluan / Guna Dari Purpose

Fitur ini berfungsi untuk dosen dapat melihat nama mahasiswa yang mengambil
matakuliah yang diampu olehnya, melihat daftar kehadiran mahasiswa di kelasnya, men-generate
QR Code untuk absen.

3.2.2.2 Urutan Stimulus / Respons

a) Dosen melihat daftar mahasiswa yang mengambil kelasnya

b) Dosen men-generate QR Code yang akan dibuka selama 1 jam.
c) Dosen melihat daftar mahasiswa yang telah melakukan presensi.

3.2.2.3 Kebutuhan Fungsional Yang Berhubungan

3.2.2.3.1 Kebutuhan fungsional 1

Melihat daftar mahasiswa dikelasnya.

3.2.2.3.2 Kebutuhan fungsional 2

Men-generate QR Code.

3.2.2.3.3 Kebutuhan fungsional 3

Melihat daftar mahasiswa yang telah melakukan presensi

3.2.2.4 Pesan (komunikasi yang diterima/dikirim)

Ketika mahasiswa telah berhasil melakukan presensi, nama-nama mahasiswa tersebut akan
muncul pada daftar kehadiran matakuliah terkait.

3.2.3 User Class 3

Fitur ketiga yang dibuat adalah fitut yang dapat digunakan oleh mahasiswa.

3.2.3.1 Pendahuluan / Guna Dari Purpose

Fitur ini berfungsi untuk mahasiswa dapat melakukan presensi, melihat jadwal matakuliah
yang diambil, melihat daftar kehadiran dalam seminggu, mendapat peringatan ketika melewati
batas toleransi absen.
3.2.3.2 Urutan Stimulus / Respons

a) Mahasiswa melakuan presensi via QR Code.

b) Ketika telah berhasil presensi, mahasiswa dapat melihat jadwal matakuliah, daftar
kehadiran selama seminggu, dan peringatan jika mahasiswa sudah melewati batas
toleransi ketidakhadiran.

3.2.3.3 Kebutuhan Fungsional Yang Berhubungan

3.2.3.3.1 kebutuhan fungsional 1

Melakukan presensi via QR Code.

3.2.3.3.2 kebutuhan fungsional 2

Melihat jadwal matakuliah yang diambil.

3.2.3.3.3 kebutuhan fungsional 3

Melihat daftar kehadiran selama seminggu.

3.2.3.3.4 kebutuhan fungsional 4

Melihat peringatan ketika melewati batas toleransi ketidakhadiran.

3.2.3.4 Pesan (komunikasi yang diterima/dikirim)

Ketika mahasiswa berhasil melakukan presensi, maka akan muncul layar yang berisikan
data berupa jadwal matakuliah yang diambil pada semester saat itu, daftar kehadiran selama
seminggu, dan peringatan jika mahasiswa melewati batas toleransi ketidakhadiran matakuliah saat
itu.

3.2.4 Kebutuhan Non-Fungsional

Table 3.2.4.1 Kebutuhan Non-Fungsional

SKPL-ID Requirements

SKPL- Aplikasi dapat dijalankan pada smartphone berbasis Android.

 SKPL- Mahasiswa yang dapat melakukan presensi dalam satu waktu terbatas
hanya 1000 orang.

3.3 Kebutuhan Performansi

Kebutuhan ini meliputi hal yang dapat meningkatkan sistem yang dikembangkan.Untuk
meningkatkan kinerja sistem ini dibutuhkan kriteria spesifikasi kualitas dan kuantitas yang
harus dipenuhi perangkat lunak.Kebutuhan perfomansi juga dapat menspesifikasikan
kebutuhan numerik statis dan dinamis.

Hingga saat ini sistem presensi yang dilakukan mahasiswa dan dosen dengan menggunakan
quick respon (QR) Code. Sistem ini diharapkan dapat menambahkan beberapa fitur seperti
menampilkan status kehadiran mahasiswa setelah melakukan presensi.Sistem pada perangkat
membutuhkan waktu yang cepat dalam scanning QR,semakin cepat waktu merespon maka
semakin banyak jumlah pengguna simultan seperti mahasiswa yang dapat mengakses presensi
hingga batas waktu akhir yang ditentukan oleh dosen.

98% Jumlah data presensi yang dapat diproses dalam lingkup mahasiswa yang jadwalnya
sama.yang kemudian sistem dapat menginfokan dengan menampilkan data mahasiswa dan
data mata kuliah mapun jadwal kelas yang telah dihadirinya,namun jika melewati batas akhir
presensi kehadiran,sistem akan memberikan notice ke pengguna atau presensiator.

3.4 Batasan Perancangan

Untuk memudahkan kita dalam membuat rancangan perangkat lunak maka perlu dilakukan
pembatasan

Perancangan sehingga perancangan ini menjadi lebih sederhana. Pembatasan perancangan

tersebut meliputi :

1. Tidak dilakukan analisa pengadaan biaya hardware dan perangkat lunak.

 2. Pada tahap implementasi hanya bersifat usulan.

3. Pembatasan hanya pada perancangan data berupa jadwal mata kuliah, status kehadiran
perminggu, dan peringatan apabila melebihi batas toleransi tidak masuk kelas

3.5 Atribut Sistem Perangkat Lunak

1. Software Bisa Difungsikan:

Tujuan utama prangkat lunak untuk mempermudah menyelesaikan masalah,baik

masalah yang sulit maupun mudah,dari sini seharusnya perangkat lunak harus bekerja dan
difungsikan,tidak adanya bug dalam menjalankan sistem perangkat lunak akan menjadi
salah satu nilai plus terhadap perangkat lunak tersebut

2. Software bisa di pelihara/bisa berevolusi:

Semakin tingginya kebutuhan manusia harus di barengi dengan berkembangnya

sebuah sistem yang di jalankan untuk menyokong kebutuhan tersebut,jika membuat
perangkat lunak harus memikirkan aspek evolusi dari aplikasi tersebut agar jika terjadi
perkembangan aplikasi dapat mudah di ubah tanpa harus mengulang program pembuatan
dari nol sampai aplikasi terbaru selesai.

3. Software harus efesien :

Keefesienan aplikasi sangat mempengaruhi sistem kerja aplikasi tersebut,dengan

adanya banyak fitur aplikasi akan memperlambat sistem kerja aplikasi tersebut , maka fitur"
yang tidak terlalu di perlukan harus di buang

4. Software harus diterima dengan baik:

Soft where harus mudah di fungsikan oleh user agar user bisa memakai aplikasi
dengan mudah tanpa mengalami kendala,dengan kemudahan tersebut maka aplikasi bisa
diterima dengan baik.
3.6 Model Analisis

3.6.1 Diagram Use case

3.6.1.1 Definisi Aktor

Aktor merupakan peran penting dalam suatu subsistem,aktor juga dapat disebut dengan
“pengguna” dari subsistem itu sendiri.Representasi aktor tidak hanya manusia,namun juga dapat
berupa mesin atau sistem.

Dalam sub sistem presensi kehadiran mahasiswa,aktor disini merepresentasikan

manusia,yaitu :

1. Mahasiswa
2. Dosen
3. Admin

Pada kasus ini, mahasiswa dan dosen merupakan aktor yang menggunakan sistem, dan admin ialah
aktor yang dapat merawat atau mengendalikan sistem tersebut.

3.6.1.2 Definisi Use Case 1

Use case yang terkait pada subbab ini, yaitu aktor admin, use-case yang nantinya akan
memberikan hasil untuk aktor tersebur. Maka dari itu, aktor admin dapat melakukan beberapa aksi
sebagai berikut:

1. Mendata nama mahasiswa.

2. Mendata nama dosen.
3. Mendata jadwal matakuliah.
4. Mendata kehadiran mahasiswa.

3.6.1.3 Definisi Use Case 2

Use-Case yang terkait pada subbab ini yaitu aktor Dosen, use-case yang nantinya akan
memberikan hasil untuk aktor tersebut, maka dari itu aktor dosen akan melakukan beberapa aksi,
yaitu :

1. Men-generate QR Code.
2. Melihat daftar presensi mahasiswa di kelasnya.
3. Melihat daftar mahasiswa yang mengambil kelasnya.
3.6.1.4 Definisi Use Case 3

Use-Case yang terkait pada subbab ini yaitu aktor Mahasiswa, use-case yang nantinya akan
memberikan hasil untuk aktor tersebut, maka dari itu aktor mahasiswa akan melakukan beberapa
aksi, yaitu :

1. Melakukan presensi dengan scan QR-Code.

2. Melihat jadwal presensi selama seminggu.
3. Melihat jadwal mata kuliah.
4. Mendapat peringatan lewat batas toleransi ketidakhadiran.
3.6.2 Diagram Kelas
3.6.3 Diagram Sekuens
3.6.3.1 Diagram Sekuens Sistem Presensi

3.6.3.2 Diagram Sekuens Menampilkan Data Mahasiswa

3.7 Data Flow Diagram

Kamus data 1

a) Nama arus data : hasil scan QR code

b) Bentuk data : descode kode matriks
c) Arus data : proses 1.1 -mahasiswa
1.1 -sistem
d) Penjelasan : hasil scan QR code untuk di-decode oleh sistem.
e) Periode : setiap kali mahasiswa melakukan presensi
f) Volume : volume rata-rata tiap hari adalah 700
volume puncak adalah 1000
g) Struktur data terdiri atas item data :
• Decode kode matriks

Kamus data 2

a) Nama arus data : data mahasiswa

b) Alias : mahasiswa yang presensi, waktu presensi, mata kuliah, jadwal presensi, Riwayat
presensi selama seminggu.
c) Bentuk data : dokumen soft file
d) Arus data : proses 1.1 - server
proses 1.2 - Database
proses 1.2.1 - Database
proses 1.2.2 - mahasiswa, dosen
e) Penjelasan : setelah server men-decode QR code, server melanjutkan data mahasiswa ke
database untuk disimpan nama, waktu presensi, dan matakuliah. Kemudian database secara
otomatis mengeluarkan nama mahasiswa, jadwal kuliah, Riwayat presensi selama
seminggu ke mahasiswa, lalu daftar nama mahasiswa yang presensi ke dosen.
f) Periode : setiap QR code di-generate oleh dosen
g) Volume : volume rata-rata tiap hari adalah 700, volume puncak adalah 1000
h) Struktur data terdiri atas item data :
• Nama mahasiswa
 • Jadwal kuliah
• Riwayat presensi selama seminggu

3.7.1 DFD Diagram Konteks

3.7.2 DFD Level 0

3.7.3 DFD Level 1
3.7.4 DFD Level 2
Lampiran
Indeks