System Requirements Document for techzone-phones

1. Introduction

TechZone is a physical mobile phone shop that sells both brand-new sealed phones and second-hand/used phones. This project delivers a native Android application whose central purpose is to let customers check, in real time, exactly which phones are currently available in the shop — the app is the shop window for live stock.

The application is split into two clearly separated areas:

• Customer Area — accessible to everyone without a login. Customers open the app, immediately see "Phones Available at TechZone", browse available phones, search and filter, open a phone's details, and contact the shop via WhatsApp or the phone dialer.
• Admin Area — protected by a password and accessible only to the shop owner/staff. Admins log in, view inventory metrics, and add, edit, delete, and re-status phones, manage categories, and configure shop settings.

The audience is twofold: walk-in shoppers browsing TechZone's current stock on their own phones, and the shop owner/staff who maintain that stock behind a secure login. The inventory must always represent the current stock in the physical TechZone shop, and the app must be scalable so more phones, brands, categories, and features can be added later.

2. System Overview

TechZone is delivered as a native Android application built with Kotlin, Jetpack Compose, Material 3, MVVM architecture, and the Repository pattern, backed by a cloud backend (Firebase Authentication, Cloud Firestore, and Firebase Storage). The customer-facing inventory is driven by real-time backend synchronization: when the shop owner adds, edits, deletes, or re-statuses a phone, the customer-facing inventory updates automatically without requiring customers to manually refresh.

Actors

• Customer — an anonymous shopper who browses available phones, searches, filters, sorts, views details, and contacts the shop. No account is required.
• Shop Owner / Staff (Admin) — an authenticated operator who maintains the live inventory and shop settings.
• Cloud backend (Firebase) — a non-persona system actor that stores inventory and shop settings, hosts images, authenticates admins, and enforces authorization.

Accepted behavior

• Customer Home Screen with branding, search, condition filters, brand filters, sorting, price range, and available-phone cards.
• Phone Details Screen with full specification, gallery, and a prominent "Contact TechZone" action using the admin-configured WhatsApp/phone number.
• Real-time inventory that reflects the physical shop stock.
• Admin Login, Admin Dashboard with metrics and actions, Add Phone, Edit Phone, Delete Phone (with confirmation and soft deletion), Manage Categories, and Shop Settings.
• Security: secure admin authentication, backend-handled password hashing, admin-only database permissions, customer read-only access to available inventory, admin-only create/update/delete permissions, secure image storage, session management, and logout.

Narrow exclusions

• Customers must not be able to access the inventory management functions.
• The admin password must not be stored as plain text inside the Android application.
• The backend must enforce permissions; hiding the Admin button from customers is not sufficient.
• Only phones currently marked as Available appear in the main customer inventory by default.

2a. Product Interpretation and Delivery Boundary

The Customer Area is public and anonymous: no login, no account creation, and no gating of browsing, search, filtering, sorting, or phone details. The Admin Area is a separate, password-protected surface reachable only through the Admin Login screen, which requires username/email and password. Authentication and password hashing are handled by the backend; the Android app never stores the admin password as plain text. Authorization is enforced by the backend, not merely by hiding the Admin entry point.

The current delivery horizon covers the complete customer browsing and contact experience, the complete admin inventory management experience, shop settings, real-time synchronization, and the security model. The app is intentionally structured to be scalable so more phones, brands, categories, and features can be added later; such future additions are not part of the current acceptance scope.

2b. Source Content Inventory

Not applicable — no reference directive with content_source authority was supplied.

2c. Page Content and Component Coverage

Customer Home Screen

• Information/state: TechZone logo/name at the top; shop name TECHZONE; subtitle such as "Phones Available Now"; live count of available phones; the current search query; the active condition filter (All / Brand New / Second Hand); the active brand filter (Apple, Samsung, OnePlus, Xiaomi, Vivo, Oppo, Realme, Motorola, Other); the active sort order (Price: Low to High, Price: High to Low, Newest Added, Brand); the active price range; the list of available phones.
• Primary actions: enter a search query; select a condition filter; select a brand filter; open the sort/filter sheet; set a price range; tap "View Details" on a card; navigate to the Admin Login screen.
• Supporting actions: clear search; clear filters; reset sort; scroll the filter rails.
• Domain entities: Phone (id, brand, model, storage, ram, color, condition, price, originalPrice, batteryHealth, warranty, description, images, status, createdAt, updatedAt); Shop Settings (shop name, logo, address, phone number, WhatsApp number, opening hours, social links, description).
• Component responsibilities: app bar with wordmark and Admin link; hero block with wordmark, "PHONES AVAILABLE NOW", and live count; search field; condition filter chips; brand filter chips; sort/filter bar opening a bottom sheet; phone card grid/list; each card renders image, brand, model name, storage, RAM, condition, price, availability status, optional battery health for second-hand iPhones, optional warranty, and a "View Details" button.
• States:
  • Loading: skeleton/placeholder cards while the real-time inventory subscription is establishing.
  • Empty: no available phones match the current filters — a clear empty state with a reset-filters action.
  • Success: available-phone cards render and update live as the backend pushes changes.
  • Error: backend read failure — an error message with a retry action.
  • Recovery: retry re-establishes the real-time subscription; reset filters restores the default available inventory.

Phone Details Screen

• Information/state: large phone image/gallery; brand; model; storage; RAM; color; condition; price; battery health (if applicable); warranty; description; date/time the item was added; availability status.
• Primary actions: swipe through the image gallery; tap "Contact TechZone" to open WhatsApp or the phone dialer using the admin-configured number.
• Supporting actions: back navigation to the Customer Home Screen.
• Domain entities: Phone; Shop Settings (WhatsApp number, phone number).
• Component responsibilities: full-bleed image gallery with page dots; specification block; description block; sticky "Contact TechZone" button; availability status indicator.
• States:
  • Loading: placeholder while phone details and images load.
  • Empty: phone no longer available (e.g., marked Sold) — the details view reflects the current status.
  • Success: full details render with a working contact action.
  • Error: details or image load failure — an error message with retry.
  • Recovery: retry reloads details; if the phone is no longer available, the status reflects that.

Admin Login screen

• Information/state: username/email field; password field; authentication error message; loading state during sign-in.
• Primary actions: enter username/email; enter password; submit login.
• Supporting actions: navigate back to the Customer Area.
• Domain entities: Admin credential (handled by the backend; never stored as plain text in the app).
• Component responsibilities: credential form; submit control; error display; loading indicator.
• States:
  • Loading: sign-in in progress.
  • Empty: initial form state.
  • Success: authenticated session established; navigate to Admin Dashboard.
  • Error: invalid credentials or backend failure — a clear error message.
  • Recovery: re-enter credentials and retry.

Admin Dashboard

