System Requirements Document for sma-frateran-podor

1. Introduction

This document specifies the system requirements for sma-frateran-podor, a free (gratis) website for SMA Frateran Podor, an Indonesian public high school. The product intent is derived directly from the authoritative user requirement thread: build a no-cost website for a school. The website serves two audiences: members of the school community and the public who need to find information about the school, and school staff who are responsible for keeping the school's published information accurate and current.

The website must be free — no cost to the requester. This is an explicit hard constraint. The design language is drawn from the supplied creative direction (Paula Scher poster typography), which gives the school an identity it can own without photo budgets, stock imagery, or licensing costs, while remaining legible and orderly for staff-facing content management.

2. System Overview

The system is a first-party web application with a public-facing school information surface and a protected staff content-management workflow. It is delivered as a custom UI with application-owned identity.

Actors:

• School Website Visitor — anonymous public visitor who browses published school information.
• School Content Administrator — school staff who authenticate and manage the school's durable published content.

Accepted behavior:

• Anonymous visitors can read the school's published information on the Landing and School Information pages.
• School staff are provisioned or invited before first access, complete returning verification, and then manage durable website content through the Content and Content Editor pages.

Ownership:

• All five pages (Landing, Login, School Information, Content, Content Editor) are first-party application-owned custom pages.
• Identity is application-owned. Staff access to Content and Content Editor is role-restricted; Landing, Login, and School Information are publicly accessible.

Narrow exclusions:

• No adjacent account-management capabilities beyond provisioning/invitation and returning verification.
• No differentiated permissions beyond the staff role restriction on Content and Content Editor.
• No payment, e-commerce, or paid-tier functionality — the website must be free.

2a. Product Interpretation and Delivery Boundary

The website is delivered as a first-party web application. Public information is anonymously reachable; the staff content-management workflow is protected by application-owned identity. School staff are provisioned or invited before first access, then complete returning verification before managing durable content. The current delivery horizon covers the Landing, Login, School Information, Content, and Content Editor pages. No future-horizon features are specified in the authoritative source; nothing beyond the accepted behavior above is in scope.

2b. Source Content Inventory

No content_source reference directive was supplied. This section is intentionally omitted.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Full-viewport poster hero with the school name "SMA FRATERAN PODOR" set in Anton, all caps, stacked flush-left, bleeding off the right edge. A solid Scher-red rectangle sits behind the third line. A 6-degree rotated yellow band carries the school's tagline and "PPDB" in small caps. A black rectangular slab CTA "Lihat Informasi Sekolah" pinned bottom-left; a text link "Masuk Staf" bottom-right.
• Primary actions: Navigate to School Information ("Lihat Informasi Sekolah"); navigate to Login ("Masuk Staf").
• Supporting actions: Marquee band of school words (visi misi, ekstrakurikuler, prestasi, PPDB) scrolling continuously; stops and wraps into static rows under prefers-reduced-motion.
• Domain entities: School name, tagline, PPDB reference, school words for marquee.
• Component responsibilities: Poster hero panel; red block behind headline line; rotated yellow marquee band; primary CTA slab; secondary text link; full-bleed 4px black section rules.
• States:
  • Loading: Static poster renders immediately; no data dependency for hero.
  • Empty: Not applicable — hero content is static.
  • Success: Visitor reads school name and tagline, selects a CTA.
  • Error: Not applicable for static hero.
  • Recovery: Not applicable.

Login

• Information/state: Anonymous access surface for returning school staff. Identity verification form.
• Primary actions: Submit credentials for returning verification; proceed to Content upon success.
• Supporting actions: Navigate back to Landing.
• Domain entities: Staff identity, verification credential.
• Component responsibilities: Verification form; submit control; error display; link back to Landing.
• States:
  • Loading: Submit control disabled with progress indication during verification.
  • Empty: Form fields empty on first render.
  • Success: Verified staff redirected to Content.
  • Error: Invalid credentials shown with a clear message; form remains editable for retry.
  • Recovery: Staff can re-enter credentials; provisioning/invitation path is handled out-of-band per the accepted boundary.

School Information

