Qwizin — Consolidated Requirements Baseline

Status: Draft v0.1 · Date: 2026-07-20 · Tech Lead: Amir Haroun Purpose: Single distilled source of architectural truth extracted from the twelve source documents. Every downstream architecture document traces back to an identifier defined here.

1. Source Document Inventory#

Architectural note on SRC-CNT: these six files are frequently mistaken for requirements. They are not. They are representative assets of the Templates module. Their structure matters for one reason only: the audit workbooks are structured, row-per-control checklists with compliance-status and responsible-person columns. That shape is a strong signal that "downloadable template" is a transitional MVP form of what will later become an interactive digital audit instrument. See SEAM-03.

2. Actors#

Six actor types. Note that SRC-BRD §7.1 and §11 enumerate six, while SRC-MOM §6 says "3 main account types (individuals, companies, service providers)". The BRD's six-actor model is taken as normative; the MoM's three is a simplification that omits Employee (a sub-type of Company), Consultant, and Admin.

ACT-EMP lifecycle dependency: an employee account cannot exist outside an approved company (SRC-BRD §12 constraint 10). This makes company suspension/rejection a cascading state change across all its employees, their in-flight assessments, and their issued certificates. This is a non-trivial state machine and is under-specified in all source documents → OQ-07.

3. Functional Capability Map#

Grouped into candidate modules. The MOD- identifiers become the building-block decomposition in the arc42 building block view.

4. Explicitly Out of Scope (MVP)#

From SRC-BRD §7.2 and SRC-MOM §6/§14. Recorded because architecture must not foreclose these, and because §5 below shows two of them are contradicted elsewhere.

• Full LMS: learning paths, virtual classrooms, homework, learning analytics
• Video-based e-learning (explicitly deferred on cost grounds; MoM §11 constraint)
• Inventory management, procurement, purchase orders, supplier contracts
• ERP / accounting / CRM integration
• Departments within companies (BRD §10.2 — "future enhancement")

5. ⚠ Contradictions and Defects in the Source Documents#

These require the architect's or sponsor's ruling. Each is a genuine blocker or risk, not a documentation nitpick.

CONF-01 — Training scope: BRD vs Training Portal deck#

SRC-BRD §7.2 and SRC-MOM §14 ("Won't Have") exclude video-based e-learning, learning paths, and learning analytics. SRC-TRN specifies videos as a learning method (p.12), practical assessments (p.4), a branch comparison dashboard, and overdue-course tracking (p.13). Impact: High. Video learning content changes storage, CDN, and transcoding architecture materially. Practical assessment implies a human-graded workflow that MCQ auto-grading does not cover. "Branch comparison" implies a company→branch hierarchy that the data model does not currently have (and BRD defers departments). Ruling needed: Is SRC-TRN MVP scope, Phase-2 vision, or aspirational content-team planning?

CONF-02 — Payment precedes consultant acceptance#

SRC-BRD §10.4 appointment workflow: (1) customer books → (2) customer pays → (3) consultant receives request → (4) consultant approves → (5) system confirms. Impact: High. Money is captured before the service is agreed. This mandates: authorization-hold-then-capture (or full escrow), automatic refund on consultant rejection, a booking-expiry timer for consultant non-response, and a dispute path. None of this appears in any source document. Ruling needed: Confirm hold-then-capture, define the consultant response SLA, and define refund policy. Interacts with OQ-01 (gateway must support holds and refunds).

CONF-03 — Roles & permissions matrix is internally inconsistent#

SRC-BRD §11 grants ACT-ADM "Book Consultation" and "Manage Availability", and grants ACT-SP "Access Learning", "Take Assessments", "Download Certificates". It also shows ACT-CON with "Upload Legal Documents" but the Employee column blank for profile management ("Limited"). Assessment: This reads as a column-alignment artifact from the PDF table rather than deliberate intent — the "Service Provider" and "Admin" columns appear merged in extraction. Impact: Critical — this table is the authoritative input to the authorization model. Building to a misaligned matrix produces real privilege bugs. Ruling needed: Re-issue §11 as a machine-checkable permission matrix. The architecture will define authorization from a corrected matrix; do not implement from the PDF as-is.

CONF-04 — Phase-2 commitments far exceed MVP#

SRC-DECK p.12 competitor matrix marks Qwizin "YES" on: reservations/table management, CRM & guest database, loyalty & vouchers, labour scheduling & payroll, inventory & procurement, POS/PMS integration, sentiment analytics, B2B supplier communication, omnichannel ordering, digital menu, and government integration. Impact: These are investor-facing commitments. They are not MVP, but they define where the architecture must leave extraction seams. Designing the MVP as though they do not exist is the single most likely cause of a Phase-2 rewrite. Ruling needed: None immediately — but this is why the modular-monolith boundaries in MOD-* are drawn where they are.

CONF-05 — Date inconsistencies#

SRC-BRD is dated 18/7/2026 and SRC-MOM 14/07/2026 (both consistent with today, 2026-07-20). SRC-DECK is dated July 2025 and shows an action plan of "Build & Test Sep 2025 → Launch April 2026 → Gov Jan 2027 → Phase 2 2028". Impact: Low architecturally, high for planning. The deck's timeline has already lapsed; the BRD/MoM represent the current programme. Treat SRC-DECK as business intent, not schedule.

6. Open Questions#

OQ-01–OQ-03 were raised in SRC-MOM §15 and remain unanswered. OQ-04+ are raised by this analysis.

7. Architectural Seams (Phase-2 Extraction Points)#

Derived from CONF-04. These are the boundaries the MVP must respect so Phase 2 is additive rather than a rewrite.

8. Constraints (Normative)#

Architect-imposed constraints (this engagement)#

9. Traceability to the BA's RTM#

SRC-MOM defines six requirement IDs. Mapping to this baseline:

10. Success Metrics (from SRC-MOM §13)#

Recorded because they imply reporting/analytics data requirements on the architecture:

• Monthly consultations booked and completed
• Free templates downloaded and customised
• % of employees passing assessments and receiving certificates
• MRR from provider subscriptions and featured-listing packages

These four metrics are the minimum viable analytics surface. They require event capture in MOD-CONS, MOD-TPL, MOD-ASMT/MOD-CERT, and MOD-PAY respectively. Designing them in from the start is far cheaper than reconstructing them from transactional tables later.

Next Documents#

1. 01-quality-attribute-scenarios.md — turns the NFRs above into measurable, architecture-driving scenarios
2. arc42/ — the architecture description proper
3. adr/ — decision records for every choice made here and downstream