• Information/state: total phones; brand-new phones; second-hand phones; available phones; sold/unavailable phones.
• Primary actions: Add Phone; Edit Phone; Delete Phone; Mark as Sold; Mark as Available; Manage Categories; Shop Settings; Logout.
• Supporting actions: select an existing phone for editing or deletion.
• Domain entities: Phone; Shop Settings.
• Component responsibilities: metric tiles; action buttons; phone selection list.
• States:
  • Loading: metrics loading.
  • Empty: no phones in inventory — metrics show zero with a prompt to add the first phone.
  • Success: metrics and actions render with live values.
  • Error: metrics load failure — error message with retry.
  • Recovery: retry reloads metrics; logout returns to Admin Login.

Add Phone

• Information/state: form fields — brand; model; storage; RAM; color; condition (Brand New / Second Hand); price; original price (optional); battery health (optional); warranty; description; phone images; availability (Available / Sold / Reserved).
• Primary actions: fill fields; upload one or multiple photos; submit to add the phone.
• Supporting actions: remove an uploaded image; cancel.
• Domain entities: Phone; image assets in secure storage.
• Component responsibilities: validated form; image picker/uploader; submit control.
• States:
  • Loading: image upload and save in progress.
  • Empty: blank form.
  • Success: phone added; customer-facing inventory updates immediately.
  • Error: required-field validation failure or upload/save failure — inline messages.
  • Recovery: correct the fields or retry the upload; the form retains entered values.

Edit Phone

• Information/state: existing phone's current values across all editable fields — price; images; storage/RAM; condition; warranty; availability; description.
• Primary actions: select an existing phone; modify any field; save changes.
• Supporting actions: replace or remove images; cancel.
• Domain entities: Phone; image assets in secure storage.
• Component responsibilities: pre-populated editable form; image management; save control.
• States:
  • Loading: phone data and images loading; save in progress.
  • Empty: no phone selected.
  • Success: changes saved; customer-facing inventory updates immediately.
  • Error: validation or save failure — inline messages.
  • Recovery: retry save; the form retains edits.

Delete Phone

• Information/state: the selected phone; the confirmation dialog text "Are you sure you want to delete this phone?" with Cancel and Delete.
• Primary actions: confirm Delete; choose Cancel.
• Supporting actions: select a different phone.
• Domain entities: Phone (soft deletion so accidentally deleted inventory can potentially be recovered).
• Component responsibilities: confirmation dialog; delete action; cancel action.
• States:
  • Loading: deletion in progress.
  • Empty: no phone selected.
  • Success: phone removed from the customer-facing inventory.
  • Error: deletion failure — error message.
  • Recovery: retry deletion; Cancel dismisses the dialog without changes.

Manage Categories

• Information/state: the current set of categories/brands used by inventory.
• Primary actions: add a category; edit a category; remove a category.
• Supporting actions: view existing categories.
• Domain entities: Category.
• Component responsibilities: category list; add/edit/remove controls.
• States:
  • Loading: categories loading.
  • Empty: no categories defined.
  • Success: category changes saved and reflected in inventory forms and filters.
  • Error: save failure — error message.
  • Recovery: retry save.

Shop Settings

• Information/state: shop name; shop logo; shop address; phone number; WhatsApp number; opening hours; Instagram/social media links; shop description.
• Primary actions: edit each setting; upload/replace the shop logo; save settings.
• Supporting actions: cancel.
• Domain entities: Shop Settings record.
• Component responsibilities: settings form; logo uploader; save control.
• States:
  • Loading: settings loading; save in progress.
  • Empty: default/blank settings.
  • Success: settings saved and appear in the customer-facing app.
  • Error: validation or save failure — inline messages.
  • Recovery: retry save; the form retains edits.

3. Functional Requirements

FR-1 — Customer Home Screen branding and header (explicit) As a Customer, I should see the TechZone logo/name at the top, the shop name TECHZONE, and a subtitle such as "Phones Available Now", so that I immediately know I am in the TechZone shop app.

• Trigger: app open.
• Observable result: branded header renders with logo/name, TECHZONE, and subtitle.
• Access: no login required.
• Failure/recovery: if branding assets fail to load, the text wordmark still renders.
• Continuation: the customer proceeds to browse the available-phone list.

FR-2 — Customer Home Screen search bar (explicit) As a Customer, I should have a search bar on the home screen, so that I can quickly find phones.

• Trigger: customer enters a query.
• Observable result: the available-phone list filters to matching results.
• Access: no login required.
• Failure/recovery: no matches shows an empty state with a reset action.
• Continuation: the customer opens a matching phone's details.

FR-3 — Condition filter buttons (explicit) As a Customer, I should be able to filter by All, Brand New, or Second Hand, so that I can narrow the inventory to the condition I want.

• Trigger: customer selects a condition filter.
• Observable result: the list shows only phones matching the selected condition.
• Access: no login required.
• Failure/recovery: no matches shows an empty state with a reset action.
• Continuation: the customer combines the condition filter with brand filters and search.

FR-4 — Brand filters (explicit) As a Customer, I should be able to filter by brand — Apple, Samsung, OnePlus, Xiaomi, Vivo, Oppo, Realme, Motorola, Other — so that I can browse phones from the brands I care about.

• Trigger: customer selects a brand filter.
• Observable result: the list shows only phones matching the selected brand.
• Access: no login required.
• Failure/recovery: no matches shows an empty state with a reset action.
• Continuation: the customer opens a matching phone's details.

FR-5 — Available-phone cards (explicit) As a Customer, I should see available phones displayed as attractive cards showing phone image, brand, model name, storage, RAM, condition (Brand New or Second Hand), price, availability status, optional battery health percentage for second-hand iPhones, optional warranty information, and a "View Details" button, so that I can evaluate stock at a glance.

• Trigger: home screen inventory loads.
• Observable result: each available phone renders as a card with the listed fields.
• Access: no login required.
• Failure/recovery: a card whose image fails to load still shows its text fields.
• Continuation: the customer taps "View Details".

FR-6 — Only Available phones in the customer inventory (explicit) As a Customer, I should see only phones currently marked as Available in the customer inventory by default, so that I am not shown stock that is not for sale.

• Trigger: inventory load or real-time update.
• Observable result: phones with status Reserved or Sold do not appear in the default customer inventory.
• Access: no login required.
• Failure/recovery: if the backend read fails, an error state with retry is shown rather than stale data.
• Continuation: the customer browses the available set.

FR-7 — Phone Details Screen content (explicit) As a Customer, I should see a detailed page when I tap a phone, containing a large phone image/gallery, brand, model, storage, RAM, color, condition, price, battery health (if applicable), warranty, description, date/time when the item was added, and availability status, so that I can make an informed decision.

• Trigger: customer taps a phone card.
• Observable result: the details screen renders all listed fields.
• Access: no login required.
• Failure/recovery: details or image load failure shows an error with retry.
• Continuation: the customer contacts the shop.

