System Requirements Document for surat-menyurat

1. Introduction

surat-menyurat adalah aplikasi Sistem Informasi Surat Menyurat dan Administrasi Barang untuk UPTD Pemeliharaan Jalan, SDA dan Bangunan Gedung, Dinas Pekerjaan Umum (DPU) Banyumas. Aplikasi ini dibangun sebagai infrastruktur administrasi internal instansi: mencatat, menomori, mengarsipkan, dan menelusuri kembali surat masuk dan surat keluar, serta mencatat dan memelihara data barang milik UPTD beserta penggunaan, mutasi, dan kondisinya.

Audiens produk adalah pegawai UPTD yang menjalankan fungsi tata usaha dan administrasi barang, serta pejabat penanggung jawab yang memerlukan gambaran status administrasi untuk pengambilan keputusan dan pertanggungjawaban. Produk ini bukan alat publik: seluruh area pengelolaan data surat dan barang berada di balik verifikasi identitas, sementara halaman awal tersedia secara anonim untuk menjelaskan aplikasi sebelum pengguna masuk.

Tujuan yang harus dicapai aplikasi:

• Setiap surat masuk dan surat keluar tercatat, bernomor, dan dapat ditelusuri kembali.
• Arsip surat rapi dan mudah dicari.
• Data barang UPTD akurat dan terkini, termasuk penggunaan, mutasi, dan kondisi barang.
• Rekap dan laporan administrasi surat serta barang dapat ditinjau dan dipertanggungjawabkan.

2. System Overview

Aplikasi ini adalah sistem berbasis web dengan antarmuka kustom milik aplikasi (bukan antarmuka pihak ketiga) dan backend terintegrasi. Identitas pengguna dimiliki oleh aplikasi: pengguna mendaftar sendiri melalui jalur pendaftaran awal, lalu memverifikasi kembali melalui Login sebelum mengakses data surat dan barang yang bersifat tahan lama. Sistem menetapkan peran pengguna sehingga pengelolaan surat, pengelolaan barang, dan peninjauan laporan memiliki batas akses yang sesuai.

Aktor manusia yang aktif dalam sistem ini adalah Petugas Tata Usaha (Administrasi Surat), Petugas Administrasi Barang, dan Kepala UPTD / Pejabat Penanggung Jawab. Tidak ada aktor manusia lain di luar ketiga peran tersebut dalam lingkup saat ini.

Perilaku yang diterima untuk saat ini:

• Pencatatan dan pengelolaan surat masuk, termasuk penomoran surat.
• Pencatatan dan pengelolaan surat keluar, termasuk penomoran surat.
• Pengarsipan dan pencarian kembali surat yang telah tercatat.
• Pencatatan dan pengelolaan data barang UPTD, termasuk penggunaan, mutasi, dan kondisi barang.
• Penyajian rekap dan laporan administrasi surat serta barang untuk ditinjau pejabat penanggung jawab.
• Pendaftaran awal akun, verifikasi kembali melalui Login, dan pembatasan akses sesuai peran.

Batasan sempit yang berlaku: aplikasi ditujukan untuk instansi UPTD Pemeliharaan Jalan, SDA dan Bangunan Gedung DPU Banyumas. Tidak ada modul di luar surat menyurat, administrasi barang, arsip, laporan, dan akses identitas yang diuraikan di dokumen ini.

2a. Product Interpretation and Delivery Boundary

Aplikasi ini dimiliki dan dioperasikan sebagai antarmuka kustom milik aplikasi sendiri, dengan backend terintegrasi yang menyimpan data surat dan barang secara tahan lama. Tidak ada pekerjaan yang dialihkan ke antarmuka milik penyedia pihak ketiga, dan tidak ada tujuan eksternal yang menjadi pemilik alur kerja pengguna.

Batas akses ditetapkan sebagai berikut. Halaman Landing dapat diakses tanpa identitas dan berfungsi sebagai penjelasan aplikasi sebelum akses terlindungi. Halaman Login dan Sign Up juga dapat dijangkau tanpa identitas karena keduanya adalah batas masuk itu sendiri — sebuah halaman terlindungi tidak boleh memiliki interaksi yang membuka akses ke dirinya sendiri. Seluruh halaman pengelolaan dan peninjauan data — Surat Masuk, Detail Surat Masuk, Surat Keluar, Detail Surat Keluar, Arsip Surat, Barang, Detail Barang, dan Laporan — berada di balik verifikasi identitas dan dibatasi sesuai peran: pengelolaan surat untuk Petugas Tata Usaha, pengelolaan barang untuk Petugas Administrasi Barang, dan peninjauan laporan untuk Kepala UPTD / Pejabat Penanggung Jawab.

Batas saat ini dan masa depan: seluruh perilaku yang diuraikan dalam dokumen ini adalah lingkup saat ini. Tidak ada kebutuhan masa depan yang dinyatakan dalam sumber otoritatif, sehingga tidak ada bagian masa depan yang dijanjikan di sini.

2b. Source Content Inventory

Tidak ada direktif referensi dengan content_source dalam sumber, sehingga tidak ada inventaris konten yang disertakan.

2c. Page Content and Component Coverage

Landing

• Informasi/state: Penjelasan anonim aplikasi untuk UPTD Pemeliharaan Jalan, SDA dan Bangunan Gedung DPU Banyumas; cakupan pengelolaan surat menyurat; cakupan administrasi barang; tautan masuk ke area terlindungi. Tidak ada data surat atau barang yang ditampilkan di sini.
• Aksi utama: Menuju Login untuk pengguna yang sudah memiliki akun; menuju Sign Up untuk pengguna yang belum memiliki akun.
• Aksi pendukung: Membaca penjelasan modul surat dan modul barang sebelum memutuskan masuk.
• Entitas domain: Tidak ada entitas surat atau barang yang dimuat; hanya identitas instansi dan deskripsi modul.
• Tanggung jawab komponen: Poster hero dengan wordmark SURAT-MENYURAT; tiga baris salinan Indonesia berbaris rata kiri ('Pencatatan surat masuk dan keluar', 'Administrasi barang UPTD', 'Arsip dan laporan'); blok warna merah solid berisi diagram surat bertumpuk dengan angka tabular dan dua titik masuk 'Masuk' dan 'Keluar'; grid 12 kolom yang digambar dengan garis rambut dan nomor kolom 01–12; aturan horizontal 1px selebar viewport di bawah komposisi.
• State: Loading — tidak ada permintaan data, halaman dirender langsung. Empty — tidak berlaku. Success — halaman tampil penuh dengan grid dan blok merah pada posisi gridnya. Error — tidak ada kegagalan data; jika navigasi ke Login atau Sign Up gagal, pengguna tetap berada di Landing dan dapat mencoba lagi. Recovery — pengguna dapat mengulang pemilihan titik masuk.

Login

• Informasi/state: Formulir verifikasi kembali untuk pengguna yang sudah memiliki akun; pesan kesalahan kredensial; status sedang memverifikasi.
• Aksi utama: Mengirim kredensial untuk verifikasi dan melanjutkan ke area terlindungi sesuai peran pengguna.
• Aksi pendukung: Berpindah ke Sign Up bila belum memiliki akun; kembali ke Landing.
• Entitas domain: Identitas pengguna dan peran yang melekat padanya.
• Tanggung jawab komponen: Field identitas dan kata sandi; tombol kirim bertepi keras; area pesan kesalahan; tautan ke Sign Up.
• State: Loading — tombol kirim menampilkan status sedang memverifikasi dan tidak dapat dikirim ulang. Empty — field kosong dengan penanda wajib. Success — verifikasi berhasil dan pengguna diarahkan ke area terlindungi yang sesuai perannya. Error — kredensial tidak cocok atau akun tidak ditemukan; pesan ditampilkan dan field dapat diperbaiki. Recovery — pengguna dapat mengirim ulang kredensial atau berpindah ke Sign Up.

