14. Requirements-to-Delivery Lifecycle: FR, NFR, Constraints, ADR, and TIP
Requirements are not finished when they are written. They stay traceable through design, decisions, implementation, verification, deployment, and operation. ISO/IEC/IEEE 29148 treats requirements engineering as a life-cycle activity. NASA guidance adds explicit requirement quality, traceability, and verification practices. Microsoft guidance connects business requirements, architecture specifications, engineering work items, testing, and ongoing operation.
Evidence: S46, S47, S49, S50, S53
14.1 The full cycle
Requirements-to-delivery lifecycle.
Diagram loads as you approach it.
The key idea is bidirectional traceability: requirements point forward to design and proof, while implementation and decisions point backward to the requirement, constraint, assumption, or risk that justified them.
Evidence: S46, S47, S49, S50, S53
14.2 Functional requirements (FR) — full cycle
FRs describe required behavior for a user, business process, or another system. They should be clear enough to design, implement, and verify. A user-story sentence can be useful for planning, but it is not a substitute for important business rules, data rules, error behavior, or integration semantics when those details affect correctness.
Discover: identify the business outcome, actors, triggers, rules, data, dependencies, and unhappy paths.
Clarify: remove ambiguity and separate assumptions from confirmed requirements.
Specify: give important requirements a stable identifier and define observable acceptance/verification conditions.
Validate: review correctness, completeness, consistency, feasibility, and ambiguity with relevant stakeholders.
Design: map the FR to components, APIs, data, workflows, and any architecturally significant decisions.
Implement: create traceable work items and keep deviations visible rather than silently drifting from the approved design.
Verify: prove the requirement by test, analysis, inspection, demonstration, or another appropriate method.
Release and observe: confirm the real user flow works and use incidents/feedback to refine future requirements.
FR vs acceptance criteria
An FR states required system behavior. Acceptance criteria are concrete conditions used to prove a story, feature, or requirement. They are related, but they are not the same artifact.
Evidence: S46, S47, S49, S50, S53
FR minimum checklist
Business outcome and user/system actor are clear.
Requirement has a stable ID or traceable work-item identity.
Source/owner and rationale are known for important requirements.
Trigger, normal flow, error flow, and important business rules are clear.
Inputs, outputs, data ownership, and external dependencies are known.
Acceptance criteria or verification method are observable and testable.
Out-of-scope behavior is explicit when ambiguity is likely.
The requirement has priority/change authority.
Assumptions are explicit and confirmed before they become part of the baseline.
The design and work items link back to the FR.
Verification evidence links back to the FR or its acceptance criteria.
Any implementation deviation is reviewed and reflected in the requirement/design/ADR as appropriate.
14.3 Nonfunctional requirements (NFR) — full cycle
In this book, NFR means a measurable quality requirement: how well a named system or critical flow must operate. Examples include availability, latency, throughput, recovery, security, scalability, privacy, and operability. Cost can also be a measurable design target. Fixed mandates are tracked as constraints rather than hidden inside the NFR list.
Evidence: S1, S2, S23, S31, S46, S51, S53
A practical NFR format
For <critical flow>, measure <metric> at <measurement point>. Target <threshold> under <load/conditions> during <observation window>. Verify with <test method> and monitor with <production signal>.
Example: “For the checkout API, p95 server latency must stay below 500 ms at 100 requests/second for 15 minutes, with an error rate below 1%. Verify in a load test and monitor the same signals in production.”
Discover: identify which quality attributes matter for each critical user/system flow.
Quantify: add metric, target, load/conditions, measurement point, and time window.
Prioritize: decide which NFRs are hard targets and which can be traded against cost, complexity, or time.
Design: use NFRs to drive capacity, resilience, security, data, deployment, and observability decisions.
Record decisions: create ADRs when meeting an NFR requires a significant or difficult-to-reverse architectural choice.
Plan verification: define load, resilience, security, recovery, or operational tests before implementation is considered done.
Observe: map ongoing NFRs to production telemetry, SLIs/SLOs, alerts, or periodic exercises.
Revisit: if real traffic, business criticality, incidents, or cost assumptions change, review both the NFR and the design.
Evidence: S2, S23, S31, S47, S50, S51, S53
NFR minimum checklist
NFR applies to a named system or flow, not vaguely to everything.
Metric is defined.
Target/threshold is defined.
Load, failure, geography, data volume, or other relevant conditions are defined.
Measurement point and observation window are defined.
Trade-off priority is understood.
Architecture choices that exist mainly to satisfy the NFR are traceable.
A pre-production verification method exists.
A production signal exists where ongoing compliance matters.
The NFR is reviewed when assumptions or criticality change.
14.4 Constraints and assumptions
Constraints are boundaries the design must respect, such as a mandated platform, legal/data-residency rule, fixed integration protocol, budget ceiling, or delivery deadline. Assumptions are unproven statements used to move the design forward. They are useful, but dangerous when they silently become “facts.”
Constraint and assumption checklist
Each important constraint has a source/owner and is truly fixed rather than a preference.
Conflicting constraints are escalated instead of hidden in the design.
Each important assumption states what evidence would confirm or reject it.
Assumptions have an owner and a revisit trigger/date when the risk is material.
Architecture decisions identify which assumptions they depend on.
A disproved assumption triggers requirement/design/ADR review rather than silent implementation drift.
Design/ADRs, work items, rollout, rollback/roll-forward, tests
Verification evidence
How do we prove it?
FR/acceptance criteria and NFR targets
Telemetry / SLO
Does it still work as required in production?
NFR/critical flow and operational owner
Evidence: S46, S47, S49, S50, S53
14.6 ADRs — use them for decisions, not for everything
An ADR records an architecturally significant decision and why it was made. Microsoft recommends ADRs for choices that affect system structure, key quality attributes, or are difficult to reverse. An ADR should contain context, options, the decision, important trade-offs, confidence/assumptions, and status. Keep accepted ADRs as history; when a decision changes, create a new ADR that supersedes the old one instead of rewriting the past.
Evidence: S48, S52
Create an ADR when…
The choice changes system boundaries, data ownership, integration style, deployment topology, or a major technology.
The choice exists mainly to satisfy an important NFR such as availability, consistency, security, recovery, or scale.
The decision has meaningful trade-offs or rejected alternatives that future engineers need to understand.
The decision is expensive, risky, cross-team, or difficult to reverse.
A previous accepted architecture decision must change.
ADR lifecycle
Proposed: context, requirements, options, trade-offs, assumptions, and recommendation are written.
Reviewed: relevant stakeholders challenge assumptions and consequences.
Accepted: decision becomes the current architectural direction.
Linked implementation/validation evidence: work items, TIP/technical specification, tests, and production evidence show whether the assumptions held. This does not have to be a formal ADR status.
Superseded: a new ADR replaces the old decision while preserving history and links.
Do not turn an ADR into a design document
The ADR explains the significant choice and rationale. Detailed diagrams and implementation steps belong in the architecture/technical design and TIP or technical specification. Link them instead of duplicating them.
14.7 TIP — Technical Implementation Plan
Terminology note
“TIP” is not a universal industry-standard acronym. In this book, TIP means Technical Implementation Plan: the implementation-ready plan that translates approved requirements, design, and ADRs into a safe sequence of engineering work. Other teams might call the same artifact a technical specification, implementation plan, engineering plan, or detailed technical design. Microsoft uses the closely related term “technical specification” for the engineering plan-of-record.
Evidence: S47, S49
A TIP should be detailed enough that developers, QA, DevOps, security, and operations can understand what changes, in what order, how it is verified, and how it is released or reversed. It should not silently reopen settled architecture decisions. If implementation exposes a broken assumption or requires a new architecturally significant decision, review/supersede the ADR and then align the TIP.
TIP minimum contents
Scope and links to FRs, NFRs, constraints, architecture/TD, and relevant ADRs.
Assumptions, prerequisites, dependencies, and known constraints.
Impacted components, APIs/contracts, data stores, infrastructure, and configuration.
Implementation sequence and dependencies between work items.
Database/schema migration, data backfill, compatibility, and cleanup steps where relevant.
Security/identity/network changes and required permissions where relevant.
Feature flags or compatibility strategy for mixed old/new versions where relevant.
Test plan: unit, integration, contract, E2E, performance, resilience, security, and recovery tests as required by risk/NFRs.
Observability changes: logs, metrics, traces, alerts, dashboards, and health checks.
Deployment/rollout plan, success gates, rollback or roll-forward path.
Operational/runbook changes and ownership.
Risks, open questions, decisions still needed, and explicit N/A items.
Evidence: S47, S49, S55
TIP lifecycle
Draft after the design is stable enough to implement.
Review with the people who will build, test, deploy, secure, and operate the change.
Break the TIP into traceable work items without losing the end-to-end sequence.
Update implementation detail when reality changes; do not silently change architecture intent.
If implementation requires a new significant architecture choice, create/supersede the ADR and then align the TIP.
Before release, verify that all planned FR/NFR checks, constraint checks, and operational prerequisites are complete.
After release, compare production evidence with the assumptions and NFR targets.
Evidence: S47, S49, S50, S55
TIP — short template
Table · scroll horizontally when needed
Section
What to write
Goal / scope
What change are we delivering and what is explicitly out of scope?
Traceability
FR/NFR/constraint IDs, TD/design links, ADR IDs, main work item.
Current → target
What exists now and what will be true after implementation?