System Requirements Document for hotel-booking

1. Introduction

hotel-booking is a modern hotel booking website serving two audiences: travellers who want to discover a hotel, reserve a room, and pay for it under their own account, and hotel administrators who need to keep hotel, room, booking, and payment records accurate and current. The product intent is a single web application that combines customer login, hotel search, room booking, payments, an admin dashboard, and a database backing all of it.

The audience is therefore split cleanly in two. Guest Customers are travellers who arrive without an account, enrol or sign in, search hotels, select a room, create a booking, and complete payment. Hotel Administrators are operations users who sign in to a protected dashboard and manage the hotel booking business through dedicated hotel, room, booking, and payment management surfaces.

The product is delivered as a first-party web application with application-owned identity: customers self-enrol and returning customers verify themselves, while administrators are provisioned and then verify themselves on return. All booking, payment, and management state is persisted in a database owned by the application.

2. System Overview

hotel-booking is a custom-UI web application with a backend and a database. It exposes eleven pages in a fixed, ordered information architecture:

1. Landing — anonymous public entry surface.
2. Login — identity access surface for returning customers and returning administrators.
3. Sign Up — identity access surface for first-use customer enrolment.
4. Hotel Search — customer hotel discovery.
5. Booking — room selection and creation of a customer booking (protected).
6. Payment — completion of payment for an existing room booking (protected).
7. Admin Dashboard — administrator operational overview and management entry point (protected).
8. Admin Hotels — hotel record management (protected).
9. Admin Rooms — room inventory management (protected).
10. Admin Bookings — reservation review and management (protected).
11. Admin Payments — payment record review and management (protected).

Actors. Two accepted human personas: Guest Customer and Hotel Administrator. The database is a system-owned persistence actor, not a persona. Any payment provider used to settle a booking is an external actor, not a persona.

Accepted behavior. Customers discover hotels, select rooms, create bookings, and pay for them. Administrators review and manage hotels, rooms, bookings, and payment records. Identity is application-owned: customers self-enrol through Sign Up and verify through Login; administrators are provisioned and verify through Login.

Ownership. All eleven pages are first-party application-owned custom pages. Persistence of accounts, hotels, rooms, bookings, and payment records is owned by the application database. Payment settlement for a booking is completed on the Payment page; where an external payment provider is involved, that provider owns only the settlement step, not the booking lifecycle.

Narrow exclusions. No capability beyond customer login, hotel search, room booking, payments, admin dashboard, and the backing database is in scope. No loyalty programme, no reviews, no messaging, no third-party channel management, and no reporting suite beyond what the admin dashboard and its management pages state are included.

2a. Product Interpretation and Delivery Boundary

Delivery. hotel-booking is delivered as a first-party web application with custom UI, a backend, and a database. There is no headless-only, provider-owned, or external-only delivery: every accepted human-facing capability has a first-party page owner.

Access ownership. Identity is application-owned. Customers establish identity themselves on Sign Up and verify it on Login. Administrators are provisioned before first use and verify themselves on Login. Landing, Login, Sign Up, and Hotel Search are reachable without an established session. Booking, Payment, Admin Dashboard, Admin Hotels, Admin Rooms, Admin Bookings, and Admin Payments are protected: their state is bound to the correct participant and is unavailable until identity is established. The interaction that establishes access to a protected destination never lives on that protected destination itself; it lives on Login and Sign Up.

Role separation. Customer-owned booking and payment state is bound to the customer who created it. Administrator management surfaces are bound to provisioned administrators. This separation is a source-stated constraint: customer login is required for customers, and the admin dashboard is for administrators.

Current and future boundary. Everything described in this document is current. No future-horizon capability is accepted; nothing in this document should be read as committing to a later phase.

2b. Source Content Inventory

No reference directive in this project declares content_source. There is no verified external factual inventory to preserve, and none is invented here.

2c. Page Content and Component Coverage

Landing