Sign Up

• Informasi/state: Formulir pendaftaran awal akun; penjelasan bahwa akun diperlukan untuk mengakses data surat dan barang; pesan kesalahan pendaftaran.
• Aksi utama: Mendaftarkan akun baru sehingga pengguna memperoleh akun yang sah untuk masuk ke area terlindungi.
• Aksi pendukung: Berpindah ke Login bila sudah memiliki akun; kembali ke Landing.
• Entitas domain: Identitas pengguna baru dan peran yang akan ditetapkan sistem.
• Tanggung jawab komponen: Field data pendaftaran; penanda field wajib; tombol daftar bertepi keras; area pesan kesalahan; tautan ke Login.
• State: Loading — tombol daftar menampilkan status sedang memproses. Empty — field kosong dengan penanda wajib. Success — akun terbentuk dan pengguna dapat melanjutkan ke Login untuk verifikasi. Error — data tidak lengkap atau akun sudah ada; pesan ditampilkan dan field dapat diperbaiki. Recovery — pengguna dapat memperbaiki data dan mengirim ulang, atau berpindah ke Login.

Surat Masuk

• Informasi/state: Daftar surat masuk yang telah dicatat, ditampilkan sebagai register tabular dengan kolom sejajar: nomor surat, tanggal, asal surat, dan status; penghitung surat masuk aktif pada header bar; keadaan daftar kosong bila belum ada catatan.
• Aksi utama: Mencatat surat masuk baru dengan membuka Detail Surat Masuk.
• Aksi pendukung: Membuka baris surat untuk melihat atau mengeditnya di Detail Surat Masuk; menyaring dan mengurutkan daftar register.
• Entitas domain: Surat masuk (nomor, tanggal, asal, perihal, status).
• Tanggung jawab komponen: Header bar beraturan dengan wordmark UPTD, nama modul aktif dalam huruf kapital, dan penghitung tabular; tabel register dengan aturan 1px antar baris dan titik status merah 6px di gutter kiri; kontrol pencatatan surat baru; kontrol penyaringan.
• State: Loading — baris register muncul bertahap saat pertama kali dimuat. Empty — pesan bahwa belum ada surat masuk yang tercatat, dengan arahan mencatat surat pertama. Success — daftar tampil dengan nomor, tanggal, asal, dan status sejajar. Error — daftar gagal dimuat; pesan ditampilkan dan daftar dapat dimuat ulang. Recovery — pengguna dapat memuat ulang daftar atau melanjutkan mencatat surat baru.

Detail Surat Masuk

• Informasi/state: Konteks fokus satu surat masuk: nomor surat, tanggal, asal, perihal, status, dan data pencatatan lainnya; mode catat baru atau mode sunting.
• Aksi utama: Menyimpan data surat masuk yang dicatat atau disunting, termasuk penetapan nomor surat.
• Aksi pendukung: Kembali ke daftar Surat Masuk; membatalkan perubahan yang belum disimpan.
• Entitas domain: Surat masuk dan nomor suratnya.
• Tanggung jawab komponen: Formulir pasangan label/nilai yang sejajar; penanda field wajib; tombol simpan bertepi keras; aturan 2px merah untuk penekanan bagian; tautan kembali ke daftar.
• State: Loading — data surat dimuat sebelum formulir dapat disunting. Empty — mode catat baru dengan field kosong dan penanda wajib. Success — data tersimpan dan status surat tercatat pada register. Error — penyimpanan gagal atau field wajib belum lengkap; pesan ditampilkan dan data yang sudah diisi tetap ada. Recovery — pengguna dapat memperbaiki field dan menyimpan ulang, atau membatalkan dan kembali ke daftar.

Surat Keluar

• Informasi/state: Daftar surat keluar yang telah dicatat, ditampilkan sebagai register tabular dengan kolom sejajar: nomor surat, tanggal, tujuan surat, dan status; penghitung surat keluar aktif pada header bar; keadaan daftar kosong bila belum ada catatan.
• Aksi utama: Mencatat surat keluar baru dengan membuka Detail Surat Keluar.
• Aksi pendukung: Membuka baris surat untuk melihat atau mengeditnya di Detail Surat Keluar; menyaring dan mengurutkan daftar register.
• Entitas domain: Surat keluar (nomor, tanggal, tujuan, perihal, status).
• Tanggung jawab komponen: Header bar beraturan dengan wordmark UPTD, nama modul aktif dalam huruf kapital, dan penghitung tabular; tabel register dengan aturan 1px antar baris dan titik status merah 6px di gutter kiri; kontrol pencatatan surat baru; kontrol penyaringan.
• State: Loading — baris register muncul bertahap saat pertama kali dimuat. Empty — pesan bahwa belum ada surat keluar yang tercatat, dengan arahan mencatat surat pertama. Success — daftar tampil dengan nomor, tanggal, tujuan, dan status sejajar. Error — daftar gagal dimuat; pesan ditampilkan dan daftar dapat dimuat ulang. Recovery — pengguna dapat memuat ulang daftar atau melanjutkan mencatat surat baru.

Detail Surat Keluar

• Informasi/state: Konteks fokus satu surat keluar: nomor surat, tanggal, tujuan, perihal, status, dan data pencatatan lainnya; mode catat baru atau mode sunting.
• Aksi utama: Menyimpan data surat keluar yang dicatat atau disunting, termasuk penetapan nomor surat.
• Aksi pendukung: Kembali ke daftar Surat Keluar; membatalkan perubahan yang belum disimpan.
• Entitas domain: Surat keluar dan nomor suratnya.
• Tanggung jawab komponen: Formulir pasangan label/nilai yang sejajar; penanda field wajib; tombol simpan bertepi keras; aturan 2px merah untuk penekanan bagian; tautan kembali ke daftar.
• State: Loading — data surat dimuat sebelum formulir dapat disunting. Empty — mode catat baru dengan field kosong dan penanda wajib. Success — data tersimpan dan status surat tercatat pada register. Error — penyimpanan gagal atau field wajib belum lengkap; pesan ditampilkan dan data yang sudah diisi tetap ada. Recovery — pengguna dapat memperbaiki field dan menyimpan ulang, atau membatalkan dan kembali ke daftar.

Arsip Surat

• Informasi/state: Kumpulan surat yang telah tercatat — surat masuk dan surat keluar — yang dapat dicari dan ditinjau kembali; hasil pencarian dalam bentuk register tabular; keadaan tanpa hasil.
• Aksi utama: Mencari arsip surat berdasarkan kriteria pencarian dan meninjau kembali surat yang ditemukan.
• Aksi pendukung: Membuka surat yang ditemukan pada konteks detailnya; mengosongkan kriteria pencarian untuk kembali ke seluruh arsip.
• Entitas domain: Arsip surat (nomor, tanggal, asal atau tujuan, perihal, status).
• Tanggung jawab komponen: Kontrol pencarian; tabel register hasil dengan kolom sejajar dan aturan 1px; titik status merah di gutter kiri; tautan ke konteks detail surat.
• State: Loading — hasil pencarian dimuat setelah kriteria dikirim. Empty — pesan bahwa tidak ada surat yang cocok dengan kriteria, dengan arahan mengubah kriteria. Success — hasil tampil sebagai register yang dapat ditelusuri. Error — pencarian gagal; pesan ditampilkan dan pencarian dapat diulang. Recovery — pengguna dapat mengubah kriteria dan mencari ulang.

Barang

