Skip to content

Use cases — who can do what

What this answers: which actors interact with 961tech and what each can do, with the relationships between use cases («include», «extend», generalisation).

The drawio version is the source of truth — see diagrams/01-use-case-diagram.drawio. The PNG is the rendered view embedded below; the mermaid block beneath is the same diagram in text form, useful for diff'ing changes and as a fallback when drawio isn't available.

Use case diagram

graph LR
    Visitor((Visitor))
    Builder((Builder))
    Retailer((Retailer))
    Operator((Operator))
    RSite[("Retailer Site<br/>external")]
    Mail[("Email Service<br/>external")]

    Builder -.->|generalizes| Visitor

    subgraph SYS["961tech System"]
      direction TB
      subgraph DISCOVER["Discovery & Browse"]
        UC1(UC-1<br/>Browse catalog)
        UC3(UC-3<br/>See min info<br/>on cards)
        UC4(UC-4<br/>Filter products)
        UC5(UC-5<br/>Filter by stock)
        UC6(UC-6<br/>Quote-only<br/>price range)
        UC7(UC-7<br/>Filter by retailer)
        UC8(UC-8<br/>Retailers<br/>per product)
        UCA(UC-A<br/>Search catalog)
        UCE(UC-E<br/>Compare 2+)
        UCF(UC-F<br/>Price history)
        UCH(UC-H<br/>Build guides)
        UCI(UC-I<br/>Retailer profile)
      end
      subgraph BUILD["Build & Configure"]
        UC9(UC-9<br/>Build a PC)
        UCB(UC-B<br/>Compat check)
        UC10(UC-10<br/>Templates)
        UC11(UC-11<br/>Per-retailer cart)
        UC12(UC-12<br/>Cart aggregator)
        UCC(UC-C<br/>Save build)
        UCD(UC-D<br/>Share build)
        UCG(UC-G<br/>Price drop alerts)
      end
      subgraph CONVERT["Conversion"]
        UC2(UC-2<br/>Buy via deep-link)
      end
      subgraph OPS["Operator & Backend"]
        UCJ(UC-J<br/>Admin tools)
        UCL(UC-L<br/>Affiliate reconciliation)
      end
      subgraph M2["Retailer (M2)"]
        UCK(UC-K<br/>Retailer self-onboarding)
      end
    end

    Visitor --- UC1
    Visitor --- UCA
    Visitor --- UC9
    Visitor --- UC2
    Visitor --- UCD
    Visitor --- UCE
    Visitor --- UCH
    Builder --- UCC
    Builder --- UCG
    Retailer --- UCK
    Operator --- UCJ
    Operator --- UCL
    UC2 --- RSite
    UCL --- RSite
    UCG --- Mail

    UC1 -.->|includes| UC3
    UC1 -.->|includes| UC4
    UC1 -.->|includes| UC8
    UC4 -.->|includes| UC5
    UC4 -.->|includes| UC7
    UC6 -.->|extends| UC5
    UCI -.->|extends| UC8
    UC9 -.->|includes| UCB
    UC9 -.->|includes| UC11
    UC10 -.->|extends| UC9
    UC12 -.->|extends| UC11
    UCD -.->|extends| UCC
    UCL -.->|extends| UC2

Actors

Actor Role
Visitor Anonymous web user. Default actor. Can do most things without an account.
Builder Visitor who has signed in. Inherits all Visitor abilities + UC-C and UC-G.
Retailer Lebanese merchant who self-onboards via the backoffice. M2 deferred.
Operator MASTER. Admin / catalog curator / affiliate reconciler.
Retailer Site (external) Third-party retailer (PCAndParts, 961Souq, etc.) — receives outbound clicks and may post back conversions.
Email Service (external) Outgoing email provider (Resend planned) for price-drop alerts.

Use cases

See the Glossary for term definitions and the open issues for implementation status per UC.

Visitor + Builder (consumer): UC-1 Browse catalog, UC-2 Buy via deep-link, UC-3 See min info on cards, UC-4 Filter products, UC-5 Filter by stock, UC-6 Quote-only price range, UC-7 Filter by retailer, UC-8 See retailers per product, UC-9 Build a PC, UC-10 Templates & prebuilts, UC-11 Per-retailer cart, UC-12 Cart aggregator, UC-A Search, UC-B Compatibility check, UC-D Share build, UC-E Compare 2+, UC-F Price history, UC-H Build guides, UC-I Retailer profile.

Builder only: UC-C Save build, UC-G Price drop alerts.

Retailer (M2 deferred): UC-K Retailer self-onboarding.

Operator only: UC-J Admin tools, UC-L Affiliate reconciliation.

Relationships

  • Solid Actor —— UC — actor performs the use case
  • Dashed «include» UC -.→ UC — included use case ALWAYS runs as part of the parent
  • Dashed «extend» UC -.→ UC — extending use case OPTIONALLY enriches the parent
  • Dashed «generalises» Actor -.→ Actor — sub-actor inherits all parent's permissions

Design notes

  1. Builder generalises Visitor. Anyone signed in can do everything an anonymous Visitor can, plus the account-bound use cases (UC-C, UC-G). UML inheritance.
  2. Browse is a composite. UC-1 always involves seeing min info (UC-3), filtering (UC-4), and seeing retailer presence (UC-8). Filtering itself decomposes into stock-state and per-retailer filters.
  3. Quote-only price estimation (UC-6) extends UC-5. When the user filters to include request-quote products, we optionally enrich those with a computed price range.
  4. Build (UC-9) is the central composite. Always includes compat check (UC-B) and per-retailer cart view (UC-11). Optionally extended by templates (UC-10) and cart aggregator suggestions (UC-12 extends UC-11).
  5. Save extends to Share. A saved build is shareable; share is the natural extension of save.
  6. Buy (UC-2) extends to Affiliate (UC-L). Every successful buy is a candidate for attribution; reconciliation fires asynchronously on click + conversion data.
  7. External actors as system rectangles (UML 2 convention) — they participate in use cases but aren't actors in the same sense as humans.
  8. UC-K is M2-deferred — visually grouped separately so it's clear it's not v1.x work.

Decisions taken from this view

What was deliberately left out

  • Authentication actor and flows — handled at the Auth.js layer, not as use cases. See #11.
  • Internal scrapers and matchers — infrastructure, not actor-facing. They appear in Ingest pipeline.
  • Notification-of-share / email confirmations — out of scope for v1.