• Information and state. Anonymous public entry surface. Presents the hotel booking website, its travellers, and its hotel search and reservation purpose. No session required; no account-specific state is shown.
• Primary actions. Begin hotel search; go to Login; go to Sign Up.
• Supporting actions. Navigate to the search entry point from the hero composition.
• Domain entities. Hotels (as presented discovery content), search intent (destination, dates, guests).
• Component responsibilities. Hero composition carrying the display headline and the curved search capsule; featured hotels row; curved section dividers; navigation into identity surfaces.
• States. Loading: hero imagery and featured hotels resolve progressively. Empty: if no featured hotels are available, the featured row is omitted and the hero and search capsule remain fully usable. Success: the visitor understands the product and can start a search or reach Login/Sign Up. Error: if featured content fails to load, the hero, headline, and search capsule still render and search still starts. Recovery: retry featured content without blocking search.

Login

• Information and state. Identity access surface for returning customers and returning administrators. Anonymous; no protected state is shown before verification succeeds.
• Primary actions. Submit credentials to verify identity; continue to the destination the actor was seeking.
• Supporting actions. Navigate to Sign Up for a customer without an account.
• Domain entities. Customer account, administrator account, session.
• Component responsibilities. Credential form; verification feedback; routing to the correct protected destination after successful verification.
• States. Loading: verification in progress, submit disabled. Empty: initial form with no input. Success: identity verified, actor routed to the protected destination appropriate to their role. Error: invalid credentials produce a clear message and the form remains usable. Recovery: re-enter credentials; a customer without an account is directed to Sign Up.

Sign Up

• Information and state. First-use enrolment surface for customers. Anonymous.
• Primary actions. Submit enrolment details to establish a customer account.
• Supporting actions. Navigate to Login for a customer who already has an account.
• Domain entities. Customer account.
• Component responsibilities. Enrolment form; validation feedback; handoff to Login or directly into the customer's first authenticated step.
• States. Loading: submission in progress, submit disabled. Empty: initial form. Success: customer account established and the customer can proceed to search and booking. Error: invalid or already-used details produce a clear message with the form preserved. Recovery: correct the flagged input and resubmit; existing customers are routed to Login.

Hotel Search

• Information and state. Customer hotel discovery. Reachable without an established session; results are public discovery content.
• Primary actions. Enter destination, dates, and guests; run a search; select a hotel to continue to Booking.
• Supporting actions. Refine or re-run a search; adjust dates or guest count.
• Domain entities. Hotel, room, availability, destination, date range, guest count.
• Component responsibilities. Curved search capsule; results grid with a featured result spanning larger than the others; per-result availability and price presentation; selection handoff into Booking.
• States. Loading: results resolve with a visible in-progress state. Empty: no hotels match the criteria; the criteria remain editable and a re-run is offered. Success: matching hotels are listed and selectable. Error: a failed search reports the failure and preserves the entered criteria. Recovery: re-run the search or adjust criteria without re-entering everything.

Booking

• Information and state. Protected. Owns room selection and creation of a customer booking. Shows the selected hotel, the chosen room, the date range, the guest count, and the resulting booking state.
• Primary actions. Choose a room; confirm the booking; proceed to Payment.
• Supporting actions. Change the selected room or dates before confirming; return to Hotel Search.
• Domain entities. Booking, room, hotel, date range, guest count, booking status.
• Component responsibilities. Room selection; booking summary; confirmation control; handoff to Payment for the created booking.
• States. Loading: room and availability data resolve. Empty: no room is selected yet, with selection invited. Success: a booking is created and bound to the signed-in customer, and Payment is offered. Error: a room that became unavailable, or a failed booking creation, is reported clearly and the customer can choose another room. Recovery: reselect a room and confirm again; the customer is never left with an ambiguous booking state.

Payment

• Information and state. Protected. Owns completion of payment for an existing room booking. Shows the booking being paid for, the amount due, and the payment outcome.
• Primary actions. Submit payment for the booking; observe the payment result.
• Supporting actions. Return to the booking; retry a failed payment.
• Domain entities. Payment record, booking, amount, payment status.
• Component responsibilities. Payment form; amount and booking summary; settlement submission; outcome presentation; recording of the payment result against the booking.
• States. Loading: payment submission in progress, resubmission prevented. Empty: no booking is pending payment, with a route back to the customer's booking. Success: payment is recorded against the booking and the confirmed outcome is shown. Error: a declined or failed payment is reported clearly and the booking remains payable. Recovery: retry payment for the same booking without recreating it.

