System Requirements Document for absensi-pkl-siswa

1. Introduction

absensi-pkl-siswa adalah aplikasi web absensi untuk siswa Praktik Kerja Lapangan (PKL). Produk ini menyediakan dua sisi pengalaman yang saling melengkapi:

• Sisi siswa — tampilan web absensi online dengan menu yang lengkap, tempat siswa mencatat kehadiran PKL harian mereka.
• Sisi admin — web admin dengan tampilan mengikuti template SB Admin, tempat admin memantau dan mengelola data absensi siswa.

Inti produk adalah logbook kehadiran harian: satu hari, satu absen. Sistem menyimpan setiap catatan absensi siswa ke database MySQL melalui API Express.js, dan menerapkan validasi keras sehingga siswa tidak bisa absen dua kali di hari yang sama.

Audiens: siswa SMK yang sedang menjalani PKL (16–18 tahun) dan guru/koordinator PKL yang mengelola data absensi mereka.

2. System Overview

Aplikasi terdiri dari frontend web (tampilan absensi online untuk siswa dan web admin bergaya SB Admin), API backend Express.js, dan database MySQL sebagai penyimpanan persisten data absensi.

Aktor aktif (manusia):

• Siswa (Student) — melakukan absensi PKL harian melalui tampilan web absensi.
• Admin — memantau dan mengelola catatan absensi siswa melalui web admin.

Aktor non-persona: API Express.js (layanan backend), database MySQL (penyimpanan), dan template SB Admin (referensi visual/struktur untuk area admin).

Perilaku yang diterima saat ini:

• Absensi online harian oleh siswa, disimpan ke MySQL melalui API Express.js.
• Validasi keunikan absensi per siswa per hari — percobaan absen kedua di hari yang sama ditolak.
• Tampilan web absensi online dengan menu lengkap.
• Web admin dengan tampilan seperti template SB Admin untuk memantau dan mengelola data absensi.

Pengecualian sempit: Tidak ada fitur di luar absensi PKL, pengelolaan data absensi oleh admin, dan akses akun yang diperlukan agar kedua alur tersebut dapat dijalankan. Tidak ada modul kategori produk lain (misalnya penggajian, penilaian akademik, atau manajemen kurikulum) yang ditambahkan.

2a. Product Interpretation and Delivery Boundary

Kepemilikan delivery dan akses. Aplikasi ini dimiliki dan dijalankan sendiri (first-party). Siswa membuat akun mereka sendiri melalui pendaftaran mandiri, lalu memverifikasi kembali melalui Login untuk mengakses fungsi absensi. Admin harus diprovisikan/diotorisasi sebagai peran admin sebelum dapat mengakses Dashboard dan pengelolaan absensi. Halaman Landing bersifat anonim dan menjelaskan aplikasi sebelum akses terlindungi.

Batas saat ini vs. masa depan. Seluruh perilaku yang dijelaskan dalam dokumen ini adalah current (delivery_horizon: current). Tidak ada fitur masa depan yang dinyatakan dalam sumber; tidak ada bagian future yang dibuat.

Batas teknologi. API wajib dibangun dengan Express.js; data absensi wajib disimpan ke database MySQL. Tampilan web admin wajib mengikuti template SB Admin (struktur sidebar, kartu, tabel) — namun dengan skin visual yang ditentukan oleh Creative Direction (lihat §6–§8), bukan default biru-putih Bootstrap.

2b. Source Content Inventory

Tidak ada reference directive dengan uses: content_source. Bagian ini sengaja dihilangkan.

2c. Page Content and Component Coverage

Landing

• Informasi/state: Penjelasan aplikasi Absensi PKL, pengguna yang dilayani (siswa PKL dan admin), dan fungsi absensi online. Ditampilkan dalam keadaan anonim (belum login).
• Aksi utama: ABSEN SEKARANG (mengarahkan ke alur absensi; jika belum login, mengarah ke Login/Sign Up), MASUK SEBAGAI ADMIN (mengarah ke Login).
• Aksi pendukung: Navigasi ke Login dan Sign Up.
• Entitas domain: Aplikasi, peran pengguna (Siswa, Admin), fungsi absensi.
• Tanggung jawab komponen: Hero dua-bagian (wordmark + pernyataan + dua tombol), pita hazard-stripe sebagai pembatas, badge stamp 'PKL', fotografi halftone-duotone tempat kerja.
• State: Loading (aset hero), empty (tidak berlaku — konten statis), success (halaman tampil), error (fallback teks jika aset gambar gagal dimuat), recovery (tombol tetap dapat diklik tanpa aset).