• Informasi/state: Daftar barang milik UPTD, ditampilkan sebagai register tabular dengan kolom sejajar: kode barang, nama barang, dan kondisi barang; penghitung barang aktif pada header bar; keadaan daftar kosong bila belum ada catatan.
• Aksi utama: Mencatat barang baru dengan membuka Detail Barang.
• Aksi pendukung: Membuka baris barang untuk melihat atau mengeditnya di Detail Barang; menyaring dan mengurutkan daftar register.
• Entitas domain: Barang (kode, nama, kondisi, data administrasi lainnya).
• Tanggung jawab komponen: Header bar beraturan dengan wordmark UPTD, nama modul aktif dalam huruf kapital, dan penghitung tabular; tabel register dengan aturan 1px antar baris; kontrol pencatatan barang baru; kontrol penyaringan.
• State: Loading — baris register muncul bertahap saat pertama kali dimuat. Empty — pesan bahwa belum ada barang yang tercatat, dengan arahan mencatat barang pertama. Success — daftar tampil dengan kode, nama, dan kondisi sejajar. Error — daftar gagal dimuat; pesan ditampilkan dan daftar dapat dimuat ulang. Recovery — pengguna dapat memuat ulang daftar atau melanjutkan mencatat barang baru.

Detail Barang

• Informasi/state: Konteks fokus satu barang: kode barang, nama barang, kondisi barang, catatan penggunaan, catatan mutasi, dan data administrasi lainnya; mode catat baru atau mode sunting.
• Aksi utama: Menyimpan data barang yang dicatat atau disunting, termasuk penggunaan, mutasi, dan kondisi barang.
• Aksi pendukung: Kembali ke daftar Barang; membatalkan perubahan yang belum disimpan.
• Entitas domain: Barang, penggunaan barang, mutasi barang, kondisi barang.
• Tanggung jawab komponen: Formulir pasangan label/nilai yang sejajar; bagian terpisah untuk penggunaan, mutasi, dan kondisi; penanda field wajib; tombol simpan bertepi keras; aturan 2px merah untuk penekanan bagian; tautan kembali ke daftar.
• State: Loading — data barang dimuat sebelum formulir dapat disunting. Empty — mode catat baru dengan field kosong dan penanda wajib. Success — data tersimpan dan kondisi barang tercatat pada register. Error — penyimpanan gagal atau field wajib belum lengkap; pesan ditampilkan dan data yang sudah diisi tetap ada. Recovery — pengguna dapat memperbaiki field dan menyimpan ulang, atau membatalkan dan kembali ke daftar.

Laporan

• Informasi/state: Rekap dan laporan administrasi surat serta administrasi barang untuk ditinjau; ringkasan jumlah dan status; grid 12 kolom yang digambar dengan garis rambut dan nomor kolom 01–12 pada tepi atas.
• Aksi utama: Meninjau rekap dan laporan administrasi surat serta barang.
• Aksi pendukung: Memilih cakupan laporan yang ditinjau; membaca rincian rekap per bagian.
• Entitas domain: Rekap surat masuk, surat keluar, arsip surat, dan barang.
• Tanggung jawab komponen: Grid 12 kolom yang terlihat; blok rekap dengan angka tabular; aturan 1px dan 2px merah sebagai pemisah bagian; pasangan label/nilai yang sejajar.
• State: Loading — rekap dimuat sebelum ditampilkan. Empty — pesan bahwa belum ada data yang dapat direkap. Success — rekap dan laporan tampil dengan angka tabular yang sejajar. Error — rekap gagal dimuat; pesan ditampilkan dan pemuatan dapat diulang. Recovery — pengguna dapat memuat ulang rekap atau memilih cakupan lain.

3. Functional Requirements

FR-01 — Pencatatan surat masuk (explicit) As a Petugas Tata Usaha (Administrasi Surat), I should mencatat surat masuk ke dalam register aplikasi sehingga setiap surat masuk tercatat dan dapat ditelusuri kembali.

• Trigger/input: petugas membuka Surat Masuk dan memilih pencatatan surat baru, lalu mengisi data surat masuk pada Detail Surat Masuk.
• Observable result: surat masuk tersimpan dengan nomor surat, tanggal, asal, dan status, dan muncul sebagai baris pada register Surat Masuk.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan surat.
• Failure/recovery: bila penyimpanan gagal atau field wajib belum lengkap, pesan kesalahan ditampilkan dan data yang sudah diisi tetap ada sehingga petugas dapat memperbaiki dan menyimpan ulang.
• Continuation: petugas kembali ke daftar Surat Masuk dan dapat mencatat surat berikutnya.

FR-02 — Penomoran surat masuk (explicit) As a Petugas Tata Usaha (Administrasi Surat), I should menetapkan nomor surat pada setiap surat masuk yang dicatat sehingga penomoran surat instansi tetap tertib dan dapat dirujuk.

• Trigger/input: penetapan nomor dilakukan saat mencatat atau menyunting surat masuk pada Detail Surat Masuk.
• Observable result: nomor surat tersimpan bersama data surat dan tampil pada kolom nomor di register Surat Masuk dengan angka tabular.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan surat.
• Failure/recovery: bila nomor belum diisi atau penyimpanan gagal, pesan kesalahan ditampilkan dan nomor dapat diisi ulang.
• Continuation: nomor surat yang tersimpan dapat dirujuk kembali melalui register dan Arsip Surat.

FR-03 — Pengelolaan surat masuk (explicit) As a Petugas Tata Usaha (Administrasi Surat), I should melihat dan menyunting data surat masuk yang telah tercatat sehingga data surat tetap akurat.

• Trigger/input: petugas membuka baris surat dari register Surat Masuk ke Detail Surat Masuk.
• Observable result: perubahan data surat tersimpan dan register Surat Masuk menampilkan data terbaru.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan surat.
• Failure/recovery: bila penyimpanan gagal, pesan kesalahan ditampilkan dan perubahan yang belum tersimpan tetap ada untuk dicoba ulang; petugas dapat membatalkan perubahan dan kembali ke daftar.
• Continuation: petugas kembali ke register Surat Masuk atau melanjutkan ke Arsip Surat.

FR-04 — Pencatatan surat keluar (explicit) As a Petugas Tata Usaha (Administrasi Surat), I should mencatat surat keluar ke dalam register aplikasi sehingga setiap surat keluar tercatat dan dapat ditelusuri kembali.

• Trigger/input: petugas membuka Surat Keluar dan memilih pencatatan surat baru, lalu mengisi data surat keluar pada Detail Surat Keluar.
• Observable result: surat keluar tersimpan dengan nomor surat, tanggal, tujuan, dan status, dan muncul sebagai baris pada register Surat Keluar.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan surat.
• Failure/recovery: bila penyimpanan gagal atau field wajib belum lengkap, pesan kesalahan ditampilkan dan data yang sudah diisi tetap ada sehingga petugas dapat memperbaiki dan menyimpan ulang.
• Continuation: petugas kembali ke daftar Surat Keluar dan dapat mencatat surat berikutnya.

FR-05 — Penomoran surat keluar (explicit) As a Petugas Tata Usaha (Administrasi Surat), I should menetapkan nomor surat pada setiap surat keluar yang dicatat sehingga penomoran surat instansi tetap tertib dan dapat dirujuk.

• Trigger/input: penetapan nomor dilakukan saat mencatat atau menyunting surat keluar pada Detail Surat Keluar.
• Observable result: nomor surat tersimpan bersama data surat dan tampil pada kolom nomor di register Surat Keluar dengan angka tabular.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan surat.
• Failure/recovery: bila nomor belum diisi atau penyimpanan gagal, pesan kesalahan ditampilkan dan nomor dapat diisi ulang.
• Continuation: nomor surat yang tersimpan dapat dirujuk kembali melalui register dan Arsip Surat.

FR-06 — Pengelolaan surat keluar (explicit) As a Petugas Tata Usaha (Administrasi Surat), I should melihat dan menyunting data surat keluar yang telah tercatat sehingga data surat tetap akurat.

