System Requirements Document

1. Introduction

This System Requirements Document (SRD) defines the requirements for Batangas Lowkey Eatery, a free, front-end-only food directory prototype built by Group 7 as a class presentation deliverable.

Batangas Lowkey Eatery helps people find verified, hidden local eateries in Batangas City. It deliberately focuses on small eateries, street food stalls, and turo-turo spots that delivery apps and tourist sites skip. The prototype is built to be simple, responsive, mobile-first, and easy to explain during a classroom presentation.

The system is a static front-end prototype: it runs entirely in the browser with hardcoded sample data, and it deliberately excludes backend services, databases, authentication, and API calls.

2. System Overview

Batangas Lowkey Eatery is a free food directory for verified hidden local eats in Batangas City. The system surface consists of a single-page-style browsing experience composed of:

• A Home view with branding, search, filters, and a card grid.
• Eatery Cards summarizing each listing.
• An Eatery Detail view (modal or separate section) with the full listing information.
• A Featured section of promoted eateries that demonstrates the project's revenue model.
• A Footer with a short About Us and the group name (Group 7).
• A Favorites view driven by localStorage, reachable from the mobile bottom navigation.

All content is supplied by a single hardcoded data source (data.js) containing 10 sample eateries across different Batangas City barangays. The entire prototype must work when opened locally from a folder (index.html) and must look good on both phone and desktop.

External recipients: local eatery owners whose establishments appear in the directory — in particular the promoted eateries surfaced in the Featured section. They receive visibility from the directory and do not operate any workflow inside the prototype.

3. Functional Requirements

3.1 Branding and Home View

• FR-1: As a local food seeker, I want a header showing the logo text "Batangas Lowkey Eatery" so that I can immediately identify the directory.
• FR-2: As a local food seeker, I want a short header tagline reading "Find hidden, verified local eats in Batangas City" so that I understand what the directory does.
• FR-3: As a local food seeker, I want a search bar on the Home view so that I can begin looking for an eatery.
• FR-4: As a local food seeker, I want a grid of eatery cards on the Home view so that I can browse multiple eateries at once.

3.2 Filters and Toggles

• FR-5: As a local food seeker, I want filter chips for All, Eatery, Street Food, and Turo-turo so that I can narrow the listing by category.
• FR-6: As a local food seeker, I want a Barangay dropdown filter so that I can limit results to a specific barangay in Batangas City.
• FR-7: As a local food seeker, I want a Price Range dropdown filter using the tiers \xe2\x82\xb1, \xe2\x82\xb1\xe2\x82\xb1, and \xe2\x82\xb1\xe2\x82\xb1\xe2\x82\xb1 so that I can match listings to my budget.
• FR-8: As a local food seeker, I want a "Verified only" toggle so that I can display only locally verified eateries.

3.3 Eatery Card Contents

• FR-9: As a local food seeker, I want each eatery card to show a photo so that I can visually assess the eatery.
• FR-10: As a local food seeker, I want each eatery card to show the eatery name so that I can identify it.
• FR-11: As a local food seeker, I want each eatery card to show the category so that I can tell whether it is an eatery, street food, or turo-turo spot.
• FR-12: As a local food seeker, I want each eatery card to show the barangay so that I know roughly where it is.
• FR-13: As a local food seeker, I want each eatery card to show the price range so that I know the cost tier at a glance.
• FR-14: As a local food seeker, I want each eatery card to show the rating so that I can gauge its reputation.
• FR-15: As a local food seeker, I want each eatery card to show a green "Locally Verified" badge so that I can trust that the listing is genuine.

3.4 Eatery Detail View

• FR-16: As a local food seeker, I want to open an Eatery Detail view as a modal or a separate section so that I can see the full listing without leaving the page.
• FR-17: As a local food seeker, I want the detail view to show a large photo of the eatery so that I can see what it looks like.
• FR-18: As a local food seeker, I want the detail view to show a description so that I understand what the eatery offers.
• FR-19: As a local food seeker, I want the detail view to show the address so that I can locate the eatery.
• FR-20: As a local food seeker, I want the detail view to show the opening hours so that I know when it is open.
• FR-21: As a local food seeker, I want the detail view to show menu highlights so that I know what to order.
• FR-22: As a local food seeker, I want the detail view to show a contact number so that I can reach the eatery.
• FR-23: As a local food seeker, I want an "Open in Maps" button in the detail view so that I can navigate to the eatery.
• FR-24: As a local food seeker, I want a Share button in the detail view that copies the link so that I can send the listing to someone else.