FR-8 — Contact TechZone button (explicit) As a Customer, I should have a prominent "Contact TechZone" button that opens WhatsApp or the phone dialer, so that I can contact the shop about the phone.

• Trigger: customer taps "Contact TechZone".
• Observable result: WhatsApp or the phone dialer opens with the shop's configured number.
• Access: no login required.
• Failure/recovery: if the target app is unavailable, the alternative contact method is offered.
• Continuation: the customer completes contact with the shop.

FR-9 — Configurable WhatsApp/phone number (explicit) As a Shop Owner / Staff (Admin), I should be able to configure the WhatsApp/phone number from the Admin Area rather than it being hard-coded, so that the customer contact action always uses the correct number.

• Trigger: admin edits the WhatsApp/phone number in Shop Settings.
• Observable result: the "Contact TechZone" action uses the configured number.
• Access: authenticated admin only.
• Failure/recovery: invalid number input is rejected with a validation message.
• Continuation: the customer's contact action uses the updated number.

FR-10 — Real-time inventory synchronization (explicit) As a Customer, I should see the customer-facing inventory update automatically when the shop owner adds, edits, or deletes a phone, without manually refreshing, so that I always see current stock.

• Trigger: admin add/edit/delete/status change in the Admin Area.
• Observable result: the customer-facing inventory reflects the change automatically.
• Access: no login required for the customer view.
• Failure/recovery: if the real-time connection drops, the app re-establishes it and shows an error state with retry in the interim.
• Continuation: the customer continues browsing the updated inventory.

FR-11 — Sold phone disappears from available inventory (explicit) As a Customer, when the shop sells a phone and the admin marks it as Sold/Unavailable, it should immediately disappear from my available inventory, so that I do not pursue stock that is gone.

• Trigger: admin marks a phone as Sold/Unavailable.
• Observable result: the phone is removed from the customer's available inventory.
• Access: no login required for the customer view.
• Failure/recovery: if the update fails to propagate, the app surfaces an error and retries synchronization.
• Continuation: the customer browses the remaining available phones.

FR-12 — Separate Admin Login screen (explicit) As a Shop Owner / Staff (Admin), I should have a separate Admin Login screen requiring username/email and password, so that only authorized staff can reach administration.

• Trigger: navigating to the Admin Area.
• Observable result: the Admin Login screen requests username/email and password.
• Access: anonymous entry to the login screen; protected administration only after successful authentication.
• Failure/recovery: invalid credentials show a clear error and allow retry.
• Continuation: successful login opens the Admin Dashboard.

FR-13 — Customers cannot access inventory management (explicit) As a Shop Owner / Staff (Admin), customers should not be able to access the inventory management functions, so that stock control remains restricted to the shop.

• Trigger: any attempt to reach inventory management without authentication.
• Observable result: inventory management functions are inaccessible to customers.
• Access: enforced by backend authentication and authorization, not merely by hiding the Admin button.
• Failure/recovery: unauthorized attempts are rejected.
• Continuation: authorized admins proceed normally.

FR-14 — Secure admin authentication and credential storage (explicit) As a Shop Owner / Staff (Admin), the admin section must be protected using proper authentication and authorization, and the admin password must not be stored as plain text inside the Android application, so that credentials remain secure.

• Trigger: admin login.
• Observable result: authentication is handled securely by the backend with password hashing; no plain-text password is stored in the app.
• Access: authenticated admin only.
• Failure/recovery: authentication failures are reported without exposing credential details.
• Continuation: the authenticated admin reaches the Admin Dashboard.

FR-15 — Admin Dashboard metrics (explicit) As a Shop Owner / Staff (Admin), I should see total phones, brand-new phones, second-hand phones, available phones, and sold/unavailable phones after logging in, so that I understand the current inventory position.

• Trigger: successful admin login.
• Observable result: the dashboard shows all five metrics.
• Access: authenticated admin only.
• Failure/recovery: metrics load failure shows an error with retry.
• Continuation: the admin takes an inventory action.

FR-16 — Admin Dashboard actions (explicit) As a Shop Owner / Staff (Admin), I should have buttons for Add Phone, Edit Phone, Delete Phone, Mark as Sold, Mark as Available, Manage Categories, Shop Settings, and Logout, so that I can perform all inventory operations from one place.

• Trigger: admin views the dashboard.
• Observable result: all listed actions are available.
• Access: authenticated admin only.
• Failure/recovery: an action that fails reports an error and leaves inventory unchanged.
• Continuation: the admin completes the chosen action and returns to the dashboard.

FR-17 — Add Phone form fields (explicit) As a Shop Owner / Staff (Admin), I should have an easy form for adding a phone with brand, model, storage, RAM, color, condition (Brand New or Second Hand), price, original price (optional), battery health (optional), warranty, description, phone images, and availability (Available, Sold, Reserved), so that I can record complete inventory details.

• Trigger: admin opens Add Phone.
• Observable result: the form presents all listed fields.
• Access: authenticated admin only.
• Failure/recovery: validation errors are shown inline.
• Continuation: the admin submits the form.

FR-18 — Multiple photo upload (explicit) As a Shop Owner / Staff (Admin), I should be able to upload one or multiple photos for a phone, so that customers can see the actual device.

• Trigger: admin selects images in Add Phone or Edit Phone.
• Observable result: one or more images are uploaded to secure image storage and associated with the phone.
• Access: authenticated admin only.
• Failure/recovery: upload failure shows an error and allows retry without losing other form data.
• Continuation: the admin saves the phone.

FR-19 — Required-field validation on Add Phone (explicit) As a Shop Owner / Staff (Admin), required fields must be validated before allowing the phone to be added, so that incomplete inventory records cannot enter the system.

• Trigger: admin attempts to submit Add Phone.
• Observable result: submission is blocked until required fields are valid, with clear validation messages.
• Access: authenticated admin only.
• Failure/recovery: the form retains entered values for correction.
• Continuation: the admin corrects the fields and resubmits.

FR-20 — Edit Phone (explicit) As a Shop Owner / Staff (Admin), I should be able to select an existing phone and edit any of its information — price, images, storage/RAM, condition, warranty, availability, and description — so that inventory stays accurate.

• Trigger: admin selects a phone and opens Edit Phone.
• Observable result: the phone's current values are editable and saved changes immediately update the customer-facing inventory.
• Access: authenticated admin only.
• Failure/recovery: save failure shows an error and retains edits.
• Continuation: the admin returns to the dashboard.

FR-21 — Delete Phone with confirmation (explicit) As a Shop Owner / Staff (Admin), I should have a Delete option that shows a confirmation dialog "Are you sure you want to delete this phone?" with Cancel and Delete, so that accidental deletions are prevented.