• Trigger/input: petugas membuka baris surat dari register Surat Keluar ke Detail Surat Keluar.
• Observable result: perubahan data surat tersimpan dan register Surat Keluar menampilkan data terbaru.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan surat.
• Failure/recovery: bila penyimpanan gagal, pesan kesalahan ditampilkan dan perubahan yang belum tersimpan tetap ada untuk dicoba ulang; petugas dapat membatalkan perubahan dan kembali ke daftar.
• Continuation: petugas kembali ke register Surat Keluar atau melanjutkan ke Arsip Surat.

FR-07 — Pengarsipan surat (explicit) As a Petugas Tata Usaha (Administrasi Surat), I should mengarsipkan surat yang telah tercatat sehingga arsip surat rapi.

• Trigger/input: surat masuk dan surat keluar yang telah tersimpan menjadi bagian arsip surat yang tersedia pada Arsip Surat.
• Observable result: surat yang tercatat dapat ditemukan kembali melalui Arsip Surat dengan nomor, tanggal, asal atau tujuan, perihal, dan status yang sejajar.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan surat.
• Failure/recovery: bila arsip gagal dimuat, pesan kesalahan ditampilkan dan pemuatan dapat diulang.
• Continuation: petugas dapat membuka surat yang ditemukan pada konteks detailnya.

FR-08 — Pencarian arsip surat (explicit) As a Petugas Tata Usaha (Administrasi Surat), I should mencari surat pada arsip sehingga surat yang telah tercatat mudah dicari kembali.

• Trigger/input: petugas memasukkan kriteria pencarian pada Arsip Surat.
• Observable result: hasil pencarian tampil sebagai register surat yang cocok dengan kriteria.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan surat.
• Failure/recovery: bila tidak ada surat yang cocok, pesan tanpa hasil ditampilkan dengan arahan mengubah kriteria; bila pencarian gagal, pesan kesalahan ditampilkan dan pencarian dapat diulang.
• Continuation: petugas dapat membuka surat yang ditemukan atau mengubah kriteria dan mencari ulang.

FR-09 — Pencatatan barang (explicit) As a Petugas Administrasi Barang, I should mencatat barang milik UPTD sehingga data barang tercatat dan dapat dipertanggungjawabkan.

• Trigger/input: petugas membuka Barang dan memilih pencatatan barang baru, lalu mengisi data barang pada Detail Barang.
• Observable result: barang tersimpan dengan kode barang, nama barang, dan kondisi barang, dan muncul sebagai baris pada register Barang.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan barang.
• Failure/recovery: bila penyimpanan gagal atau field wajib belum lengkap, pesan kesalahan ditampilkan dan data yang sudah diisi tetap ada sehingga petugas dapat memperbaiki dan menyimpan ulang.
• Continuation: petugas kembali ke daftar Barang dan dapat mencatat barang berikutnya.

FR-10 — Pengelolaan data barang (explicit) As a Petugas Administrasi Barang, I should melihat dan menyunting data barang yang telah tercatat sehingga data barang tetap akurat dan terkini.

• Trigger/input: petugas membuka baris barang dari register Barang ke Detail Barang.
• Observable result: perubahan data barang tersimpan dan register Barang menampilkan data terbaru.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan barang.
• Failure/recovery: bila penyimpanan gagal, pesan kesalahan ditampilkan dan perubahan yang belum tersimpan tetap ada untuk dicoba ulang; petugas dapat membatalkan perubahan dan kembali ke daftar.
• Continuation: petugas kembali ke register Barang dan dapat melanjutkan ke barang berikutnya.

FR-11 — Pencatatan penggunaan barang (explicit) As a Petugas Administrasi Barang, I should mencatat penggunaan barang pada data barang sehingga penggunaan barang terdokumentasi.

• Trigger/input: petugas mengisi catatan penggunaan pada bagian penggunaan di Detail Barang.
• Observable result: catatan penggunaan tersimpan bersama data barang dan dapat ditinjau kembali dari Detail Barang.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan barang.
• Failure/recovery: bila penyimpanan gagal, pesan kesalahan ditampilkan dan catatan yang sudah diisi tetap ada untuk dicoba ulang.
• Continuation: petugas dapat melanjutkan mencatat mutasi atau kondisi barang pada barang yang sama.

FR-12 — Pencatatan mutasi barang (explicit) As a Petugas Administrasi Barang, I should mencatat mutasi barang pada data barang sehingga perpindahan barang terdokumentasi.

• Trigger/input: petugas mengisi catatan mutasi pada bagian mutasi di Detail Barang.
• Observable result: catatan mutasi tersimpan bersama data barang dan dapat ditinjau kembali dari Detail Barang.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan barang.
• Failure/recovery: bila penyimpanan gagal, pesan kesalahan ditampilkan dan catatan yang sudah diisi tetap ada untuk dicoba ulang.
• Continuation: petugas dapat melanjutkan memperbarui kondisi barang pada barang yang sama.

FR-13 — Pencatatan kondisi barang (explicit) As a Petugas Administrasi Barang, I should mencatat kondisi barang pada data barang sehingga kondisi barang tetap terkini.

• Trigger/input: petugas mengisi kondisi barang pada bagian kondisi di Detail Barang.
• Observable result: kondisi barang tersimpan dan tampil pada kolom kondisi di register Barang.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran pengelolaan barang.
• Failure/recovery: bila penyimpanan gagal, pesan kesalahan ditampilkan dan kondisi yang sudah dipilih tetap ada untuk dicoba ulang.
• Continuation: petugas kembali ke register Barang dan dapat melanjutkan ke barang berikutnya.

FR-14 — Peninjauan rekap dan laporan administrasi surat serta barang (explicit) As a Kepala UPTD / Pejabat Penanggung Jawab, I should meninjau rekap dan laporan administrasi surat serta administrasi barang sehingga saya memperoleh gambaran status administrasi untuk pengambilan keputusan dan pertanggungjawaban.

• Trigger/input: pejabat membuka Laporan dan memilih cakupan laporan yang ditinjau.
• Observable result: rekap dan laporan administrasi surat serta barang tampil dengan angka tabular yang sejajar.
• Access state: hanya setelah verifikasi identitas melalui Login; dibatasi untuk peran peninjauan laporan.
• Failure/recovery: bila belum ada data yang dapat direkap, pesan kosong ditampilkan; bila rekap gagal dimuat, pesan kesalahan ditampilkan dan pemuatan dapat diulang.
• Continuation: pejabat dapat memilih cakupan laporan lain atau menutup peninjauan.

FR-15 — Pendaftaran awal akun (required_inference) As a Petugas Tata Usaha (Administrasi Surat), Petugas Administrasi Barang, atau Kepala UPTD / Pejabat Penanggung Jawab, I should menyelesaikan pendaftaran awal akun sehingga saya memperoleh akun yang sah sebelum menggunakan area aplikasi terlindungi.

• Trigger/input: pengguna membuka Sign Up dari Landing atau dari Login dan mengisi data pendaftaran.
• Observable result: akun terbentuk dan pengguna dapat melanjutkan ke Login untuk verifikasi.
• Access state: Sign Up dapat dijangkau tanpa identitas karena merupakan batas masuk itu sendiri.
• Failure/recovery: bila data tidak lengkap atau akun sudah ada, pesan kesalahan ditampilkan dan field dapat diperbaiki; pengguna dapat berpindah ke Login bila ternyata sudah memiliki akun.
• Continuation: pengguna melanjutkan ke Login untuk verifikasi kembali.

FR-16 — Verifikasi kembali melalui Login (required_inference) As a Petugas Tata Usaha (Administrasi Surat), Petugas Administrasi Barang, atau Kepala UPTD / Pejabat Penanggung Jawab, I should melakukan verifikasi kembali melalui Login sehingga saya dapat melanjutkan akses ke data surat dan barang.