• Information/state: Public destination for browsing the school's published information. Two-column reading grid with a colour-coded left rail of category blocks. Every news item, announcement, and class carries a red, yellow, or teal tag chip that also tints its left rail.
• Primary actions: Browse published school information; read individual items.
• Supporting actions: Navigate back to Landing; navigate to Login ("Masuk Staf").
• Domain entities: Published school information items, category tags (red/yellow/teal), announcements, news, class/unit labels.
• Component responsibilities: Two-column reading grid; colour-coded left rail; category tag chips; item cards with hard 4px offset black shadow flipping to inverted colour on hover; full-bleed 4px black section rules.
• States:
  • Loading: Skeleton or progress indication while published content loads.
  • Empty: Message indicating no published information is currently available.
  • Success: Visitor reads the school information they came for.
  • Error: Load failure message with retry control.
  • Recovery: Retry reloads published content.

Content

• Information/state: Role-restricted staff destination for reviewing and managing the school's durable website content. Dense tabular grid with black hairlines and colour-coded status chips.
• Primary actions: Review existing content items; select an item to edit; create a new content item.
• Supporting actions: Navigate to Content Editor; sign out.
• Domain entities: Content items, status (colour-coded chips), category tags (red/yellow/teal), publication state.
• Component responsibilities: Dense tabular grid; black hairlines; status chips; row selection; create-new control; sign-out control.
• States:
  • Loading: Table skeleton while content list loads.
  • Empty: Message indicating no content items exist yet, with a create-new control.
  • Success: Staff sees the current content list and can select or create items.
  • Error: Load failure message with retry control.
  • Recovery: Retry reloads the content list.

Content Editor

• Information/state: Role-restricted focused staff workspace for adding and updating published school content. Split view: fields on the left, live poster preview on the right, both inside the same grid rules.
• Primary actions: Add a new content item; update an existing content item; publish/save changes.
• Supporting actions: Return to Content; discard changes.
• Domain entities: Content item fields, category tag (red/yellow/teal), publication state, live poster preview.
• Component responsibilities: Field column; live poster preview column; save/publish control; discard control; return-to-Content control; validation display.
• States:
  • Loading: Editor fields and preview load for the selected item.
  • Empty: New-item mode with blank fields and empty preview.
  • Success: Saved/published item reflected in Content and on public pages.
  • Error: Validation or save failure shown with a clear message; fields remain editable.
  • Recovery: Staff corrects fields and retries save; discard returns to Content without changes.

3. Functional Requirements

FR-1 — Free school website As a school, I should have a free (gratis) website so that the school can publish information at no cost to the requester.

• Provenance: explicit
• Actor: School (requester)
• Trigger/input: Request for a no-cost website.
• Observable result: A functioning school website delivered with no cost to the requester.
• Access state: Public.
• Failure/recovery: Not applicable — this is a delivery constraint.
• Continuation: School staff can manage content; visitors can read it.

FR-2 — Anonymous school entry As a School Website Visitor, I should land on a public entry page that presents the school so that I can understand what the school is and where to go next.

• Provenance: required_inference
• Actor: School Website Visitor
• Trigger/input: Visiting the site root.
• Observable result: Landing page renders the school name, tagline, and navigation controls.
• Access state: Anonymous, no identity required.
• Failure/recovery: Static hero renders without data dependency.
• Continuation: Visitor selects "Lihat Informasi Sekolah" or "Masuk Staf".

FR-3 — Browse published school information As a School Website Visitor, I should browse the school's published information so that I can read the details I came for.

• Provenance: required_inference
• Actor: School Website Visitor
• Trigger/input: Selecting "Lihat Informasi Sekolah" from Landing.
• Observable result: School Information page displays published items with colour-coded category tags.
• Access state: Anonymous, no identity required.
• Failure/recovery: Load failure shows a message with retry; retry reloads content.
• Continuation: Visitor reads items and can return to Landing or proceed to Login.

FR-4 — Staff provisioning or invitation before first access As a School Content Administrator, I should be provisioned or invited before first access so that only authorized staff can reach the protected content-management workflow.

