Skip to Content
DocsNeedsNeeds and Requirements
DRAFT — This document is under development and not yet reviewed.

Needs and Requirements

Updated 15 May 2026

A scaled delivery system responds to two distinct domains.

Needs are directional vectors — what stakeholders want the system to deliver. They are consumed when delivered: once a need has been built, it leaves the system as accomplished work. Needs flow through the Portfolio Kanban, the DVS Feature Kanban, and team-level backlogs as Initiative → Feature → Story. The structure of this flow is described in Needs Hierarchy; this document does not duplicate it.

Requirements are always-active constraints — rules, policies, standards, and obligations that shape work continuously. They are not consumed when delivered; they persist. Every feature and story that flows through the system must respect them. They are not items on the backlog — they are the surrounding conditions within which the backlog operates.

The distinction matters because the two domains have different ownership, different lifecycles, and different content treatment. Conflating them creates two failure modes. Treating requirements as needs puts them on a backlog where they accumulate as unresolvable items. Treating needs as requirements freezes them into specifications before they have been tested against value.

Per ADR-003 in meta/DECISIONS.md.

The Needs Domain

The needs domain contains the work the delivery system actively builds and delivers. It is the substance of the backlogs at every level.

Needs flow through three artifacts:

  • Initiative — at portfolio level. A value hypothesis describing what problem is worth solving, what outcome is expected, and what investment is justified.
  • Feature — at DVS level. A solution hypothesis describing how the DVS will deliver part of the Initiative’s intended value.
  • Story — at team level. A specific testable behavior the team will implement.

Each level carries needs at a different specificity. The hierarchy and its rules are described in Needs Hierarchy.

Ownership: Product Owner / Product Management at DVS level; Initiative Owners and Portfolio Leadership at portfolio level.

The Requirements Domain

The requirements domain contains four categories. They differ in source, lifespan, and ownership — but they share the structural property of being always-active rather than consumed.

1. Domain Requirements (Business Rules)

The stable logic of the domain — rules that describe how the business works, independent of any specific feature.

Examples:

  • Calculation rules (how interest is calculated, how prices are derived)
  • Validation rules (what constitutes a valid order, a valid identity)
  • State transition rules (what states an entity can move through and under what conditions)
  • Authorization logic (who can do what)
  • Decision rules (if X, then Y)

Nature: Stable — they change infrequently, often driven by law, regulation, or business policy Lifespan: Long-lived — they predate and outlast individual features Ownership: Domain experts / business analysts Relationship to needs: A Feature may introduce, modify, or expose a business rule — but the rule is larger than the feature

The critical insight: a business rule is not a story. It is not a feature. It is a domain constraint that features must respect. Embedding business rules inside feature descriptions obscures them — they should be documented and versioned separately.

2. System Requirements (Non-Functional Requirements)

Constraints on how the system behaves — performance, security, availability, scalability, compliance with technical standards.

Examples:

  • Response time under load
  • Data encryption requirements
  • Availability targets (uptime SLAs)
  • Accessibility standards
  • API versioning policy

Nature: Cross-cutting — they apply to all features, not individual ones Lifespan: Long-lived — they evolve with technology and organizational standards Ownership: Architecture / engineering leads Relationship to needs: Every Feature must satisfy the system’s NFRs. When a Feature creates new NFR risk (e.g., a new high-traffic endpoint), that risk must be addressed as part of the Feature’s acceptance criteria.

System requirements are frequently neglected in backlogs because they do not map neatly to individual features. The result is technical debt and production incidents. Making NFRs explicit and governing them separately is a sign of delivery system maturity.

3. Governing Requirements

External obligations — regulatory, legal, contractual, or organizational policy — that constrain what the system may do and how it must behave.

Examples:

  • Data protection regulation (GDPR, local equivalents)
  • Industry-specific regulation (financial services, healthcare, public sector)
  • Contractual SLAs with customers or suppliers
  • Internal architecture and security policies
  • Audit and traceability requirements

Nature: Mandatory — non-compliance carries legal, financial, or reputational consequences Lifespan: Tied to regulation or contract — changes when the external obligation changes Ownership: Legal / compliance / architecture Relationship to needs: Governing requirements constrain what needs may propose. A feature that violates a governing requirement is not deliverable regardless of its business value.

4. Operational Requirements

Requirements for how the system is operated, maintained, and evolved over its lifetime — beyond its initial delivery.

Examples:

  • Monitoring and alerting standards
  • Backup and recovery requirements
  • Incident response procedures
  • Deployment and release constraints
  • End-of-life and data retention policies

Nature: Ongoing — they describe continuous obligations, not one-time changes Lifespan: Active for the life of the system Ownership: Operations / platform / SRE Relationship to needs: Operational requirements may generate needs (e.g., a new monitoring standard requires Features to add instrumentation) — but they are not themselves features.

The Two Domains Together

A complete picture of what a delivery system must do has both domains visible. The needs domain answers what are we building?; the requirements domain answers what conditions must our building satisfy?

Backlog discipline relates to both. Items on the backlog should be needs. Items that violate the requirements domain — or require updating to remain compliant with it — should surface as needs derived from those requirements, not as untracked work or hidden assumptions.

A delivery system that maintains both domains explicitly:

  • Knows what it is building and what is shaping that building
  • Can distinguish a missed feature from a violated constraint
  • Can govern technical debt as a recognized requirement-domain concern rather than as silent erosion
  • Can answer compliance and audit questions without ad hoc investigation
Needs HierarchyFeature