3.5 Featured / Promoted Section

• FR-25: As a local food seeker, I want a Featured section showing 2–3 eateries labeled "Promoted" so that I can see highlighted listings.
• FR-26: As a project presenter, I want the Promoted labels to be visible in the Featured section so that the prototype can demonstrate the project's revenue model.

3.6 Footer

• FR-27: As a local food seeker, I want a footer containing a short About Us text so that I understand who runs the directory.
• FR-28: As a project presenter, I want the footer to display the group name Group 7 so that the class presentation is properly credited.

3.7 Interactivity (JavaScript Behavior on Sample Data)

• FR-29: As a local food seeker, I want live search by name so that results update as I type.
• FR-30: As a local food seeker, I want to filter listings by category so that I only see the type of eatery I want.
• FR-31: As a local food seeker, I want to filter listings by barangay so that I only see eateries in my chosen area.
• FR-32: As a local food seeker, I want to filter listings by price range so that I only see eateries within my budget tier.
• FR-33: As a local food seeker, I want to filter listings by Verified only so that unverified listings are hidden.
• FR-34: As a local food seeker, I want to combine search text, category, barangay, price, and verified filters together so that I can narrow results precisely.
• FR-35: As a local food seeker, I want to click an eatery card to open its details so that I can read the full listing.
• FR-36: As a local food seeker, I want a "Save to Favorites" heart button on eateries so that I can keep a personal shortlist.
• FR-37: As a local food seeker, I want my favorites to be stored in localStorage with no login required so that my saved list survives a page reload.
• FR-38: As a local food seeker, I want a "No results found" message when my filters match nothing so that I understand why the grid is empty.

3.8 Sample Data Requirements

• FR-39: As a project presenter, I want 10 sample eateries located in different Batangas City barangays so that the directory demonstrates geographic coverage.
• FR-40: As a project presenter, I want each sample eatery record to contain the fields id, name, category, barangay, address, priceRange, rating, isVerified, isPromoted, hours, description, menuHighlights, contact, and image so that every part of the interface can be populated from one data source.

3.9 Responsive Behavior and Navigation

• FR-41: As a local food seeker, I want the site to be mobile-first and responsive so that it works on phones and desktops.
• FR-42: As a local food seeker, I want the layout to respond at the 768px and 1024px breakpoints so that it adapts cleanly to tablet and desktop.
• FR-43: As a local food seeker, I want the eatery card grid to display 1 column on mobile, 2 on tablet, and 3 on desktop so that cards remain readable at every size.
• FR-44: As a local food seeker on mobile, I want a bottom navigation bar containing Home, Featured, and Favorites so that I can move between sections with my thumb.
• FR-45: As a local food seeker on desktop, I want a top navbar so that navigation matches desktop conventions.
• FR-46: As a local food seeker, I want all buttons to be at least 44px tall so that they are easy to tap.
• FR-47: As a local food seeker, I want readable fonts so that all content is legible.
• FR-48: As a local food seeker, I want high-contrast text and controls so that content remains readable in bright conditions.
• FR-49: As a local food seeker, I want a simple loading effect so that the interface feels responsive while content renders.
• FR-50: As a local food seeker, I want smooth hover animations on interactive elements so that the interface feels polished.

3.10 Deliverables and Build Constraints

• FR-51: As a project presenter, I want the complete code delivered as separate files — index.html, style.css, script.js, and data.js — so that the project structure is easy to explain.
• FR-52: As a project presenter, I want short setup instructions ("Save the files in one folder and open index.html") so that anyone can run the prototype locally.
• FR-53: As a project presenter, I want a 3-sentence explanation of how the site works so that I can narrate it during the class presentation.
• FR-54: As a project presenter, I want the prototype to be front-end only with no backend, database, login, or API calls so that it stays simple, dependency-free, and demo-safe.

4. User Personas

4.1 Local Food Seeker

