HOCO B2B
SRS

Source traceability

Every section of the cahier des charges mapped to requirement ids, screens and the pages that cover it, the list of team additions with their rationale, and how traceability is kept when the cahier is revised.

The source is the Cahier des charges — Écosystème B2B HOCO, version 1.0, July 2026 (40 pages, 16 reference screens). Each requirement in requirements.json carries a source field citing a cahier section (cahier §4.4), a reference screen, or a team decision. The table below reads the other way round: from each section of the cahier to what implements it. Requirement lists are generated from the source fields; screens are those whose requirements implement the section.

Section by section

§ (page)SectionRequirementsMain screensCovered by
p. 1Cover — the three solutions and the API——Overview, scope
p. 2Validation sheet and scope clause— (process)—Change control, change requests
1 · 1.1 · 1.2Vision, context, target visionContext for every area—PRD, scope
1.3Business objectivesMeasured through ANA-01 to ANA-04BO-04, BO-59Scope
1.4Success indicatorsANA-04BO-59Analytics
2Global architecture (single API and database)SYN-01, SYN-02, NFR-03—Architecture and data, service catalogue
2.1Exchange principlesSUP-01, SUP-02, SUP-04, AUD-01RA-32 to RA-34, RA-40, BO-55, BO-56, BO-69Support, notifications matrix
3User profiles (8 roles)ACL-01, AUTH-01, ADM-01, STK-06, DLV-01, DLV-03BO-01, BO-61, BO-62Permissions matrix
3.1Permission principlesACL-02 to ACL-05, AUD-01, ADM-02BO-62, BO-63Permissions matrix
4Back-office overview, indicators and reportsCAT-01, ANA-03BO-05, BO-59Analytics
4.1DashboardANA-01, ANA-02, CRM-11, STK-05, GEO-01BO-04 to BO-08Analytics, admin dashboard API
4.2CRM resellers and prospectsCRM-01 to CRM-13, AUTH-05BO-09 to BO-15, DA-13 to DA-15, RA-05, RA-28CRM, ResellerStatus, BR-04
4.3Products, categories, brands, stockCAT-01 to CAT-06, PRC-01, PRC-02, STK-01, STK-02, STK-04, STK-05, STK-07, STK-08, AUD-02BO-27 to BO-37, BO-71Catalog, pricing, stock, ProductStatus
4.4Order managementORD-04 to ORD-06, ORD-08, ORD-10 to ORD-14, DLV-01 to DLV-03, NOT-05, LOY-01BO-38 to BO-42, BO-69, RA-22, RA-23, RA-40Orders, OrderStatus, ReturnStatus
4.5Delegates, zones, toursGEO-02, FLD-01 to FLD-04, FLD-09, FLD-13, FLD-14, FLD-17BO-16 to BO-25, DA-05 to DA-07Field operations, TourStatus
4.6Promotions, packs, loyaltyPRM-01 to PRM-03, PRM-06, LOY-01 to LOY-04BO-49 to BO-54, RA-24, RA-25Promotions, loyalty, BR-64
4.7Payments, credit, invoicingFIN-01 to FIN-09, PRC-04, ACL-04BO-44 to BO-48, RA-29 to RA-31Finance, InvoiceStatus, BR-32
5Reseller app — homeCAT-11, PRM-05, FIN-10, NOT-01, AUTH-03, AUTH-04, SUP-01, SUP-03RA-09, RW-02Reseller app screens
5.1Product catalogCAT-07, CAT-09, PRC-05, NFR-01RA-10 to RA-13, RW-03Catalog, BR-63
5.2Product detailCAT-08, CAT-09RA-14 to RA-16, RW-04Catalog API
5.3Cart and checkoutORD-01 to ORD-03, PRC-05, FIN-05, SYN-07RA-17 to RA-20, RW-06, RW-07Cart and checkout API, BR-20 to BR-23
5.4Order tracking and historyORD-06, ORD-07, ORD-15, NOT-05RA-21, RA-22, RW-08, RW-09What the reseller sees, BR-30
5.5Promotions, packs, loyalty (app)PRM-04, PRM-06, LOY-04, LOY-05RA-24, RA-25, RA-37 to RA-39Promotions, PromotionStatus
6Delegate app — sign-in and profileAUTH-02, AUTH-08, GEO-02, NOT-01, NOT-05DA-01 to DA-04, DA-24, DA-25AccountStatus
6.1Delegate homeFLD-04, FLD-05, FLD-19, NOT-07DA-05, DA-22, DA-23Delegate day API
6.2Tour programmeFLD-03, FLD-06, FLD-17DA-06, DA-07, BO-21, BO-22TourStatus
6.3Map and navigationGEO-03, FLD-07DA-08, DA-28BR-51
6.4Visit and check-inFLD-08, FLD-13, FLD-16, GEO-03, SYN-07DA-10, BO-24 to BO-26VisitStatus
6.5Reseller sign-up in the fieldFLD-11, CRM-02, CRM-03, CRM-05, CRM-09, AUTH-05, GEO-01, ADM-05DA-14, BO-12, BO-13ValidationStatus, BR-75
6.6Invitation and app downloadIVT-01 to IVT-04, AUTH-03, AUTH-05DA-16, RA-02 to RA-05InvitationStep, BR-03
6.7First-order assistanceORD-08, ORD-09DA-17, DA-18, RA-23, BO-41AssistedConfirmation, BR-70
6.8Visit reportFLD-10, CRM-08, FLD-16, ADM-05DA-12, DA-19, BO-25TaskStatus
6.9Tour closing and resultsFLD-09, FLD-12, FLD-19DA-20, DA-21, BO-23TourStatus
7.1Back-office → appsSYN-01—Architecture and data, sync API
7.2Apps → back-officeSYN-02—Architecture and data
7.3Synchronisation and offlineSYN-03 to SYN-06DA-27, DA-28Offline sync design
8Cross-cutting business rulesADM-03, ADM-04, PRC-01 to PRC-03, STK-02, STK-03, ORD-02, FIN-05, FLD-15, GEO-03, NOT-01 to NOT-04, AUD-02BO-64Business rules (one group per §8 family)
9Technical and non-functional requirementsNFR-01 to NFR-08, AUTH-09, ADM-07, ANA-05, CRM-11RA-36, DA-28, BO-60, BO-66Cross-cutting requirements
10Security, compliance, traceabilitySEC-01 to SEC-08, AUTH-06 to AUTH-08, ACL-05, AUD-01, AUD-03, FLD-15, NOT-06, CRM-10DA-04, BO-63, BO-68Security, BR-84
11External integrationsINT-01 to INT-07, NOT-02, NOT-03, NOT-08, DLV-04, DLV-05, STK-09, FIN-09, GEO-04BO-43Integrations
12Acceptance criteria and test scenariosOPS-05, AUTH-03, ACL-05, CRM-03, CRM-09, STK-03, ORD-03, ORD-09, PRM-04, LOY-05, IVT-04—Acceptance scenarios
13.1EnvironmentsOPS-01—Deployment and operations
13.2Deployment, initial importOPS-02, ADM-06, CAT-06BO-32, BO-67Deployment and operations
13.3TrainingOPS-03—Deployment and operations
13.4MaintenanceOPS-04, NFR-09, ADM-07BO-66Deployment and operations
14Roadmap in ten phasesOPS-06—Delivery frame: phases 1–3 → P0, 4–7 → P1 (reseller web included), 8–9 → P2 (acceptance, go-live at the start of January, two-week pilot) within the three months; 10 → P3 after them · timeline
14.1Recommended V1PRM-01, SUP-01 and every V1 requirement—V1/V2 boundary
14.2V2 evolutionsPRM-06, LOY-01, FIN-06, DLV-05, NOT-08, FLD-18, ANA-06 (returns and after-sales moved to V1)RA-37 to RA-39, BO-47, BO-48, BO-52 to BO-54, RW-15V1/V2 boundary, releases
15.1Reseller statusesCRM-04BO-11, DA-13ResellerStatus
15.2Order statusesORD-04BO-38OrderStatus
15.3Tour statusesFLD-04DA-06, BO-23TourStatus
15.4Minimum product dataCAT-03BO-28Database design, ProductStatus
15.5Minimum reseller dataCRM-01, CRM-10DA-14, BO-12, RA-05CRM
p. 40Décisions restantes à validerSEC-08 and the requirements each decision affects—Decision register D-01 to D-11, in the cahier's order
Ref. screens 1, 5, 7Client reference screensCAT-10, FIN-10, PRC-04, DLV-06, PRM-05RA-09, RA-11, RA-18, RA-24Reference screens

