System Requirements Document for toren-jemuran

1. Introduction

toren-jemuran is a home-layout planning experience for a homeowner to update and review a house plan showing a water tank moved out of the child’s room to beside the jemuran (clothes-drying area), with a new door from the jemuran toward the tank. The plan must leave the child’s room free of the tank and make the tank straightforward to reach for maintenance.

The current audience is the Pemilik Rumah (Homeowner), who creates and saves the requested plan change.

2. System Overview

The application provides an anonymous entry, first-use registration, returning login, and a protected floor-plan workspace. The homeowner reviews and updates the plan, then saves it for later access. Application-owned identity and durable storage support that continuity.

The accepted plan change is specific: remove the tank from the child’s room, place it beside—not above—the jemuran, and add a door connecting the jemuran toward the tank. The plan and its change summary communicate these outcomes. The supplied reference image provides residential floor-plan context only; it does not require reproducing its full layout or adding its other rooms, dimensions, or features.

No other human persona, collaboration workflow, home-design capability, or future feature is established.

2a. Product Interpretation and Delivery Boundary

The application owns the plan-editing experience and saved plan state. Landing is anonymously reachable. Sign Up and Login are anonymous identity-entry surfaces. Floor Plan requires login; saved plan state is available to the verified homeowner. Registration and login are limited to establishing and verifying the identity needed to create, save, and resume the plan. No additional account-management capabilities or differentiated permissions are specified.

The current delivery includes the requested tank relocation and doorway in the plan, durable saving, and returning review. It does not include construction execution, professional approval, or unrelated changes to the reference floor plan.

2c. Page Content and Component Coverage

Landing

• Information and state: A concise explanation that the application supports updating a house plan to show the tank beside the jemuran, clear of the child’s room, with access from a new door. The entry is public and does not expose protected saved plan state.
• Primary actions: Continue to Sign Up or Login.
• Supporting components: Project introduction and a restrained preview of the requested plan change.
• Domain entities: Requested plan-change summary; no private saved plan is exposed here.
• States: Loading is not applicable to static entry content. If entry content fails to load, show a clear error and a way to retry or continue when available. Success is the homeowner choosing an identity-entry path. Recovery returns the homeowner to this entry surface.

Sign Up

• Information and state: First-use identity establishment for the homeowner before creating and saving a plan.
• Primary actions: Provide the information required to register and submit.
• Supporting components: Registration form, submission status, and validation or error feedback.
• Domain entities: Application identity and registration result.
• States: Show submission progress; on success, continue to Floor Plan. On invalid or failed submission, explain the issue and allow correction or retry. No additional profile or account-management workflow is included.

Login

• Information and state: Returning identity verification before accessing a saved plan.
• Primary actions: Provide login credentials and submit.
• Supporting components: Login form, submission status, and validation or error feedback.
• Domain entities: Application identity, verification result, and access to the homeowner’s saved plan.
• States: Show submission progress; on success, continue to Floor Plan with the saved plan available. On invalid or failed verification, explain the issue and allow correction or retry. No additional account-recovery capability is specified.

Floor Plan

• Information and state: The homeowner’s editable and saved house plan, with the tank beside—not above—the jemuran, no tank in the child’s room, and a door from the jemuran toward the tank. Show the plan as the dominant surface and a compact ordered change summary: “Toren dipindah”, “Kamar anak tetap lega”, and “Akses pintu dari jemuran”.
• Primary actions: Review the plan, make the requested placement and doorway changes, and save the updated plan.
• Supporting components: A top-down plan drawing; readable room and feature labels; a sage-highlighted tank labeled “Toren baru”; a visibly empty former tank location in the child’s room; a terracotta door leaf and swing arc showing the jemuran-to-tank connection; change summary; and save/review actions.
• Domain entities: House plan, room locations, tank placement, doorway connection, and saved plan state.
• States: On loading, indicate that the plan is being retrieved. If no saved plan is available, present the plan-editing state needed to make the accepted change. On successful save, visibly confirm that the updated plan is saved. On load or save failure, preserve the current editable state where possible, explain the failure, and allow retry. After saving, the homeowner can review the saved plan; on a later visit, login returns them to that saved plan.
• Responsive presentation: At 1280px, place the plan beside its change summary. At 768px and 375px, stack them in reading order. Keep the plan navigable and all labels and controls readable without clipping.