Login

• Informasi/state: Form verifikasi kembali untuk Siswa dan Admin. Akses: none (anonim).
• Aksi utama: Masuk dengan kredensial.
• Aksi pendukung: Navigasi ke Sign Up (untuk siswa yang belum punya akun).
• Entitas domain: Akun (Siswa/Admin), sesi.
• Tanggung jawab komponen: Form login (field identitas + kata sandi), tombol submit, pesan error, tautan ke Sign Up.
• State: Loading (saat submit), empty (field kosong), success (dialihkan ke Attendance untuk siswa / Dashboard untuk admin), error (kredensial salah — pesan jelas), recovery (form tetap terisi, dapat dicoba ulang).

Sign Up

• Informasi/state: Form pendaftaran mandiri untuk Siswa. Akses: none (anonim).
• Aksi utama: Membuat akun siswa.
• Aksi pendukung: Navigasi ke Login.
• Entitas domain: Akun siswa (identitas, kredensial).
• Tanggung jawab komponen: Form pendaftaran, validasi input, tombol submit, pesan error, tautan ke Login.
• State: Loading (saat submit), empty (field kosong), success (akun dibuat, diarahkan ke Login atau langsung ke Attendance), error (input tidak valid / akun sudah ada), recovery (form tetap terisi).

Attendance

• Informasi/state: Halaman absensi harian siswa. Menampilkan tanggal hari ini, status absensi hari ini (belum absen / sudah absen), dan hasil validasi. Akses: login (siswa).
• Aksi utama: ABSEN SEKARANG — mencatat kehadiran hari ini.
• Aksi pendukung: Melihat riwayat absensi pribadi, navigasi menu absensi online yang lengkap.
• Entitas domain: Catatan absensi (siswa, tanggal, waktu, status), status kehadiran.
• Tanggung jawab komponen: Tombol stamp fisik (2px border ink, 3px hard shadow), badge hasil stamp (HADIR — 07:42 atau SUDAH ABSEN HARI INI), panel ruled-paper, riwayat absensi.
• State: Loading (memuat status hari ini), empty (belum ada absensi hari ini — tombol aktif), success (badge HADIR — HH:MM muncul dengan motion stamp), error (validasi duplikat — badge orange SUDAH ABSEN HARI INI; atau kegagalan API — pesan error dan tombol dapat dicoba ulang), recovery (tombol kembali aktif jika gagal; tetap nonaktif jika sudah absen).

Dashboard

• Informasi/state: Ringkasan area admin — jumlah kehadiran hari ini, statistik absensi, dan titik masuk menu pengelolaan. Akses: role_restricted (admin).
• Aksi utama: Navigasi ke menu pengelolaan (Data Siswa, Absensi, Rekap, Laporan, Pengaturan).
• Aksi pendukung: Melihat ticker/marquee jumlah absensi hari ini, breadcrumb, user chip.
• Entitas domain: Catatan absensi agregat, data siswa, periode rekap.
• Tanggung jawab komponen: Sidebar denim 260px dengan nav bergrup, top bar dengan breadcrumb dan user chip, stat cards bergaya ledger panel, tabel absensi (ruled rows, sticky header denim, zebra striping, tabular numerals), badge-stamp section headers, hazard-stripe divider.
• State: Loading (memuat statistik dan tabel), empty (belum ada data absensi — pesan kosong yang jelas), success (statistik dan tabel tampil), error (kegagalan API — pesan error dan opsi muat ulang), recovery (muat ulang data).

3. Functional Requirements

FR-01 — Absensi online harian siswa

As a Siswa (Student) I should mencatat kehadiran PKL harian saya melalui tampilan web absensi online so that kehadiran saya tercatat untuk hari itu.

• Provenance: explicit
• Aktor: Siswa (Student)
• Trigger/input: Siswa membuka halaman Attendance dan menekan ABSEN SEKARANG.
• Hasil/state yang dapat diamati: Catatan absensi tersimpan ke database MySQL melalui API Express.js; badge HADIR — HH:MM muncul dengan motion stamp.
• Access state: login (siswa)
• Failure/recovery: Jika API gagal, pesan error ditampilkan dan tombol dapat dicoba ulang.
• Continuation: Siswa dapat melihat riwayat absensi pribadinya dan kembali ke halaman absensi pada hari berikutnya.

