System Requirements Document for jaringan-wi-fi

1. Introduction

jaringan-wi-fi is a simple web application built with HTML, CSS, and JavaScript that displays a list of Wi-Fi networks available in the surroundings. The application uses simulated/dummy data rather than a real network scan, and it shows the names of the Wi-Fi networks in that list.

The product intent is deliberately narrow: an ordinary person opens the page, glances at it, and recognises which Wi-Fi network names are available around them within a couple of seconds. There is no account, no configuration, no real radio scanning, and no network interaction of any kind. The audience is a single, non-technical person using a phone or laptop who wants a quick, legible readout of nearby network names.

The interface is treated as a small instrument panel rather than a marketing surface: honest controls, a strict modular grid, muted warm surfaces, and exactly one saturated signal accent.

2. System Overview

The current delivery is a single anonymous, first-party web page — Landing — that opens directly onto the Wi-Fi network readout. The page presents:

• A charcoal instrument header bar carrying the wordmark JARINGAN-WI-FI and a live detection counter.
• A hero instrument panel split by a vertical hairline: an oversized display line JARINGAN DI SEKITAR ANDA with the scan control pinned beneath it, and a drawn concentric-arc signal dial summarising the networks found.
• A ruled network table listing one network per row, with aligned columns for name, band, channel, five discrete strength bars, and dBm in tabular numerals.

All network data is simulated/dummy data defined inside the application. The application does not perform real Wi-Fi scanning, does not request device radio permissions, does not connect to any network, and does not transmit any data anywhere.

Actors

• Pengguna Pencari Jaringan Wi-Fi — the single accepted active human persona. This person opens the page, triggers a scan, and reviews the resulting list of network names.
• Application (system process) — owns the simulated dataset and the scan simulation that produces the displayed list. This is a non-persona actor.

Ownership and exclusions

• The single page is owned by the application and is anonymously reachable; no identity, login, or account is required or provided.
• No real network discovery, no connection management, no credential entry, no speed testing, no historical logging, and no sharing/export are part of this product.

2a. Product Interpretation and Delivery Boundary

The product is a self-contained, client-side web page. Everything the user sees — the header counter, the hero panel, the signal dial, and the ruled network table — is rendered by the application from a fixed set of simulated network records. The scan control re-runs the simulation locally and re-presents the same simulated catalogue; it never touches the device's Wi-Fi hardware.

Access is anonymous and immediate. Because the page holds no durable per-user state, no commitment, no entitlement, and no value transfer, there is no application-owned identity and no sign-in step. The page is the entry point and the working surface at the same time.

Current scope: the anonymous Landing page, the simulated network dataset, the scan interaction, and the network list readout.

Future scope (not current): anything involving real network scanning, live signal measurement, saved or favourited networks, or multi-page navigation. These are explicitly out of the current delivery and must not appear in current pages or acceptance criteria.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source, so no external factual inventory is carried into this document. All network records are simulated/dummy data authored for the application itself.

2c. Page Content and Component Coverage

Landing

The single anonymous entry and working surface. It explains the application in one line and immediately presents the simulated Wi-Fi network readout.

Information and state

• Application wordmark: JARINGAN-WI-FI, uppercase.
• Live detection counter: the number of networks currently in the displayed list, e.g. 7 JARINGAN TERDETEKSI, marked with a small orange dot.
• Hero display line: JARINGAN DI SEKARANG ANDA — rendered as JARINGAN DI SEKITAR ANDA, oversized, wrapping to three lines.
• Scan state: idle (SCAN) or active (MEMINDAI…).
• Summary readout: the strongest network's name and its dBm reading in tabular numerals, beneath the signal dial.
• Network table columns: name, band, channel, five discrete strength bars, dBm.
• Strongest-network marker: a 3px orange left edge on the strongest row.

Primary actions

• SCAN — triggers the simulated scan. The button flips to a charcoal MEMINDAI… state for 900ms, then returns to SCAN with the list re-presented.
• Row hover / focus — darkens the row's 1px top rule to full opacity. A state change, not an animation.

Supporting actions

• None. There is no filtering, sorting, connecting, saving, or exporting control in the current scope.

