Requirements — overview

The requirements catalogs describe what the applications are capable of, at the level a user observes it. They serve two purposes:

1. A readable capability overview of the tracking app and the portal.
2. The anchor for system tests: every stable requirement is covered by at least one manual test case in System tests, and every test case declares which requirements it covers.

This is deliberately not a full V-model artifact. There are no separate architecture or module specifications — the code and the rest of /docs are the source of truth for how. What we keep from that world is traceability: requirement ↔ test case, both directions, via stable IDs.

Documents

Document	Prefix	Scope
Shared requirements	SHR-*	Behavior shared by both apps via @enode/core / @enode/ui: auth flow, i18n, units, error handling
Tracking app requirements	TRK-*	@enode/tracking — the coach-facing training app (Capacitor iOS/Android + PWA)
Portal requirements	POR-*	@enode/portal — the browser-based coach/admin console

ID scheme

<APP>-<AREA>-<NN>       e.g. TRK-LIVE-03, POR-USERS-07, SHR-ERR-01

• APP — TRK (tracking), POR (portal), SHR (shared).
• AREA — a short feature-area code, defined at the top of each catalog.
• NN — two-digit sequence within the area.

IDs are stable. Never renumber or reuse an ID. When a requirement is dropped, keep the row, strike the text, and note why. New requirements get the next free number in their area.

Status legend

Status	Meaning	Gets system tests?
stable	Implemented and expected to work in release builds	Yes
flag	Behind an in-code flag (flag name noted); both branches exist	Only if the flag is ON in release builds
wip	Visibly present but known-incomplete	No — noted as known behaviour
mocked	UI exists but renders mock/preview data	No — noted as known behaviour

Traceability

• Each requirement row has a Tests column listing the covering test-case IDs (e.g. TRK-ST-4.2) — filled in as protocols are written.
• Each test protocol ends with a coverage table listing every stable requirement and its cases, so gaps are visible at a glance. A stable requirement with no system test needs an explicit reason there (e.g. "covered by unit tests only — not observable at system level").

Change rules

• A PR that changes user-facing behavior updates the affected requirement row(s) and the linked test cases in the same PR (same rule as the rest of /docs — see the repo CLAUDE.md).
• Requirements state user-observable behavior, 1–3 sentences, present tense ("The user can …", "The app shows …"). Implementation details belong in the linked architecture docs, not here.