• Trigger: admin chooses Delete for a phone.
• Observable result: the confirmation dialog appears with Cancel and Delete.
• Access: authenticated admin only.
• Failure/recovery: Cancel dismisses the dialog with no change; a failed deletion reports an error.
• Continuation: on Delete, the phone is removed from the customer-facing inventory.

FR-22 — Soft deletion (explicit) As a Shop Owner / Staff (Admin), soft deletion should be considered in the database so that accidentally deleted inventory can potentially be recovered.

• Trigger: admin confirms deletion.
• Observable result: the record is soft-deleted so it can potentially be recovered.
• Access: authenticated admin only.
• Failure/recovery: a failed soft delete reports an error and leaves the record intact.
• Continuation: the phone no longer appears in the customer-facing inventory.

FR-23 — Customer search scope (explicit) As a Customer, search should work by brand, model, storage, and price, so that I can find phones by the attributes I know.

• Trigger: customer enters a query.
• Observable result: results match on brand, model, storage, or price.
• Access: no login required.
• Failure/recovery: no matches shows an empty state with a reset action.
• Continuation: the customer opens a matching phone.

FR-24 — Sorting options (explicit) As a Customer, I should be able to sort by Price: Low to High, Price: High to Low, Newest Added, and Brand, so that I can order results the way I prefer.

• Trigger: customer selects a sort option.
• Observable result: the list reorders according to the selected sort.
• Access: no login required.
• Failure/recovery: an unavailable sort falls back to the default order.
• Continuation: the customer opens a phone from the sorted list.

FR-25 — Price range filter (explicit) As a Customer, I should have a price range filter, so that I can limit results to my budget.

• Trigger: customer sets a price range.
• Observable result: only phones within the range are shown.
• Access: no login required.
• Failure/recovery: an empty range result shows an empty state with a reset action.
• Continuation: the customer opens a phone within the range.

FR-26 — Shop Settings configuration (explicit) As a Shop Owner / Staff (Admin), I should be able to configure shop name, shop logo, shop address, phone number, WhatsApp number, opening hours, Instagram/social media links, and shop description, so that the customer-facing app reflects the real shop.

• Trigger: admin edits Shop Settings.
• Observable result: the settings are saved and appear in the customer-facing app.
• Access: authenticated admin only.
• Failure/recovery: validation or save failure shows an error and retains edits.
• Continuation: customers see the updated shop information.

FR-27 — Shop Settings appear in the customer app (explicit) As a Customer, the shop settings configured by the admin should appear in the customer-facing app, so that I have accurate shop information and contact details.

• Trigger: customer browses the app.
• Observable result: shop name, logo, address, phone number, WhatsApp number, opening hours, social links, and description are reflected in the customer-facing app.
• Access: no login required.
• Failure/recovery: if settings fail to load, the app shows an error state with retry.
• Continuation: the customer uses the contact action.

FR-28 — Clear status labels (explicit) As a Shop Owner / Staff (Admin), I should use clear status labels — Available, Reserved, Sold — so that inventory status is unambiguous.

• Trigger: viewing or setting a phone's status.
• Observable result: the status is displayed and selectable as Available, Reserved, or Sold.
• Access: authenticated admin only for setting status.
• Failure/recovery: an invalid status change is rejected.
• Continuation: the status is reflected in the customer-facing inventory.

FR-29 — Inventory record structure (explicit) As a Shop Owner / Staff (Admin), a phone/inventory record should contain fields similar to id, brand, model, storage, ram, color, condition, price, originalPrice, batteryHealth, warranty, description, images, status, createdAt, and updatedAt, so that inventory data is complete and consistent.

• Trigger: creating or updating a phone record.
• Observable result: the record stores the listed fields.
• Access: authenticated admin only for writes.
• Failure/recovery: a malformed record is rejected with an error.
• Continuation: the record is available to the customer-facing inventory.

FR-30 — Shop settings record (explicit) As a Shop Owner / Staff (Admin), a shop settings record should exist in the backend, so that shop configuration is stored consistently.

• Trigger: saving Shop Settings.
• Observable result: a shop settings record is created or updated.
• Access: authenticated admin only for writes.
• Failure/recovery: save failure shows an error and retains edits.
• Continuation: the settings appear in the customer-facing app.

FR-31 — Real-time database synchronization (explicit) As a Shop Owner / Staff (Admin), real-time database synchronization should be used if supported by the chosen backend, so that customer-facing inventory stays current.

• Trigger: any inventory or settings change.
• Observable result: changes propagate to the customer-facing inventory automatically.
• Access: backend-enforced.
• Failure/recovery: connection loss triggers reconnection and an error state with retry.
• Continuation: customers see the updated inventory.

FR-32 — Security implementation (explicit) As a Shop Owner / Staff (Admin), the app should implement secure admin authentication, password hashing/authentication handled by the backend, admin-only database permissions, customer read-only access to available inventory, admin-only create/update/delete permissions, secure image storage, session management, and logout functionality, so that the system is secure end to end.

• Trigger: any authenticated or unauthenticated access attempt.
• Observable result: permissions are enforced by the backend; customers have read-only access to available inventory; only admins can create, update, or delete.
• Access: backend-enforced.
• Failure/recovery: unauthorized operations are rejected.
• Continuation: authorized operations proceed normally.

FR-33 — Backend-enforced permissions (explicit) As a Shop Owner / Staff (Admin), the backend must enforce the permissions rather than relying only on hiding the Admin button from customers, so that security does not depend on UI concealment.

• Trigger: any attempt to perform a restricted operation.
• Observable result: the backend rejects unauthorized operations regardless of UI state.
• Access: backend-enforced.
• Failure/recovery: rejected operations return an error without side effects.
• Continuation: authorized admins continue working.

FR-34 — Recommended technology stack (explicit) As a Shop Owner / Staff (Admin), the app should be built as a native Android application using Kotlin, Jetpack Compose, Material 3, MVVM architecture, the Repository pattern, and a cloud backend such as Firebase, using Firebase Authentication for admin login, Cloud Firestore for inventory, and Firebase Storage for phone images; if a different backend is chosen, it must maintain the same security and real-time requirements.

• Trigger: project build and configuration.
• Observable result: the app is built on the specified stack with the specified backend services.
• Access: not applicable.
• Failure/recovery: if a different backend is chosen, the same security and real-time requirements must be maintained.
• Continuation: the app functions with the chosen backend.

FR-35 — Customer flow (explicit) As a Customer, the flow should be Open App → Browse Phones → Search/Filter → View Phone → Contact TechZone, and I should not need to create an account just to browse phones.

• Trigger: app open.
• Observable result: the customer can complete the full flow without creating an account.
• Access: no login required.
• Failure/recovery: any step failure shows an error with retry.
• Continuation: the customer contacts the shop.

FR-36 — Admin flow (explicit) As a Shop Owner / Staff (Admin), the flow should be Admin Login → Dashboard → Add/Edit/Delete/Update Inventory.

