Qwizin — Quality Attribute Scenarios

Status: Draft v0.1 · Date: 2026-07-20 Input: 00-requirements-baseline.md · Method: six-part scenario form (source, stimulus, artifact, environment, response, response measure)

Summary#

The source documents state quality goals only as adjectives: "secure", "scalable", "easy to use", "stable video calls". None are measurable, so none can drive or falsify a design decision. This document converts them into 21 testable scenarios.

The headline finding is that Qwizin's dominant quality attributes are not the ones the documents emphasise. The documents stress cost and usability. The architecture is actually dominated by:

1. Confidentiality & tenant isolation — the platform holds commercial registrations, tax cards, and one employer's records about their employees. A cross-tenant leak is an existential, PDPL-reportable event. This outranks everything.
2. Integrity of assessment and certification — certificates assert food-safety competence. A forgeable or tamperable certificate transfers real-world risk to restaurant patrons and destroys the platform's core value claim. This is a safety-adjacent concern that no source document treats as one.
3. Modifiability at the Phase-2 seams — CONF-04 commits to a Phase-2 scope several times the MVP. The cost of getting boundaries wrong is a rewrite.

Availability and raw performance, by contrast, are moderate requirements. This is a scheduled-appointment, document-download, and read-heavy directory system — not a payments switch or a real-time trading platform. Over-engineering availability at the expense of the three attributes above would be the classic mistake here.

Priority Method#

Each scenario carries an ATAM-style (Business Value, Architectural Impact) pair, each H/M/L.

• (H,H) — must be designed for explicitly and verified. These drive the architecture.
• (H,L) — important but achievable with conventional practice; do not over-invest.
• (L,H) — architecturally expensive for limited value; candidate for deliberate deferral.

1. Security — Confidentiality & Tenant Isolation#

QAS-SEC-01 — Cross-tenant data isolation (H,H) ⭐ Top priority#

Rationale: the single most likely catastrophic defect in a multi-tenant Laravel application is a query that forgot its tenant scope. Per-endpoint authorization checks fail because they rely on developer discipline at every new endpoint forever. The measure deliberately mandates an enforcement mechanism, not an outcome, because only the mechanism is testable in advance.

QAS-SEC-02 — Legal document confidentiality (H,H)#

QAS-SEC-03 — Malicious file upload (H,M)#

QAS-SEC-04 — Credential compromise blast radius (H,M)#

2. Integrity — Assessment & Certification#

QAS-INT-01 — Assessment answer-key confidentiality (H,H) ⭐#

Rationale: the naive implementation ships the whole question object — including is_correct — to the client and grades locally. SRC-MOM REQ-05 says "automatic instant grading", which invites exactly this. Because certificates carry external weight, this is an integrity control, not a nicety.

QAS-INT-02 — Score tampering (H,M)#

QAS-INT-03 — Certificate authenticity (H,M)#

Depends on OQ-09. If verification is ruled out of scope, this scenario drops to (M,L) — but the architect should note that an unverifiable food-safety certificate is trivially forged in a graphics editor, which undermines SRC-MOM KPI 3 and the platform's credibility claim.

3. Availability#

Deliberate position: Qwizin does not need four-nines. It needs predictable availability concentrated in KSA business hours, and it needs booked consultations not to fail. Availability investment should be asymmetric.

QAS-AVL-01 — Video consultation at appointment time (H,H) ⭐#

This is the highest-value availability scenario because a failure is simultaneously a refund event, a reputational event, and a two-sided marketplace failure — it burns the consultant's time slot as well as the customer's money.

QAS-AVL-02 — Core platform availability (H,M)#

QAS-AVL-03 — Payment provider outage (H,M)#

QAS-AVL-04 — Graceful degradation of non-critical modules (M,M)#

4. Performance & Scalability#

QAS-PERF-01 — Mobile API responsiveness on KSA mobile networks (H,M)#

QAS-PERF-02 — Arabic-language marketplace search (H,H) ⭐#

Called out as (H,H) deliberately. Arabic search quality is where naive stacks fail badly, and it is not a cosmetic issue — a Saudi user who searches in Arabic and gets nothing concludes the directory is empty. Generic full-text search on Arabic without normalisation produces near-zero recall. This constrains the search-engine choice and is the subject of dedicated research.

QAS-SCL-01 — Growth to target scale (H,H)#

QAS-SCL-02 — Video capacity elasticity (H,H) ⭐#

The last sentence is an architectural insight worth preserving: unlike most systems, Qwizin knows its future load in advance because sessions are booked. Predictive scaling from the appointment calendar is strictly better than reactive autoscaling here.

QAS-SCL-03 — Certificate/PDF generation burst (M,M)#

5. Modifiability#

QAS-MOD-01 — Payment provider replacement (H,H) ⭐#

This scenario is elevated to (H,H) because the decision is deliberately deferred. Deferring a decision is only safe if the architecture makes it cheap to make later — that is the whole justification for the port.

QAS-MOD-02 — Video provider replacement (H,H)#

QAS-MOD-03 — Phase-2 module extraction (H,H) ⭐#

The CI-enforcement clause is the entire point. Modular monoliths fail not because the boundaries were drawn wrong, but because nothing stopped them eroding. A boundary that is not machine-checked is a comment.

QAS-MOD-04 — Adding a template as a structured instrument (M,H)#

(M,H) — modest MVP value, high architectural leverage. The cost today is small (a richer schema behind an unchanged API); the cost of retrofitting later is a full remodelling of the module.

6. Compliance, Localization, Operability#

QAS-CMP-01 — Data subject rights request (H,M)#

The hard part is not deletion — it is enumeration. A personal-data inventory must be maintained as a first-class artifact, or this scenario becomes unsatisfiable once data has spread into a search index and a log pipeline.

QAS-CMP-02 — Audit trail for approval decisions (H,L)#

QAS-LOC-01 — Arabic/RTL correctness in generated artifacts (H,M)#

This eliminates several common PHP PDF libraries outright. It is a genuine constraint on technology choice, not a rendering detail — a certificate with disconnected, reversed Arabic letters is unusable and visibly amateur to every Saudi user.

QAS-LOC-02 — GCC expansion (M,M)#

QAS-OPS-01 — Operability by a small team (H,H) ⭐#

(H,H) and non-negotiable. CON-15 (Kubernetes) raises the operational floor. Choosing Kubernetes without a matching investment in observability and automation converts an infrastructure choice into a permanent operational tax on a small team — that trade-off must be paid deliberately, not discovered later.

QAS-OPS-02 — Cost efficiency at low utilisation (H,M)#

Evidence vs Assumptions#

Evidence (traceable to source documents):

• Approval-gated onboarding, six actor types, module capabilities — SRC-BRD
• MCQ auto-grading + automatic PDF certificate — SRC-MOM REQ-05
• Featured listings rank above standard — SRC-MOM REQ-06
• "Stable video call start to finish" — SRC-MOM REQ-03
• Security of uploaded legal documents — SRC-MOM NFR-1
• Low cost / open-source preference — SRC-BRD §12, SRC-MOM NFR-3
• GCC scalability without redesign — SRC-BRD §3.7

Assumptions (mine — require confirmation):

Risks & Trade-offs#

Scenario Priority Summary#

Recommended Next Steps#

1. architecture-risk-assessor on the (H,H) set — particularly the Kubernetes/operability tension (#2) and the deferred payment decision (OQ-10).
2. tradeoff-analysis-writer for the video build-vs-buy and search-engine decisions, once the research strands report.
3. adr-writer for each decision already taken (hosting, style, orchestration, ports) so the rationale is captured while it is fresh.