FR-02 — Validasi tidak bisa absen dua kali di hari yang sama

As a Sistem I should menolak percobaan absensi kedua oleh siswa yang sama pada hari yang sama so that setiap siswa hanya memiliki satu catatan absensi per hari.

• Provenance: explicit
• Aktor: Siswa (Student) sebagai pemrakarsa; sistem sebagai penegak validasi.
• Trigger/input: Siswa menekan ABSEN SEKARANG padahal sudah ada catatan absensi untuk hari itu.
• Hasil/state yang dapat diamati: Percobaan ditolak; badge orange SUDAH ABSEN HARI INI ditampilkan; tidak ada catatan baru yang dibuat di database.
• Access state: login (siswa)
• Failure/recovery: Siswa melihat status bahwa ia sudah absen hari ini; tombol absen tidak lagi menghasilkan catatan baru.
• Continuation: Siswa dapat kembali besok untuk absen hari berikutnya.

FR-03 — Penyimpanan data absensi ke MySQL melalui API Express.js

As a Sistem I should menyimpan setiap catatan absensi siswa ke database MySQL melalui API yang dibangun dengan Express.js so that data absensi tersimpan secara persisten.

• Provenance: explicit
• Aktor: API Express.js (non-persona), database MySQL (non-persona).
• Trigger/input: Permintaan absensi yang valid dari halaman Attendance.
• Hasil/state yang dapat diamati: Baris catatan absensi baru tersimpan di MySQL.
• Access state: Dipicu oleh aksi siswa yang sudah login.
• Failure/recovery: Kegagalan koneksi database atau API menghasilkan respons error yang ditampilkan ke siswa.
• Continuation: Data tersedia untuk dibaca oleh admin di Dashboard.

FR-04 — Tampilan web absensi online dengan menu lengkap

As a Siswa (Student) I should menggunakan tampilan web absensi online dengan menu yang lengkap so that saya dapat menjalankan absensi dan melihat informasi terkait dengan mudah.

• Provenance: explicit
• Aktor: Siswa (Student)
• Trigger/input: Siswa membuka aplikasi web absensi.
• Hasil/state yang dapat diamati: Tampilan web absensi online dengan menu lengkap tersedia dan dapat digunakan.
• Access state: login (siswa) untuk fungsi absensi; Landing anonim.
• Failure/recovery: Jika halaman gagal dimuat, siswa dapat memuat ulang.
• Continuation: Siswa dapat berpindah antar menu absensi online.

FR-05 — Web admin bergaya SB Admin

As an Admin I should menggunakan web admin dengan tampilan seperti template SB Admin so that saya dapat memantau dan mengelola data absensi siswa dengan antarmuka yang familiar dan padat informasi.

• Provenance: explicit
• Aktor: Admin
• Trigger/input: Admin membuka Dashboard setelah login.
• Hasil/state yang dapat diamati: Web admin tampil dengan struktur SB Admin (sidebar, kartu, tabel) yang di-skin sesuai Creative Direction.
• Access state: role_restricted (admin)
• Failure/recovery: Jika data gagal dimuat, pesan error dan opsi muat ulang ditampilkan.
• Continuation: Admin dapat menavigasi menu pengelolaan.

FR-06 — Pendaftaran mandiri akun siswa

As a Siswa (Student) I should membuat akun melalui pendaftaran mandiri so that saya dapat melakukan absensi.

• Provenance: required_inference
• Aktor: Siswa (Student)
• Trigger/input: Siswa membuka Sign Up dan mengisi form pendaftaran.
• Hasil/state yang dapat diamati: Akun siswa dibuat; siswa dapat login.
• Access state: none (anonim)
• Failure/recovery: Input tidak valid atau akun sudah ada menghasilkan pesan error; form tetap terisi.
• Continuation: Siswa diarahkan ke Login (atau langsung ke Attendance) untuk memulai absensi.

FR-07 — Verifikasi kembali melalui Login

As a Siswa (Student) atau Admin I should memverifikasi kembali melalui Login so that saya dapat mengakses fungsi terlindungi sesuai peran saya.