Admin Dashboard

• Information and state. Protected. Administrator operational overview and entry point for managing the hotel booking business. Summarises current hotels, rooms, bookings, and payment records.
• Primary actions. Open Admin Hotels, Admin Rooms, Admin Bookings, or Admin Payments.
• Supporting actions. Read the operational summary at a glance.
• Domain entities. Hotel, room, booking, payment record.
• Component responsibilities. Summary surfaces for each managed record type; navigation into each management page; curved section dividers and curved-topped data surfaces.
• States. Loading: summary data resolves. Empty: a record type with no entries shows an explicit empty state rather than a blank panel. Success: current operational state is visible and each management page is reachable. Error: a failed summary load is reported without blocking navigation into management pages. Recovery: reload the summary; management pages remain independently reachable.

Admin Hotels

• Information and state. Protected. Independently revisitable management of hotel records.
• Primary actions. Review hotel records; create, update, or remove a hotel record.
• Supporting actions. Search or filter the hotel list; open a single hotel record.
• Domain entities. Hotel.
• Component responsibilities. Hotel list inside a curved-topped surface; record editor; validation feedback; confirmation of changes.
• States. Loading: hotel records resolve. Empty: no hotels exist yet, with creation invited. Success: the change is persisted and reflected in the list. Error: invalid or rejected changes are reported with the record preserved. Recovery: correct and resubmit; the list remains usable.

Admin Rooms

• Information and state. Protected. Independently revisitable management of room inventory.
• Primary actions. Review rooms; create, update, or remove a room; associate a room with its hotel.
• Supporting actions. Filter rooms by hotel; open a single room record.
• Domain entities. Room, hotel.
• Component responsibilities. Room list; room editor; hotel association control; validation feedback.
• States. Loading: room records resolve. Empty: no rooms exist yet, with creation invited. Success: the change is persisted and reflected in the list. Error: invalid or rejected changes are reported with the record preserved. Recovery: correct and resubmit; the list remains usable.

Admin Bookings

• Information and state. Protected. Independently revisitable review and management of reservations.
• Primary actions. Review bookings; update a booking's state; open a single booking record.
• Supporting actions. Filter bookings by hotel, date, or status.
• Domain entities. Booking, room, hotel, customer account, booking status.
• Component responsibilities. Booking list; booking detail; state update control; validation feedback.
• States. Loading: booking records resolve. Empty: no bookings exist yet, shown explicitly. Success: the update is persisted and reflected in the list. Error: a rejected update is reported with the record preserved. Recovery: correct and resubmit; the list remains usable.

Admin Payments

• Information and state. Protected. Independently revisitable review and management of payment records.
• Primary actions. Review payment records; open a single payment record; update a payment record's state.
• Supporting actions. Filter payment records by booking, date, or status.
• Domain entities. Payment record, booking, amount, payment status.
• Component responsibilities. Payment list; payment detail; state update control; validation feedback.
• States. Loading: payment records resolve. Empty: no payment records exist yet, shown explicitly. Success: the update is persisted and reflected in the list. Error: a rejected update is reported with the record preserved. Recovery: correct and resubmit; the list remains usable.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-1 — Customer self-enrolment (required_inference) As a Guest Customer, I should be able to create my own account so that I can book and pay under my own identity.

• Trigger/input: the customer submits enrolment details on Sign Up.
• Observable result: a customer account exists and the customer can proceed to search and booking.
• Access state: anonymous entry; the account is established by this interaction.
• Failure/recovery: invalid or already-used details are reported and the form is preserved for correction; existing customers are routed to Login.
• Continuation: the customer continues into hotel search.

FR-2 — Returning customer verification (required_inference) As a Guest Customer, I should be able to verify my identity on return so that I can reach my own bookings and payments.

• Trigger/input: the customer submits credentials on Login.
• Observable result: the session is bound to the correct customer and protected customer destinations become reachable.
• Access state: anonymous entry; protected state stays unavailable until verification succeeds.
• Failure/recovery: invalid credentials are reported and the form remains usable; a customer without an account is directed to Sign Up.
• Continuation: the customer continues to Hotel Search, Booking, or Payment.