Domain entities

• Network — a simulated Wi-Fi network record with: name (SSID), band (2.4GHz / 5GHz / 6GHz), channel, signal strength expressed as five discrete bars, and dBm reading.
• Scan result set — the ordered collection of Network records currently displayed, ordered strongest-first.

Component responsibilities

• Instrument header bar — charcoal bar flush to the top edge, no shadow, no rounding. Carries the wordmark flush left and the orange-dot detection counter flush right.
• Hero instrument panel — a single panel divided by one vertical hairline. Left half: the oversized display line plus the SCAN button pinned directly beneath the type. Right half: the drawn signal dial with the strongest network's name and dBm beneath it.
• Signal dial — a drawn instrument element: concentric 1px arcs, five orange bars, and thin ruled tick marks for the 2.4/5/6GHz bands. Sized 220px on mobile, 380px on desktop.
• SCAN button — rectangular, charcoal body, orange left edge, uppercase label. Radius 6px.
• Network table — a ruled spec table. One network per row, hairline 1px top rule per row, aligned columns, tabular numerals for dBm, channel, and frequency readings.
• Strength bars — five hard-edged rectangular bars per row, filling left-to-right in 60ms steps on scan. Never a smooth wave or gradient meter.
• Band icon — a 16px line icon per row indicating the band (a 2.4GHz wave, a 5GHz wave).

States

• Loading / scanning — the SCAN button reads MEMINDAI… in a charcoal active state for 900ms; rows re-enter with a 40ms staggered slide-and-fade from 4px below and settle with no bounce; strength bars fill in 60ms steps.
• Empty — if the simulated result set is empty, the table area shows a single ruled row with an uppercase micro-label stating that no networks were detected, and the header counter reads 0 JARINGAN TERDETEKSI. The SCAN control remains available.
• Success — the ruled table is populated, the header counter matches the row count, the strongest row carries the 3px orange left edge, and the dial summary shows the strongest network's name and dBm.
• Error — the application has no external dependency, so no network or server error state exists. If the simulated dataset cannot be read, the table area shows the same ruled empty row with an uppercase micro-label indicating the list is unavailable, and the SCAN control remains available to retry.
• Recovery — pressing SCAN again re-runs the simulation and re-presents the list from the idle state.

3. Functional Requirements

FR-1 — Simple web application in HTML, CSS, and JavaScript As a Pengguna Pencari Jaringan Wi-Fi, I should open a simple web application built with HTML, CSS, and JavaScript so that I can use it directly in a browser without installing anything.

• Provenance: explicit
• Trigger: the user opens the application in a web browser.
• Observable result: the Landing page renders in the browser using only HTML, CSS, and JavaScript.
• Access state: anonymous; no identity, login, or permission is required.
• Failure/recovery: if the page fails to render, reloading the page restores it.
• Continuation: the user proceeds to review the network list or press SCAN.

FR-2 — Display a list of nearby Wi-Fi networks As a Pengguna Pencari Jaringan Wi-Fi, I should see a list of Wi-Fi networks available in the surroundings so that I know what networks are around me.

• Provenance: explicit
• Trigger: the Landing page loads, or the user presses SCAN.
• Observable result: the ruled network table presents one row per network in the current result set, ordered strongest-first, with the header counter matching the row count.
• Access state: anonymous.
• Failure/recovery: if the result set is empty or unavailable, the table area shows a ruled row with an uppercase micro-label instead of rows, and SCAN remains available.
• Continuation: the user reads the rows and may press SCAN again.

FR-3 — Simulated/dummy network data As a Pengguna Pencari Jaringan Wi-Fi, I should see network data that comes from simulation rather than a real scan so that the application stays simple and requires no device radio access.

• Provenance: explicit
• Trigger: the Landing page loads, or the user presses SCAN.
• Observable result: every displayed network record originates from the application's built-in simulated dataset; no real Wi-Fi scan is performed and no radio permission is requested.
• Access state: anonymous.
• Failure/recovery: if the simulated dataset cannot be read, the table area shows the unavailable-list state described in FR-2.
• Continuation: the user reviews the simulated list.