A Batangas City resident, student, or visiting newcomer who wants affordable, authentic local food. This persona groups audiences whose workflows and visible information are identical: they browse the eatery grid, search by name, apply category/barangay/price/verified filters, open eatery details, open a listing in Maps, share a listing, and save favorites to localStorage. They never log in and never see any administrative interface.

4.2 Project Presenter (Group 7)

A student of Group 7 presenting the prototype to a class. Their distinct workflow is demonstration rather than discovery: they walk through the Home view, apply filters, open an eatery detail, show the Promoted section as evidence of the revenue model, show the Favorites behavior backed by localStorage, and deliver a 3-sentence explanation of how the site works. They need the code split into clearly named files they can explain, and the footer must credit Group 7.

5. Core User Flows

5.1 Flow: Discover Eateries by Browsing

1. The seeker opens index.html locally in a browser.
2. The Home view loads with the "Batangas Lowkey Eatery" header and the tagline "Find hidden, verified local eats in Batangas City".
3. A simple loading effect plays while the hardcoded eatery data renders.
4. The grid of eatery cards appears, showing photo, name, category, barangay, price range, rating, and the green "Locally Verified" badge where applicable.
5. The seeker scans the grid and decides whether to filter or open a card.

5.2 Flow: Search and Filter

1. The seeker types a name into the search bar; results update live by name.
2. The seeker selects a filter chip (All, Eatery, Street Food, Turo-turo).
3. The seeker selects a barangay from the dropdown.
4. The seeker selects a price range (\xe2\x82\xb1 /\x20\xe2\x82\xb1\xe2\x82\xb1 /\x20\xe2\x82\xb1\xe2\x82\xb1\xe2\x82\xb1) from the dropdown.
5. The seeker switches on the "Verified only" toggle.
6. All filters apply together; the seeker refines until the grid shows relevant results.
7. If nothing matches, the "No results found" message is displayed instead of the grid.

5.3 Flow: View Eatery Details

1. The seeker clicks an eatery card.
2. The Eatery Detail view opens as a modal or separate section.
3. The seeker reads the large photo, description, address, opening hours, menu highlights, and contact number.

5.4 Flow: Navigate to an Eatery

1. From the Eatery Detail view, the seeker taps "Open in Maps".
2. The listing location opens in a maps view so the seeker can travel to the eatery.

5.5 Flow: Share a Listing

1. From the Eatery Detail view, the seeker taps the Share button.
2. The link is copied so the seeker can paste and send it to a friend.

5.6 Flow: Save to Favorites

1. The seeker taps the heart button on an eatery.
2. The eatery is saved to favorites in localStorage without any login.
3. The seeker opens the Favorites view from the mobile bottom navigation (or the desktop top navbar).
4. Favorites persist after reloading the page.

5.7 Flow: Presenter Demonstration

1. The presenter opens the prototype from the delivered folder.
2. The presenter shows the Home header, tagline, search bar, filter chips, barangay and price dropdowns, and the "Verified only" toggle.
3. The presenter types a search term and applies filters to show live filtering and, if desired, the "No results found" state.
4. The presenter opens an eatery detail to show description, address, hours, menu highlights, contact number, "Open in Maps", and Share.
5. The presenter scrolls to the Featured section and points out the 2–3 eateries labeled "Promoted" to explain the revenue model.
6. The presenter saves an eatery to favorites and reloads to prove localStorage persistence without a login.
7. The presenter closes with the 3-sentence explanation of how the site works.

6. Visuals, Colors, and Theme

The visual theme is warm, friendly, and local, with a clean palette and large food photography. Rounded cards and simple icons keep the interface approachable and beginner-friendly. The user's explicit design style governs: blue for headings, green for the verified badge, red for accents, big food photos, rounded cards, and simple icons.

Color palette (derived from the specified heading-blue / verified-green / accent-red scheme):

Theme rules:

• Blue is reserved for headings and structural text.
• Green is used exclusively for the "Locally Verified" badge so verification reads as a trust signal.
• Red is used sparingly as an accent (favorites heart, "Promoted" highlights).
• Cards are rounded, with big food photos above the metadata.
• Icons are simple and minimal.
• The generic indigo/blue-on-white SaaS template is forbidden for this project; the warm cream canvas and saturated food photography carry the local, informal character.