Coverage

  • Every requirement cites a source. All 194 requirements have a source; 186 cite at least one cahier section or reference screen (6 of them together with a team decision) and 8 cite only a team decision — all listed below.
  • Every cahier section has an owner. Sections without a requirement of their own (cover, §1.1–§1.2, the validation sheet) are covered by the PRD, the scope and the change-control process.
  • Every requirement is planned, except three: GEO-04 (geocoding, COULD) and NOT-05 (automatic order notifications, MUST) have no task listing them — NOT-05 is delivered by the notification infrastructure and the orders module (SRV-08, SRV-16) and should be added to their srs lists; CRM-13 (merge tool, V2 COULD) is not planned.

Team additions

Items not literally in the cahier, added by the team and presented to HOCO with the baseline. They are not change requests while HOCO validates them at the cadrage; refused ones are removed.

AdditionRequirementsRationale
Reseller web app, in V1 and deployed before the pilotRWA-01, RWA-02iPhone users and desk-based resellers can order without iOS apps; same API and rules, no extra backend
Guest browsing without pricesAUTH-10Prospects discover the catalog before signing up; prices stay private
Customer type and three prices per variant (replacing segment price lists and quantity tiers in V1)AUTH-11, PRC-01, PRC-02Matches how HOCO sells (super-gros, demi-gros, détail); simpler than price lists; agreements in V2
Advanced filters and attributesCAT-12, CAT-13Hundreds of similar accessories need filtering by power, connector, length…
Availability only, never quantitiesSTK-07HOCO's choice among the cahier's options (§4.3)
Explicit confirmation of every order, with a queueORD-14Makes cahier §4.4 « Validation » explicit; no unattended order reaches the warehouse
Live order status for resellersORD-15Cahier §5.4 and §12 ask for dated, notified changes visible in the app
Returns, credit notes and after-sales in V1ORD-13, SUP-04, FIN-08Defective and wrong items are frequent with accessories; restocking must be exact
Regional WhatsApp supportSUP-05, ADM-08Resellers already use WhatsApp; regional teams answer faster
Account claim by phoneAUTH-05Mechanism behind cahier §6.5–§6.6: a field prospect becomes an account without a duplicate
Payment declaration with proofFIN-03CCP and BaridiMob offer no confirmation API (cahier §4.7 lists the methods)
Server-side cart shared across devicesORD-01Needed once the web and the app share an account
Minimum app version, maintenance modeAUTH-09, ADM-07Keeps old app versions from breaking business rules
Real-time streams, idempotency, sync centreSYN-05, SYN-07, DA-27Implementation of cahier §7.3 and « en temps réel » (§6.4)
Account deletion requests and anonymisationBR-85Google Play policy for apps that create accounts, Law 18-07

