Non-functional requirements

This area turns cahier §9 (performance, availability, scalability, mobile compatibility, responsive, languages, accessibility, exports, logs), §10 and §13.4 into measurable targets, each with a verification method and the task that verifies it. Apps: all. There is no owning module: targets apply to every module and app. Detailed sub-targets are in cross-cutting requirements.

ID	Requirement	Release	Priority	Source	Apps
NFR-01	Performance: app opens and search/filter results in under 3 s on a normal mobile connection; API p95 targets	V1	MUST	§5.1, §9	API · RA · DA · RW · BO
NFR-02	Availability: supervised service, backups and a tested restore procedure	V1	MUST	§9, §10	OPS
NFR-03	Scalability for more resellers, products, orders and zones	V1	MUST	§9	API
NFR-04	Android first on mid-range phones; iOS on client decision	V1	MUST	§9	RA · DA
NFR-05	Back-office usable on desktop, tablet and large screens	V1	MUST	§9	BO
NFR-06	French in V1; Arabic (RTL) and English prepared from day one	V1	MUST	§9	API · BO · RA · RW · DA
NFR-07	Accessibility: readable contrast, reachable buttons, consistent text sizes, explicit messages	V1	MUST	§9	BO · RA · RW · DA
NFR-08	Logging of sensitive actions and technical errors; monitoring and alerting	V1	MUST	§9	API · OPS
NFR-09	Maintainability: automated tests, CI gates, typed contracts, documentation	V1	MUST	§13.4	API · BO · RW · RA · DA

Reference conditions used below: reference phone = mid-range Android (4 GB RAM, Android 11 or later, octa-core 2 GHz class); normal mobile connection = 4G, 5 Mbps down, 100 ms latency; 3G-class = 1 Mbps, 300 ms. Sizing assumption for load tests: 2 000 resellers and 50 delegates in year 1, 5 000 variants, 300 orders per day at peak, 1 500 visits per day; scalability is tested at 5× these volumes.

NFR-01 — PerformanceCopy Anchor Link

Statement — Apps shall open, and search and filter results shall appear, in under 3 seconds on a normal mobile connection, and the API shall meet the p95 targets below.

Rules

Acceptance criteria

• The SRV-28 load-test report shows every API target met at 3× peak with error rate under 1 %; the MOB-12 report shows cold start and search within 3 s on the reference phone.

Data — none.

Interfaces — all.

NFR-02 — Availability, backups, restoreCopy Anchor Link

Statement — The service shall be supervised, backed up and restorable with a tested procedure.

Rules

Acceptance criteria

• A restore of the latest dump into an empty database completes within 4 hours with row counts matching production; the report is attached to the go-live checklist.

Data — all.

Interfaces — /health.

NFR-03 — ScalabilityCopy Anchor Link

Statement — The architecture shall absorb more resellers, products, orders and zones without redesign.

Rules

1. Stateless API processes (sessions in the database, SSE fan-out through Redis) so more replicas can be added; jobs in a separate worker process.
2. Every list is paginated (max 100 per page); every filter used in production has an index; no query scans a table that grows with orders or pings without an index.
3. Target: the 5× dataset meets the NFR-01 targets on the production server size.

Acceptance criteria

• The SRV-28 test on the 5× dataset meets NFR-01; adding a second API replica on staging serves SSE and requests without session loss.

Data — all.

Interfaces — all.

NFR-04 — Android first, iOS on decisionCopy Anchor Link

Statement — Both mobile apps shall run well on mid-range Android phones; iOS builds follow HOCO's decision.

Rules

1. Minimum Android 8.0 (API 26) (assumption); download size ≤ 35 MB per app; smooth scrolling (under 5 % janky frames) on the reference phone.
2. iOS only if D-10 decides it (MOB-16, after the three months).
3. The delegate app works outdoors (contrast checked in sunlight, DQA-03) and through a full day offline (SYN-04).