• Trigger: admin opens the Admin Area.
• Observable result: the admin completes login and reaches the dashboard to manage inventory.
• Access: authenticated admin only.
• Failure/recovery: login failure shows an error and allows retry.
• Continuation: the admin manages inventory and logs out.

FR-37 — Inventory reflects physical shop stock (explicit) As a Shop Owner / Staff (Admin), the inventory must represent the current stock in the physical TechZone shop; when a phone is sold, I should be able to mark it as Sold/Unavailable from the Admin Area, and customers should no longer see it as available.

• Trigger: admin marks a sold phone as Sold/Unavailable.
• Observable result: the phone no longer appears as available to customers.
• Access: authenticated admin only for the status change.
• Failure/recovery: a failed status change reports an error and leaves the status unchanged.
• Continuation: customers see the updated available inventory.

FR-38 — Scalability (explicit) As a Shop Owner / Staff (Admin), the application should be scalable so more phones, brands, categories, and features can be added later.

• Trigger: adding phones, brands, categories, or features.
• Observable result: the app accommodates growth without structural rework.
• Access: not applicable.
• Failure/recovery: not applicable.
• Continuation: the app continues to function as inventory grows.

FR-39 — Deliverables (explicit) As a Shop Owner / Staff (Admin), the complete Android application should include Customer UI, Admin UI, authentication, database, image upload, inventory management, search and filters, real-time inventory updates, secure admin permissions, shop settings, proper error handling, loading states, empty inventory states, responsive Android UI, and production-ready project structure.

• Trigger: project delivery.
• Observable result: all listed deliverables are present.
• Access: not applicable.
• Failure/recovery: not applicable.
• Continuation: the app is ready for use and publication.

FR-40 — Setup and publishing instructions (explicit) As a Shop Owner / Staff (Admin), clear instructions should be provided for setting up the backend, creating the first admin account, configuring TechZone's phone/WhatsApp number, adding the first phone, building the APK, and publishing the app to Google Play.

• Trigger: project handover.
• Observable result: instructions cover all listed topics.
• Access: not applicable.
• Failure/recovery: not applicable.
• Continuation: the shop can operate and publish the app.

FR-41 — First admin account provisioning (required_inference) As a Shop Owner / Staff (Admin), a first admin account must be securely provisioned through the backend before administrative use, so that the accepted admin journey is executable.

• Trigger: initial backend setup.
• Observable result: a secure admin account exists and can authenticate.
• Access: backend provisioning.
• Failure/recovery: provisioning failure is reported with guidance.
• Continuation: the admin logs in via the Admin Login screen.

FR-42 — Admin returning verification (required_inference) As a Shop Owner / Staff (Admin), returning verification must occur through the Admin Login screen before protected administration is available, so that only verified staff reach the Admin Area.

• Trigger: admin opens the Admin Area.
• Observable result: the Admin Login screen verifies credentials before granting access.
• Access: anonymous entry to the login screen; protected administration only after verification.
• Failure/recovery: failed verification shows an error and allows retry.
• Continuation: verified admins reach the Admin Dashboard.

FR-43 — Backend authorization for mutations (required_inference) As a Shop Owner / Staff (Admin), backend authorization must restrict inventory and shop-setting mutations to authenticated shop owner or staff accounts, so that only authorized staff can change stock.

• Trigger: any mutation attempt.
• Observable result: only authenticated admin accounts can mutate inventory or shop settings.
• Access: backend-enforced.
• Failure/recovery: unauthorized mutations are rejected.
• Continuation: authorized mutations proceed.

FR-44 — Customer inventory reads limited to Available (required_inference) As a Customer, customer inventory reads must expose only phones whose status is Available, so that I never see unavailable stock in the default inventory.

• Trigger: inventory read.
• Observable result: only Available phones are returned to the customer inventory.
• Access: no login required.
• Failure/recovery: read failure shows an error with retry.
• Continuation: the customer browses the available set.

FR-45 — Real-time propagation of inventory changes (required_inference) As a Customer, real-time backend synchronization must propagate authoritative inventory changes to the customer-facing inventory, so that my view stays current without manual refresh.

• Trigger: backend inventory change.
• Observable result: the customer-facing inventory updates automatically.
• Access: no login required.
• Failure/recovery: connection loss triggers reconnection and an error state with retry.
• Continuation: the customer continues browsing the updated inventory.

4. User Personas

Customer

Product context: A walk-in shopper browsing TechZone's current stock on their own Android phone. They may be looking for a sealed brand-new device or a graded second-hand phone, and they want to know what is actually on the shelf right now before visiting or calling.

Primary goal: Find an available phone that matches their needs and budget, and reach TechZone to buy it.

Distinct accepted responsibilities:

• Open the app and immediately see "Phones Available at TechZone" without creating an account.
• Browse available phones as cards showing image, brand, model, storage, RAM, condition, price, availability status, optional battery health for second-hand iPhones, and optional warranty.
• Search by brand, model, storage, and price.
• Filter by condition (All, Brand New, Second Hand) and by brand (Apple, Samsung, OnePlus, Xiaomi, Vivo, Oppo, Realme, Motorola, Other).
• Sort by Price: Low to High, Price: High to Low, Newest Added, or Brand.
• Apply a price range filter.
• Open a phone's details to see the large image/gallery, full specification, description, date/time added, and availability status.
• Contact TechZone via WhatsApp or the phone dialer using the admin-configured number.

Relevant inputs or decisions: search queries; condition and brand filter selections; sort selection; price range; which phone to open; whether to contact the shop.

Interactions with other accepted participants: The Customer's browsing is served by the live inventory maintained by the Shop Owner / Staff (Admin). When the admin marks a phone Sold or Reserved, the Customer's available inventory updates automatically. The Customer's contact action uses the WhatsApp/phone number configured by the admin.

Observable success: The Customer finds an available phone and successfully reaches TechZone through WhatsApp or the dialer.

Shop Owner / Staff (Admin)

Product context: The shop owner or staff member who maintains the live inventory behind a password-protected login. They work back-of-house, keeping the app's inventory aligned with the physical stock in the shop.

Primary goal: Ensure the customer-facing inventory always reflects the physical stock in the shop.

Distinct accepted responsibilities:

• Log in through the separate Admin Login screen with username/email and password.
• View the Admin Dashboard metrics: total phones, brand-new phones, second-hand phones, available phones, and sold/unavailable phones.
• Add phones with brand, model, storage, RAM, color, condition, price, optional original price, optional battery health, warranty, description, images, and availability (Available, Sold, Reserved).
• Upload one or multiple photos per phone.
• Edit any information on an existing phone — price, images, storage/RAM, condition, warranty, availability, and description.
• Delete a phone after confirming "Are you sure you want to delete this phone?" with Cancel or Delete, with soft deletion considered for recovery.
• Mark phones as Sold or Available.
• Manage categories.
• Configure shop settings: shop name, shop logo, shop address, phone number, WhatsApp number, opening hours, Instagram/social media links, and shop description.
• Log out.