Typography:

• Headings and the wordmark use a chunky display sans (e.g. Archivo Black) in all-caps for section openers, with tight line-height; the hero headline scales from a mobile floor up to a large desktop size so it dominates the viewport.
• Card names and UI labels use a friendly geometric sans (e.g. Outfit) at 500–700; body copy uses the same family at 400/16px with ~1.55 line-height for easy phone reading.
• Modular type scale with mobile floors: hero 44, section 28, card title 20, body 16, meta 14.
• Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are not used for headings or body.

Shape language:

• Generous 24–32px radii on cards and modals; pill-shaped filter chips (fully rounded).
• Sticker-shaped badges with a 3px offset ink border and a hard 4px shadow (no blur).
• Scalloped/wavy section dividers between Home, Featured, and Favorites.
• One large organic blob shape behind the hero headline.
• No sharp corners anywhere except the sticker borders.

Imagery:

• Big, saturated, art-directed food photography (e.g. a bowl of lomi, a plate of pancit canton, a sizzling plate of sisig), cropped tight and colour-blocked behind the dish so every card reads as a poster rather than a stock thumbnail.
• Small sticker illustrations (a chili, a calamansi, a fork) are placed as overlays on cards and section dividers.
• No soft lifestyle photography, no white-plate minimalism, no gradient blobs.

Readable text and controls stay whole at every viewport: headlines, wordmarks, labels, numbers, and 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, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, as long as they cover no readable text or control. Moving and scrollable content (marquees, tickers, carousels, horizontally scrollable rows) may cross the viewport or container edge by design; every item must become fully readable as it passes. With prefers-reduced-motion, provide a usable static arrangement: wrap items into rows or allow horizontal scrolling so each item can be brought fully into view.

7. Signature Design Concept

"Verified Hidden Gem Cards." The signature element is the rounded eatery card anchored by a big food photo and stamped with the green "Locally Verified" badge. Cards behave like small trust certificates: a photo up top, a green verification stamp, and a compact metadata row (category · barangay · price tier · rating). A warm cream canvas and the "Promoted" strip in the Featured section turn the grid into a browsable market street rather than a generic listing table. The chip-based filter row and the price-tier notation (\xe2\x82\xb1 /\x20\xe2\x82\xb1\xe2\x82\xb1 /\x20\xe2\x82\xb1\xe2\x82\xb1\xe2\x82\xb1) keep the local, informal character of a turo-turo directory.

Signature moves:

• Warm cream full-bleed hero band with an oversized all-caps wordmark on the left and a saturated colour-blocked food photo bleeding off the right edge, with a rotated sticker badge overlapping the photo.
• Horizontally scrollable filter chip row that deliberately bleeds past the viewport edge, with active chips flipping to a solid accent ground and white text — no Apply button, results update live.
• Eatery cards built as mini-posters: a colour-blocked food photo with a hard 3px ink border and 4px offset shadow, the card title in a chunky all-caps display face, and a green "Locally Verified" pill stamped at a slight angle in the top-right corner.
• Featured section as a distinct colour band with a slow horizontal marquee of "PROMOTED" labels and 2–3 cards tilted ±2° with an ink "Promoted" tag sticker, visually separated from the Home band by a scalloped divider.
• Favorites heart as a chunky sticker button: ink outline, white fill, flips to solid accent red with a 1.25 pop on save; the Favorites view replaces the grid with a single-column list of saved cards on a warm ground and a friendly empty-state illustration of an empty plate.

7.1 Landing Hero Motion Brief

Motion tempo: expressive (per the CREATIVE DIRECTION Motion Tempo: line). Hero dimensionality: layered_2d; hero drama: bold.

Input → transformation → outcome thesis: The seeker's arrival (input) is transformed by a staged, poster-like hero that assembles the wordmark, tagline, search pill, and a colour-blocked food photo into a browsable food world (transformation), so the seeker immediately understands this is a warm, local, verified-eats directory and is invited to search or swipe the chip row (outcome).

Focal subject: The oversized all-caps wordmark "Batangas Lowkey Eatery" paired with a saturated cut-out food photo (a bowl of lomi) held in a large organic blob that bleeds off the right edge.