3. Functional Requirements

1. As a Pemilik Rumah, I should be able to understand the purpose of toren-jemuran from its public entry.

   • Provenance: required_inference — the anonymous entry is specified in the accepted page contract.
   • Lifecycle: From Landing, the homeowner sees that the application supports the requested tank relocation and doorway change, then chooses Sign Up for first use or Login to return.
   • Access: Anonymous.
   • Observable acceptance: The entry explains the accepted plan change without exposing protected saved plan state.
   • Failure and continuation: If entry content fails to load, the homeowner can retry or continue when available.

2. As a Pemilik Rumah, I should be able to establish an application identity before creating and saving a plan.

   • Provenance: required_inference — required for the accepted durable, actor-specific plan lifecycle.
   • Lifecycle: The homeowner opens Sign Up, submits the information required for registration, and receives a success or actionable failure result. On success, the homeowner continues to Floor Plan.
   • Access: Sign Up is anonymously reachable; the plan workspace requires login.
   • Observable acceptance: Successful registration establishes the identity needed to save and later resume the homeowner’s plan.
   • Failure and recovery: Invalid or failed registration is reported; the homeowner can correct the input or retry.
   • Continuation: Successful registration leads to the plan workspace. No additional account-management behavior is included.

3. As a Pemilik Rumah, I should be able to verify my identity when returning to access my saved plan.

   • Provenance: required_inference — specified as a prerequisite for returning access to durable plan state.
   • Lifecycle: The homeowner opens Login, submits credentials, and receives a verification result. On success, the saved plan is available in Floor Plan.
   • Access: Login is anonymously reachable; saved plan access requires successful login.
   • Observable acceptance: Successful verification returns the homeowner to their saved plan.
   • Failure and recovery: Invalid or failed verification is reported; the homeowner can correct the input or retry.
   • Continuation: After verification, the homeowner reviews the saved plan. No additional account-recovery behavior is specified.

4. As a Pemilik Rumah, I should be able to move the water tank out of the child’s room and place it beside the jemuran, not above it.

   • Provenance: explicit.
   • Lifecycle: In Floor Plan, the homeowner reviews the plan and makes the requested placement change. The plan shows the tank beside the jemuran and the former child-room location free of the tank.
   • Access: Login required.
   • Observable acceptance: The plan does not place the tank in the child’s room or on top of the jemuran; it shows the tank beside the jemuran and the child’s room clear of it.
   • Failure and recovery: If the plan cannot be loaded or saved, report the failure and allow retry; preserve the current editable state where possible.
   • Continuation: The homeowner can review and save the updated plan.

5. As a Pemilik Rumah, I should be able to add a door from the jemuran toward the water tank.

   • Provenance: explicit.
   • Lifecycle: In Floor Plan, the homeowner reviews and updates the plan to show the new doorway connecting the jemuran toward the tank. The plan depicts the door leaf and swing arc so the connection is clear.
   • Access: Login required.
   • Observable acceptance: The doorway connects from the jemuran toward the tank; it is not shown as an unrelated or disconnected door.
   • Failure and recovery: If the plan cannot be loaded or saved, report the failure and allow retry; preserve the current editable state where possible.
   • Continuation: The homeowner can review and save the updated plan.

6. As a Pemilik Rumah, I should be able to save and later review the updated plan.

   • Provenance: required_inference — durable storage and returning access are required by the accepted plan-creation and review lifecycle.
   • Lifecycle: After making the requested changes in Floor Plan, the homeowner saves the plan and receives a visible result. On a later visit, the homeowner logs in and reviews the saved plan.
   • Access: Login required for the saved plan.
   • Observable acceptance: The saved plan retains the tank beside the jemuran, the child’s room clear of the tank, and the new jemuran-to-tank door.
   • Failure and recovery: A failed save is reported and can be retried; preserve the current editable state where possible. A failed load is reported and can be retried.
   • Continuation: After successful save or later retrieval, the homeowner can review the plan.

4. User Personas

Pemilik Rumah