FR-4 — Show Wi-Fi network names As a Pengguna Pencari Jaringan Wi-Fi, I should see the name of each Wi-Fi network so that I can recognise which networks are available.

• Provenance: explicit
• Trigger: the network list is rendered.
• Observable result: each row displays the network's name (SSID) in the name column, set at 18px on mobile and 22px on desktop, and the strongest network's name also appears beneath the signal dial.
• Access state: anonymous.
• Failure/recovery: if a simulated record has no name, that row shows an uppercase micro-label placeholder in the name column rather than an empty cell.
• Continuation: the user recognises the network names and may press SCAN again.

FR-5 — Trigger a simulated scan As a Pengguna Pencari Jaringan Wi-Fi, I should press SCAN so that the list is re-presented from the simulated data.

• Provenance: required_inference — the scan control is the accepted mechanism by which the displayed list is produced and refreshed on the Landing page.
• Trigger: the user presses the SCAN button.
• Observable result: the button flips to the charcoal MEMINDAI… state for 900ms; rows re-enter with a 40ms staggered slide-and-fade from 4px below and settle with no bounce; strength bars fill left-to-right in 60ms steps; the header counter and dial summary update to match the new result set.
• Access state: anonymous.
• Failure/recovery: if the result set is empty or unavailable, the empty/unavailable state from FR-2 is shown and the SCAN control remains available.
• Continuation: the user reads the refreshed list, or presses SCAN again.

FR-6 — Read signal strength and band metadata per network As a Pengguna Pencari Jaringan Wi-Fi, I should see each network's band, channel, strength bars, and dBm reading so that I can tell the networks apart at a glance.

• Provenance: required_inference — the accepted list readout is presented as an aligned spec table whose columns carry the network's identifying and signal attributes.
• Trigger: the network list is rendered.
• Observable result: each row shows band, channel, five discrete orange strength bars, and a dBm value in tabular numerals; the strongest row carries a 3px orange left edge.
• Access state: anonymous.
• Failure/recovery: if a simulated record lacks a metadata value, that cell shows an uppercase micro-label placeholder rather than an empty cell.
• Continuation: the user continues reading the list or presses SCAN again.

4. User Personas

Pengguna Pencari Jaringan Wi-Fi

Product context. This person is an ordinary, non-technical user on a phone or laptop who wants a quick readout of which Wi-Fi networks are around them. They did not come to configure anything, sign in, or connect to a network — they came to look. Their attention budget is roughly two seconds.

Primary goal. Recognise the names of the Wi-Fi networks available in the surroundings from the displayed list.

Distinct accepted responsibilities.

• Open the application and read the network list as presented on first load.
• Press SCAN to re-present the list from the simulated data.
• Read each row's network name, and use the band, channel, strength bars, and dBm columns to tell networks apart.
• Recognise the strongest network from its orange left-edge marker and the dial summary.

Relevant inputs or decisions.

• The decision to press SCAN or to simply read the list already on screen.
• No credentials, no configuration values, and no network selection are entered or made.

Interactions with other accepted participants.

• The only other actor is the application itself, which supplies the simulated dataset and renders the list. There is no second human participant, no counterparty, and no recipient of any value or commitment. Nothing the user does changes state for another person.

Observable success.

• The user can name at least one Wi-Fi network from the list, and can identify which listed network is strongest, without any additional step.

Constraints carried from source.

• The application must remain simple and built only with HTML, CSS, and JavaScript.
• The data must be simulated/dummy, not a real scan.

5. Core User Flows

Flow 1 — Open the application and read the network list

1. Starting context: the user is on a phone or laptop with a browser open, and has no account and no prior session.
2. The user opens the Landing page.
3. The application renders the charcoal instrument header bar with the wordmark JARINGAN-WI-FI flush left and the orange-dot detection counter flush right, e.g. 7 JARINGAN TERDETEKSI.
4. The application renders the hero instrument panel: the oversized display line JARINGAN DI SEKITAR ANDA on the left with the SCAN button pinned beneath it, and the drawn signal dial on the right with the strongest network's name and dBm reading beneath it.
5. The application renders the ruled network table below the panel, one row per simulated network, ordered strongest-first, with the strongest row carrying a 3px orange left edge.
6. Observable result: the user sees the names of the available Wi-Fi networks, each with its band, channel, five discrete strength bars, and dBm reading.
7. Next step: the user either stops here, having recognised the network names, or proceeds to Flow 2.

