Software requirements specification
What the SRS of the HOCO B2B ecosystem contains, how to use it, the baseline in numbers, the map of its pages and the change-control rule.
The SRS says exactly how the HOCO B2B ecosystem must behave — the back-office, the reseller app and web, the delegate app and the central API. The PRD explains what is built and why; the SRS is the contract the team builds, tests and accepts against. It turns the client's Cahier des charges — Écosystème B2B HOCO v1.0 (July 2026) into identified requirements, state machines, numbered business rules, permissions, notifications, acceptance scenarios, a data model and an API catalogue, and it records the product decisions of 17 and 18 October 2026 (customer-type prices, guest mode, no automatic order confirmation, returns and after-sales in V1, the reseller web in V1, the three-month frame).
Status: baseline 0.1.0, to be validated by HOCO at the cadrage workshop (PRJ-03, milestone Cadrage validated — validation sheet signed). From then on it changes only through the change-control rule.
How to use it
Every feature is read the same way, from the requirement to the test:
Find the requirement in its area page under requirements — an id like ORD-14, with its release (V1 or V2), its priority and its cahier source. Non-functional and transverse needs are in cross-cutting requirements.
Check the behaviour: the states and allowed moves in lifecycles and statuses, the numbered rules and their settings in business rules, who may do it in the permissions matrix, who is told in the notifications matrix.
Find the data and the API: the module that owns it in the service catalogue, the tables in database design, the operations in the API reference, background work in jobs and scheduler, offline behaviour in offline sync design.
Know how it is accepted: the matching scenario in acceptance scenarios, and the screens in the screen inventory.
Find who builds it and when: the task pages under team tasks list the requirement, screen and API ids of each task; dates are on the timeline.
Example — the order confirmation queue: ORD-14 → OrderStatus transitions and BR-24 → orders.validate in the permissions matrix → admin.orders.toConfirm and admin.orders.validate → screen BO-41 → tasks SRV-16 and DSH-06.
Identifiers used everywhere
| Kind | Format | Source of truth |
|---|---|---|
| Requirement | AREA-nn (CRM-03), release V1 or V2, priority MUST · SHOULD · COULD | content/spec/requirements.json |
| Screen | RA-nn reseller app · RW-nn reseller web · DA-nn delegate app · BO-nn back-office | content/spec/screens.json |
| API operation | Operation id (cart.checkout), method and path under /v1 | content/spec/endpoints.json |
| Status and enum | UPPER_SNAKE_CASE value with its French label | content/spec/enums.json |
| Business rule | BR-nn | Business rules |
| Decision | D-nn | Decision register |
| Task | SRV-nn, DSH-nn, WEB-nn, MRA-nn, MDA-nn, DES-nn… | content/plan/tasks.json |
Priorities: MUST — required for the acceptance of its release; SHOULD — planned in its release, may move to the next one by written agreement; COULD — done if capacity allows. Release: V1 is delivered within the three-month frame (design, build, deployment, go-live at the start of January 2027, then a two-week pilot); V2 comes after it (cahier §14.2).
The baseline in numbers
Counts of baseline 0.1.0 (18 October 2026); the tables linked from each line are generated live from the JSON files.
| Item | Total | V1 | V2 |
|---|---|---|---|
| Requirements (25 areas) | 194 | 177 | 17 |
— of which MUST · SHOULD · COULD | 155 · 33 · 6 | ||
| Screens and pages (4 interfaces) | 155 | 146 | 9 |
| API operations | 286 | 271 | 15 |
| Enums and statuses | 54 | ||
| Plan tasks | 145 | P0 45 · P1 76 · P2 7 | P3 4 (generalisation) · P4 13 (V2) |
Requirements by area
| Area | Name | V1 | V2 | Total |
|---|---|---|---|---|
| AUTH | Authentication & accounts | 11 | 0 | 11 |
| ACL | Roles, permissions & data scope | 5 | 0 | 5 |
| AUD | Audit trail & history | 3 | 0 | 3 |
| GEO | Geography, zones & GPS | 4 | 0 | 4 |
| CRM | Resellers & prospects | 12 | 1 | 13 |
| CAT | Catalog | 13 | 0 | 13 |
| PRC | Pricing | 4 | 1 | 5 |
| STK | Stock | 8 | 1 | 9 |
| ORD | Cart & orders | 15 | 0 | 15 |
| DLV | Preparation & delivery | 5 | 1 | 6 |
| FIN | Invoicing, payments & credit | 7 | 3 | 10 |
| PRM | Promotions & packs | 5 | 1 | 6 |
| LOY | Loyalty programme | 0 | 5 | 5 |
| FLD | Field operations | 18 | 1 | 19 |
| IVT | Invitations & activation | 4 | 0 | 4 |
| SUP | Support & claims | 5 | 0 | 5 |
| NOT | Notifications & messaging | 7 | 1 | 8 |
| ANA | Dashboards, KPIs & reports | 5 | 1 | 6 |
| ADM | Administration & settings | 8 | 0 | 8 |
| SYN | Synchronisation & offline | 7 | 0 | 7 |
| INT | External integrations | 6 | 1 | 7 |
| RWA | Reseller web app | 2 | 0 | 2 |
| NFR | Non-functional | 9 | 0 | 9 |
| SEC | Security, privacy & compliance | 8 | 0 | 8 |
| OPS | Deployment, training & maintenance | 6 | 0 | 6 |
Screens per interface
| Interface | Screens | V1 | V2 | Built by |
|---|---|---|---|---|
| Reseller app (RA) | 41 | 38 | 3 | Imad |
| Delegate app (DA) | 28 | 28 | 0 | Imad |
| Back-office (BO) | 71 | 66 | 5 | Anis |
| Reseller web (RW) | 15 | 14 | 1 | Anis |
API operations per audience
| Audience | Groups | Operations | V1 | V2 |
|---|---|---|---|---|
| Every app | auth, me and reference data, files, notifications and live events | 30 | 30 | 0 |
| Reseller and delegate (guests included) | catalog and favorites | 12 | 12 | 0 |
| Reseller | cart, orders and returns, finance, promotions, loyalty, profile, support | 50 | 42 | 8 |
| Public and reseller | invitations and attribution | 3 | 3 | 0 |
| Delegate | day, tours and visits, resellers, assisted orders, sync | 47 | 47 | 0 |
| Back-office | twelve admin groups and the real-time stream | 144 | 137 | 7 |
Eleven operations are public and fifteen accept guests (auth: optional); 44 require an Idempotency-Key. The full catalogue is on the API reference.
Tasks per person — Anis owns 67 tasks (server, back-office, reseller web, operations), Imad 43 (both Flutter apps), Akram 35 (design, design QA, assets, training material); load and dates per lane:
| Person | Role | Effort | Tasks | Window | Owns |
|---|---|---|---|---|---|
| Anis | Full-stack developer · 1 FTE | 60.75 d | 39 | 18 Oct 2026 → 18 Feb 2027 | Server (API), back-office dashboard, reseller web app, docs, DevOps |
| Imad | Mobile developer (Flutter) · 1 FTE | 69.75 d | 44 | 18 Oct 2026 → 31 Jan 2027 | Reseller app and delegate app (Flutter monorepo) |
| Akram | UI/UX designer · 1 FTE | 43.25 d | 36 | 18 Oct 2026 → 22 Feb 2027 | Design system and every interface, design QA, training and store assets |
Structure of the SRS
Scope
Glossary
Source traceability
Lifecycles and statuses
Business rules
Permissions matrix
Notifications matrix
Acceptance scenarios
Requirements
Cross-cutting requirements
Architecture and data
Service catalogue
Database design
API reference
Jobs and scheduler
Offline sync design
Integrations
Deployment and operations
Releases and team
Decision register
Change control
The cahier's validation sheet (p. 2) carries the scope clause: « Toute fonctionnalité non décrite ou non validée dans le présent cahier des charges fera l'objet d'une analyse complémentaire, d'un chiffrage séparé ou d'une planification dans une version ultérieure. »
Applied to this SRS:
- What is described here, once validated at the cadrage, is the scope. Anything not described — a new feature, screen, field, report, rule, integration, or a change to a validated design or a decided register entry — is a change request, analysed, priced and planned separately (process).
- Not a change request: a behaviour that contradicts the SRS (a bug, handled by the bug process); a detail left open inside the described scope (a clarification logged in the register); a value changed within the allowed range of a setting.
- Team additions already in the plan (the reseller web, the product decisions of 17 October) are part of the baseline presented to HOCO, listed in source traceability.
- Every accepted change updates the JSON files first (a new id, never a reused one), then the pages and
tasks.json, in one pull request; the plan recomputes the dates (planning method). - Within the three-month frame, a slip moves scope after go-live along the ordered list of decision D-38, unless HOCO decides otherwise in writing.
User flows
Every journey across the reseller app, the reseller web, the delegate app and the back-office — flowcharts, sequence diagrams and the reseller lifecycle, traced to requirements, screens and API operations.
Scope
Purpose, audiences, what each surface contains, the V1/V2 boundary per area, explicit exclusions, numbered assumptions and the constraints of the Algerian context.