• Trigger/input: pengguna membuka Login dan mengirim kredensialnya.
• Observable result: verifikasi berhasil dan pengguna diarahkan ke area terlindungi yang sesuai perannya.
• Access state: Login dapat dijangkau tanpa identitas karena merupakan batas masuk itu sendiri; area terlindungi tetap tidak tersedia sebelum identitas terverifikasi.
• Failure/recovery: bila kredensial tidak cocok atau akun tidak ditemukan, pesan kesalahan ditampilkan dan pengguna dapat mengirim ulang kredensial atau berpindah ke Sign Up.
• Continuation: setelah verifikasi, pengguna melanjutkan ke modul yang menjadi tanggung jawabnya.

FR-17 — Penetapan peran dan batas akses (required_inference) As the Sistem, I should menetapkan peran pengguna sehingga pengelolaan surat, pengelolaan barang, dan peninjauan laporan memiliki batas akses yang sesuai.

• Trigger/input: peran melekat pada akun pengguna dan dibaca saat verifikasi melalui Login.
• Observable result: pengguna hanya dapat membuka area yang sesuai perannya — pengelolaan surat untuk Petugas Tata Usaha, pengelolaan barang untuk Petugas Administrasi Barang, dan peninjauan laporan untuk Kepala UPTD / Pejabat Penanggung Jawab.
• Access state: berlaku pada seluruh halaman terlindungi.
• Failure/recovery: bila pengguna mencoba membuka area di luar perannya, akses tidak diberikan dan pengguna tetap pada area yang menjadi tanggung jawabnya.
• Continuation: pengguna melanjutkan pekerjaan pada area yang sesuai perannya.

4. User Personas

Petugas Tata Usaha (Administrasi Surat)

Konteks produk: Staf tata usaha UPTD Pemeliharaan Jalan, SDA dan Bangunan Gedung DPU Banyumas yang memegang register surat instansi. Pekerjaannya berulang dan berbasis catatan: setiap surat yang masuk atau keluar harus masuk ke register dengan nomor yang benar.

Tujuan utama: Memastikan setiap surat tercatat dan dapat ditelusuri kembali, dengan hasil akhir arsip surat yang rapi dan mudah dicari.

Tanggung jawab yang diterima: Mencatat surat masuk (FR-01), menetapkan nomor surat masuk (FR-02), melihat dan menyunting surat masuk (FR-03), mencatat surat keluar (FR-04), menetapkan nomor surat keluar (FR-05), melihat dan menyunting surat keluar (FR-06), mengarsipkan surat (FR-07), dan mencari arsip surat (FR-08).

Input dan keputusan: Data surat masuk (nomor, tanggal, asal, perihal, status), data surat keluar (nomor, tanggal, tujuan, perihal, status), serta kriteria pencarian arsip. Keputusan utamanya adalah penetapan nomor surat dan penentuan kriteria pencarian saat menelusuri kembali surat.

Interaksi dengan peserta lain: Petugas ini bekerja pada area pengelolaan surat yang dibatasi perannya. Hasil kerjanya — register surat dan arsip — menjadi bahan yang ditinjau oleh Kepala UPTD / Pejabat Penanggung Jawab pada Laporan. Ia tidak mengelola data barang.

Keberhasilan yang teramati: Surat yang baru dicatat muncul pada register dengan nomor, tanggal, asal atau tujuan, dan status yang sejajar; surat yang dicari melalui Arsip Surat ditemukan kembali.

Yang membedakan peran ini: Fokusnya adalah ketertiban penomoran dan ketertelusuran surat, bukan pemeliharaan inventaris fisik. Nilai kerjanya terlihat pada register yang konsisten dan arsip yang dapat dicari.

Petugas Administrasi Barang

Konteks produk: Staf yang bertanggung jawab atas administrasi barang milik UPTD Pemeliharaan Jalan, SDA dan Bangunan Gedung DPU Banyumas. Pekerjaannya menjaga agar catatan barang mengikuti keadaan sebenarnya di lapangan dan di gudang.

Tujuan utama: Menjaga data barang tetap akurat dan terkini, dengan hasil akhir laporan administrasi barang yang dapat dipertanggungjawabkan.

Tanggung jawab yang diterima: Mencatat barang (FR-09), melihat dan menyunting data barang (FR-10), mencatat penggunaan barang (FR-11), mencatat mutasi barang (FR-12), dan mencatat kondisi barang (FR-13).

Input dan keputusan: Kode barang, nama barang, kondisi barang, catatan penggunaan, dan catatan mutasi. Keputusan utamanya adalah penetapan kode barang dan penilaian kondisi barang.

Interaksi dengan peserta lain: Petugas ini bekerja pada area pengelolaan barang yang dibatasi perannya. Data barang yang dipeliharanya menjadi bahan rekap yang ditinjau oleh Kepala UPTD / Pejabat Penanggung Jawab pada Laporan. Ia tidak mengelola surat.

Keberhasilan yang teramati: Barang yang baru dicatat muncul pada register Barang dengan kode, nama, dan kondisi yang sejajar; catatan penggunaan, mutasi, dan kondisi tersimpan pada barang yang bersangkutan.

Yang membedakan peran ini: Fokusnya adalah keadaan fisik dan perpindahan barang, bukan alur dokumen surat. Perubahan kondisi dan mutasi barang adalah inti pekerjaannya.

Kepala UPTD / Pejabat Penanggung Jawab

Konteks produk: Pejabat yang memimpin UPTD Pemeliharaan Jalan, SDA dan Bangunan Gedung dan membutuhkan pemantauan atas administrasi surat menyurat serta administrasi barang. Ia tidak menjalankan pencatatan harian.

Tujuan utama: Memperoleh gambaran status administrasi untuk pengambilan keputusan dan pertanggungjawaban, dengan hasil akhir laporan/rekap yang dapat ditinjau.

Tanggung jawab yang diterima: Meninjau rekap dan laporan administrasi surat serta administrasi barang (FR-14).

Input dan keputusan: Pemilihan cakupan laporan yang ditinjau. Keputusannya adalah penilaian atas status administrasi berdasarkan rekap yang tersaji.

Interaksi dengan peserta lain: Ia meninjau hasil kerja Petugas Tata Usaha (Administrasi Surat) dan Petugas Administrasi Barang melalui Laporan. Ia tidak mencatat surat maupun barang.

Keberhasilan yang teramati: Rekap dan laporan administrasi surat serta barang tampil dengan angka tabular yang sejajar dan dapat dibaca untuk pertanggungjawaban.

Yang membedakan peran ini: Perannya bersifat peninjauan dan pertanggungjawaban, bukan pencatatan. Ia membutuhkan gambaran menyeluruh, bukan kendali atas satu register.

5. Core User Flows

Alur 1 — Petugas Tata Usaha mencatat surat masuk

1. Petugas Tata Usaha (Administrasi Surat) membuka Landing dan memilih titik masuk 'Masuk'.
2. Karena belum memiliki sesi terverifikasi, ia diarahkan ke Login.
3. Ia mengirim kredensialnya. Sistem memverifikasi identitas dan menetapkan perannya sebagai pengelola surat.
4. Ia diarahkan ke Surat Masuk dan melihat register surat masuk dengan nomor, tanggal, asal, dan status yang sejajar, serta penghitung surat masuk pada header bar.
5. Ia memilih pencatatan surat baru dan masuk ke Detail Surat Masuk dalam mode catat baru.
6. Ia mengisi nomor surat, tanggal, asal, perihal, dan status, lalu menyimpan.
7. Hasil yang teramati: surat tersimpan dan muncul sebagai baris baru pada register Surat Masuk dengan nomor tabular dan titik status merah di gutter kiri.
8. Kegagalan dan pemulihan: bila field wajib belum lengkap atau penyimpanan gagal, pesan kesalahan ditampilkan dan data yang sudah diisi tetap ada; ia memperbaiki field dan menyimpan ulang.
9. Kelanjutan: ia kembali ke register Surat Masuk dan mencatat surat berikutnya.