Visible layers (back to front):

1. Warm cream full-bleed hero band (colour field, never white).
2. Large organic blob shape behind the headline.
3. Wordmark + tagline block (left on desktop, top on mobile).
4. Colour-blocked food photo bleeding off the right edge.
5. Rotated sticker badge reading "VERIFIED LOCALS ONLY" overlapping the photo's bottom-left corner.
6. White search pill spanning the hero width with an accent search icon.
7. Horizontally scrollable chip row half-cut by the viewport edge.

Staged opening (expressive tempo): On load, the hero band fades in; the wordmark and tagline rise and settle with a light spring; the food photo scales in from 0.94 → 1; the sticker badge rotates into place; the search pill and chip row fade up last. Total opening ≈ 600–900ms, ease-out, no motion that covers readable text or controls.

Story loop: After the opening, the hero settles into a restrained contained loop — the sticker badge gives a subtle idle wobble and the chip row's edge hint gently nudges, signalling swipeability without distracting from the search bar.

Composed first frame: Warm cream band, wordmark top-left in ink, tagline beneath, food photo right with the rotated sticker badge, white search pill below, chip row cut at the right edge — an asymmetric poster composition, never a centred headline over a gradient.

Optional interaction: Hovering/focusing the search pill lifts it slightly with a shadow increase; tapping a chip flips its ground colour instantly and re-renders the grid.

Responsive behavior: Mobile-first single column — wordmark and tagline stack above the photo; the chip row scrolls horizontally and bleeds past the edge. At 768px the photo moves beside the type; at 1024px the hero reaches its largest headline size with the photo bleeding off the right edge.

Reduced-motion fallback: All springs become instant state changes; the sticker badge and chip row are static; the hero appears without transform; the chip row wraps into rows or remains horizontally scrollable so every chip can be brought fully into view.

Implementation: 2D DOM/SVG/CSS composition in the direction's motion vocabulary, implemented with Motion for React (motion/react) or GSAP. No Canvas/R3F/Drei is required (hero dimensionality is layered_2d).

8. Interaction Model & Motion Direction

Interaction model:

• Chip-selection filtering — tapping a category chip immediately applies that category.
• Instant, combined filtering — search text, category, barangay, price, and verified filters apply together with no "Apply" button.
• Card → detail — clicking anywhere on a card opens the detail view.
• Modal or section detail — the detail view presents the listing in place, without a page navigation.
• Heart toggle for favorites — a single tap saves or removes an eatery; state persists in localStorage with no login.
• Persistent bottom navigation on mobile (Home, Featured, Favorites) and a top navbar on desktop.
• Widescreen pointer devices are all click/keyboard-driven; no pointer-only interactions.

Motion direction:

• Hover animations on cards and buttons: subtle lift plus a small shadow increase.
• A simple loading effect (skeleton or spinner) before the eatery grid renders.
• The detail view rises from the bottom on mobile and fades/scales in on desktop.
• Filter changes animate the grid in/out rather than snapping.
• Duration: 150–250ms with ease-out for a calm, friendly feel.
• Heart button gives a brief pop/scale confirmation when saving a favorite.
• Cards scale-in with a light spring (0.94 → 1, 220ms) as they enter the viewport.
• The Featured band runs a slow horizontal marquee of "PROMOTED • PROMOTED •" labels.
• Favor simple transforms and opacity; reduce animation when the user prefers reduced motion. Under prefers-reduced-motion, all springs become instant state changes, the marquee becomes a static row of labels, and cards appear without transform.
• No motion may hide or cover readable text, controls, or the search bar.

9. Page Content and Component Coverage

This section defines the presentation contract for each page: its purpose, the information it shows, the actions it offers, the domain and feedback states it must handle, and the components it owns. It adds no personas, routes, behaviors, integrations, or adjacent modules beyond the accepted scope.

9.1 Home

