Non-Functional Requirements are not a separate grammar. An NFR is a requirement written in EARS, just like any functional obligation. What distinguishes it is what it constrains: how well the system performs rather than what it does. A latency budget is an event-driven requirement. An availability SLA is ubiquitous. An encryption obligation is ubiquitous. A degraded-mode behavior is state-driven. The metric lives inside the EARS statement, and the same satisfies bridge carries NFRs down to domain elements.

NFRs as EARS

Specy deliberately avoids a separate NFR grammar. The EARS keywords — While, When, If, Where — are expressive enough to pin down quality attributes without a parallel notation. A latency SLA is just a When with a measurable response. An availability commitment is just a ubiquitous statement. A degraded-mode obligation is just a While scoped to a failure state. Domain elements that realize NFRs reference them via satisfies, exactly like functional requirements.

Example: "When a customer submits an order, the system shall respond within 500 ms at p95." An NFR, measurable, testable, phrased as a plain event-driven EARS statement. “The system shall maintain 99.9% availability measured monthly.” A ubiquitous NFR — no keyword, always active.

NFR Categories & Domain Anchors

Not all NFRs are equal. Some trace directly to domain model elements — an operation, an entity, an infrastructure service. Others are cross-cutting and require broader scoping. The table below classifies NFR categories by where they anchor in the metamodel, and recommends whether they should scope to a bounded context or to the organization.

Example: A performance NFR anchors on an operation: "When a customer submits an order, the OrderContext shall respond within 500 ms at p95." A compliance NFR anchors on an entity and scopes to the organization: "When a personal-data deletion request is received, the platform shall delete the associated customer records within 30 days."

Discovery Heuristic

NFRs are forgotten. Teams remember to capture commands and events; they forget to capture latencies, retention limits, and incident-response targets. The discovery heuristic is a structured questioning routine: ask the same questions at each scope level, and surface NFRs before they become incidents.

• Per operation — latency (p95/p99 target), throughput (invocations per second at peak), idempotency (retry safety), timeout (deadline), authorization (who may invoke), audit (is invocation logged for compliance).
• Per entity — data classification (PII, financial, health), retention (how long kept, when deleted), encryption (at rest, in transit), backup and recovery (RPO, RTO), partitioning (geographic, tenant).
• Per infrastructure service — availability (SLA of the wrapped external system), circuit breaking (stop calling after N failures), fallback (degraded mode, stale-acceptable data), rate limiting (external quota, throttling handling).
• Per bounded context — availability SLA (uptime to consumers), deployment independence (can deploy without coordinating), observability (metrics, logs, traces exposed), incident response (severity classification, escalation path).
• Per organization (cross-cutting) — regulatory compliance (GDPR, PCI-DSS, HIPAA, SOC2), data sovereignty (geographic boundaries), disaster recovery (organization-wide RPO/RTO), security baseline (authentication, encryption, network segmentation), accessibility (WCAG standards).

Example: Running the heuristic on the placeOrder operation yields at least: a latency NFR ("When a customer submits an order, the system shall respond within 500 ms at p95."), an idempotency NFR ("When the same order is submitted twice with identical idempotency keys, the system shall return the existing order."), and an audit NFR ("When an order is placed, the system shall write an audit record to the append-only log.").

Cross-Cutting NFRs

Some NFRs cannot be meaningfully scoped to a single bounded context. “99.9% availability” is an organizational commitment — no single context owns it. “PCI-DSS compliance” spans every context that touches payment card data. “GDPR right to erasure” requires coordinated deletion across multiple bounded contexts.

Specy handles these by extending the scoped-to relation to accept either a bounded context or the organization. Cross-cutting NFRs scope to the organization. The requirement is then owned at the platform level and decomposed into context-level obligations (see the next section).

Example:

requirements "Platform Reliability" scoped-to RideNowOrganization {

  REQ-NFR-001 "Platform availability" : ubiquitous
    :: "Contractual SLA with riders and drivers — breach triggers penalties"
    "The RideNow platform shall maintain 99.9% availability measured
     monthly across all rider-facing and driver-facing services."
    priority must
}

Decomposition into Context Obligations

A cross-cutting NFR at the organization level creates derived obligations on each bounded context it affects. The derivation is explicit: the organization-level requirement declares decomposed-into a list of context-level requirement IDs that collectively satisfy it. Each derived context-level requirement is itself a regular EARS requirement scoped to its bounded context, and domain elements within each BC reference the derived ID via satisfies.

This makes the organizational SLA a collective responsibility — not owned by any single team — and keeps the bridge from the organization-level obligation to running code traversable.

Some cross-cutting NFRs may not be realizable by domain model elements at all — they are satisfied by deployment, networking, or operational tooling below the domain layer. Domain elements that cannot satisfy such a requirement simply do not include its ID in their satisfies list. The requirement is still tracked, still has an owner, still has a priority — the absence of a satisfies reference in the domain model is an honest boundary, not a gap.

Example:

REQ-NFR-001 "Platform availability" : ubiquitous
  scoped-to RideNowOrganization
  priority must
  decomposed-into {
    REQ-RIDE-NFR-001   // Ride Management context availability
    REQ-PAY-NFR-001    // Payment context availability
    REQ-GEO-NFR-001    // Geolocation context availability
    REQ-DRV-NFR-001    // Driver Management context availability
    REQ-RDR-NFR-001    // Rider Management context availability
  }

Cross-Cutting NFRs in the Verification Loops

Cross-cutting NFRs are the primary targets of the Observe loop, and the Build and Check loops treat them with one extra step: the decomposition.

Example: The REQ-NFR-001 platform-availability requirement is satisfied collectively by five context-level derived requirements. The Build loop reads each derived requirement and configures the context’s redundancy and health-check targets. The Check loop confirms each derived ID is either referenced by a domain element or flagged as infrastructure-only. The Observe loop watches the rolling monthly uptime against the 99.9% threshold and fires an alert when drift crosses a pre-set margin.