• Provenance: required_inference
• Aktor: Siswa (Student), Admin
• Trigger/input: Pengguna memasukkan kredensial di halaman Login.
• Hasil/state yang dapat diamati: Sesi dibuat; siswa diarahkan ke Attendance, admin diarahkan ke Dashboard.
• Access state: none (anonim) untuk halaman Login itu sendiri.
• Failure/recovery: Kredensial salah menghasilkan pesan error; form tetap terisi.
• Continuation: Pengguna melanjutkan ke fungsi sesuai perannya.

FR-08 — Provisi/otorisasi akun admin

As a Sistem I should memastikan akun admin diprovisikan atau diotorisasi sebagai peran admin sebelum mengakses Dashboard dan pengelolaan absensi so that hanya admin yang dapat mengelola data absensi.

• Provenance: required_inference
• Aktor: Admin (diprovisikan), sistem (penegak).
• Trigger/input: Admin login dan mencoba mengakses Dashboard.
• Hasil/state yang dapat diamati: Akses diberikan hanya jika akun berperan admin; jika tidak, akses ditolak.
• Access state: role_restricted (admin)
• Failure/recovery: Akun tanpa peran admin tidak dapat mengakses Dashboard.
• Continuation: Admin yang sah dapat menggunakan menu pengelolaan.

FR-09 — Ketersediaan API Express.js dan koneksi MySQL

As a Sistem I should menyediakan API Express.js dan koneksi database MySQL so that data absensi dapat disimpan secara persisten.

• Provenance: required_inference
• Aktor: API Express.js, database MySQL (non-persona).
• Trigger/input: Permintaan dari frontend.
• Hasil/state yang dapat diamati: API merespons dan database dapat dibaca/ditulis.
• Access state: Internal (dipicu oleh aksi pengguna terautentikasi).
• Failure/recovery: Kegagalan koneksi menghasilkan respons error yang dapat ditangani frontend.
• Continuation: Operasi absensi dan pembacaan data admin berjalan.

FR-10 — Validasi keunikan absensi per siswa per hari pada alur penyimpanan

As a Sistem I should menerapkan validasi keunikan absensi per siswa per hari pada alur penyimpanan so that percobaan kedua ditolak di tingkat data.

• Provenance: required_inference
• Aktor: API Express.js (penegak), database MySQL (penyimpanan).
• Trigger/input: Permintaan penyimpanan absensi.
• Hasil/state yang dapat diamati: Hanya satu baris absensi per siswa per hari yang tersimpan; percobaan kedua ditolak.
• Access state: Internal (dipicu oleh aksi siswa yang sudah login).
• Failure/recovery: Penolakan mengembalikan respons yang ditampilkan sebagai badge SUDAH ABSEN HARI INI.
• Continuation: Siswa dapat absen lagi pada hari berikutnya.

4. User Personas

Siswa (Student)

Konteks produk: Siswa SMK (16–18 tahun) yang sedang menjalani PKL di lokasi kerja selama beberapa bulan. Mereka membawa logbook kehadiran harian dan perlu mencatat kehadiran sekali sehari melalui web absensi online.

Tujuan utama: Mencatat kehadiran PKL harian sekali per hari; berhasil berarti absensi tersimpan ke database dan sistem menolak percobaan absen kedua di hari yang sama.

Tanggung jawab yang diterima:

• Membuat akun melalui pendaftaran mandiri (FR-06).
• Login untuk mengakses fungsi absensi (FR-07).
• Melakukan absensi harian melalui halaman Attendance (FR-01).
• Menerima hasil validasi — termasuk penolakan jika sudah absen hari ini (FR-02).
• Menggunakan tampilan web absensi online dengan menu lengkap (FR-04).

Input/keputusan: Menekan ABSEN SEKARANG; memutuskan kapan absen pada hari itu; menafsirkan badge hasil (HADIR — HH:MM atau SUDAH ABSEN HARI INI).

Interaksi dengan peserta lain: Berinteraksi dengan sistem (API Express.js dan MySQL) yang menyimpan absensinya; data absensinya kemudian dibaca oleh Admin.

Keberhasilan yang dapat diamati: Badge HADIR — HH:MM muncul setelah absensi berhasil; percobaan kedua menampilkan SUDAH ABSEN HARI INI tanpa membuat catatan baru.