Relevant inputs or decisions: which phone to add, edit, delete, or re-status; which images to upload; which categories to manage; which shop settings to configure; when a phone has been sold in the physical shop.

Interactions with other accepted participants: The Admin's inventory changes propagate in real time to the Customer's available inventory. The Admin's shop settings — especially the WhatsApp/phone number — drive the Customer's "Contact TechZone" action.

Observable success: The customer-facing inventory always reflects the physical stock in the shop, and customers can reach the shop using the configured contact details.

5. Core User Flows

Flow 1 — Customer browses available phones and contacts TechZone

1. The Customer opens the TechZone app. No login or account creation is required.
2. The Customer Home Screen renders the TechZone logo/name, the shop name TECHZONE, and a subtitle such as "Phones Available Now", with the available-phone inventory loaded from the backend.
3. The Customer sees only phones currently marked as Available, displayed as cards showing phone image, brand, model name, storage, RAM, condition, price, availability status, optional battery health for second-hand iPhones, optional warranty, and a "View Details" button.
4. The Customer optionally enters a search query; results match on brand, model, storage, and price.
5. The Customer optionally selects a condition filter (All, Brand New, Second Hand) and/or a brand filter (Apple, Samsung, OnePlus, Xiaomi, Vivo, Oppo, Realme, Motorola, Other).
6. The Customer optionally selects a sort order (Price: Low to High, Price: High to Low, Newest Added, Brand) and/or sets a price range.
7. If no phones match, the Customer sees an empty state and can reset the filters.
8. The Customer taps "View Details" on a phone.
9. The Phone Details Screen shows the large phone image/gallery, brand, model, storage, RAM, color, condition, price, battery health (if applicable), warranty, description, date/time the item was added, and availability status.
10. The Customer taps the prominent "Contact TechZone" button.
11. WhatsApp or the phone dialer opens using the WhatsApp/phone number configured by the admin in Shop Settings.
12. The Customer contacts the shop to arrange the purchase.
13. Failure/recovery: If the inventory read fails, the Customer sees an error state with a retry action. If the details or images fail to load, the Customer sees an error with retry. If the phone is marked Sold or Reserved while the Customer is viewing it, the availability status reflects the change and the phone no longer appears in the available inventory.
14. Continuation: The Customer returns to the Customer Home Screen to browse other available phones.

Flow 2 — Customer sees a sold phone disappear in real time

1. The Customer is browsing the Customer Home Screen with the available-phone inventory displayed.
2. In the physical shop, a phone is sold.
3. The Shop Owner / Staff (Admin) marks that phone as Sold/Unavailable from the Admin Area.
4. The backend propagates the change through real-time synchronization.
5. The phone immediately disappears from the Customer's available inventory without the Customer manually refreshing.
6. Failure/recovery: If the real-time connection drops, the app re-establishes it and shows an error state with retry in the interim.
7. Continuation: The Customer continues browsing the remaining available phones.

Flow 3 — Admin logs in and reviews the dashboard

1. The Shop Owner / Staff (Admin) opens the Admin Area from the app.
2. The Admin Login screen requests username/email and password.
3. The Admin enters credentials and submits.
4. The backend authenticates the credentials with password hashing; no plain-text password is stored in the Android app.
5. On success, the Admin Dashboard opens showing total phones, brand-new phones, second-hand phones, available phones, and sold/unavailable phones.
6. The Admin sees the action buttons: Add Phone, Edit Phone, Delete Phone, Mark as Sold, Mark as Available, Manage Categories, Shop Settings, and Logout.
7. Failure/recovery: If credentials are invalid or the backend fails, the Admin sees a clear error and can retry. If metrics fail to load, the Admin sees an error with retry.
8. Continuation: The Admin chooses an inventory action or logs out.

Flow 4 — Admin adds a phone

1. The Admin opens Add Phone from the Admin Dashboard.
2. The Admin fills in brand, model, storage, RAM, color, condition (Brand New or Second Hand), price, original price (optional), battery health (optional), warranty, description, and availability (Available, Sold, Reserved).
3. The Admin uploads one or multiple photos of the phone.
4. The Admin submits the form.
5. Required fields are validated before the phone can be added; if validation fails, the Admin sees inline messages and the form retains entered values.
6. On success, the phone is added and the customer-facing inventory updates immediately.
7. Failure/recovery: If image upload or save fails, the Admin sees an error and can retry without losing other form data.
8. Continuation: The Admin returns to the Admin Dashboard.

Flow 5 — Admin edits a phone

1. The Admin selects an existing phone from the Admin Dashboard and opens Edit Phone.
2. The form is pre-populated with the phone's current values.
3. The Admin changes any information — price, images, storage/RAM, condition, warranty, availability, or description.
4. The Admin saves the changes.
5. Changes immediately update the customer-facing inventory.
6. Failure/recovery: If the save fails, the Admin sees an error and the form retains the edits.
7. Continuation: The Admin returns to the Admin Dashboard.

Flow 6 — Admin deletes a phone

1. The Admin selects a phone and chooses Delete.
2. A confirmation dialog appears: "Are you sure you want to delete this phone?" with Cancel and Delete.
3. If the Admin chooses Cancel, the dialog dismisses and nothing changes.
4. If the Admin chooses Delete, the phone is deleted; soft deletion is considered in the database so accidentally deleted inventory can potentially be recovered.
5. The phone is removed from the customer-facing inventory.
6. Failure/recovery: If deletion fails, the Admin sees an error and the record remains intact.
7. Continuation: The Admin returns to the Admin Dashboard.

Flow 7 — Admin marks a phone as Sold or Available

1. The Admin selects a phone from the Admin Dashboard.
2. The Admin chooses Mark as Sold or Mark as Available.
3. The phone's status changes to Sold or Available accordingly.
4. The customer-facing inventory updates immediately: a Sold phone no longer appears as available; an Available phone appears in the customer inventory.
5. Failure/recovery: If the status change fails, the Admin sees an error and the status remains unchanged.
6. Continuation: The Admin returns to the Admin Dashboard.

Flow 8 — Admin manages categories

1. The Admin opens Manage Categories from the Admin Dashboard.
2. The Admin views the current categories/brands used by inventory.
3. The Admin adds, edits, or removes a category.
4. The changes are saved and reflected in inventory forms and filters.
5. Failure/recovery: If the save fails, the Admin sees an error and can retry.
6. Continuation: The Admin returns to the Admin Dashboard.

Flow 9 — Admin configures shop settings