Alur 2 — Petugas Tata Usaha mencatat surat keluar

1. Petugas Tata Usaha (Administrasi Surat) sudah berada di area terlindungi setelah verifikasi melalui Login.
2. Ia membuka Surat Keluar dan melihat register surat keluar dengan nomor, tanggal, tujuan, dan status yang sejajar.
3. Ia memilih pencatatan surat baru dan masuk ke Detail Surat Keluar.
4. Ia mengisi nomor surat, tanggal, tujuan, perihal, dan status, lalu menyimpan.
5. Hasil yang teramati: surat tersimpan dan muncul sebagai baris baru pada register Surat Keluar.
6. Kegagalan dan pemulihan: bila penyimpanan gagal, pesan kesalahan ditampilkan dan data yang sudah diisi tetap ada; ia dapat memperbaiki dan menyimpan ulang atau membatalkan dan kembali ke daftar.
7. Kelanjutan: ia kembali ke register Surat Keluar dan melanjutkan pencatatan berikutnya.

Alur 3 — Petugas Tata Usaha menyunting surat yang telah tercatat

1. Petugas Tata Usaha (Administrasi Surat) membuka register Surat Masuk atau Surat Keluar.
2. Ia memilih baris surat yang perlu diperbaiki.
3. Detail Surat Masuk atau Detail Surat Keluar terbuka dengan data surat yang ada.
4. Ia mengubah data yang perlu diperbaiki dan menyimpan.
5. Hasil yang teramati: register menampilkan data terbaru untuk surat tersebut.
6. Kegagalan dan pemulihan: bila penyimpanan gagal, perubahan yang belum tersimpan tetap ada dan ia dapat mencoba ulang; ia juga dapat membatalkan perubahan dan kembali ke daftar.
7. Kelanjutan: ia kembali ke register atau melanjutkan ke Arsip Surat.

Alur 4 — Petugas Tata Usaha mencari surat pada arsip

1. Petugas Tata Usaha (Administrasi Surat) membuka Arsip Surat.
2. Ia memasukkan kriteria pencarian, misalnya nomor surat, tanggal, asal atau tujuan, atau perihal.
3. Hasil yang teramati: hasil tampil sebagai register surat yang cocok, dengan kolom sejajar dan titik status merah di gutter kiri.
4. Ia membuka surat yang ditemukan pada konteks detailnya untuk meninjau kembali.
5. Kegagalan dan pemulihan: bila tidak ada surat yang cocok, pesan tanpa hasil ditampilkan dan ia mengubah kriteria; bila pencarian gagal, pesan kesalahan ditampilkan dan ia mencari ulang.
6. Kelanjutan: ia kembali ke Arsip Surat atau melanjutkan ke register surat.

Alur 5 — Petugas Administrasi Barang mencatat barang

1. Petugas Administrasi Barang membuka Landing dan memilih titik masuk, lalu diarahkan ke Login.
2. Ia mengirim kredensialnya. Sistem memverifikasi identitas dan menetapkan perannya sebagai pengelola barang.
3. Ia diarahkan ke Barang dan melihat register barang dengan kode, nama, dan kondisi yang sejajar, serta penghitung barang pada header bar.
4. Ia memilih pencatatan barang baru dan masuk ke Detail Barang.
5. Ia mengisi kode barang, nama barang, dan kondisi barang, lalu menyimpan.
6. Hasil yang teramati: barang tersimpan dan muncul sebagai baris baru pada register Barang.
7. Kegagalan dan pemulihan: bila field wajib belum lengkap atau penyimpanan gagal, pesan kesalahan ditampilkan dan data yang sudah diisi tetap ada; ia memperbaiki dan menyimpan ulang.
8. Kelanjutan: ia kembali ke register Barang dan mencatat barang berikutnya.

Alur 6 — Petugas Administrasi Barang mencatat penggunaan, mutasi, dan kondisi barang

1. Petugas Administrasi Barang membuka register Barang dan memilih barang yang akan diperbarui.
2. Detail Barang terbuka dengan data barang yang ada.
3. Ia mengisi catatan penggunaan pada bagian penggunaan, lalu menyimpan.
4. Hasil yang teramati: catatan penggunaan tersimpan bersama data barang.
5. Ia mengisi catatan mutasi pada bagian mutasi, lalu menyimpan.
6. Hasil yang teramati: catatan mutasi tersimpan bersama data barang.
7. Ia memperbarui kondisi barang pada bagian kondisi, lalu menyimpan.
8. Hasil yang teramati: kondisi barang tersimpan dan tampil pada kolom kondisi di register Barang.
9. Kegagalan dan pemulihan: bila salah satu penyimpanan gagal, pesan kesalahan ditampilkan dan catatan yang sudah diisi tetap ada untuk dicoba ulang.
10. Kelanjutan: ia kembali ke register Barang dan melanjutkan ke barang berikutnya.

Alur 7 — Kepala UPTD meninjau laporan administrasi

1. Kepala UPTD / Pejabat Penanggung Jawab membuka Landing dan memilih titik masuk, lalu diarahkan ke Login.
2. Ia mengirim kredensialnya. Sistem memverifikasi identitas dan menetapkan perannya sebagai peninjau laporan.
3. Ia diarahkan ke Laporan dan melihat grid 12 kolom yang digambar dengan nomor kolom 01–12 pada tepi atas.
4. Ia memilih cakupan laporan yang ditinjau.
5. Hasil yang teramati: rekap dan laporan administrasi surat serta administrasi barang tampil dengan angka tabular yang sejajar, termasuk rekap surat masuk, surat keluar, arsip surat, dan barang.
6. Kegagalan dan pemulihan: bila belum ada data yang dapat direkap, pesan kosong ditampilkan; bila rekap gagal dimuat, pesan kesalahan ditampilkan dan ia memuat ulang atau memilih cakupan lain.
7. Kelanjutan: ia menyelesaikan peninjauan dan menggunakan rekap sebagai dasar pengambilan keputusan dan pertanggungjawaban.

Alur 8 — Pengguna baru mendaftar dan masuk pertama kali

1. Calon pengguna membuka Landing dan membaca penjelasan aplikasi untuk UPTD, pengelolaan surat menyurat, dan administrasi barang.
2. Ia memilih titik masuk menuju Sign Up karena belum memiliki akun.
3. Ia mengisi data pendaftaran dan mengirimkannya.
4. Hasil yang teramati: akun terbentuk dan ia dapat melanjutkan ke Login.
5. Kegagalan dan pemulihan: bila data tidak lengkap atau akun sudah ada, pesan kesalahan ditampilkan dan ia memperbaiki field; bila ternyata sudah memiliki akun, ia berpindah ke Login.
6. Ia membuka Login, mengirim kredensialnya, dan sistem memverifikasi identitas serta menetapkan perannya.
7. Kelanjutan: ia diarahkan ke area terlindungi yang sesuai perannya — Surat Masuk dan Surat Keluar untuk pengelola surat, Barang untuk pengelola barang, atau Laporan untuk peninjau laporan.

Alur 9 — Pengguna kembali setelah sesi berakhir

1. Pengguna yang sebelumnya sudah memiliki akun membuka Landing.
2. Ia memilih titik masuk menuju Login.
3. Ia mengirim kredensialnya dan sistem memverifikasi identitas serta perannya.
4. Hasil yang teramati: ia kembali ke area terlindungi yang sesuai perannya dan dapat melanjutkan pekerjaan atas data surat atau barang yang tersimpan.
5. Kegagalan dan pemulihan: bila kredensial tidak cocok atau akun tidak ditemukan, pesan kesalahan ditampilkan dan ia dapat mengirim ulang kredensial atau berpindah ke Sign Up.
6. Kelanjutan: ia melanjutkan pekerjaan pada modul yang menjadi tanggung jawabnya.