FR-3 — Administrator provisioning (required_inference) As a Hotel Administrator, I should be provisioned with an administrator identity before first use so that the admin dashboard and management pages are reachable only by administrators.

• Trigger/input: administrator provisioning occurs outside the customer self-enrolment path.
• Observable result: an administrator identity exists that can verify on Login.
• Access state: provisioning is a prerequisite; it does not itself grant a session.
• Failure/recovery: an unprovisioned actor cannot reach protected administrator surfaces and is directed to Login.
• Continuation: the administrator verifies on Login.

FR-4 — Returning administrator verification (required_inference) As a Hotel Administrator, I should be able to verify my identity on return so that I can reach protected operational records.

• Trigger/input: the administrator submits credentials on Login.
• Observable result: the session is bound to the correct administrator and the admin dashboard and management pages become reachable.
• Access state: anonymous entry; protected operational state stays unavailable until verification succeeds.
• Failure/recovery: invalid credentials are reported and the form remains usable.
• Continuation: the administrator continues to Admin Dashboard or a management page.

FR-5 — Hotel search (explicit) As a Guest Customer, I should be able to search hotels so that I can find a place to stay.

• Trigger/input: destination, dates, and guests entered into the search capsule on Hotel Search.
• Observable result: matching hotels are listed and selectable.
• Access state: reachable without an established session.
• Failure/recovery: a failed search reports the failure and preserves the entered criteria for a re-run; no matches leave the criteria editable.
• Continuation: the customer selects a hotel and continues to Booking.

FR-6 — Room booking (explicit) As a Guest Customer, I should be able to book a room so that I have a reservation at the hotel I chose.

• Trigger/input: the customer selects a room and confirms the booking on Booking.
• Observable result: a booking is created and bound to the signed-in customer.
• Access state: protected; requires an established customer session.
• Failure/recovery: a room that became unavailable, or a failed booking creation, is reported clearly and the customer can choose another room.
• Continuation: the customer proceeds to Payment for the created booking.

FR-7 — Payment for a booking (explicit) As a Guest Customer, I should be able to pay for my booking so that my reservation is settled.

• Trigger/input: the customer submits payment for an existing booking on Payment.
• Observable result: a payment record is created against the booking and the outcome is shown.
• Access state: protected; requires an established customer session and an existing booking.
• Failure/recovery: a declined or failed payment is reported clearly and the booking remains payable for retry without being recreated.
• Continuation: the customer sees the confirmed outcome and can return to their booking.

FR-8 — Administrator operational overview (explicit) As a Hotel Administrator, I should have an admin dashboard so that I can oversee the booking business.

• Trigger/input: the administrator opens Admin Dashboard after verification.
• Observable result: current hotels, rooms, bookings, and payment records are summarised and each management page is reachable.
• Access state: protected; administrators only.
• Failure/recovery: a failed summary load is reported without blocking navigation into management pages.
• Continuation: the administrator opens a management page.

FR-9 — Hotel record management (explicit) As a Hotel Administrator, I should be able to manage hotel records so that the hotels offered stay accurate.

• Trigger/input: the administrator creates, updates, or removes a hotel record on Admin Hotels.
• Observable result: the change is persisted and reflected in the hotel list.
• Access state: protected; administrators only.
• Failure/recovery: invalid or rejected changes are reported with the record preserved for correction.
• Continuation: the administrator continues managing hotels or moves to another management page.

FR-10 — Room inventory management (explicit) As a Hotel Administrator, I should be able to manage room inventory so that bookable rooms stay accurate.

• Trigger/input: the administrator creates, updates, or removes a room and associates it with its hotel on Admin Rooms.
• Observable result: the change is persisted and reflected in the room list.
• Access state: protected; administrators only.
• Failure/recovery: invalid or rejected changes are reported with the record preserved for correction.
• Continuation: the administrator continues managing rooms or moves to another management page.

FR-11 — Reservation review and management (explicit) As a Hotel Administrator, I should be able to review and manage reservations so that bookings stay current.