Yang membedakan peran ini: Siswa adalah satu-satunya aktor yang menghasilkan catatan absensi; ia bekerja sekali sehari dengan satu keputusan tunggal (absen atau tidak), dan menerima umpan balik langsung berupa stamp.

Admin

Konteks produk: Guru/koordinator PKL yang mengelola data absensi siswa melalui web admin bergaya SB Admin. Ia bekerja dengan tabel padat dan perlu membaca data dengan cepat.

Tujuan utama: Memantau dan mengelola catatan absensi siswa yang tersimpan di database MySQL melalui menu admin yang lengkap.

Tanggung jawab yang diterima:

• Login dan diprovisikan/diotorisasi sebagai admin (FR-07, FR-08).
• Mengakses Dashboard dan menu pengelolaan (FR-05).
• Memantau catatan absensi siswa.

Input/keputusan: Menavigasi menu (Dashboard, Data Siswa, Absensi, Rekap, Laporan, Pengaturan); membaca statistik dan tabel absensi.

Interaksi dengan peserta lain: Membaca data absensi yang dihasilkan oleh Siswa; berinteraksi dengan sistem (API Express.js dan MySQL).

Keberhasilan yang dapat diamati: Statistik dan tabel absensi tampil dengan benar; data absensi siswa dapat dipantau dan dikelola.

Yang membedakan peran ini: Admin adalah pembaca dan pengelola data, bukan penghasil catatan absensi. Ia bekerja dengan volume data (banyak siswa, banyak hari) dan membutuhkan kepadatan informasi serta navigasi bergrup, bukan alur satu-keputusan seperti siswa.

5. Core User Flows

Flow A — Siswa mendaftar dan melakukan absensi pertama

1. Konteks awal: Siswa belum memiliki akun dan membuka halaman Landing (anonim).
2. Siswa membaca penjelasan aplikasi dan menekan ABSEN SEKARANG.
3. Karena belum login, siswa diarahkan ke Sign Up.
4. Siswa mengisi form pendaftaran mandiri dan mengirimkannya.
5. Hasil yang dapat diamati: Akun siswa dibuat. Jika input tidak valid atau akun sudah ada, pesan error ditampilkan dan form tetap terisi (recovery).
6. Siswa diarahkan ke Login (atau langsung ke Attendance).
7. Siswa memasukkan kredensial di Login.
8. Hasil yang dapat diamati: Sesi dibuat; siswa diarahkan ke Attendance.
9. Di Attendance, siswa melihat status hari ini (belum absen) dan menekan ABSEN SEKARANG.
10. Hasil yang dapat diamati: API Express.js menyimpan catatan absensi ke database MySQL; badge HADIR — HH:MM muncul dengan motion stamp.
11. Langkah berikutnya: Siswa dapat melihat riwayat absensi pribadinya dan kembali besok untuk absen hari berikutnya.

Flow B — Siswa mencoba absen kedua di hari yang sama

1. Konteks awal: Siswa sudah login dan sudah memiliki catatan absensi untuk hari ini.
2. Siswa membuka Attendance dan menekan ABSEN SEKARANG lagi.
3. Hasil yang dapat diamati: Validasi keunikan per siswa per hari menolak percobaan; badge orange SUDAH ABSEN HARI INI ditampilkan; tidak ada catatan baru di database.
4. Failure/recovery: Siswa memahami bahwa ia sudah absen hari ini; tombol tidak menghasilkan catatan baru.
5. Langkah berikutnya: Siswa kembali besok untuk absen hari berikutnya.

Flow C — Siswa gagal absen karena kegagalan API

1. Konteks awal: Siswa sudah login di Attendance dan belum absen hari ini.
2. Siswa menekan ABSEN SEKARANG.
3. Hasil yang dapat diamati: API atau koneksi database gagal; pesan error ditampilkan.
4. Failure/recovery: Tombol kembali aktif dan siswa dapat mencoba ulang.
5. Langkah berikutnya: Setelah berhasil, badge HADIR — HH:MM muncul.

Flow D — Admin login dan memantau data absensi

