Non Functional Requirements

Non-functional requirements here are constraints: rules the system has to satisfy, independent of any particular technology choice. Each carries a MoSCoW priority — Must, Should, or Could — reflecting what’s load-bearing (Must), valuable but not essential (Should), or nice-to-have (Could). They are distinct from Quality Attributes — the measurable how well (performance, scalability, availability) — which are documented separately. Each is traced back to User Stories or Business Requirements that require it.

1. Decentralized Authorization Evaluation

• Must The Requirement: The system shall evaluate authorization decisions locally without requiring a network round-trip to a central authority.
• Why this is required: A central authority queried on every decision becomes a bottleneck and single point of failure — its latency and uptime cap the latency and uptime of everything that depends on it. Grounded in AA-5 (switch organizations without re-authenticating) and every “instant” story (LD-4, AL-3) where per-request latency cannot be hidden.

2. Strict Tenant Data Isolation

• Must The Requirement: The system shall ensure data belonging to one tenant is never readable by a principal outside it, regardless of any other access path in the system.
• Why this is required: The platform holds data for independent organizations; a single cross-tenant leak breaks the trust the entire multi-tenant model depends on. Grounded in BT-4 (see only my organizations’ buildings), AA-6 (private, invite-only domains), and AI-4 (assistant scoped to accessible organizations).

3. Complete Access Audit Trail

• Must The Requirement: The system shall log every access to tenant data (who, what, when) in an immutable log that cannot be altered or deleted after creation.
• Why this is required: GDPR requires proving who accessed what and when; an audit trail that can be edited after the fact proves nothing. Required by EU data protection obligations stated in Business Requirements.

4. Accessible Interface Conformance

• Must The Requirement: The system shall ensure every user-facing interface conforms to WCAG 2.1 AA accessibility standards.
• Why this is required: A dashboard or twin that only works by sight excludes a screen-reader user from the platform entirely — that’s not a degraded experience, it’s no access at all. Grounded in LD-7 (dashboard data available through accessible markup) and inclusive design principles.

5. EU Data Residency

• Must The Requirement: The system shall ensure all data belonging to EU tenants resides exclusively in EU infrastructure; no default transfer to non-EU regions.
• Why this is required: Required by Business Requirements (European market focus, GDPR compliance, Italy data residency preferences). Cross-border data transfer requires explicit legal basis and tenant consent.

6. No Hardcoded Secrets

• Must The Requirement: The system shall not store credentials, API keys, tokens, or other secrets in code, configuration files, or logs; all secrets must be stored in a secure external system and rotated regularly.
• Why this is required: Required by Business Requirements (SaaS security table-stakes) and GDPR obligation to protect personal data in transit and at rest. Hardcoded secrets are the fastest path to a data breach.

7. Graceful Degradation

• Should The Requirement: The system shall degrade gracefully when non-critical services fail: show stale or partial data with a warning rather than crashing the critical path.
• Why this is required: Sensor service outage should not make the dashboard unusable; it should show last-known values and indicate staleness. Improves resilience and user trust in partial failures. Grounded in LD-4’s outage criterion — a dashboard that goes silently stale while disconnected is exactly the crash-the-critical-path failure this rules out.

8. Internationalization

• Could The Requirement: The system shall support English and Italian at minimum in the UI; no user-facing text shall be hardcoded without localization keys.
• Why this is required: Supports Business Requirements’ European market focus (Italy priority). Enables fast expansion to other languages without code changes.

Traceability: NFRs 1–2, 4, 7 trace to specific User Stories. NFRs 3, 5, 6 derive from Business Requirements (GDPR compliance, EU data strategy, SaaS security table-stakes). NFR 8 is an operational/strategic priority (market expansion).

The measurable how well counterpart to these constraints — performance, scalability, availability — is covered separately in Quality Attributes.