Flow 2 — Re-run the simulated scan

1. Starting context: the user is on the Landing page with a network list already displayed.
2. The user presses the SCAN button.
3. The button flips to the charcoal MEMINDAI… state and holds for 900ms.
4. The rows re-enter with a 40ms staggered slide-and-fade from 4px below and settle with no bounce; the strength bars fill left-to-right in 60ms steps.
5. Observable result: the button returns to SCAN, the header counter and dial summary match the refreshed result set, and the strongest row carries the 3px orange left edge.
6. Next step: the user reads the refreshed list, or presses SCAN again.

Flow 3 — Read a single network's details

1. Starting context: the user is on the Landing page with the network table populated.
2. The user moves their pointer over, or focuses, a network row.
3. The row's 1px top rule darkens to full opacity — a state change, not an animation.
4. Observable result: the user reads that row's name, band, channel, five discrete strength bars, and dBm value in tabular numerals.
5. Next step: the user continues down the list, or presses SCAN to re-present it.

Flow 4 — Empty or unavailable list

1. Starting context: the user is on the Landing page and the simulated result set is empty or cannot be read.
2. The application renders the table area as a single ruled row carrying an uppercase micro-label stating that no networks were detected, or that the list is unavailable.
3. The header counter reads 0 JARINGAN TERDETEKSI.
4. Observable result: the user understands that no networks are currently listed, and the SCAN control remains visible and available.
5. Next step: the user presses SCAN to re-run the simulation and return to Flow 2.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Dieter Rams; the headline idea is Less, but better — a Wi-Fi signal scanner that reads like a Braun instrument panel.

Colour tokens — light mode

Ratio roughly 70% warm neutrals, 22% charcoal, 8% orange. Text on surfaces stays above 12:1 contrast. Orange is used only on dark charcoal or as a bar of at least 3px — never as small type on the light ground, never for large fills, never for decoration.

Typography

• Headings: Archivo, 600–700 weight. Panel labels uppercase at 12–13px with 0.12em tracking. A single oversized lowercase display line in the hero at 700 weight with -0.02em tracking. No italics, no decorative weights.
• Body: Fira Sans.
• Scale: 1.25 modular. Display 44px → 104px; section head 22px → 32px; network name 18px → 22px; body 15px → 16px; label/meta 11px → 12px uppercase.
• Line-height: 1.05 for display, 1.5 for body. Tabular numerals for dBm, channel, and frequency readings.

Shape language

• Rounded-rectangle controls with a consistent 6px radius — the radius of a physical switch, not a pill. No radii above 8px.
• Hairline 1px rules in #1A1A18 at 18% opacity divide every row.
• Strength is drawn as five discrete rectangular bars, never a smooth wave.
• No blobs. No soft shadows beyond a 1px 2px 0 rgba(26,26,24,0.08) edge on panels. Everything sits flush on the grid with hard, honest edges.

Layout

• A 12-column modular grid on the warm paper ground.
• Header: a thin charcoal bar carrying the wordmark JARINGAN-WI-FI in uppercase Archivo and a live scan counter.
• Hero: a single full-width instrument panel. Left column holds the oversized display line JARINGAN DI SEKITAR ANDA and the scan control. Right column holds a large dial-like summary of networks found.
• List: a ruled table — one network per row, aligned columns for name, band, channel, signal bars, and dBm. Dense but ordered, like a Braun product spec sheet.
• Mobile: the grid collapses to one column. Hero type stacks above the scan button, and each network row becomes a two-line block with the name on top and the metadata as an uppercase micro-row beneath.

Imagery

• Diagrammatic, not photographic. A single drawn instrument element: a circular signal dial built from concentric 1px arcs and five orange bars, plus thin ruled tick marks for the 2.4/5/6GHz bands.
• Network rows may carry a tiny 16px line-icon per band (a 2.4GHz wave, a 5GHz wave).
• No stock photography, no illustration for its own sake, no device mockups.