• Purpose: Anonymous entry surface for discovering verified hidden local eateries in Batangas City.
• Information shown: Wordmark "Batangas Lowkey Eatery"; tagline "Find hidden, verified local eats in Batangas City"; search bar; filter chips (All, Eatery, Street Food, Turo-turo); Barangay dropdown; Price Range dropdown (₱ / ₱₱ / ₱₱₱); "Verified only" toggle; grid of eatery cards; "No results found" message; loading effect; Featured section; Footer.
• Actions: Type to search live by name; select a category chip; select a barangay; select a price tier; toggle "Verified only"; click a card to open its detail; tap the heart to save/remove a favorite; navigate via bottom nav (mobile) or top navbar (desktop).
• Domain states: All listings; filtered listings; empty result set; loading; favorites saved/unsaved.
• Feedback states: Loading effect before the grid renders; "No results found" when filters match nothing; heart pop/scale confirmation on save; grid animate in/out on filter change.
• Owned components: HeroBand (wordmark, tagline, search pill, chip row, blob, sticker badge); FilterBar (chips, barangay dropdown, price dropdown, verified toggle); EateryGrid; EateryCard; NoResultsMessage; LoadingEffect; FeaturedBand; Footer; BottomNav (mobile); TopNavbar (desktop).

9.2 Eatery Card

• Purpose: Present a listing summary and the localStorage favorites control within the Home browsing experience.
• Information shown: Photo; name; category; barangay; price range; rating; green "Locally Verified" badge (where applicable).
• Actions: Click anywhere on the card to open the detail view; tap the heart to save/remove a favorite.
• Domain states: Verified / unverified; promoted / not promoted; saved / unsaved favorite.
• Feedback states: Hover lift with shadow increase; heart pop/scale on save; scale-in on viewport entry.
• Owned components: CardPhoto; CardTitle; CardMetaRow (category · barangay · price tier · rating); VerifiedBadge; FavoriteHeart.

9.3 Eatery Detail

• Purpose: Present complete listing information plus Maps and sharing actions without leaving the prototype.
• Information shown: Large photo; description; address; opening hours; menu highlights; contact number; "Open in Maps" button; Share button.
• Actions: Open the listing location in a maps view; copy the listing link to share; close the detail view.
• Domain states: Any single listing record.
• Feedback states: Rise-from-bottom on mobile / fade-scale on desktop; share-copied confirmation.
• Owned components: DetailPhoto; DetailDescription; DetailAddress; DetailHours; DetailMenuHighlights; DetailContact; OpenInMapsButton; ShareButton; DetailClose.

9.4 Featured

• Purpose: Surface 2–3 promoted eateries for discovery and to demonstrate the project's revenue model.
• Information shown: 2–3 eatery cards labeled "Promoted"; marquee of "PROMOTED" labels.
• Actions: Click a promoted card to open its detail view; tap the heart to save/remove a favorite.
• Domain states: Promoted listings only.
• Feedback states: Slow horizontal marquee; cards tilted ±2° with an ink "Promoted" tag sticker.
• Owned components: FeaturedBand; PromotedMarquee; PromotedTag; EateryCard (reused).

9.5 Favorites

• Purpose: Display the user's localStorage-backed personal shortlist without login.
• Information shown: Single-column list of saved eatery cards; friendly empty-state illustration of an empty plate when nothing is saved.
• Actions: Open a saved eatery's detail; remove a favorite via the heart; navigate back to Home/Featured.
• Domain states: Empty shortlist; populated shortlist; persistence across reloads.
• Feedback states: Empty-state illustration; heart pop on removal; list updates immediately.
• Owned components: FavoritesList; EmptyPlateIllustration; EateryCard (reused).

9.6 Footer

• Purpose: Provide the About Us content and the Group 7 credit required for the presentation prototype.
• Information shown: Short "About Us" text; group name "Group 7".
• Actions: None (informational).
• Domain states: Static.
• Feedback states: None.
• Owned components: AboutUs; GroupCredit.

10. Non-Functional Requirements