• Trigger/input: the administrator reviews bookings and updates a booking's state on Admin Bookings.
• Observable result: the update is persisted and reflected in the booking list.
• Access state: protected; administrators only.
• Failure/recovery: a rejected update is reported with the record preserved for correction.
• Continuation: the administrator continues reviewing bookings or moves to another management page.

FR-12 — Payment record review and management (explicit) As a Hotel Administrator, I should be able to review and manage payment records so that payment state stays accurate.

• Trigger/input: the administrator reviews payment records and updates a payment record's state on Admin Payments.
• Observable result: the update is persisted and reflected in the payment list.
• Access state: protected; administrators only.
• Failure/recovery: a rejected update is reported with the record preserved for correction.
• Continuation: the administrator continues reviewing payments or moves to another management page.

FR-13 — Database persistence (required_inference) As the system, I should persist accounts, hotels, rooms, bookings, and payment records in a database so that every accepted journey survives across sessions.

• Trigger/input: any accepted create, update, or removal of an account, hotel, room, booking, or payment record.
• Observable result: the record is durably stored and readable on later visits by the correct participant.
• Access state: persistence is system-owned; reads and writes are scoped to the participant entitled to them.
• Failure/recovery: a failed write is surfaced to the initiating page as an error rather than silently succeeding.
• Continuation: the participant retries or corrects the input on the owning page.

4. User Personas

Guest Customer

Product context. A traveller who arrives at hotel-booking without an account, wants to find a hotel and reserve a room, and needs to pay for it without anxiety. They may arrive directly on Landing or on Hotel Search, and they may return later to a booking they already made.

Primary goal. A confirmed booking made under their own account, with payment settled.

Distinct accepted responsibilities. The Guest Customer is the only persona that self-enrols (Sign Up), verifies on return (Login), searches hotels (Hotel Search), selects a room and creates a booking (Booking), and completes payment (Payment). No other persona performs any of these.

Relevant inputs and decisions. Destination, dates, and guest count for a search; which hotel and which room to choose; whether to confirm a booking; whether to submit payment for it.

Interactions with other accepted participants. The Guest Customer's booking and payment records become visible to the Hotel Administrator on Admin Bookings and Admin Payments. The customer does not interact with the administrator directly; the handoff is through the persisted booking and payment state.

Observable success. A booking exists and is bound to the customer's account, and a payment record exists against that booking with a confirmed outcome.

What makes this role different. The Guest Customer's work is a discovery-to-commitment journey with a value transfer at the end. Their state is private to them and must remain bound to the correct account across sessions, and their failure modes are availability and payment failures rather than record-accuracy failures.

Hotel Administrator

Product context. An operations user who oversees the booking business through an admin dashboard. They are provisioned rather than self-enrolled, and they work across the whole inventory and reservation set rather than a single account's records.

Primary goal. Inventory and reservations kept accurate and current.

Distinct accepted responsibilities. The Hotel Administrator is the only persona that verifies into the admin dashboard, manages hotel records (Admin Hotels), manages room inventory and hotel association (Admin Rooms), reviews and updates reservations (Admin Bookings), and reviews and updates payment records (Admin Payments).

Relevant inputs and decisions. Which hotel, room, booking, or payment record to open; what to change on it; whether to create or remove a record; what state to set on a booking or payment record.

Interactions with other accepted participants. The administrator sees the bookings and payments created by Guest Customers and can update their state. The administrator does not act on a customer's behalf inside the customer's own booking or payment flow.

Observable success. Hotel and room records reflect the real inventory, and booking and payment records reflect the real reservation and settlement state.

What makes this role different. The Hotel Administrator's work is record stewardship over shared state rather than a personal commitment journey. Their failure modes are validation and rejected-update failures, and their success is measured by the accuracy of records other participants depend on.

5. Core User Flows

Flow A — Guest Customer enrols and books a room

1. The Guest Customer arrives on Landing without a session and reads what the hotel booking website offers.
2. The customer enters destination, dates, and guests into the search capsule and starts a search, arriving on Hotel Search.
3. Hotel Search returns matching hotels. If nothing matches, the criteria stay editable and the customer adjusts and re-runs the search.
4. The customer selects a hotel and continues to Booking. Because Booking is protected, the customer is routed to Login.
5. The customer has no account, so they go to Sign Up and submit enrolment details. Their account is established.
6. The customer returns to Booking, selects a room, and confirms. A booking is created and bound to their account.
7. The customer proceeds to Payment, submits payment for the booking, and sees the confirmed outcome.
8. Failure/recovery: if the chosen room became unavailable at step 6, the customer is told clearly and selects another room. If payment fails at step 7, the booking remains payable and the customer retries without recreating it.
9. Continuation: the customer's booking and payment record persist under their account and are visible to the Hotel Administrator.