6. Visuals Colors and Theme

Arah kreatif proyek ini mengikuti Josef Müller-Brockmann dan tradisi poster geometris serta sistem grid Swiss. Headline arah: Swiss geometric rigour for a government records office. Bahasa visualnya adalah bahasa buku register publik: kolom modular, tabel bergaris, huruf rata kiri, dan satu warna aksen murni sebagai penanda arah. Ketegasannya hidup pada skala huruf dan grid yang diperlihatkan, bukan pada dekorasi.

Mode: light mode sebagai mode utama.

Token warna (light mode):

Proporsi warna dijaga sekitar 80% kertas/putih, 15% hitam, dan 5% merah. Merah tidak pernah dipakai sebagai bidang besar di belakang teks isi; teks hitam di atas kertas dan hitam di atas putih membawa seluruh keterbacaan. Penanda arah sekunder menggunakan hitam dengan berbagai tint, tidak pernah hue kedua. Biru dan indigo tidak digunakan di mana pun.

Tipografi:

• Heading: Archivo — grotesque, rata kiri ragged-right, huruf kapital untuk label dan penanda bagian dengan tracking 0.08em; headline berat 800 pada ukuran sangat besar dengan leading rapat 0.95 sehingga terkunci ke grid seperti huruf poster.
• Body: Archivo — regular 400 dengan leading 1.6.
• Skala modular rasio 1.5: 96 / 64 / 40 / 27 / 18 / 16 px. Hero mobile 40px, tablet 64px, desktop 96px.
• Micro-label: 12px huruf kapital dengan tracking 0.12em.
• Angka tabular wajib untuk semua nomor surat, tanggal, dan kode barang.
• Inter, Roboto, Arial, Helvetica, Poppins, dan system-ui tidak digunakan untuk heading maupun body.

Bahasa bentuk: Tidak ada sudut membulat di mana pun. Persegi keras, aturan hitam 1px, aturan merah 2px untuk penekanan, lingkaran geometris hanya sebagai titik status, dan batas bagian bersudut siku. Geometri adalah konten: grid digambar, bukan disiratkan.

Ritme spasi: Satuan dasar 8px dengan kelipatan 8/16/24/32/48/64/96; baris tabel rapat dengan tinggi konsisten agar kolom angka tetap sejajar pada baseline yang ketat.

Gaya citra: Hanya diagram garis dan abstraksi geometris. Modul surat memakai diagram amplop atau tumpukan arsip yang direduksi menjadi persegi dan garis; modul barang memakai siluet geometris peralatan pemeliharaan jalan dan bangunan sebagai piktogram hitam datar. Tidak ada fotografi stok, tidak ada ilustrasi demi ilustrasi, tidak ada 3D.

7. Signature Design Concept

Konsep visual untuk halaman masuk publik Landing adalah poster grid yang diperlihatkan. Alih-alih hero SaaS yang berpusat, halaman ini adalah poster selebar viewport yang memperlihatkan sistem gridnya sendiri sebagai ornamen.

Komposisinya asimetris dan terkunci pada grid 12 kolom:

• Kolom 1–8: wordmark SURAT-MENYURAT disusun dalam Archivo 800 huruf kapital, dari 40px di mobile hingga 96px di desktop, bertumpuk di atas tiga baris salinan Indonesia — 'Pencatatan surat masuk dan keluar', 'Administrasi barang UPTD', 'Arsip dan laporan' — masing-masing duduk rata kiri pada aturan kolom yang terlihat.
• Kolom 9–12: blok #D42A20 solid yang penuh hingga tepi bagian, berisi diagram hitam-putih tumpukan persegi surat dengan angka tabular 001–240 dan dua titik masuk 'Masuk' dan 'Keluar' sebagai tombol hitam bertepi keras di atas merah.
• Garis dasar: aturan horizontal hitam 1px selebar viewport berjalan di bawah seluruh komposisi, dengan tick 12 kolom tercetak di atasnya.
• Grid sebagai ornamen: garis vertikal rambut berjalan sepanjang tinggi hero, dengan nomor kolom 01–12 tercetak di tepi atas dalam 12px huruf kapital.

Tidak ada gradien, tidak ada blob, tidak ada tombol terpusat. Ketegasan datang dari skala huruf dan grid yang diperlihatkan. Konsep ini hanya menyusun ulang konten, state, dan kontrol yang sudah diterima — penjelasan aplikasi, dua titik masuk ke Login dan Sign Up, serta identitas instansi — dan tidak menambahkan perilaku, halaman, atau tujuan baru.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Subjek fokus: wordmark SURAT-MENYURAT pada kolom 1–8 dan blok merah pada kolom 9–12 yang berisi diagram tumpukan surat dengan angka tabular 001–240 serta dua titik masuk 'Masuk' dan 'Keluar'.
• Tesis input → transformasi → hasil: saat halaman dimuat, blok merah bergeser 24px ke posisi gridnya dan aturan bagian tergambar dari kiri; hasilnya adalah komposisi poster yang terkunci pada grid, dengan dua titik masuk ke Login dan Sign Up siap dipilih.
• Kosakata gerak: aturan bagian tergambar dari kiri (200ms, ease-out); baris surat muncul bertahap dengan interval 40ms pada paint pertama; titik status berdenyut satu kali ketika surat ditandai terkirim; blok merah hero bergeser 24px ke posisi gridnya saat dimuat. Tidak ada bounce, tidak ada parallax, tidak ada partikel.
• Frame pertama yang tersusun: grid 12 kolom dengan nomor kolom 01–12 sudah tercetak di tepi atas, wordmark dan tiga baris salinan sudah rata kiri pada aturan kolom, blok merah sudah berada di kolom 9–12, dan aturan horizontal 1px sudah membentang selebar viewport.
• State reduced-motion: dengan prefers-reduced-motion, blok merah langsung berada pada posisi grid akhirnya, aturan bagian sudah tergambar penuh, baris surat tampil tanpa stagger, dan titik status tidak berdenyut. Semua teks dan kontrol tetap utuh dan dapat dibaca pada 375px, 768px, dan 1280px.

Transisi antar modul: perpindahan antara Surat Masuk, Surat Keluar, Arsip Surat, Barang, dan Laporan menggunakan wipe blok warna — pita hitam atau merah solid melintasi aturan header sebelum tipografi halaman baru masuk. Header bar beraturan yang persisten membawa wordmark UPTD, nama modul aktif dalam huruf kapital, dan penghitung langsung ('Surat Masuk 128 · Surat Keluar 96 · Barang 412') dalam angka tabular.

9. Non-Functional Requirements

NFR-01 — Cakupan instansi (explicit) Aplikasi ditujukan untuk instansi UPTD Pemeliharaan Jalan, SDA dan Bangunan Gedung DPU Banyumas. Seluruh konten, penamaan modul, dan konteks administratif mengikuti instansi tersebut.

• Rasional: batasan keras yang dinyatakan pengguna.

NFR-02 — Identitas dimiliki aplikasi (required_inference) Aplikasi memiliki identitas penggunanya sendiri: pendaftaran awal melalui Sign Up, verifikasi kembali melalui Login, dan sesi yang mengikat pengguna pada perannya. Tidak ada penyedia identitas eksternal yang menjadi pemilik alur masuk.

• Rasional: diperlukan agar data surat dan barang yang tahan lama tetap terikat pada peserta yang benar.

