System Requirements Document for omar-itech

1. Introduction

Omar iTech is a modern technology platform providing fast, reliable, and affordable digital services. The product exists so that everyday customers can, in one convenient place:

• access tech products and services,
• purchase data bundles,
• manage their orders, and
• receive quick support.

The audience is the everyday consumer of digital services — customers in Nigeria and comparable markets who are often on mid-range Android devices and patchy connections, and who need a service platform that feels like dependable public infrastructure rather than a startup landing page. The register is trust, speed, and legibility: "this will just work."

This document specifies the current, buildable product: a customer-facing application with a public entry surface, self-service enrollment and returning verification, a browsable catalogue of tech products and digital services, a data-bundle purchase surface, a durable order-management surface, and a support surface — all owned by the application and reachable from one place.

2. System Overview

Omar iTech is delivered as a first-party application with custom UI. A single active human role — the Customer — uses the platform end to end. The application owns identity: a customer establishes an account once through self-service enrollment, and returning customers verify themselves before reaching their purchases, orders, and support activity.

Current accepted behavior, by area:

• Public entry (Landing): explains Omar iTech, who it serves, and the technology products and digital services on offer; provides the entry point into enrollment and into the catalogue.
• Identity access (Sign Up, Login): self-service enrollment establishes a durable customer identity; returning verification restores access to that customer's own purchases, orders, and support activity.
• Products: browse technology products and digital services offered by the platform.
• Data Bundles: select and purchase available data bundles.
• Orders: review and manage the customer's durable orders and purchases.
• Support: request and receive quick customer support.

The platform is backed by application services and durable storage so that orders, purchases, and support activity persist and remain bound to the correct customer across sessions.

Narrow exclusions for the current horizon: no administrative, staff, or operator console is specified; no multi-role permission model is specified; no provider-owned or external-only surface is specified; no headless-only delivery is specified. The reusable trading-analysis skill surfaced during planning is not part of this product and is not incorporated.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. All accepted customer-facing behavior is delivered as first-party custom UI owned by the Omar iTech application. There is no accepted provider-owned surface, no external destination that owns a customer outcome, and no headless-only delivery path. Backend services and storage support the application but do not replace any customer interaction.

Access ownership. The application owns customer identity. Because purchases, orders, and support activity are durable, customer-specific, and must remain bound to the correct participant, identity continuity is indispensable. The Landing, Sign Up, and Login surfaces are reachable without an established session; Data Bundles, Orders, and Support require a verified customer session. Products is browsable without an established session so that prospective customers can see what the platform offers before enrolling.

Current vs. future. Everything specified in Sections 3 through 5 is current. No future-horizon requirements were accepted in the authoritative thread; Section 11 records the boundaries and assumptions that keep the current scope narrow.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source authority, so no source content inventory is rendered.

2c. Page Content and Component Coverage

Landing

• Information and state: Public first impression. States the platform's promise — fast, reliable, affordable digital services — names the four service areas (Data Bundles, Products, Orders, Support), and shows entry points into enrollment and into browsing. No session required; if a session already exists, the surface reflects that the customer can continue to their own areas.
• Primary actions: Begin enrollment ("Get started" → Sign Up); proceed to returning verification (→ Login); enter the catalogue (→ Products).
• Supporting actions: Read the service-area overview; follow the service board rows into the corresponding area.
• Domain entities: Service area (Data Bundles, Products, Orders, Support); price-from value per area.
• Component responsibilities: Full-bleed amber hero band carrying the headline; ink service board panel with four hairline-separated rows, each with a 4px line tick, an all-caps label, and a tabular-numeral price-from value; hairline rule spanning the viewport with the rectangular red CTA slab cut into it; transit-line navigation rail with the four coloured lines and square station markers; numbered section header (01) with rotated gutter label.
• States: Loading — hero type and service board render immediately from static content; no blocking fetch. Empty — not applicable; the surface always carries its four service areas. Success — customer reaches Sign Up, Login, or Products. Error — if the service board's price-from values cannot be refreshed, the board retains its last known values and shows a muted "prices unavailable" note in the row metadata position. Recovery — the customer can still enter Products, Sign Up, or Login while price-from values are unavailable.

Sign Up