Flow B — Returning Guest Customer books another stay

1. The returning customer arrives on Landing or Hotel Search.
2. The customer searches on Hotel Search and selects a hotel.
3. On reaching protected Booking, the customer verifies on Login. Their session is bound to the correct account.
4. The customer selects a room, confirms the booking, and proceeds to Payment.
5. The customer submits payment and sees the confirmed outcome.
6. Failure/recovery: invalid credentials at step 3 are reported and the form remains usable; a failed payment at step 5 leaves the booking payable for retry.
7. Continuation: the new booking joins the customer's existing account-owned records.

Flow C — Hotel Administrator verifies and reviews operations

1. The Hotel Administrator, already provisioned, opens Login and submits credentials.
2. Their session is bound to the correct administrator and Admin Dashboard becomes reachable.
3. On Admin Dashboard the administrator reads the current summary of hotels, rooms, bookings, and payment records. If a summary panel has no entries, it shows an explicit empty state.
4. The administrator opens Admin Hotels, Admin Rooms, Admin Bookings, or Admin Payments depending on what needs attention.
5. Failure/recovery: invalid credentials at step 1 are reported and the form remains usable. If the dashboard summary fails to load, the failure is reported and the management pages remain reachable.
6. Continuation: the administrator returns to Admin Dashboard or moves directly between management pages.

Flow D — Hotel Administrator manages hotel records

1. From Admin Dashboard, the administrator opens Admin Hotels.
2. The administrator reviews the hotel list. If no hotels exist yet, the empty state invites creation.
3. The administrator creates, updates, or removes a hotel record.
4. The change is persisted and reflected in the hotel list.
5. Failure/recovery: an invalid or rejected change is reported with the record preserved, and the administrator corrects and resubmits.
6. Continuation: the administrator continues managing hotels or moves to Admin Rooms to attach rooms to the hotel.

Flow E — Hotel Administrator manages room inventory

1. From Admin Dashboard, the administrator opens Admin Rooms.
2. The administrator reviews rooms, filtering by hotel as needed. If no rooms exist yet, the empty state invites creation.
3. The administrator creates, updates, or removes a room and associates it with its hotel.
4. The change is persisted and reflected in the room list, and the affected rooms become the inventory customers can book.
5. Failure/recovery: an invalid or rejected change is reported with the record preserved, and the administrator corrects and resubmits.
6. Continuation: the administrator continues managing rooms or moves to another management page.

Flow F — Hotel Administrator reviews and manages reservations

1. From Admin Dashboard, the administrator opens Admin Bookings.
2. The administrator reviews bookings, filtering by hotel, date, or status. If no bookings exist yet, that is shown explicitly.
3. The administrator opens a booking and updates its state.
4. The update is persisted and reflected in the booking list.
5. Failure/recovery: a rejected update is reported with the record preserved, and the administrator corrects and resubmits.
6. Continuation: the administrator continues reviewing bookings or moves to Admin Payments to check the related payment.

Flow G — Hotel Administrator reviews and manages payment records

1. From Admin Dashboard, the administrator opens Admin Payments.
2. The administrator reviews payment records, filtering by booking, date, or status. If no payment records exist yet, that is shown explicitly.
3. The administrator opens a payment record and updates its state.
4. The update is persisted and reflected in the payment list.
5. Failure/recovery: a rejected update is reported with the record preserved, and the administrator corrects and resubmits.
6. Continuation: the administrator continues reviewing payments or returns to Admin Dashboard.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. Muse: Zaha Hadid. Headline idea: Fluid parametric grandeur for the art of arrival — sweeping continuous curves, pearl-light surfaces, and dramatic negative space, so the product feels like walking into a designed lobby rather than filling out a form.