• Provenance: required_inference in the Planning Scope; the accepted active-human catalog contains this persona only.
• Product context: A homeowner updating a house plan to reflect a specific water-tank relocation and access change.
• Primary goal: Keep the child’s room free of the tank while placing the tank beside the jemuran and making it reachable through a new door from that area.
• Accepted responsibilities: Establish identity for first use, verify identity on return, review and update the plan, and save it for later review.
• Relevant decisions and inputs: Decide on the requested tank placement beside the jemuran and the doorway connection from the jemuran toward the tank.
• Interaction with other participants: No other accepted human participant is involved. The application stores and returns the homeowner’s plan.
• Observable success: The saved plan shows the tank beside—not above—the jemuran, no tank in the child’s room, and a clear door connection from the jemuran toward the tank.

5. Core User Flows

First-use plan update

1. The homeowner opens Landing anonymously and reads that the application supports the requested tank relocation and doorway change.
2. The homeowner chooses Sign Up and submits the information required to establish an application identity.
3. If registration fails, the homeowner sees an actionable error and can correct the input or retry. On success, the homeowner continues to Floor Plan.
4. The homeowner reviews the plan and updates it so the tank is beside—not above—the jemuran and the child’s room is free of the tank.
5. The homeowner adds the door from the jemuran toward the tank. The plan shows the door leaf and swing arc at the connection.
6. The homeowner reviews the ordered change summary: “Toren dipindah”, “Kamar anak tetap lega”, and “Akses pintu dari jemuran”.
7. The homeowner saves the plan. A successful save is visibly confirmed. If saving fails, the homeowner receives an error, can retry, and retains the current editable state where possible.
8. The homeowner reviews the saved plan in Floor Plan.

Returning plan review

1. The homeowner opens Login anonymously and submits credentials.
2. If verification fails, the homeowner sees an actionable error and can correct the input or retry.
3. On successful verification, the homeowner enters Floor Plan and the saved plan is retrieved.
4. The homeowner reviews the tank beside the jemuran, the child’s room clear of the tank, and the door connection from the jemuran toward the tank.
5. If the plan cannot be loaded, the homeowner sees an error and can retry. On successful retrieval, the homeowner can continue reviewing the saved plan.

6. Visuals Colors and Theme

Muse: Kenya Hara
Headline: A calm, legible plan for a more considered home

Use the floor plan—not decorative interface elements—as the primary visual. The tone is calm and reassuring, helping the homeowner understand the tank’s new position, the clear child’s room, and the direct access from the jemuran.

• Light-mode color tokens:
  • Background: #F5F2EA warm paper.
  • Surface: #FFFEFA off-white plan surface.
  • Text: #282923 charcoal.
  • Primary: #526B55 muted sage for key plan state and controls.
  • Accent: #B96B4B restrained terracotta for the new door or pending change.
  • Muted: #D9D4C8 supporting neutral.
• Typography: Newsreader, regular weight, for headings; Fira Sans for body copy and labels. Use clear medium-weight sans-serif labels and plan annotations.
• Type scale: Responsive 1.25 rhythm: display 40px on mobile to 72px on desktop; section headings 30–40px; body 16–18px; labels 13–14px. Scale or wrap text so it remains fully inside its container.
• Shape and line language: Quiet architectural geometry, fine charcoal rules, square-cornered plan lines, restrained rounded control surfaces, and small consistent door-swing arcs.
• Layout: A concise project header, dominant editable plan, and clearly grouped change summary with save/review actions. At 1280px, place plan and summary side by side; at 768px and 375px, stack them in reading order.

• Plan rendering: Use crisp, high-contrast architectural lines and restrained room fills. Highlight the tank beside the jemuran in sage with a readable “Toren baru” label; leave its former child-room location visibly empty; show the new door leaf and swing arc in terracotta.
• Responsive readability: At 375px, 768px, and 1280px, keep all readable text and controls within their containers and the viewport. Reflow or scale content rather than clipping it. Keep the plan navigable and labels readable.
• Motion and reduced motion: Use brief, purposeful fades for state changes and a subtle highlight when the tank position or doorway is selected. Do not use looping decoration or motion that obscures plan details. Provide a complete usable static arrangement when reduced motion is preferred.
• Avoid: Placing the tank in the child’s room or above the jemuran; showing a doorway that does not connect the jemuran toward the tank; reproducing the reference image’s full page structure or adding unrelated room details; generic blue-on-white styling, gradient blobs, identical hover-lift cards, low-contrast labels, clipped controls, decorative overlays over readable information, unrelated stock photography, ornamental illustration, or distracting motion.