• Provenance: required_inference
• Actor: School Content Administrator
• Trigger/input: School provisions or invites the staff member.
• Observable result: Staff member has an identity that can complete returning verification.
• Access state: Pre-identity; provisioning/invitation handled out-of-band per the accepted boundary.
• Failure/recovery: Not applicable within the product surface.
• Continuation: Staff member proceeds to Login for returning verification.

FR-5 — Returning verification As a School Content Administrator, I should complete returning verification so that I can access the protected content-management workflow.

• Provenance: required_inference
• Actor: School Content Administrator
• Trigger/input: Submitting credentials on the Login page.
• Observable result: Verified staff are granted access to Content.
• Access state: Anonymous entry on Login; protected state becomes available only after verification.
• Failure/recovery: Invalid credentials show a clear error; the form remains editable for retry.
• Continuation: Verified staff proceed to Content.

FR-6 — Review and manage durable content As a School Content Administrator, I should review and manage the school's durable website content so that the published site reflects the school's latest details.

• Provenance: required_inference
• Actor: School Content Administrator
• Trigger/input: Opening Content after verification.
• Observable result: Dense tabular grid shows content items with colour-coded status chips.
• Access state: Role-restricted; requires completed returning verification.
• Failure/recovery: Load failure shows a message with retry; retry reloads the list.
• Continuation: Staff select an item to edit or create a new item.

FR-7 — Add and update published content As a School Content Administrator, I should add and update published school content so that visitors see correct information.

• Provenance: required_inference
• Actor: School Content Administrator
• Trigger/input: Opening Content Editor from Content, editing fields, and saving/publishing.
• Observable result: Saved/published item is reflected in Content and on public pages.
• Access state: Role-restricted; requires completed returning verification.
• Failure/recovery: Validation or save failure shows a clear message; fields remain editable for correction and retry.
• Continuation: Staff return to Content or continue editing.

4. User Personas

School Website Visitor

• Product context: Members of the school community and the public who need to find information about SMA Frateran Podor.
• Primary goal: Read the school information they came for.
• Distinct accepted responsibilities: Browse the site's public pages to learn what the school offers and locate the details they need.
• Relevant inputs or decisions: Choosing which published information to read; deciding whether to proceed to the staff login.
• Interactions with other accepted participants: None directly; the visitor consumes content published by the School Content Administrator.
• Observable success: The visitor can read the school information they came for on the School Information page.
• What makes this role different: The visitor is anonymous and read-only; they never authenticate and never change durable state.

School Content Administrator

• Product context: School staff responsible for keeping the school website's information accurate and current.
• Primary goal: Ensure the published site reflects the school's latest details.
• Distinct accepted responsibilities: Complete returning verification; review and manage durable content; add and update published school content.
• Relevant inputs or decisions: Content item fields, category tag selection (red/yellow/teal), publication state, save/publish decisions.
• Interactions with other accepted participants: Their published content is consumed by the School Website Visitor.
• Observable success: The published site reflects the school's latest details.
• What makes this role different: The administrator is authenticated, role-restricted, and writes durable state; they are provisioned or invited before first access and must complete returning verification.

5. Core User Flows

Flow A — Visitor reads school information

1. Starting context: The visitor opens the site root anonymously.
2. Owner: Landing.
3. Action: The visitor reads the poster hero — "SMA FRATERAN PODOR" in Anton, the red block behind the third line, the rotated yellow band with the tagline and "PPDB".
4. Decision: The visitor selects "Lihat Informasi Sekolah".
5. Owner: School Information.
6. Observable result: The two-column reading grid renders published items with colour-coded category tags and tinted left rails.
7. Continuation: The visitor reads the items they came for. If content fails to load, a message with a retry control appears; retry reloads the content.
8. Next step: The visitor may return to Landing or select "Masuk Staf".

Flow B — Staff completes returning verification

1. Starting context: A provisioned or invited staff member opens the site anonymously.
2. Owner: Landing.
3. Action: The staff member selects "Masuk Staf".
4. Owner: Login.
5. Action: The staff member submits credentials for returning verification.
6. Observable result: On success, the staff member is granted access to Content.
7. Failure/recovery: Invalid credentials show a clear error; the form remains editable and the staff member retries.
8. Continuation: Verified staff proceed to Content.