Colour tokens (light mode)

No blue or indigo appears anywhere in the palette. Contrast of #1C1C1E on #F4F1EC exceeds 12:1. The gold accent is used only on dark or white grounds with sufficient weight.

Typography

• Headings: Jost, light weights (300/400), wide tracking (+0.02em to +0.08em). Sentence case, never all-caps.
• Body: Work Sans.
• Scale: 1.333 modular scale — 128 / 96 / 72 / 54 / 40 / 30 / 22 / 17 / 16 px.
• Hero display: 56px mobile → 128px desktop, using clamp(). Section headings 40–72px. Body 16–17px with 1.6 line-height.
• Admin dashboard: the same scale compressed to 24 / 20 / 17 / 15 px for data density, keeping Jost for section titles.
• Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are not used for headings or body.

Shape language

• Sweeping continuous curves are the primary structural device. Section boundaries are gentle curved arcs, not straight horizontal rules.
• Cards use large asymmetric radii: one corner at 32px, the opposite at 8px.
• Buttons are pill-shaped with a subtle inner highlight.
• Search inputs sit inside a curved capsule spanning the viewport width.
• No sharp 90-degree corners on interactive elements. No drop shadows that read as material elevation; depth comes from soft luminous gradients on curved surfaces.

Layout

• Asymmetric editorial grid on a 12-column base.
• Hero breaks the grid: full-bleed architectural image in columns 5–12 with a curved left edge; headline and search capsule in columns 1–5, overlapping the image edge by one column.
• Search results use a 3-column card grid with one featured card spanning 2 columns and 2 rows, its curved boundary cutting into the adjacent card.
• Admin dashboard uses a 4-column modular grid with curved section dividers; data tables sit inside a white surface with a curved top edge.
• Margins: 5vw mobile, 8vw desktop. Section transitions use curved dividers.

Imagery

Architectural photography and renders: hotel exteriors at dusk with warm interior light through glass, sweeping lobby staircases, pool edges echoing the parametric language. Images are cropped inside curved frames, never full rectangles. Secondary imagery is monochrome warm-grey with a single gold accent element. No stock photography of people smiling at reception or in beds; human presence, if needed, is silhouettes or distant figures at architectural scale. The admin dashboard uses abstract curved data visualisations and floor-plan-like diagrams rather than photography.

7. Signature Design Concept

The public entry is a full-viewport architectural composition on Landing.

On the left, a 5-column stack carries a 2px gold rule (120px wide) above a 96–128px Jost light headline — Stay somewhere that moves you — sitting above a curved capsule search bar in white with a gold search button pinned at its right end. The capsule holds destination, dates, and guests.

On the right, columns 5–12, a full-bleed dusk photograph of a curved hotel facade has its left edge cut by a sweeping concave arc that overlaps the headline column by one grid unit. The image parallax-pans slowly on scroll while the frame stays fixed.

Below the fold, the same curve continues as the section divider into the featured hotels row, where cards carry asymmetric radii and a gold accent line traces each card's curve. The composition is asymmetric, architectural, and unmistakably not a template: no centred text, no blue button, no gradient blob.

Every readable element — headline, search labels, input values, button text — stays whole inside its container at 375px, 768px, and 1280px, wrapping or scaling with clamp(). The curved crop is carried by the photograph and the arc dividers, never by the text or the controls.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject. The dusk architectural photograph of a curved hotel facade, cropped inside a sweeping concave arc that overlaps the headline column.
• Input → transformation → outcome thesis. As the visitor scrolls, the architectural image pans slowly inside its fixed curved frame (0.85x scroll speed) while the headline fades up and the search capsule settles into place — the outcome is that the hotel feels like a place being revealed rather than a listing being displayed, and the visitor's eye is carried down the curve into the featured hotels row.
• Motion vocabulary. Slow parallax pan inside a fixed curved frame; headline fade-up with 400ms ease-out and 20px translate; search capsule expanding from a thin 2px line to full height on first load over 600ms; hotel card hover tilting 2 degrees along its curved axis with a gold accent line shift; admin table state changes as instant 150ms background fades. No bounce, no particles, no gradient blobs.
• Composed first frame. The capsule is still a 2px gold line spanning the viewport; the headline is at its resting position above it; the facade photograph is fully visible inside its arc, its left edge overlapping the headline column by one grid unit; the 2px gold rule sits above the headline.
• Reduced-motion state. With prefers-reduced-motion, all parallax and transforms are removed: the capsule renders at full height immediately, the headline is static and fully visible, the facade photograph is static inside its arc, and card hover produces no tilt. Content remains complete and readable.