Forbidden

• Any blue or indigo accent (#2563EB, #4F46E5, #7C3AED and neighbours). Orange #E4570E is the only signal colour.
• Inter, Roboto, Arial, Helvetica, Poppins, or system-ui for headings or body.
• Gradient-blob heroes, glassmorphism, frosted panels, soft multi-colour gradients.
• A grid of identical hover-lift cards with drop shadows — rows are ruled, not carded.
• Centred headline + subtext + rounded CTA composition.
• Smooth wave or radial-gradient signal meters; strength is discrete bars only.
• Decorative motion, parallax, particles, or bouncy easing.
• Rounded-pill buttons and radii above 8px.

Readability rule. Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit. No other element covers any part of them. Where the direction asks for a cropped or bled gesture, it is carried by imagery or decoration only.

7. Signature Design Concept

The instrument face. The first screen is not a SaaS hero — it is a faceplate.

A charcoal header bar spans the viewport flush against the top edge, with no shadow and no rounding: JARINGAN-WI-FI in uppercase Archivo flush left, and a small orange dot plus 7 JARINGAN TERDETEKSI flush right. The orange dot is the only saturated mark above the fold, and it is the same orange that will mark the strongest network below.

Beneath it, on the warm paper ground, a single panel is divided by one vertical hairline. The left half carries the display line JARINGAN DI SEKITAR ANDA in Archivo 700, set at 44px on mobile and 104px on desktop, wrapping to three lines, with a rectangular charcoal SCAN button — orange left edge, uppercase label — pinned directly beneath the type rather than centred. The right half carries the drawn signal dial at 220px on mobile and 380px on desktop, with the strongest network's name and its -42 dBm reading in tabular numerals beneath it.

The ruled network table begins immediately below the panel, its first row visible above the fold on desktop. Nothing is centred, nothing floats, no gradient appears anywhere. The composition reads as a physical instrument: one ground, one panel, one hairline, one signal colour.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the drawn concentric-arc signal dial on the right half of the hero panel, with the strongest network's name and dBm reading in tabular numerals beneath it.
• Input → transformation → outcome thesis: the user presses SCAN → the button flips to the charcoal MEMINDAI… state for 900ms while the rows re-enter with a 40ms staggered slide-and-fade from 4px below and the strength bars fill left-to-right in 60ms steps → the list settles with no bounce, the header counter and dial summary match the refreshed result set, and the strongest row carries its 3px orange left edge.
• Motion vocabulary: instant, mechanical feedback. Discrete steps, no easing flourish, no bounce, no parallax, no particles, no gradient drift. Hovering a row darkens its 1px top rule to full opacity — a state change, not an animation.
• Composed first frame: the charcoal header bar flush to the top edge with the orange dot and detection counter; the hero panel split by one vertical hairline, the oversized display line on the left with the SCAN button pinned beneath it, the drawn signal dial on the right with the strongest network's name and dBm beneath; the first ruled table row visible above the fold on desktop.
• Reduced-motion state: with prefers-reduced-motion, the staggered row entry and the 60ms bar fill are suppressed. The MEMINDAI… state still appears, rows and bars appear whole and settled, and the list remains fully readable. No item is left partially revealed.

9. Non-Functional Requirements

NFR-1 — Technology constraint. The application must be simple and built only with HTML, CSS, and JavaScript. Provenance: explicit. Rationale: an explicit hard constraint in the authoritative user evidence; no framework, build step, or server-side runtime is required or permitted for the current delivery.

NFR-2 — Simulated data only. The Wi-Fi network data must be simulated/dummy data, not the result of a real network scan. Provenance: explicit. Rationale: an explicit hard constraint in the authoritative user evidence. The application must not request device radio permissions, must not invoke any real scanning API, and must not connect to any network.

NFR-3 — No external data transmission. Because all data is simulated and rendered client-side, the application sends no user data to any external service. Provenance: required_inference. Rationale: a direct consequence of NFR-2 and of the absence of any accepted server, account, or provider in the source.

NFR-4 — Legibility at every viewport. Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Provenance: explicit (creative direction readability rule). Rationale: the product's whole value is a two-second read of network names.

NFR-5 — Accessible contrast and colour use. Text on surfaces stays above 12:1 contrast. Orange #E4570E is used only on dark charcoal or as a bar of at least 3px, never as small type on the light ground. Provenance: explicit (creative direction). Rationale: the single signal colour must remain a signal, not a legibility hazard.

NFR-6 — Reduced-motion support. With prefers-reduced-motion, the staggered row entry and stepped bar fill are suppressed and content appears whole. Provenance: explicit (creative direction readability rule). Rationale: motion is feedback, not content; removing it must not remove information.

10. Tech Stack

• HTML — page structure for the single Landing page. Source-specified.
• CSS — all styling, the 12-column modular grid, the ruled table, the discrete strength bars, and the restrained motion. Source-specified.
• JavaScript — the simulated network dataset, the scan interaction, the 900ms MEMINDAI… state, the 40ms staggered row entry, the 60ms stepped bar fill, and the header counter and dial summary updates. Source-specified.
• Fonts — Archivo (headings) and Fira Sans (body), loaded as web fonts. Source-specified by the creative direction.
• Storage — none. The application holds no durable user state and persists nothing.
• Backend, Docker, Kubernetes — none. The current delivery is a static client-side page with no server component.

11. Assumptions and Constraints

Assumptions

• A-1. The simulated network dataset is authored as part of the application and contains a fixed set of network records with name, band, channel, strength, and dBm values. [Default — not specified by user]
• A-2. The list is ordered strongest-first, so the strongest network is the first row and carries the 3px orange left edge. [Default — not specified by user]
• A-3. The header counter reflects the number of networks currently in the displayed result set. [Default — not specified by user]
• A-4. The scan duration of 900ms and the 40ms / 60ms step timings come from the creative direction and are presentation defaults, not product behaviour. [Default — not specified by user]

Constraints

• C-1. The application must be simple and built only with HTML, CSS, and JavaScript. explicit
• C-2. The Wi-Fi network data must be simulated/dummy data, not a real network scan. explicit
• C-3. The application must display a list of Wi-Fi networks available in the surroundings. explicit
• C-4. The list must display the names of the Wi-Fi networks. explicit
• C-5. No blue or indigo accent may be used; orange #E4570E is the only signal colour. explicit (creative direction)
• C-6. Inter, Roboto, Arial, Helvetica, Poppins, and system-ui are forbidden for headings and body. explicit (creative direction)
• C-7. No gradient-blob heroes, glassmorphism, frosted panels, hover-lift card grids, centred headline-plus-CTA compositions, smooth wave or radial-gradient signal meters, decorative motion, parallax, particles, bouncy easing, rounded-pill buttons, or radii above 8px. explicit (creative direction)
• C-8. The generic indigo/blue-on-white SaaS template is forbidden for this project. explicit

Out of current scope

• Real Wi-Fi scanning, live signal measurement, and any device radio permission request.
• Connecting to, authenticating with, or managing any network.
• Accounts, sign-in, saved or favourited networks, history, sharing, and export.
• Additional pages or navigation beyond the single Landing page.

12. Glossary

• SSID / Nama Jaringan — the name of a Wi-Fi network, displayed in the name column of the network table.
• Band — the radio frequency band a network operates on: 2.4GHz, 5GHz, or 6GHz.
• Channel — the numbered channel within a band on which a network operates.
• dBm — the unit in which signal strength is expressed, shown in tabular numerals in the network table.
• Strength bars — the five discrete rectangular orange bars per row that render a network's signal strength. Never a smooth wave or gradient meter.
• Simulated / dummy data — network records authored inside the application, not obtained from a real network scan.
• Scan — the user-triggered action that re-presents the network list from the simulated dataset. It does not touch the device's Wi-Fi hardware.
• Landing — the single anonymous page that is both the entry point and the working surface of the application.
• Pengguna Pencari Jaringan Wi-Fi — the single accepted active human persona: an ordinary user who opens the page to recognise which Wi-Fi network names are available around them.