Flow C — Staff reviews and manages content

1. Starting context: A verified staff member is on Content.
2. Owner: Content.
3. Observable result: The dense tabular grid shows content items with black hairlines and colour-coded status chips.
4. Decision: The staff member selects an existing item to edit or chooses to create a new item.
5. Continuation: The staff member proceeds to Content Editor. If the list fails to load, a message with a retry control appears; retry reloads the list.

Flow D — Staff adds or updates published content

1. Starting context: A verified staff member is on Content Editor.
2. Owner: Content Editor.
3. Action: The staff member edits fields on the left and reviews the live poster preview on the right.
4. Decision: The staff member saves/publishes the item.
5. Observable result: The saved/published item is reflected in Content and on the public pages.
6. Failure/recovery: Validation or save failure shows a clear message; fields remain editable for correction and retry.
7. Continuation: The staff member returns to Content or continues editing. Discard returns to Content without changes.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. Muse: Paula Scher. Headline: typography as a school gate — the school's own name becomes the image.

Colour tokens (light mode):

• Background (warm paper ground): #F4EFE6
• Surface: #FFFFFF
• Text: #111111
• Primary (Scher red): #E03C31
• Accent (poster yellow): #F2B705
• Muted: #6E6A63
• Third coded category (teal): #0E7C7B

Colour rules: Never more than two block colours visible in one viewport; red ≈ 60% of coloured area, yellow ≈ 25%, teal ≈ 15%. Body text always #111111 on paper or white. No coloured text on coloured grounds except white on red at 24px+.

Typography:

• Headings: Anton, all-caps, leading 0.86–0.92, tracking -0.01em; headlines stack in 2–4 lines spanning the viewport edge to edge.
• Sub-heads: Archivo 700 uppercase, 0.14em tracking, small sizes.
• Body: Archivo 400/500 at 17–19px, 1.6 leading.
• Scale (1.333 modular, poster rhythm): display clamp(56px, 11vw, 168px) / section head clamp(32px, 5vw, 64px) / sub-head 20px caps / body 18px / label 13px caps. Mobile display starts at 56px; nothing below 13px.

Shape language: Hard edges only — zero border radius on cards, buttons, images, and inputs. Rules are 2px or 4px solid black. Colour blocks are perfect rectangles meeting at right angles, bleeding off the viewport edge. Diagonal bands appear only as 6–8 degree rotated red or yellow strips carrying marquee text. Buttons are rectangular slabs of flat colour with an offset 4px black shadow.

Layout: Visible 12-column poster grid, 24px gutters, 48–96px outer margins at desktop; 4 columns and 20px margins at 375px. Sections separated by full-width 4px black rules. Landing is a stack of poster panels. Public information pages use a two-column reading grid with a colour-coded left rail. Staff content list is a dense tabular grid with black hairlines and colour-coded status chips. Editor is a split view: fields left, live poster preview right, both inside the same grid rules.

Imagery: Typography is the imagery. Where a photograph is unavoidable, it is treated as a high-contrast duotone in black + Scher red or black + yellow, cropped hard to a rectangle, bled off one edge or locked inside a colour block. Decorative marks are simple flat pictograms, oversized punctuation, and rotated colour bands. No soft shadows, no gradients, no rounded stock-photo cards, no illustration for its own sake.

7. Signature Design Concept

The public entry is a full-viewport poster, not a SaaS hero. The words "SMA FRATERAN PODOR" are set in Anton at clamp(56px, 11vw, 168px), all caps, stacked in four flush-left lines that bleed off the right edge of the viewport, printed black on the warm paper ground. Behind and around the third line sits a solid Scher-red rectangle that overlaps the descenders. A 6-degree rotated yellow band carrying the school's tagline and "PPDB" in small caps cuts across the lower third. There is no image and no button in the centre. The single call to action is a black rectangular slab pinned to the bottom-left grid line reading "Lihat Informasi Sekolah", with a second text link "Masuk Staf" at bottom-right. On mobile the headline wraps to six lines at 56px, the red block sits behind the school name only, and the yellow band runs full-bleed under the type with its text fully inside the safe area.