Keeping traceability when the cahier changes

  1. Version the source. Each cahier version HOCO issues (v1.1, v2.0…) is stored with its text extraction in the project's shared folder and referenced here with its date; requirements.json records it in generatedFrom.
  2. Diff, section by section. Extract the text of the new version (one block per section, as for v1.0), compare it with the previous one and list the sections added, changed or removed.
  3. Assess each change. For every changed section: update this table; add, change or retire requirements — ids are never reused, a retired requirement is removed only through a change request and noted in its pull request; update the screens and operations that cite it; check the business rules and lifecycles that quote the cahier.
  4. Route scope changes through change control. Anything that adds or changes scope after the cadrage is a change request with its impact on the plan (process); a pure rewording only updates the citations.
  5. Re-run the checks. Every requirement keeps a source; every section keeps at least one owner; every screen, operation and task references existing requirement ids (the team runs this cross-reference check on the JSON files in CI).
  6. Bump the baseline. The version of the spec files moves (0.1.0 → 0.2.0…) and the SRS index states the new counts.

Glossary

French ↔ English glossary of the business, administrative, project and technical terms used in the cahier and across the HOCO docs.

Lifecycles and statuses

Every status machine of the platform — values, diagram, allowed transitions with actors, guards, side effects and the API operation that performs them.

On this page

Section by sectionCoverageTeam additionsKeeping traceability when the cahier changes