7. Signature Design Concept

Open on a warm-paper plan workspace with a large top-down house-plan drawing as the main visual field. A narrow header carries the project title and a compact change summary rather than a centered marketing headline. The plan marks the tank’s new position beside the jemuran with a sage outline and the label “Toren baru”; the child’s room is visibly free of the tank. A terracotta door leaf and swing arc make the jemuran-to-tank connection unmistakable. Keep the review/save action beside the summary on desktop and below it on mobile. Use fine architectural rules and generous breathing room; do not add decorative card grids or unrelated room details.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The top-down floor plan, with the tank beside the jemuran, the child’s room clear, and the new doorway visible.
• Input → transformation → outcome: The homeowner opens the plan workspace → the requested tank placement and doorway are clearly highlighted → the homeowner can review the resulting plan and its ordered change summary. This communicates accepted behavior without adding a new interaction.
• Motion vocabulary: Almost still; brief purposeful fades for state changes and a subtle highlight on the tank position or doorway. No looping decoration and no motion that obscures plan details.
• Composed first frame: Warm-paper workspace, narrow project header, dominant plan, sage tank marker, empty former child-room location, terracotta door leaf and swing arc, and compact change summary with review/save action.
• Reduced-motion state: Present the complete plan and change summary as a usable static arrangement. Do not rely on animation to communicate the tank location or doorway.

9. Non-Functional Requirements

1. Plan-state durability

   • Provenance: required_inference.
   • The application must durably store the homeowner’s updated tank placement, removal from the child’s room, and new doorway so the plan can be retrieved after returning login.
   • Rationale: Required for the accepted save-and-review lifecycle.

2. Responsive readability

   • Provenance: Explicit in the Creative Direction.
   • At 375px, 768px, and 1280px, readable text and controls must remain fully within their containers and the viewport. The plan, labels, and controls must remain navigable and readable at these sizes.
   • Rationale: The direction explicitly requires these viewport checks and responsive reflow.

3. Reduced-motion usability

   • Provenance: Explicit in the Creative Direction.
   • With reduced motion preferred, the plan and its change information must remain fully usable in a static arrangement.
   • Rationale: The direction requires a complete static arrangement.

4. Plan legibility

   • Provenance: Explicit in the Creative Direction.
   • Use crisp, high-contrast architectural lines and legible labels; do not allow decorative overlays or motion to obscure plan details.
   • Rationale: The plan is the primary means of communicating the accepted change.

10. Tech Stack

• Frontend: React — [Default — not specified by user]
• Backend: Python/FastAPI — [Default — not specified by user]; one shared backend supports identity verification and durable plan storage.
• Storage: Persistent application storage for homeowner identity association and saved plan state — [Default — not specified by user]
• Deployment: Docker and docker-compose — [Default — not specified by user]

No separate worker or additional service is required by the accepted workflows.

11. Assumptions and Constraints

• The accepted active-human persona is Pemilik Rumah only.
• The versioned page contract is final and ordered: Landing, Sign Up, Login, Floor Plan. Their access boundaries are preserved: Landing, Sign Up, and Login are anonymously reachable; Floor Plan requires login.
• Application-owned identity and durable plan storage are required to create, save, and later retrieve the homeowner’s plan. Registration and login are limited to that purpose.
• The tank must not be in the child’s room and must be beside—not above—the jemuran.
• The new door must connect from the jemuran toward the tank.
• The reference image is optional visual context for a residential floor plan. Its other depicted rooms, dimensions, and features are not accepted requirements.
• No construction, contractor coordination, professional approval, collaboration, or unrelated home-layout changes are included.
• No future requirements are specified.

12. Glossary

• Jemuran: The clothes-drying area referenced in the requested plan change.
• Toren: The water tank to be moved beside the jemuran.
• Floor plan: The house-layout representation used to show the tank’s new position, the child’s room clear of the tank, and the new doorway connection.