1. Konteks awal: Admin memiliki akun yang telah diprovisikan/diotorisasi sebagai peran admin, dan membuka Login (anonim).
2. Admin memasukkan kredensial.
3. Hasil yang dapat diamati: Sesi dibuat; karena akun berperan admin, admin diarahkan ke Dashboard. Jika akun tidak berperan admin, akses ke Dashboard ditolak (recovery: kembali ke Login).
4. Di Dashboard, admin melihat statistik absensi hari ini dan tabel catatan absensi siswa.
5. Hasil yang dapat diamati: Statistik dan tabel tampil; ticker jumlah absensi hari ini berjalan (atau statis di bawah prefers-reduced-motion).
6. Admin menavigasi menu pengelolaan (Data Siswa, Absensi, Rekap, Laporan, Pengaturan) melalui sidebar.
7. Failure/recovery: Jika data gagal dimuat, pesan error dan opsi muat ulang ditampilkan.
8. Langkah berikutnya: Admin melanjutkan pemantauan atau pengelolaan data absensi.

6. Visuals Colors and Theme

Muse: Aaron Draplin. Headline: Field-notes honesty for a school internship logbook — thick strokes, kraft paper, plain talk.

Bahasa visualnya adalah logbook kerja: kertas kraft, panel bergaris, label all-caps, stamp karet, dan fotografi halftone peralatan kerja. Ini memberi halaman absensi siswa martabat sebuah buku catatan lapangan, dan memberi area admin kepadatan tabular yang bisa dipindai cepat oleh guru.

Palet (light mode)

Proporsi: ~60% kraft, 25% cream, 10% denim, 5% orange. Orange harus tetap langka agar selalu berarti "lakukan ini" atau "ini terjadi". Body text di cream dan kraft harus melewati 4.5:1; jangan pernah menaruh body copy dalam mustard atau orange di atas kraft.

Tipografi

• Headings: Alfa Slab One — hanya sebagai slab badge face, tidak pernah sebagai running text. All-caps, tracking -0.01em, weight heavy. Display size untuk hero; badge size 14–18px dengan letter-spacing: 0.12em untuk section stamps seperti ABSENSI HARIAN dan DATA SISWA.
• Body: Oswald — condensed gothic untuk semua teks lain. Nav dan table headers: Oswald 600, uppercase, letter-spacing: 0.08em, 12–13px. Body copy: Oswald 400, 16–17px, line-height: 1.65.
• Numerals: font-variant-numeric: tabular-nums dengan tracking sedikit lebih lebar agar kolom sejajar seperti ledger tercetak.
• Skala: modular 1.25 pada base 17px — 17 / 21 / 26 / 33 / 41 / 51 / 64 / 80. Hero display: clamp(44px, 9vw, 104px) untuk wordmark, clamp(28px, 5vw, 52px) untuk pernyataan pendukung. Section stamps 14–18px. Table dan form text minimum 16px. Admin stat numerals: clamp(32px, 4vw, 48px).

Shape language

• Hard edges dan honest rectangles. Card radius maksimum 4px.
• Setiap panel digambar dengan border 2px solid ink atau denim, plus hard offset shadow 4px dalam #C9B896 (bukan blur lembut) — kartu terlihat tercetak di atas lembaran.
• Tombol adalah chunky rectangles dengan border 2px ink dan hard shadow 3px ke bawah yang kolaps ke 0 saat ditekan.
• Badge dan status stamps adalah lingkaran atau rounded-rectangle stamps dengan border 2px dan rotasi -2deg.
• Ruled lines (1px ink pada 30% opacity) memisahkan setiap baris tabel dan setiap grup field form.
• Tidak ada yang glassy, tidak ada yang glow, tidak ada yang float.

Layout

• Grid 12 kolom dengan struktur terlihat: top bar denim 8px membawa wordmark sekolah/aplikasi dan date stamp.
• Area siswa: kolom tunggal terpusat maksimum 720px dengan gutter 32px — halaman absensi terasa seperti halaman buku catatan.
• Area admin: mengikuti information architecture SB Admin — sidebar denim tetap 260px di kiri dengan nav bergrup (Dashboard, Data Siswa, Absensi, Rekap, Laporan, Pengaturan), top bar dengan breadcrumb dan user chip, area konten berisi panel bergaris bertumpuk.
• Stat cards: 4-up di desktop, 2-up di 768px, 1-up di 375px.
• Tabel adalah komponen admin utama: full-width, ruled rows, sticky header denim, zebra striping dua tone kertas, tabular numerals rata kanan untuk waktu dan jumlah.
• Section headers adalah badge-stamps dengan horizontal rule dari badge ke tepi kanan container.
• Di 375px: sidebar kolaps menjadi hamburger drawer, tabel menjadi horizontally scrollable dengan kolom pertama (nama/NIS) frozen, hero headline menumpuk ke ukuran mobile tanpa overflow.

