Architecturally Significant Requirements¶
ASRs are the requirements where architecture is the deciding factor: the prioritized quality attributes, and the scenarios that make each of them testable. Business risks that architecture cannot solve, such as funding or partner interest, stay in the project management pages.
Quality attributes¶
| Priority | Attribute | Meaning here |
|---|---|---|
| 1 | Integrability | New or changed data sources plug in without rewrites. |
| 2 | Privacy / GDPR by design | Health data exists only after explicit consent |
| 3 | Consumer usability | At least 95% of successful scans return the required passport content within 3 seconds over a rolling 30-day window. |
| 4 | Modifiability | adaptive project management model, we have to embrace the change |
Scalability is not a primary driver: scale is small.
Quality attribute scenarios¶
These scenarios make the quality attributes above testable. Each one follows the same six-part form: source, stimulus, artifact, environment, response and response measure. They are written against the MVP scope in Stories. They are requirements, not proof of implementation.
QAS-1: Performance, Multi-API Orchestration on Scan¶
stories 1.1, 1.2, 3.1, 3.2, 3.3.
| Part | Description |
|---|---|
| Source | A consumer |
| Stimulus | Scans a GS1 Digital Link QR code |
| Artifact | The complete public scan flow, including POST /api/v1/scans and the GS1 resolver entry path |
| Environment | Normal operation with the base product available from the synchronized producer catalog or community cache |
| Response | The system records the scan and returns the base passport plus a definitive available/unavailable state for verdict, journey and recipe sections. |
| Response measure | At least 95% of successful end-to-end scans complete within 3 seconds over a rolling 30-day period. The SLI must cover both public entry paths. |
Architectural impact¶
- Start the scan from synchronized producer data or the community-source cache.
- Give every external source its own adapter and timeout.
- Load or fail each optional section independently.
QAS-2: Availability, Graceful Degradation Under External API Failure¶
stories 1.5, 1.6.
| Part | Description |
|---|---|
| Source | An external product-data source |
| Stimulus | Returns an error or does not respond during a scan |
| Artifact | Product Passport scan flow |
| Environment | Normal operation while the external source is unavailable |
| Response | The system records the scan, returns local or cached product data and marks only the affected optional section as unavailable. |
| Response measure | The base passport remains usable and only the affected optional section becomes unavailable. Adapter timeouts and breaker thresholds are configuration, verified per environment rather than fixed by this requirement. |
QAS-3: Privacy, Health-Data Erasure on Consent Revocation¶
stories 2.5, 5.1, 5.2.
Target pending maintainer approval. The 99.9% within 60 seconds measure below is a proposed requirement, not an accepted target.
| Part | Description |
|---|---|
| Source | A consumer |
| Stimulus | Revokes health-profile consent |
| Artifact | Identity consent record and Personalization health profile |
| Environment | Normal operation with an existing health profile |
| Response | The system records the revocation, deletes the health profile and returns no_profile for later verdict requests. |
| Response measure | Proposed: within 60 seconds, at least 99.9% of revocations delete the profile and subsequent verdicts return no_profile. Success, failure and retry exhaustion are counted by erasure_propagation_total; no failed propagation is silent. |