This concept recomposes only accepted content and controls: the school name, tagline, PPDB reference, the "Lihat Informasi Sekolah" navigation to School Information, and the "Masuk Staf" navigation to Login.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The oversized stacked school name "SMA FRATERAN PODOR" in Anton, with the flat red block printed behind one line and the rotated yellow marquee band.
• Input → transformation → outcome thesis: As the page loads, section headings wipe in as flat colour blocks that slide away to reveal the type underneath (200–320ms, hard ease-out, no bounce); the yellow band's marquee of school words (visi misi, ekstrakurikuler, prestasi, PPDB) scrolls continuously across the full-width strip. The outcome is a poster that reads as alive and in motion without any parallax, particles, or float.
• Motion vocabulary: Type-led and poster-mechanical — hard colour-block wipes, continuous marquee, instant hover colour flips (paper→red, black→white) on cards and buttons. No bounce, no float, no parallax.
• Composed first frame: The full-viewport poster at rest — four flush-left Anton lines bleeding off the right edge, red block behind the third line, rotated yellow band across the lower third, black CTA slab bottom-left, "Masuk Staf" text link bottom-right.
• Reduced-motion state: The marquee becomes a static wrapped row of words; all reveals render in their final state.

9. Non-Functional Requirements

• NFR-1 — Cost: The website must be free (gratis) — no cost to the requester. Provenance: explicit. Rationale: explicit hard constraint in the authoritative user evidence.
• NFR-2 — Readable text and controls: Headlines, wordmarks, labels, numbers, cards' text, 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. Provenance: creative direction. Rationale: accessibility and legibility.
• NFR-3 — Reduced motion: With prefers-reduced-motion, the marquee stops and shows whole items (wrapped rows or a horizontally scrollable row with overflow-x: auto); all reveals render in their final state. Provenance: creative direction. Rationale: accessibility.
• NFR-4 — Colour contrast: Body text is always #111111 on paper or white; coloured grounds carry white type at 24px+ only. Provenance: creative direction. Rationale: legibility and contrast.
• NFR-5 — Identity continuity: Staff identity is application-owned; provisioning/invitation precedes first access, and returning verification is required before managing durable content. Provenance: required_inference. Rationale: makes the accepted staff journey executable.

10. Tech Stack

• Frontend: React (custom UI, poster-grid layout, split-view editor).
• Backend: Python / FastAPI (content management API, identity verification).
• Storage: Appropriate persistent storage for durable school content and staff identity records.
• Deployment: Docker / docker-compose for local and single-host deployment. Kubernetes is not required by the source and is omitted.

11. Assumptions and Constraints

• Assumption: The website is delivered as a first-party web application with application-owned identity, per the accepted Planning Scope.
• Assumption: School staff are provisioned or invited out-of-band before first access; the product surface does not include adjacent account-management capabilities.
• Assumption: The staff role restriction on Content and Content Editor is the only differentiated access control; no further RBAC is specified.
• Constraint: The website must be free (gratis) — no cost to the requester.
• Constraint: No payment, e-commerce, or paid-tier functionality.
• Constraint: The generic indigo/blue-on-white SaaS template is forbidden for this project.
• Constraint: No border radius, glassmorphism, blur, or soft drop shadows anywhere.

12. Glossary

• Gratis: Free of cost to the requester.
• SMA: Sekolah Menengah Atas — Indonesian public high school.
• PPDB: Penerimaan Peserta Didik Baru — new student admissions.
• Visi misi: School vision and mission statements.
• Ekstrakurikuler: Extracurricular activities.
• Prestasi: Achievements.
• School Website Visitor: Anonymous public visitor who reads published school information.
• School Content Administrator: Authenticated school staff member who manages durable published content.
• Returning verification: The credential check a provisioned or invited staff member completes on the Login page before accessing protected content management.
• Durable content: Published school information that persists and is visible to visitors.