NFR-03 — Batas akses berbasis peran (required_inference) Sistem menetapkan peran pengguna sehingga pengelolaan surat, pengelolaan barang, dan peninjauan laporan memiliki batas akses yang sesuai. Halaman Surat Masuk, Detail Surat Masuk, Surat Keluar, Detail Surat Keluar, dan Arsip Surat dibatasi untuk peran pengelolaan surat; Barang dan Detail Barang dibatasi untuk peran pengelolaan barang; Laporan dibatasi untuk peran peninjauan laporan. Landing, Login, dan Sign Up dapat dijangkau tanpa identitas.

• Rasional: diperlukan agar tanggung jawab tiap peran tidak saling menimpa.

NFR-04 — Ketertelusuran dan ketertiban penomoran (explicit) Setiap surat masuk dan surat keluar yang dicatat memiliki nomor surat dan dapat ditelusuri kembali melalui register dan Arsip Surat. Nomor surat, tanggal, dan kode barang ditampilkan dengan angka tabular agar sejajar dan mudah dibaca.

• Rasional: tujuan yang dinyatakan pengguna — setiap surat tercatat dan dapat ditelusuri kembali, arsip rapi dan mudah dicari.

NFR-05 — Akurasi data barang (explicit) Data barang harus tetap akurat dan terkini, mencakup penggunaan, mutasi, dan kondisi barang, sehingga laporan administrasi barang dapat dipertanggungjawabkan.

• Rasional: tujuan yang dinyatakan pengguna untuk administrasi barang.

NFR-06 — Keterbacaan pada semua viewport (explicit) Headline, wordmark, label, angka, teks kartu, dan kontrol tetap utuh di dalam viewport dan kontainernya pada 375px, 768px, dan 1280px, dengan membungkus atau menskalakan ukuran huruf (misalnya clamp(...) beserta ukuran mobile-nya). Tidak ada elemen lain yang menutupi bagian mana pun dari teks atau kontrol yang dapat dibaca. Dengan prefers-reduced-motion, disediakan susunan statis yang tetap dapat digunakan.

• Rasional: batasan keterbacaan yang dinyatakan dalam arah kreatif.

NFR-07 — Larangan tampilan template SaaS biru-indigo (explicit) Tampilan template SaaS indigo/biru di atas putih dilarang untuk proyek ini. Biru dan indigo tidak muncul di palet; merah #D42A20 adalah satu-satunya aksen kromatik.

• Rasional: larangan eksplisit dalam arah kreatif.

NFR-08 — Bahasa antarmuka (basic_default) Seluruh label, pesan, dan salinan antarmuka menggunakan Bahasa Indonesia, sesuai konteks instansi dan salinan hero yang dinyatakan.

• Rasional: default yang konsisten dengan sumber; tidak ada instruksi bahasa lain.

10. Tech Stack

• Frontend: React — antarmuka kustom milik aplikasi dengan grid 12 kolom, tabel register, dan formulir pasangan label/nilai.
• Backend: Python / FastAPI — melayani pendaftaran akun, verifikasi Login, penetapan peran, serta operasi data surat masuk, surat keluar, arsip surat, dan barang.
• Penyimpanan: basis data relasional untuk menyimpan data surat masuk, surat keluar, arsip surat, barang beserta penggunaan, mutasi, dan kondisi, serta akun dan peran pengguna.
• Kontainerisasi: Docker dan docker-compose untuk menjalankan frontend, backend, dan basis data secara terpadu.
• Orkestrasi: Kubernetes tidak disertakan karena tidak ada kebutuhan penerapan yang menyatakannya.

11. Assumptions and Constraints

Asumsi

• A-01 — Tiga peran yang ditetapkan sistem adalah Petugas Tata Usaha (Administrasi Surat), Petugas Administrasi Barang, dan Kepala UPTD / Pejabat Penanggung Jawab; tidak ada peran lain dalam lingkup saat ini. (required_inference)
• A-02 — Pendaftaran awal dilakukan sendiri oleh pengguna melalui Sign Up karena sumber tidak menetapkan penyediaan akun atau undangan administratif tertentu. (required_inference)
• A-03 — Peran pengguna ditetapkan oleh sistem pada saat akun terbentuk dan dibaca saat verifikasi melalui Login. (required_inference)
• A-04 — Data surat dan barang bersifat tahan lama sehingga memerlukan verifikasi identitas sebelum diakses atau diubah. (required_inference)
• A-05 — Surat yang telah dicatat pada register surat masuk dan surat keluar menjadi bagian dari arsip surat yang dapat dicari. (required_inference)
• A-06 — Bahasa antarmuka adalah Bahasa Indonesia. (basic_default)

Batasan

• C-01 — Aplikasi ditujukan untuk instansi UPTD Pemeliharaan Jalan, SDA dan Bangunan Gedung DPU Banyumas. (explicit)
• C-02 — Halaman Landing, Login, dan Sign Up dapat dijangkau tanpa identitas; halaman Surat Masuk, Detail Surat Masuk, Surat Keluar, Detail Surat Keluar, Arsip Surat, Barang, Detail Barang, dan Laporan berada di balik verifikasi identitas dan dibatasi sesuai peran. (required_inference)
• C-03 — Tidak ada sudut membulat, tidak ada bayangan lembut, tidak ada hover-lift, tidak ada gradien, tidak ada glassmorphism, dan tidak ada panel transparan pada permukaan administratif. (explicit)
• C-04 — Biru dan indigo tidak digunakan di mana pun; merah #D42A20 adalah satu-satunya aksen kromatik. (explicit)
• C-05 — Inter, Roboto, Arial, Helvetica, Poppins, dan system-ui tidak digunakan untuk heading maupun body. (explicit)
• C-06 — Fotografi tidak digunakan sebagai dekorasi; hanya diagram informasional dan piktogram. (explicit)
• C-07 — Gerak tidak memantul, tidak melayang, dan tidak berulang tanpa tujuan; tidak ada parallax dan tidak ada partikel. (explicit)
• C-08 — Tidak ada kebutuhan masa depan yang dinyatakan dalam sumber otoritatif, sehingga tidak ada bagian masa depan yang dijanjikan dalam dokumen ini. (explicit)

12. Glossary

• UPTD — Unit Pelaksana Teknis Dinas; unit di bawah DPU Banyumas yang menangani pemeliharaan jalan, sumber daya air (SDA), dan bangunan gedung.
• DPU — Dinas Pekerjaan Umum; instansi induk tempat UPTD bernaung.
• SDA — Sumber Daya Air; salah satu bidang pemeliharaan yang menjadi tanggung jawab UPTD.
• Surat Masuk — Surat yang diterima instansi dan dicatat ke dalam register surat masuk beserta nomor, tanggal, asal, perihal, dan statusnya.
• Surat Keluar — Surat yang dikirim instansi dan dicatat ke dalam register surat keluar beserta nomor, tanggal, tujuan, perihal, dan statusnya.
• Arsip Surat — Kumpulan surat yang telah tercatat dan dapat dicari serta ditinjau kembali.
• Barang — Aset milik UPTD yang dicatat dalam administrasi barang beserta kode, nama, kondisi, penggunaan, dan mutasinya.
• Mutasi Barang — Perpindahan barang dari satu tempat atau pengguna ke tempat atau pengguna lain yang dicatat pada data barang.
• Kondisi Barang — Keadaan barang yang dicatat pada data barang dan ditampilkan pada register barang.
• Register — Daftar tabular beraturan tempat surat atau barang dicatat dengan kolom sejajar dan aturan pemisah.
• Tata Usaha — Fungsi administrasi instansi yang menangani pencatatan dan pengarsipan surat.
• Kepala UPTD — Pejabat yang memimpin UPTD dan bertanggung jawab atas pertanggungjawaban administrasi.
• Angka Tabular — Angka dengan lebar tetap sehingga nomor surat, tanggal, dan kode barang tetap sejajar antar baris.