• Information and state: Anonymous self-service enrollment. Collects the minimum information needed to establish a durable customer identity and to bind future purchases, orders, and support activity to that customer.
• Primary actions: Submit enrollment to create the customer account.
• Supporting actions: Move to Login if the customer already has an account; return to Landing.
• Domain entities: Customer identity (the enrolling customer's own account).
• Component responsibilities: Enrollment form with 2px-radius inputs on white surface with 1px hairline rules; inline field-level validation messaging in muted metadata type; rectangular red submit slab with a 4px signal bar on its left edge; link to Login; numbered section header (02) with rotated gutter label.
• States: Loading — submit control shows an in-progress state and is not re-submittable while the request is in flight. Empty — the form opens blank with helper text in the muted metadata style. Success — the customer account is created and the customer proceeds into the application with their own session. Error — invalid or incomplete input is reported inline against the specific field; a failed submission preserves everything the customer typed and reports the failure without discarding input. Recovery — the customer corrects the reported field and resubmits; if the customer already has an account, they move to Login.

Login

• Information and state: Anonymous returning verification. Accepts the returning customer's credentials and restores access to that customer's own purchases, orders, and support activity.
• Primary actions: Submit credentials to verify the returning customer.
• Supporting actions: Move to Sign Up if the customer has no account; return to Landing.
• Domain entities: Customer identity (the returning customer's own account).
• Component responsibilities: Credential form with 2px-radius inputs on white surface with hairline rules; inline error region in muted metadata type; rectangular red submit slab with a 4px signal bar on its left edge; link to Sign Up; numbered section header (03) with rotated gutter label.
• States: Loading — submit control shows an in-progress state and is not re-submittable while verification is in flight. Empty — the form opens blank. Success — the customer is verified and lands in their own areas (Data Bundles, Orders, Support). Error — unrecognized or incorrect credentials produce a single non-enumerating error message that does not reveal which field was wrong; the entered identifier is preserved. Recovery — the customer retries, or moves to Sign Up to enroll.

Products

• Information and state: Browsable catalogue of the technology products and digital services offered by the platform. Reachable without an established session so prospective customers can see what is offered.
• Primary actions: Browse the catalogue; open an item's detail to see what it is and what it costs.
• Supporting actions: Move into Data Bundles for connectivity purchases; move to Sign Up or Login when the customer wants to commit to a purchase.
• Domain entities: Product/service item (name, description, price, category); category grouping.
• Component responsibilities: Full-bleed green signal band carrying the page headline in ink; ruled tabular item rows separated by hairlines with no card chrome; tabular numerals on all prices; geometric pictograms on a 24px grid with 2px strokes for category coding; transit-line navigation rail with the Products line thickened and its station marker filled; numbered section header (04) with rotated gutter label.
• States: Loading — ruled row skeletons on the warm paper ground, preserving the tabular rhythm. Empty — a muted message stating that no products or services are currently listed, with a route into Support. Success — items render as ruled rows with aligned label/value pairs. Error — a failed catalogue fetch shows a muted failure notice in place of the rows with a retry control. Recovery — retry re-requests the catalogue; the customer can still reach Data Bundles, Support, Sign Up, and Login.

Data Bundles

• Information and state: The customer's own data-bundle purchase surface. Requires a verified customer session. Presents available bundles and the customer's selection.
• Primary actions: Select a bundle; commit to the purchase.
• Supporting actions: Compare bundles by volume, validity, and price; move to Orders to see the resulting purchase; move to Support if a purchase needs help.
• Domain entities: Data bundle (volume, validity, price); purchase (the customer's committed bundle purchase, with its resulting order).
• Component responsibilities: Full-bleed red signal band carrying the page headline in ink; departure-board bundle rows — one hairline-separated row per bundle with tabular numerals in three aligned columns (volume / validity / price), no cards; the selected row gains a 4px red left bar and a white surface; rectangular red commit slab with a 4px signal bar on its left edge; transit-line navigation rail with the Data Bundles line thickened and its station marker filled; numbered section header (05) with rotated gutter label.
• States: Loading — departure-board row skeletons preserving the three-column tabular alignment. Empty — a muted message stating that no bundles are currently available, with a route into Support. Success — the committed purchase is confirmed and the resulting order is visible in Orders. Error — a failed purchase reports the failure without losing the customer's selection, and the selected row keeps its red left bar. Recovery — the customer retries the commit with the selection intact, or moves to Support.

Orders

• Information and state: The customer's own durable orders and purchases. Requires a verified customer session. Shows each order with its status progression and its identifying details.
• Primary actions: Review the customer's orders; open an order to see its detail and current status.
• Supporting actions: Move to Support about a specific order; move to Data Bundles or Products to make a further purchase.
• Domain entities: Order (order identifier, items, amounts, placed date, status); order status progression (Placed → Paid → Processing → Delivered).
• Component responsibilities: Full-bleed blue signal band carrying the page headline in ink; order status rendered as a route diagram — a horizontal line with square station markers, completed segments in solid ink, the current station as a filled signal-colour square with its timestamp in tabular numerals beneath; ruled tabular order rows with tabular numerals on order IDs, amounts, and dates; all-caps micro-labels such as 'ORDER #4417' at 11px with +0.14em tracking; transit-line navigation rail with the Orders line thickened and its station marker filled; numbered section header (06) with rotated gutter label.
• States: Loading — ruled order-row skeletons preserving the tabular rhythm. Empty — a muted message stating that the customer has no orders yet, with a route into Data Bundles and Products. Success — orders render as ruled rows, each with its route diagram and current station. Error — a failed fetch shows a muted failure notice with a retry control; the customer's orders are not shown as empty when the fetch failed. Recovery — retry re-requests the customer's orders; the customer can still reach Support.

Support

• Information and state: The customer's own support surface. Requires a verified customer session. Lets the customer raise a support request and see the state of their support activity.
• Primary actions: Submit a support request describing the need.
• Supporting actions: Reference a specific order when raising the request; review previously raised requests and their state.
• Domain entities: Support request (the customer's own request, its description, its optional order reference, its state, and its timestamps).
• Component responsibilities: Full-bleed amber signal band carrying the page headline in ink; request form with 2px-radius inputs on white surface with hairline rules; ruled tabular list of the customer's requests with tabular numerals on timestamps; rectangular red submit slab with a 4px signal bar on its left edge; transit-line navigation rail with the Support line thickened and its station marker filled; numbered section header (07) with rotated gutter label.
• States: Loading — ruled request-row skeletons preserving the tabular rhythm. Empty — a muted message stating that the customer has no support requests yet, with the request form presented directly. Success — the submitted request appears in the customer's request list with its state and timestamp, and the success colour bar snaps from 0 to full width. Error — a failed submission preserves the customer's typed description and reports the failure without discarding it. Recovery — the customer resubmits with the description intact.

3. Functional Requirements

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

FR-1 — Platform promise and one-place access (explicit) As a Customer, I should be able to reach tech products and services, data bundles, my orders, and support from one convenient place, so that I do not have to move between separate services.

• Trigger/input: The customer opens the application.
• Observable result: The Landing surface presents the platform's promise and the four service areas, and each area is reachable from the application's navigation.
• Access state: Landing is reachable without an established session.
• Failure/recovery: If a service-area entry cannot be reached, the customer can still reach the remaining areas and Support.
• Continuation: The customer chooses an area and proceeds.

FR-2 — Access tech products and services (explicit) As a Customer, I should be able to browse the technology products and digital services the platform offers, so that I can see what is available and what it costs.

• Trigger/input: The customer opens Products.
• Observable result: The catalogue renders as ruled tabular rows with item names, descriptions, categories, and prices in tabular numerals.
• Access state: Products is reachable without an established session.
• Failure/recovery: A failed catalogue fetch shows a muted failure notice with a retry control rather than an empty catalogue.
• Continuation: The customer opens an item's detail, moves into Data Bundles, or moves to Sign Up or Login to commit to a purchase.

FR-3 — Purchase data bundles (explicit) As a Customer, I should be able to select and purchase an available data bundle, so that I get connectivity quickly and at a price I can see up front.

• Trigger/input: A verified customer opens Data Bundles and selects a bundle row.
• Observable result: The selected row gains a 4px red left bar on a white surface; committing produces a confirmed purchase and a corresponding order.
• Access state: Data Bundles requires a verified customer session.
• Failure/recovery: A failed purchase reports the failure without losing the customer's selection; the selected row keeps its red left bar and the customer can retry.
• Continuation: The customer sees the resulting order in Orders, or moves to Support if the purchase needs help.

FR-4 — Manage orders (explicit) As a Customer, I should be able to review and manage my orders and purchases, so that I know what I bought, what it cost, and where it is.

• Trigger/input: A verified customer opens Orders.
• Observable result: The customer's own orders render as ruled tabular rows with order identifiers, amounts, and dates in tabular numerals, each with a route diagram showing Placed → Paid → Processing → Delivered, completed segments in solid ink and the current station as a filled signal-colour square with its timestamp beneath.
• Access state: Orders requires a verified customer session and shows only the verified customer's own orders.
• Failure/recovery: A failed fetch shows a muted failure notice with a retry control and never presents a failed fetch as an empty order list.
• Continuation: The customer opens an order's detail, moves to Support about it, or makes a further purchase.

FR-5 — Receive quick support (explicit) As a Customer, I should be able to raise a support request and see its state, so that a problem gets resolved without leaving the platform.

• Trigger/input: A verified customer opens Support and submits a request describing the need, optionally referencing one of their orders.
• Observable result: The submitted request appears in the customer's own request list with its state and timestamp, and the success colour bar snaps from 0 to full width.
• Access state: Support requires a verified customer session and shows only the verified customer's own requests.
• Failure/recovery: A failed submission preserves the customer's typed description and reports the failure without discarding it; the customer resubmits with the description intact.
• Continuation: The customer reviews the request's state in their request list.

FR-6 — Customer self-service enrollment (required_inference) As a Customer, I should be able to establish my own account before my first protected use, so that my purchases, orders, and support activity are bound to me.

• Trigger/input: An anonymous visitor opens Sign Up and submits the enrollment form.
• Observable result: A customer account is created and the customer proceeds into the application with their own session.
• Access state: Sign Up is reachable without an established session; it is the anonymous entry boundary that establishes access to the protected surfaces.
• Failure/recovery: Invalid or incomplete input is reported inline against the specific field; a failed submission preserves everything the customer typed.
• Continuation: The customer proceeds into Data Bundles, Orders, or Support; a customer who already has an account moves to Login.

FR-7 — Returning customer verification (required_inference) As a Customer, I should be able to verify myself when I return, so that I can get back to my own purchases, orders, and support activity.

• Trigger/input: A returning customer opens Login and submits their credentials.
• Observable result: The customer is verified and lands in their own areas with their own orders, purchases, and support activity visible.
• Access state: Login is reachable without an established session; it restores access to the protected surfaces.
• Failure/recovery: Unrecognized or incorrect credentials produce a single non-enumerating error message that does not reveal which field was wrong, and the entered identifier is preserved.
• Continuation: The customer proceeds into Data Bundles, Orders, or Support; a customer without an account moves to Sign Up.

FR-8 — Durable, customer-bound state (required_inference) As a Customer, I should find my purchases, orders, and support activity still there and still mine when I return, so that the platform is dependable rather than ephemeral.

• Trigger/input: A verified customer returns and opens Orders, Data Bundles, or Support.
• Observable result: The customer's own orders, purchases, and support requests are present with their statuses and timestamps, and no other customer's records appear.
• Access state: Requires a verified customer session.
• Failure/recovery: If the customer's session is no longer valid, the customer is returned to Login and, after verifying, finds their records intact.
• Continuation: The customer continues managing orders, purchasing bundles, or tracking support.

4. User Personas

Customer

Product context. The Customer is the primary and only active human role on Omar iTech. They are an everyday consumer of digital services — often on a mid-range Android phone over a patchy connection — who needs connectivity, tech products, and services without friction, and who is sensitive to price and to whether a platform can be trusted with their money and their order.

Primary goal. To complete a fast, reliable, affordable transaction and get their support need resolved, with their purchases, orders, and support activity kept in one convenient place.

Distinct accepted responsibilities.

• Browse the technology products and digital services the platform offers, and see what each costs.
• Select and purchase an available data bundle.
• Review and manage their own orders and purchases, including each order's status progression.
• Raise a support request and follow its state.
• Establish their own account through self-service enrollment, and verify themselves when they return.

Relevant inputs and decisions. Which product or service they want; which bundle to buy, judged on volume, validity, and price; whether to commit to the purchase; whether an order needs support; what to describe in a support request and whether to reference a specific order.

Interactions with other accepted participants. None. The Customer is the only accepted active human role; there is no counterparty, approver, or agent in the current scope. The platform's backend services and storage support the Customer's work but are not participants.

Observable success. The Customer reaches the catalogue and sees real prices; a bundle purchase is confirmed and appears as an order with a visible status progression; their orders and support requests are still there and still theirs on return; a support request is submitted and shows a state.

What makes this role's work different. The Customer is simultaneously the buyer, the account holder, and the support requester. Their work is a continuous loop of discovery → commitment → tracking → resolution, and every step must be legible at a glance on a small screen: prices in tabular numerals, order status as a route diagram, and support state visible without digging. There is no back-office role in this product, so nothing about the Customer's experience may assume an operator is watching.

5. Core User Flows

Flow 1 — First-time customer enrolls and makes a first purchase

1. The Customer opens the application and lands on Landing without any session. The amber hero band carries the headline "Fast, reliable, affordable digital services." and the ink service board lists DATA BUNDLES / PRODUCTS / ORDERS / SUPPORT with price-from values in tabular numerals.
2. The Customer reads the service board and decides to look at what is offered. They follow the PRODUCTS row into Products — reachable without a session.
3. On Products, the catalogue renders as ruled tabular rows with names, descriptions, categories, and prices in tabular numerals. The Customer scans the rows and opens an item's detail to see what it is and what it costs.
4. The Customer decides to buy connectivity instead. They follow the DATA BUNDLES line into Data Bundles. Because Data Bundles requires a verified session and the Customer has none, they are routed to Login.
5. On Login, the Customer has no account, so they follow the link to Sign Up.
6. On Sign Up, the Customer completes the enrollment form and submits. The submit slab shows an in-progress state and is not re-submittable while the request is in flight.
7. Failure branch: if a field is invalid or incomplete, the error is reported inline against that specific field and everything the Customer typed is preserved. The Customer corrects the field and resubmits.
8. On success, the Customer's account is created and they proceed into the application with their own session, arriving at Data Bundles.
9. On Data Bundles, the red signal band carries the page headline and the departure-board rows present each bundle as one hairline-separated row with tabular numerals in three aligned columns (volume / validity / price). The Customer compares rows and selects one; the selected row gains a 4px red left bar on a white surface.
10. The Customer commits to the purchase using the rectangular red commit slab.
11. Failure branch: if the purchase fails, the failure is reported without losing the selection — the selected row keeps its red left bar — and the Customer retries, or moves to Support.
12. On success, the purchase is confirmed and a corresponding order is created.
13. The Customer follows the ORDERS line into Orders, where their new order appears as a ruled row with its identifier, amount, and date in tabular numerals, and a route diagram showing Placed → Paid → Processing → Delivered with completed segments in solid ink and the current station as a filled signal-colour square with its timestamp beneath.
14. Next step: the Customer can continue to Products or Data Bundles for a further purchase, or open the order's detail.

Flow 2 — Returning customer verifies and manages an order

1. The Customer returns to the application and opens Login without a session.
2. The Customer submits their credentials. The submit slab shows an in-progress state and is not re-submittable while verification is in flight.
3. Failure branch: if the credentials are not recognized, a single non-enumerating error message appears that does not reveal which field was wrong, and the entered identifier is preserved. The Customer retries, or moves to Sign Up if they have no account.
4. On success, the Customer is verified and lands in their own areas.
5. The Customer opens Orders. Their own orders render as ruled tabular rows with identifiers, amounts, and dates in tabular numerals, each with its route diagram.
6. Failure branch: if the fetch fails, a muted failure notice with a retry control appears — the Customer's orders are never presented as an empty list because a fetch failed. The Customer retries.
7. The Customer opens an order's detail and reads its current station and the timestamp beneath it in tabular numerals.
8. Next step: the Customer moves to Support about this order, or returns to Data Bundles or Products to make a further purchase.

Flow 3 — Customer raises a support request and follows it

1. A verified Customer opens Support from the transit-line navigation rail; the Support line thickens to 8px and its station marker fills.
2. The amber signal band carries the page headline in ink, and the Customer's existing requests appear as ruled tabular rows with timestamps in tabular numerals.
3. Empty state: if the Customer has no requests yet, a muted message says so and the request form is presented directly.
4. The Customer completes the request form, describing the need and optionally referencing one of their orders.
5. The Customer submits using the rectangular red submit slab.
6. Failure branch: if the submission fails, the Customer's typed description is preserved and the failure is reported without discarding it. The Customer resubmits with the description intact.
7. On success, the success colour bar snaps from 0 to full width and the submitted request appears in the Customer's own request list with its state and timestamp.
8. Next step: the Customer