1. The Admin opens Shop Settings from the Admin Dashboard.
2. The Admin edits shop name, shop logo, shop address, phone number, WhatsApp number, opening hours, Instagram/social media links, and shop description.
3. The Admin saves the settings.
4. The settings appear in the customer-facing app, and the "Contact TechZone" action uses the configured WhatsApp/phone number.
5. Failure/recovery: If validation or save fails, the Admin sees an error and the form retains the edits.
6. Continuation: The Admin returns to the Admin Dashboard.

Flow 10 — Admin logs out

1. The Admin chooses Logout from the Admin Dashboard.
2. The session ends and the Admin Area is no longer accessible without re-authentication.
3. Continuation: The Admin returns to the Customer Area or the Admin Login screen.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Virgil Abloh, and the headline concept is "TechZone as a drop, not a catalogue" — the app is the shop window for live stock, and the visual grammar is industrial precision, quoted labels, hazard stripes, and exposed grid lines rather than corporate retail calm.

Color tokens

Light mode is concrete-grey paper (#F4F4F2) with pure white product cards and near-black ink. Primary is black — used for the wordmark, top bars, and primary buttons, never as a background wash. Safety orange #FF4D00 is the single hot accent: status pills, price, the Contact TechZone button, hazard stripes, and the live-inventory pulse. Muted grey #8C8C8C carries specs metadata (storage, RAM, colour) in small caps. Dark mode inverts to #0A0A0A ground, #161616 surface, #F4F4F2 text, orange unchanged, muted #6E6E6E; the black-on-white cards become white-on-black with the same hairline borders. Ratio: ~70% neutral ground, ~20% black ink blocks, ~10% orange. Orange never carries body text on light ground at small size — it is reserved for large numerals, pills, and buttons where it sits on black or white with 4.5:1+ contrast.

Typography

• Headings: Archivo Black — all-caps for the TECHZONE wordmark, section headers, and price figures, set with wide letterspacing (0.04em–0.12em) so it reads as an industrial label rather than a shout.
• Specs and status labels: Archivo medium in uppercase with 0.08em tracking at small sizes, mimicking a printed tag.
• Body: Archivo regular, generous line-height (1.55), sentence case — the plain-talk half of the muse.
• Never mix more than three sizes on one screen.
• Type scale: 1.333 modular. Customer home hero wordmark clamp(40px, 11vw, 96px); section headers 28/22/18; card model name 20; specs labels 11 uppercase tracked; price 24 black; body 15/16; micro-labels 11. Mobile floor for the wordmark is 40px so TECHZONE stays whole at 375px; desktop ceiling 96px.

Shape language

• Hard edges, zero border radius on cards, buttons, and inputs — the only rounded element is the phone product image itself, cropped into a square frame.
• Hairline 1px borders in #0A0A0A at 12% opacity on light, #F4F4F2 at 14% on dark, plus 2px solid black borders on the primary action buttons.
• Hazard-stripe dividers (45° repeating-linear-gradient, 8px pitch, black/orange) used as section separators and as a 6px top rule under the app bar.
• Status pills are rectangular with a 2px border and a leading 8px square dot, not a circle.
• Exposed grid: a faint 8px vertical rule pattern behind the hero only.

Spacing rhythm

• 20px gutter on mobile; 8px base unit; section spacing in multiples of 8; generous vertical rhythm between the hero, filter rail, and feed.

Imagery style

• Product photography on concrete or plain grey seamless, shot straight-on and tightly cropped into a square frame — no lifestyle staging, no hands, no happy people.
• Second-hand phones get an "authenticated" treatment: the same shot with a small orange tag overlay in the corner reading "BATTERY 89%" or "GRADE A".
• Brand-new phones are shot sealed, with the box edge visible in frame.
• Where a phone image is missing, the card shows a black panel with the brand name in tracked white caps and a hairline phone outline — never a stock placeholder or a coloured blob.
• Admin-side thumbnails are the same square crop at 64px.
• No illustration, no 3D renders, no gradient overlays.

7. Signature Design Concept

The public entry — the Customer Home Screen — is composed as a drop board, not a catalogue page.

The first screen opens with a full-bleed black block (#0A0A0A) occupying roughly the top 38% of the viewport, with a faint 8px vertical grid rule pattern at 6% white behind it. TECHZONE is set in Archivo Black all-caps at clamp(40px, 11vw, 96px), white, tracking 0.06em, flush left with a 20px gutter, and it is allowed to run to the right edge of the viewport — it is the dominant element and the largest thing on screen. Beneath it, in orange tracked caps at 12px, PHONES AVAILABLE NOW, and next to it a live count rendered as a black pill with an orange square dot and the numeral in Archivo Black 16px, which rolls when inventory changes. A 6px hazard stripe (black/orange 45°) closes the black block and separates it from the grey paper feed. The search field and condition chips sit immediately below the stripe on the grey ground, not inside the black block. No centred headline, no subtext paragraph, no gradient, no button inside the hero — the only action above the fold is scrolling into the feed. At 375px the wordmark wraps to two lines if needed and the live-count pill drops to its own row so nothing is clipped.

The signature moves that carry the concept through the app:

• Hazard-stripe section dividers: a 6px 45° black/orange repeating stripe that replaces every horizontal rule and closes the hero, the details spec block, and the admin stat grid.
• Quoted-label spec tags: every phone card carries a rectangular bordered tag reading e.g. "64GB / 4GB RAM / GRADE A" in 11px tracked uppercase Archivo, with the condition and battery health set inside the same tag block as if printed on a physical inventory label.
• Live inventory counter as a black pill with an orange square dot in the hero, whose numeral rolls 200ms whenever the backend pushes a stock change — the "real-time" promise made visible on the first screen.
• Status pills as rectangles with a leading square dot (orange = Available, amber-grey #B58900 = Reserved, #8C8C8C = Sold) and a strikethrough that draws across the model name when an item is marked sold, so the admin's action is legible to customers who had the card open.
• A sticky bottom "CONTACT TECHZONE" bar on the details screen: full-width black rectangle, 2px orange top border, white tracked-caps label, which opens WhatsApp with the model name pre-filled from the admin-configured number.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the TECHZONE wordmark and the live available-phone count pill, set on the full-bleed black hero block with its faint 8px vertical grid rule pattern.
• Input → transformation → outcome thesis: as the backend pushes an inventory change, the live count numeral rolls 200ms and the affected card's status pill crossfades from orange to grey with a single 1px horizontal strike-through drawing left-to-right across the model name — the customer sees the shop's real-time stock change without any manual refresh.
• Motion vocabulary: snappy and mechanical, never bouncy. Card entrance is a 180ms fade with a 12px upward translate, staggered 40ms per card, capped at 8 cards. Status changes flip the pill from orange to grey with a 120ms crossfade and a single 1px horizontal strike-through that draws left-to-right across the model name. The live inventory count in the hero does a 200ms digit roll when the backend pushes a change. Hazard stripe dividers do not animate. The top bar's orange rule is static.
• Composed first frame: the black hero block fills the top ~38% of the viewport; TECHZONE sits flush left in white Archivo Black, running toward the right edge; beneath it "PHONES AVAILABLE NOW" in tracked orange caps with the live-count pill beside it; the 6px hazard stripe closes the block; the search field and condition chips sit on the grey paper ground below.
• Reduced-motion state: under prefers-reduced-motion all of the above collapse to instant state changes with no translate and no strike-through animation — the sold state is shown by the grey pill and a static strikethrough. The horizontally scrollable filter rails wrap into two rows instead of scrolling.

9. Non-Functional Requirements

NFR-1 — Real-time synchronization (explicit) The inventory must be stored in a proper database/cloud backend, and when the shop owner adds, edits, or deletes a phone from the Admin Area, the customer-facing inventory must update automatically. Customers must not be required to manually refresh the app if the backend supports real-time updates. Rationale: the app's core purpose is real-time stock visibility.

NFR-2 — Security (explicit) The app must implement secure admin authentication, password hashing/authentication handled by the backend, admin-only database permissions, customer read-only access to available inventory, admin-only create/update/delete permissions, secure image storage, session management, and logout functionality. The backend must enforce the permissions rather than relying only on hiding the Admin button from customers. Rationale: security is explicitly important and must not depend on UI concealment.

NFR-3 — Credential storage (explicit) The admin password must not be stored as plain text inside the Android application; credentials must be stored securely. Rationale: explicit security constraint.

NFR-4 — Responsive Android UI (explicit) The UI must work well on both small and large Android phones. Rationale: explicit design requirement.

NFR-5 — Light and dark mode (explicit) Both light and dark mode should be included if practical. Rationale: explicit design requirement.

NFR-6 — Error handling, loading states, and empty inventory states (explicit) The app must include proper error handling, loading states, and empty inventory states. Rationale: explicit deliverable.

NFR-7 — Production-ready project structure (explicit) The project must have a production-ready structure. Rationale: explicit deliverable.

NFR-8 — Scalability (explicit) The application must be scalable so more phones, brands, categories, and features can be added later. Rationale: explicit requirement.

NFR-9 — Backend portability (explicit) If a different backend is chosen instead of Firebase, it must maintain the same security and real-time requirements. Rationale: explicit constraint.

NFR-10 — Readable text and controls at every viewport (explicit) Headlines, wordmarks, labels, numbers, cards' text, and controls must 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 may cover any part of them. Moving and scrollable content may cross the viewport or container edge by design, but every item must become fully readable as it passes; with prefers-reduced-motion it stops and shows whole items. Rationale: explicit readability constraint from the creative direction.

10. Tech Stack

The source specifies the following technology choices, which are preserved exactly:

• Language: Kotlin
• UI: Jetpack Compose
• Design system: Material 3
• Architecture: MVVM architecture with the Repository pattern
• Backend: A cloud backend such as Firebase
  • Firebase Authentication for admin login
  • Cloud Firestore for inventory
  • Firebase Storage for phone images
• Platform: Native Android application

If a different backend is chosen, it must maintain the same security and real-time requirements.

Presentation defaults [Default — not specified by user]:

• Typography: Archivo Black for headings and Archivo for body, per the creative direction.
• Color tokens: as specified in Section 6.

11. Assumptions and Constraints

Constraints (explicit, binding):

• The Customer Area must be accessible to everyone without a login; customers should not need to create an account just to browse phones.
• The Admin Area must be protected by a password and accessible only to the shop owner/staff.
• Customers must not be able to access the inventory management functions.
• The admin password must not be stored as plain text inside the Android application; secure authentication and secure credential storage are required.
• The backend must enforce permissions; hiding the Admin button from customers is not sufficient.
• Only phones currently marked as Available should appear in the main customer inventory by default.
• The WhatsApp/phone number must be configurable from the Admin Area rather than hard-coded.
• Customers must not be required to manually refresh the app if the backend supports real-time updates.
• Required fields must be validated before allowing a phone to be added.
• Before deleting a phone, a confirmation dialog "Are you sure you want to delete this phone?" with Cancel and Delete must be shown.
• The inventory must represent the current stock in the physical TechZone shop; when a phone is sold, the shop owner marks it as Sold/Unavailable and customers no longer see it as available.
• If a different backend is chosen instead of Firebase, it must maintain the same security and real-time requirements.

Assumptions (narrow, labeled):

• [Assumption] The first admin account is provisioned through the backend before administrative use, as required to make the accepted admin journey executable.
• [Assumption] Admin returning verification occurs through the Admin Login screen before protected administration is available.
• [Assumption] Backend authorization restricts inventory and shop-setting mutations to authenticated shop owner or staff accounts.
• [Assumption] Customer inventory reads expose only phones whose status is Available.
• [Assumption] Real-time backend synchronization propagates authoritative inventory changes to the customer-facing inventory.
• [Assumption] Soft deletion is implemented in the database so accidentally deleted inventory can potentially be recovered, as the source asks to "consider" it.
• [Assumption] Light and dark mode are implemented, as the source asks to include both "if practical".

12. Glossary

• TechZone — The physical mobile phone shop and the brand of the Android application.
• Customer Area — The public, no-login portion of the app where customers browse available phones.
• Admin Area — The password-protected portion of the app accessible only to the shop owner/staff.
• Customer — An anonymous shopper who browses available phones without creating an account.
• Shop Owner / Staff (Admin) — The authenticated operator who maintains inventory and shop settings.
• Phone / Inventory record — A backend record containing id, brand, model, storage, ram, color, condition, price, originalPrice, batteryHealth, warranty, description, images, status, createdAt, and updatedAt.
• Shop Settings record — A backend record containing shop name, shop logo, shop address, phone number, WhatsApp number, opening hours, Instagram/social media links, and shop description.
• Status — A phone's availability state: Available, Reserved, or Sold.
• Available — A phone currently in stock and shown in the customer inventory.
• Reserved — A phone held for a buyer and not shown in the default customer inventory.
• Sold — A phone no longer in stock and not shown in the customer inventory.
• Soft deletion — Marking a record as deleted in the database rather than physically removing it, so it can potentially be recovered.
• Real-time synchronization — Backend-driven propagation of inventory changes to the customer-facing inventory without manual refresh.
• Contact TechZone — The customer action that opens WhatsApp or the phone dialer using the admin-configured number.
• Brand New — A sealed, unused phone.
• Second Hand — A used phone, optionally with battery health information (e.g., for second-hand iPhones).
• Battery health — An optional percentage describing a second-hand phone's battery condition.
• Warranty — Optional warranty information shown on a phone card and details screen.
• MVVM — Model-View-ViewModel architecture pattern used by the app.
• Repository pattern — A data-access abstraction pattern used by the app.
• Firebase Authentication — The backend service used for admin login.
• Cloud Firestore — The backend database used for inventory.
• Firebase Storage — The backend service used for secure phone image storage.