Requirement and Requirement Set are the two first-class structural concepts of the system-requirement layer. A requirement is a named EARS statement with an identity, a justification, and a priority. A requirement set groups related requirements into a coherent unit scoped to a bounded context — typically aligned with a business capability, a use-case cluster, or a module boundary.

Every EARS sentence begins with “the system shall…”, and “the system” is not a metaphor. It is one of the software systems that lives inside a bounded context and makes that context’s domain models live. A requirement is scoped to a bounded context because the system it talks about is one of that context’s systems. This is what lets the requirement layer meet the domain layer: the BC names a shared frame where “the system shall…” (requirement) and “the entity, operation, or invariant guarantees that…” (domain) refer to the same running thing.

Every noun that appears in an EARS sentence — “order”, “rider”, “reservation”, “cancellation fee” — must come from the ubiquitous language of the bounded context the requirement is scoped to. If the requirement says “the rider” and the domain model has only Customer, one of the two is wrong; the EARS layer is unforgiving in that respect, and that strictness is a feature — language drift between requirement and model is caught at write time rather than during integration.

Requirement Anatomy

A requirement is a small, named record. It carries five attributes beyond the universal name, description, and metadata map that every metamodel concept has.

  • id — a unique, stable identifier (for example, REQ-ORD-001). The prefix anchors the requirement to a bounded context or domain area. The identifier never changes, even if the statement is revised. Stability is the whole point: downstream domain elements reference this ID through satisfies, and any renaming would invalidate that bridge.
  • statement — the full EARS sentence, following one of the six patterns. One sentence, one system, one obligation.
  • pattern — one of ubiquitous, state-driven, event-driven, unwanted, optional, complex. Declared explicitly so tooling can validate the statement against the pattern’s canonical form.
  • rationale — why this requirement exists: the business justification. Equivalent to the :: operator on domain constructs. The rationale is not itself verifiable; it explains why the verifiable obligation exists. A rationale like “Regulatory minimum — trade compliance requires explicit quantity” tells a future reader, or a future modeler, what they would break by removing the requirement.
  • priority — a domain-expert-assigned weight using MoSCoW classification (see next section).

Example:

REQ-ORD-001 "Order line quantity floor" : ubiquitous
  :: "Regulatory minimum — trade compliance requires explicit quantity"
  "The system shall reject order lines with a quantity less than one."
  priority must

Priority (MoSCoW)

Every requirement carries exactly one MoSCoW priority. The classification is a shared language between product, engineering, and operations — it decides which requirements block a release and which defer.

  • must — non-negotiable. The system is unacceptable without it. Regulatory, safety, and revenue-critical obligations sit here.
  • should — important but not blocking. The system is degraded without it. A should that slips becomes a follow-up commitment, not a silent omission.
  • could — desirable. Included if effort permits. Nice-to-have experience improvements and convenience features fit here.
  • wont — explicitly excluded from the current scope. Documented to prevent scope creep and to make no a design decision rather than an oversight.

Example: "Where express shipping is available, the system shall offer same-day delivery for orders placed before noon." (REQ-ORD-006) is priority could — a premium feature, only valuable in regions with courier partnerships. A credit-hold requirement like REQ-ORD-005 is priority should — finance wants it, operations can run without it for a quarter.

Requirement Relations

A requirement’s relations connect it to its surrounding context, to its upstream provenance, and to its siblings.

  • 1..1 scoped-to — exactly one bounded context or the organization. Functional requirements scope to a bounded context. Cross-cutting NFRs scope to the organization (see Non-Functional Requirements).
  • 0..1 sourced-from — an external reference: a PRD section, a user story ID, a regulatory clause, or a business goal. This is a provenance marker — it answers who asked for this and why, enabling impact analysis from product strategy change to affected requirements. Paired with the set-level prd-source, the reference is file-resolvable. See Traceability.
  • 0..n depends-on — other requirements that are logical prerequisites. Requirement B cannot be satisfied unless requirement A is satisfied first. "When payment is verified, the system shall confirm the order." (REQ-ORD-007) depends on the order-placement requirement REQ-ORD-002.
  • 0..n conflicts-with — other requirements in explicit tension: both cannot be fully satisfied simultaneously. The model must document the resolution strategy. "When an order is confirmed, the system shall immediately initiate fulfillment." (REQ-ORD-008) conflicts with the credit-hold requirement REQ-ORD-005 — ops wants auto-ship, finance wants credit hold, and the resolution is priority-based.
  • 0..n decomposed-into — other requirements that, together, realize this one. An organization-level NFR typically decomposes into context-level obligations (see Non-Functional Requirements).
  • 0..1 belongs-to — exactly one requirement set, when the requirement is grouped.

Example:

REQ-ORD-008 "Immediate fulfillment" : event-driven
  conflicts-with REQ-ORD-005
  :: "Ops wants auto-ship; Finance wants credit hold — resolved by priority"
  "When an order is confirmed, the system shall immediately
   initiate fulfillment."
  priority should

Requirement Set

A requirement set groups related requirements into a coherent unit — typically aligned with a business capability (“Order Processing”), a use-case cluster, or a module boundary. A set has its own name and carries one optional attribute beyond the standard triplet.

  • prd-source — the relative path to the .prd file that contains the product requirements from which this set’s requirements were derived. When present, the source field on individual requirements references elements inside this file. Multiple prd-source declarations are allowed when product requirements span several files. See PRD Releases & Traceability for how the PRD bridge is consumed.

Example:

requirements "Order Processing" scoped-to OrderContext {
  prd-source "specs/order.prd"

  REQ-ORD-001 "Order line quantity floor" : ubiquitous
    :: "Regulatory minimum — trade compliance requires explicit quantity"
    "The system shall reject order lines with a quantity less than one."
    priority must

  // ... further requirements
}

Set Relations

A requirement set is a small scope object. Its relations pin it to a bounded context and, optionally, to the module whose interface realizes it.

  • 1..n contains — requirements. A set without requirements has no reason to exist.
  • 0..1 maps-to — a module whose interface realizes this set. When the mapping exists, the domain model’s module declaration carries the inverse relation and the satisfies IDs on its exposed operations can be cross-checked against the set’s requirement IDs.
  • 1..1 scoped-to — exactly one bounded context. This is the strongest invariant: a requirement set never spans context boundaries. If an obligation genuinely crosses contexts, it is either a cross-cutting NFR scoped to the organization (see Non-Functional Requirements) or two separate requirements, one per context.

Example: The “Order Processing” set scopes to OrderContext. A requirement set “Payment Capture” would scope to PaymentContext and have its own prd-source. Even when the same PRD governs both, the sets stay separate — each belongs to a single bounded context, and each is realized by that context’s modules.