9. Non-Functional Requirements

• NFR-1 — Identity-bound state (required_inference). Booking and payment state must remain bound to the correct customer account across sessions, and administrator management state must remain bound to provisioned administrators. Rationale: the accepted journeys require a customer to return to their own booking and payment records, and require administrator surfaces to be reachable only by administrators.
• NFR-2 — Access separation (explicit). Customer login is required for customers, and the admin dashboard is for administrators. Protected destinations must not expose their state before identity is established.
• NFR-3 — Durable persistence (required_inference). Accounts, hotels, rooms, bookings, and payment records must be durably persisted in a database so that accepted journeys survive across sessions.
• NFR-4 — Readable text and controls at every viewport (explicit, from the creative direction). Headlines, wordmarks, labels, numbers, and card text 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. Imagery, decoration, and motion may be cropped, bled, rotated, or overlapped as the direction asks, provided they cover no readable text or control.
• NFR-5 — Reduced motion (explicit, from the creative direction). With prefers-reduced-motion, all parallax and transforms are removed and content is static and fully visible.
• NFR-6 — Palette and type discipline (explicit, from the creative direction). No blue or indigo anywhere; the accent is brushed gold #B08D57 only. Headings use Jost light weights; body uses Work Sans. The generic indigo/blue-on-white SaaS template is forbidden.
• NFR-7 — Failure visibility (required_inference). A failed write or a failed load must be surfaced on the page that initiated it rather than silently succeeding, so that the participant can recover.

10. Tech Stack

• Frontend: React, custom UI, built to the creative direction in sections 6–8.
• Backend: Python with FastAPI, exposing the search, booking, payment, and admin management operations.
• Database: a relational database persisting accounts, hotels, rooms, bookings, and payment records.
• Containerisation: Docker and docker-compose for local and deployment packaging.
• Deployment: Kubernetes is not required by any source statement and is not included.

No source statement specifies a particular database engine, payment provider, or hosting platform; those remain open implementation choices.

11. Assumptions and Constraints

• Constraint (explicit). Customer login is required for customers.
• Constraint (explicit). The admin dashboard is for administrators.
• Constraint (explicit). The product is a modern hotel booking website with customer login, hotel search, room booking, payments, an admin dashboard, and a database. Nothing beyond these is in scope.
• Assumption (required_inference). Customers self-enrol through Sign Up; administrators are provisioned rather than self-enrolling. This is required to make the accepted journeys executable without adding account-management capability beyond enrolment and verification.
• Assumption (required_inference). Booking and Payment are protected because they create and settle a commitment bound to a specific customer; Hotel Search remains reachable without a session because discovery precedes commitment.
• Assumption (required_inference). Where an external payment provider is used, it owns only the settlement step; the booking lifecycle and the payment record remain application-owned.
• Assumption. No future-horizon capability is accepted; everything in this document is current.
• Default — not specified by user. Database engine, payment provider, hosting platform, and deployment topology are unspecified and left to implementation.

12. Glossary

• Guest Customer — the accepted persona who searches hotels, books a room, and pays for it under their own account.
• Hotel Administrator — the accepted persona who manages hotels, rooms, bookings, and payment records through the admin dashboard.
• Booking — a reservation created by a Guest Customer for a specific room at a specific hotel over a date range, bound to that customer's account.
• Payment record — the persisted record of a payment made against a booking, with its amount and status.
• Protected destination — a page whose state is bound to a participant and is unavailable until identity is established: Booking, Payment, Admin Dashboard, Admin Hotels, Admin Rooms, Admin Bookings, Admin Payments.
• Provisioning — the establishment of an administrator identity outside the customer self-enrolment path.
• Search capsule — the curved, viewport-spanning search control on Landing and Hotel Search holding destination, dates, and guests.