Acceptance criteria

• Both apps install and pass the acceptance scenarios on the reference phone and on an Android 8 device; the Play Console reports size ≤ 35 MB.

Data — none.

Interfaces — none.

NFR-05 — Back-office on desktop, tablet and large screensCopy Anchor Link

Statement — The back-office shall be usable on desktop, tablet and large screens.

Rules

1. Checked at 1 366 × 768, 1 920 × 1 080, 2 560 × 1 440, tablet 1 024 × 768 and 768 × 1 024; tables scroll horizontally with a sticky first column on tablets; forms become one column; nothing requires hover only.
2. Browsers: last two versions of Chrome, Edge and Firefox; Safari 16+.

Acceptance criteria

• The DQA-04 checklist passes at every listed size with no blocking issue.

Data — none.

Interfaces — none.

NFR-06 — French in V1; Arabic (RTL) and English preparedCopy Anchor Link

Statement — All interfaces shall be complete in French for V1, with every string externalised and layouts ready for Arabic (right to left) and English.

Rules

1. No hard-coded user-facing string (ARB files in Flutter, next-intl messages in Next.js, localised API error messages by Accept-Language); locale stored per user (me.update).
2. Layouts use start/end (logical) spacing and mirror directional icons; an Arabic font pairing exists in the design system; reference data carries French and Arabic names (wilayas, communes).
3. Numbers and money formatted fr-DZ (1 250,00 DA); dates in Africa/Algiers. Languages at launch: D-09.

Acceptance criteria

• A lint rule fails the build on a hard-coded string; switching a test build to Arabic shows mirrored layouts on the key screens without overlap (MOB-17).

Data — User (locale), Wilaya, Commune, NotificationTemplate.

Interfaces

• Screens: RA-35 Settings
• Endpoints: me.update

NFR-07 — AccessibilityCopy Anchor Link

Statement — Interfaces shall have readable contrast, reachable buttons, consistent text sizes and explicit messages.

Rules

Acceptance criteria

• Lighthouse accessibility ≥ 90 on the back-office dashboard, orders list and reseller web catalog; design QA reports no contrast failure on status pills.

Data — none.

Interfaces

• Screens: RA-36 System states

NFR-08 — Logging, monitoring and alertingCopy Anchor Link

Statement — Sensitive actions and technical errors shall be logged, and the platform monitored with alerts.

Rules

1. Structured JSON logs with request id, user id, client app and version; secrets and tokens never logged; phones masked (+21355****456); application logs kept 30 days. Business actions go to the audit log (AUD-01).
2. Error tracking (Sentry) for server, back-office, web and both apps, tagged with release.
3. Alerts: 5xx rate over 2 % for 5 minutes; p95 latency over 1 s for 10 minutes; job queue backlog over 1 000 or oldest job over 5 minutes; disk over 80 %; missing backup; certificate expiring in under 14 days; uptime check failing.

Acceptance criteria

• An injected server error appears in Sentry with its request id; a stopped worker triggers the backlog alert within 10 minutes.

Data — AuditLog.

Interfaces — none.

NFR-09 — MaintainabilityCopy Anchor Link

Statement — The code shall be maintainable by a new developer: automated tests, CI gates, typed contracts and documentation.

Rules

1. CI on every pull request: lint, type check, unit tests, build, OpenAPI diff (breaking contract changes need explicit approval and a version note); merge to dev blocked on failure.
2. Tests: every state machine (order, tour, visit, ticket, return) covered transition by transition; domain modules ≥ 70 % line coverage; integration tests for checkout, the visit flow and sync.batch; Flutter integration tests for ordering and the visit flow.
3. Contract-first API (oRPC → OpenAPI → generated Dart client); these docs updated in the same change as the behaviour.

Acceptance criteria

• A pull request that breaks a test or the contract is blocked; the coverage report meets the thresholds at the end of P1.

Data — none.

Interfaces — /openapi.json, /reference.