Imagery

• Ikonografi vektor garis tebal (2px stroke, squared caps): clipboard, hard hat, wrench, clock face, stamp, folder, chart sebagai ruled bars.
• Hero menggunakan satu fotografi halftone tempat kerja nyata (meja bengkel, meja gudang, atau meja kantor dengan notebook dan pena) dalam duotone denim/kraft, bleed ke tepi kanan viewport.
• Elemen dekoratif: badge circular PKL 2025, hazard-stripe band 12px sebagai divider antar section admin utama, ruled-paper texture 4% opacity di belakang form absensi siswa.
• Tidak ada 3D render, gradient blob, stock photo orang tersenyum, atau glass panel.

7. Signature Design Concept

Konsep: Landing sebagai poster tercetak dua-bagian.

Hero Landing adalah poster tercetak, bukan stack SaaS terpusat:

• Kiri 58% viewport: field kertas kraft dengan rule ink 2px full-bleed di belakang type. Wordmark ABSENSI PKL dalam Alfa Slab One pada clamp(44px, 9vw, 104px), ditumpuk dua baris, flush left, ink di atas kraft. Baris kedua SISWA di-knockout cream di dalam blok denim solid yang bleed ke tepi kiri.
• Di bawahnya: satu kalimat dalam Oswald 400 pada 21px — "Catat kehadiran PKL-mu sekali sehari. Satu hari, satu absen."
• Di bawahnya lagi: dua tombol chunky berdampingan di desktop dan bertumpuk di 375px — ABSEN SEKARANG dalam safety orange dengan border ink dan hard shadow, dan MASUK SEBAGAI ADMIN sebagai outlined denim button.
• Kanan 42%: fotografi halftone duotone meja kerja dengan notebook, dipotong keras di tepi viewport, dimiringkan -1.5deg, dengan badge stamp circular PKL menimpa sudut kiri atasnya.
• Pita hazard-stripe 12px berjalan di bagian paling bawah hero sebagai transisi ke section berikutnya.

Tidak ada gradient, tidak ada glow, tidak ada floating card, tidak ada blok teks terpusat. Konsep ini hanya menyusun ulang konten, state, dan kontrol yang sudah diterima — tidak menambah perilaku, halaman, atau destinasi baru.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: Poster dua-bagian — wordmark ABSENSI PKL / SISWA di kiri, fotografi halftone duotone meja kerja di kanan.
• Input → transformation → outcome thesis: Saat halaman dimuat, panel bergaris fade up 12px sekali, staggered 60ms per panel, lalu diam. Tidak ada transformasi berkelanjutan; hero adalah poster tercetak yang sudah selesai.
• Motion vocabulary: 140–200ms ease-out pada semua perubahan state; tanpa bounce, tanpa float. Nav hover menggeser blok orange 4px dari tepi kiri item secara instan (linear 120ms). Satu-satunya marquee adalah ticker tanggal/jumlah absensi di top bar Dashboard admin, yang berhenti dan membungkus ke baris statis di bawah prefers-reduced-motion.
• Composed first frame: Wordmark ink di atas kraft, blok denim dengan SISWA knockout cream, kalimat pendukung, dua tombol chunky, fotografi halftone miring -1.5deg dengan badge stamp PKL, dan pita hazard-stripe di dasar hero.
• Reduced-motion state: Semua panel tampil langsung tanpa fade-up; ticker admin berhenti dan membungkus ke baris statis; tidak ada animasi yang tersisa.

Signature motion — stamp: Saat absensi berhasil dikirim, badge hasil jatuh ke tempatnya dengan scale 60ms dari 1.15 ke 1.0 dan overshoot kecil 3px, seperti stamp karet menghantam kertas. Penolakan absensi duplikat dirender sebagai stamp yang sama dalam orange dengan teks SUDAH ABSEN HARI INI.

9. Non-Functional Requirements