• NFR-1 — Deployment shape: The prototype must run entirely from local files, opened by double-clicking index.html, with no server, build step, or installation.
• NFR-2 — Offline data: All eatery content must come from the hardcoded data source; there must be no backend, database, login, or API calls.
• NFR-3 — Responsiveness: The layout must be mobile-first and must reflow at the 768px and 1024px breakpoints.
• NFR-4 — Card grid adaptation: 1 column on mobile, 2 columns on tablet, 3 columns on desktop.
• NFR-5 — Navigation adaptation: Bottom navigation bar (Home, Featured, Favorites) on mobile; top navbar on desktop.
• NFR-6 — Touch targets: All buttons must be at least 44px tall.
• NFR-7 — Legibility: Typography must be readable at mobile sizes, and contrast between text and background must be high.
• NFR-8 — Perceived performance: A simple loading effect must appear before content renders, and hover interactions must feel smooth.
• NFR-9 — Simplicity and maintainability: The code must stay simple and beginner-friendly so it can be explained during a presentation, with data isolated in data.js.
• NFR-10 — Local asset policy: Only free images (Unsplash links or placeholder images) may be used.
• NFR-11 — Compatibility: The prototype must work in modern desktop and mobile browsers when opened locally.
• NFR-12 — Content integrity: The interface must be driven entirely by the 10 sample eatery records; no listing content may be hardcoded directly into the markup.

11. Tech Stack

The accepted delivery shape is a static, front-end-only prototype, so only presentation-layer technology is required.

• Markup: HTML5 (index.html)
• Styling: CSS3 (style.css) — responsive layout with mobile-first breakpoints at 768px and 1024px
• Behavior: Vanilla JavaScript (ES6) (script.js) — live search, combined filtering, detail view, favorites, and rendering logic
• Data: A single hardcoded sample data file (data.js) holding 10 eatery objects with id, name, category, barangay, address, priceRange, rating, isVerified, isPromoted, hours, description, menuHighlights, contact, image
• Client persistence: Browser localStorage for saved favorites (no login)
• Images: Free images via Unsplash links or placeholder images

Explicitly out of scope — do not implement: backend services, databases, authentication or login, API calls, and JavaScript frameworks. Plain HTML/CSS/JavaScript is chosen as the simplest option permitted by the source material.

12. Assumptions and Constraints

Assumptions:

• The prototype is a class presentation deliverable for Group 7, not a deployed production service.
• Ten sample eateries across different Batangas City barangays are sufficient to demonstrate search, filtering, verification, promotion, and favorites.
• Judges/viewers will run the prototype by opening index.html locally in a browser.
• Free image links may require an internet connection to display; placeholder images are an acceptable fallback.

Constraints:

• Front-end only: no backend, no database, no login, and no API calls.
• All data must live in a single hardcoded JavaScript data file or JSON array.
• The prototype must work when opened locally from a folder.
• The prototype must look good on both phones and desktops.
• The code must remain simple and easy to explain.
• Categories are limited to Eatery, Street Food, and Turo-turo.
• Price is limited to the tiers\x20\xe2\x82\xb1,\x20\xe2\x82\xb1\xe2\x82\xb1, and\x20\xe2\x82\xb1\xe2\x82\xb1\xe2\x82\xb1.
• The footer must credit the group name as Group 7.
• Deliverables are limited to the four source files, short setup instructions, and a 3-sentence presentation explanation.

13. Glossary

14. Source Content Inventory

Source: chat_media/6b7ce22f-1528-460e-a065-32e0b18c094e/741fc317_GROUP-7_Batangas-Lowkey-Eatery_Value-Proposition-Canvas-Lean-Canvas.pdf — Group 7's Value Proposition Canvas / Lean Canvas for Batangas Lowkey Eatery.

Authority: domain_context and content_source — used as supplemental domain context for the directory's value proposition and audience, and as an authoritative content source for the project's stated value proposition. It is not a source of additional pages or features.

Identity:

• Project: Batangas Lowkey Eatery
• Owner: Group 7
• Document type: Value Proposition Canvas / Lean Canvas

Content (as supplied by the source):

• The canvas documents the directory's value proposition for people seeking verified, hidden local eateries in Batangas City, focused on small eateries, street food, and turo-turo spots that delivery apps and tourist sites skip.
• Audience: Batangas City residents, students, and visiting newcomers seeking affordable, authentic local food.
• Revenue-model concept: promoted/featured eatery listings surfaced in the Featured section.

Unverified facts: Specific canvas cell wording, named customer segments beyond those above, and any quantitative figures in the PDF are not reproduced here and remain unverified; downstream artifacts must not invent them. Where the canvas and the user requirement thread differ, the user requirement thread governs.