• NFR-01 — Teknologi API (explicit): API harus dibangun menggunakan Express.js. Rationale: constraint keras dari sumber.
• NFR-02 — Penyimpanan data (explicit): Data absensi siswa disimpan ke database MySQL. Rationale: constraint keras dari sumber.
• NFR-03 — Integritas validasi (explicit): Validasi bahwa siswa tidak bisa absen dua kali di hari yang sama harus ditegakkan pada alur penyimpanan, bukan hanya di UI. Rationale: constraint keras dari sumber; mencegah bypass.
• NFR-04 — Tampilan admin (explicit): Tampilan web admin harus mengikuti template SB Admin untuk struktur (sidebar, kartu, tabel). Rationale: constraint keras dari sumber.
• NFR-05 — Aksesibilitas warna (required_inference): Body text di atas cream dan kraft harus melewati rasio kontras 4.5:1; body copy tidak boleh diset dalam mustard atau orange di atas kraft. Rationale: keterbacaan untuk siswa dan admin.
• NFR-06 — Keterbacaan viewport (required_inference): Headline, wordmark, label, angka, teks kartu, dan kontrol harus tetap utuh di dalam viewport dan container pada 375px, 768px, dan 1280px. Rationale: audiens siswa menggunakan perangkat mobile.
• NFR-07 — Reduced motion (required_inference): Di bawah prefers-reduced-motion, ticker admin berhenti dan membungkus ke baris statis; semua animasi dinonaktifkan. Rationale: aksesibilitas.

10. Tech Stack

• Frontend: React (web) — tampilan absensi online siswa dan web admin bergaya SB Admin.
• Backend API: Express.js (wajib, explicit).
• Database: MySQL (wajib, explicit).
• Template referensi admin: SB Admin (visual_inspiration + structure_reference) — struktur sidebar/kartu/tabel dipertahankan, skin visual diganti sesuai Creative Direction.
• Font: Alfa Slab One (headings/badge stamps) dan Oswald (body, nav, table headers) — dimuat sebagai web font.
• Deployment: Docker/docker-compose untuk menjalankan frontend, API Express.js, dan MySQL secara bersamaan.

11. Assumptions and Constraints

Assumptions

• A-01 (required_inference): Siswa membuat akun mereka sendiri melalui pendaftaran mandiri; tidak ada batas provisioning yang dinyatakan sumber.
• A-02 (required_inference): Akun admin diprovisikan atau diotorisasi di luar alur pendaftaran mandiri siswa.
• A-03 (required_inference): Satu catatan absensi per siswa per hari adalah unit keunikan yang ditegakkan.
• A-04 (required_inference): Tanggal "hari yang sama" ditentukan oleh tanggal server saat absensi disimpan.

Constraints

• C-01 (explicit): API harus dibangun menggunakan Express.js.
• C-02 (explicit): Data absensi siswa disimpan ke database MySQL.
• C-03 (explicit): Validasi: siswa tidak bisa absen dua kali di hari yang sama.
• C-04 (explicit): Tampilan web admin harus mengikuti template SB Admin.
• C-05 (explicit): Tampilan web absensi online harus memiliki menu yang lengkap.
• C-06 (direction): Template indigo/blue-on-white SaaS generik dilarang untuk proyek ini; admin chrome harus denim #1F3A5F di atas kraft, dengan orange sebagai satu-satunya warna panas.

12. Glossary

• PKL (Praktik Kerja Lapangan): Program magang kerja lapangan untuk siswa SMK; konteks utama produk ini.
• Absensi: Pencatatan kehadiran harian siswa PKL.
• Siswa (Student): Aktor manusia yang melakukan absensi PKL harian.
• Admin: Aktor manusia (guru/koordinator PKL) yang memantau dan mengelola data absensi melalui web admin.
• API Express.js: Layanan backend yang dibangun dengan Express.js untuk menyimpan dan membaca data absensi.
• MySQL: Database relasional tempat data absensi siswa disimpan secara persisten.
• SB Admin: Template admin yang menjadi referensi struktur (sidebar, kartu, tabel) untuk web admin.
• Validasi absensi ganda: Aturan yang menolak percobaan absensi kedua oleh siswa yang sama pada hari yang sama.
• Stamp: Elemen visual badge hasil absensi (HADIR — HH:MM atau SUDAH ABSEN HARI INI) dengan motion stamp khas.
• Hazard-stripe band: Pita diagonal denim/kraft 12px yang menjadi divider antar section utama.
• Badge-stamp: Label denim rounded-rect dengan teks cream all-caps Oswald, rotasi -1deg, dengan rule ink ke tepi container.