Requirements Verification - Design Validation | OneNoughtOne

0/273

System Design (HLD)Design Validation

Design Validation

LevelAdvanced

Duration90 mins

TopicDesign Validation

1 / 5

Requirements Verification

The Final Gate Before Implementation

You've completed your high-level design. You have architectural diagrams, component definitions, data flow visualizations, and API contracts. The temptation is strong to declare victory and move to implementation. This is precisely the moment when most projects plant the seeds of their own failure.

Requirements verification is not a bureaucratic checkbox—it's the systematic process of ensuring that every requirement stated at the outset has a clear, traceable satisfaction path within your design. It's the difference between a design that looks complete and one that is complete.

Principal engineers know that the cost of discovering a missing requirement during implementation is 10x higher than discovering it during design review. Discovering it in production? That's 100x or more.

What You Will Master

By the end of this page, you will understand how to systematically verify that a system design satisfies all functional and non-functional requirements. You'll learn to construct traceability matrices, identify requirement gaps, validate completeness across system boundaries, and apply the verification techniques used in mission-critical systems designed by the world's best engineers.

The Verification Imperative

Requirements verification ensures that your design doesn't just look good—it actually solves the problem it was created to solve. This sounds obvious, but in practice, requirements slip through cracks with alarming regularity.

Why requirements get lost:

Translation gaps: Requirements expressed in business language get lost when translated to technical specifications
Implicit assumptions: Stakeholders assume certain capabilities are 'obvious' and don't explicitly state them
Iteration drift: As designs evolve through multiple iterations, early requirements can be inadvertently dropped
Scope creep interference: New requirements added late can obscure or conflict with original ones
Cross-cutting concerns: Non-functional requirements like security and observability often lack clear component ownership

Cost of Requirement Defects by Discovery Phase
Discovery Phase	Relative Cost	Typical Impact	Recovery Time
Requirements gathering	1x	Clarification discussion	Hours
High-level design	3-6x	Design modification	Days
Detailed design	10x	Architecture rework	Weeks
Implementation	15-40x	Code rewrite	Weeks to months
Testing	30-70x	Significant rework	Months
Production	40-1000x	Emergency remediation, customer impact	Months to years

The Exponential Cost Curve

These multipliers aren't arbitrary—they come from decades of software engineering research (Boehm, Barry W. 'Software Engineering Economics'). The message is clear: every hour spent on rigorous requirements verification saves days or weeks downstream. Principal engineers treat verification as investment, not overhead.

Functional Requirements Verification

Functional requirements describe what the system must do—the capabilities, features, and behaviors that users and stakeholders expect. Verifying these requires tracing each requirement to specific design elements.

The Traceability Matrix

A requirements traceability matrix (RTM) is a living document that maps every requirement to its implementing design components. For each functional requirement, you must be able to answer:

Which component(s) implement this requirement?
What APIs/interfaces expose this capability?
What data stores support this functionality?
What happens if this component fails?
How is success/failure of this feature observable?

Example Traceability Matrix: E-Commerce Order System
Requirement ID	Requirement	Implementing Components	Interfaces	Data Stores	Verification Method
FR-001	Users can add items to cart	Cart Service, Inventory Service	POST /cart/items	Cart DB, Inventory Cache	Integration test
FR-002	Users can checkout with payment	Order Service, Payment Gateway, Inventory Service	POST /orders/checkout	Order DB, Payment Ledger	End-to-end test
FR-003	Users receive order confirmation	Notification Service, Order Service	Event: order.confirmed	Notification Queue	Event trace validation
FR-004	Users can track order status	Order Service, Tracking Service	GET /orders/{id}/status	Order DB, Tracking Cache	API contract test
FR-005	Users can cancel orders (pre-shipment)	Order Service, Refund Service, Inventory Service	POST /orders/{id}/cancel	Order DB, Inventory DB	Saga completion test

Walking the Matrix

Once constructed, the traceability matrix must be validated through systematic review:

Forward Tracing: For each requirement, verify that at least one component implements it. Requirements with no implementing component are gaps—the design is incomplete.

Backward Tracing: For each component, verify that it implements at least one requirement. Components that don't trace back to any requirement are either:

Supporting infrastructure (acceptable)
Gold-plating (features nobody asked for—risky)
Misunderstood requirements (dangerous)

Lateral Tracing: For requirements that span multiple components, verify that the integration points are defined and that responsibility boundaries are clear.

Functional Verification Checklist

•Every functional requirement has at least one owning component — No orphaned requirements
•Each requirement has a defined interface — How is this capability invoked?
•Data dependencies are identified — What data must exist for this feature to work?
•Error conditions are specified — What happens when the happy path fails?
•Dependencies between requirements are mapped — Which features must work before others?
•Feature interactions are analyzed — Do any features conflict or interfere with each other?
•Verification method is defined — How will we know the implementation is correct?

Non-Functional Requirements Verification

Non-functional requirements (NFRs) are notoriously difficult to verify because they're often qualitative ('the system should be fast') rather than quantitative ('P99 latency under 200ms'). Principal engineers insist on quantifying NFRs before attempting verification.

The NFR Quantification Process

Every non-functional requirement must be transformed into measurable quality attributes:

NFR Quantification Examples
Vague NFR	Quantified NFR	Verification Approach
The system should be fast	P99 latency < 200ms for all user-facing APIs	Load test with realistic traffic patterns
The system should scale	Handle 10x current load with linear cost increase	Capacity model validation
The system should be reliable	99.9% availability (8.76 hours downtime/year)	Failure mode analysis + redundancy verification
The system should be secure	Pass OWASP Top 10 audit, SOC 2 compliance	Security architecture review + threat model
The system should be maintainable	Mean time to deploy < 15 minutes, rollback < 5 minutes	Deployment architecture review

Architecture-Level NFR Verification

Unlike functional requirements, NFRs are typically cross-cutting—they're satisfied (or violated) by the architecture as a whole, not by individual components. Verification requires examining how architectural decisions support each NFR:

Performance Verification Points

•Critical path analysis — Map the longest request path and sum component latencies
•Caching strategy validation — Verify cache hit rates support latency targets
•Database query patterns — Ensure indexes support expected access patterns
•Network topology — Verify geographic distribution supports latency requirements
•Async vs sync choices — Confirm synchronous paths are minimal
•Resource pooling — DB connections, thread pools sized appropriately

NFR Verification as Design Constraint Validation

Think of NFR verification as checking that your design respects the constraints that drove architectural decisions. If you chose to use a message queue for decoupling, verify that the queue design actually supports the throughput requirements. If you chose a multi-region deployment for availability, verify that regional failover actually achieves the availability target.

Completeness Verification

Beyond verifying that stated requirements are satisfied, you must verify that the design is complete—that it addresses all the concerns necessary for a production system, even if they weren't explicitly stated.

The Unstated Requirements

Stakeholders rarely state requirements like 'the system should be deployable' or 'the system should be debuggable.' These implied requirements are assumed. Principal engineers use checklists to surface these assumptions and verify that the design addresses them.

Implied Requirements Checklist

•Operational Concerns — How is the system deployed? Monitored? Upgraded? Rolled back?
•Observability — Can operators understand system behavior? Are logs, metrics, and traces available?
•Debuggability — Can engineers diagnose problems? Is request tracing available?
•Testability — Can the system be tested in isolation? Are test environments defined?
•Data Management — How is data migrated? Backed up? Restored? Retained/deleted per policy?
•Compliance — Are regulatory requirements (GDPR, HIPAA, PCI-DSS) addressed?
•Cost Model — Is the cost of running the system understood? Are cost controls in place?
•Disaster Recovery — Can the system recover from catastrophic failure? What's the RTO/RPO?
•Capacity Planning — How is capacity monitored? When and how is scaling triggered?
•Security Operations — How are incidents detected? Investigated? Remediated?

System Boundary Completeness

Every system has boundaries—points where it interfaces with external systems, users, or infrastructure. Completeness verification must ensure that all boundary interactions are defined:

User interfaces: All entry points for users are designed
API consumers: External systems that will call your APIs are identified
API dependencies: External systems you call are identified, with fallback strategies
Infrastructure dependencies: Cloud services, databases, message brokers—all with configuration requirements
Operational interfaces: Deployment pipelines, monitoring dashboards, alerting configurations

Converting Mermaid diagram...

Consistency Verification

A complete design can still be inconsistent—containing internal contradictions that would manifest as bugs or architectural conflicts during implementation. Consistency verification identifies these contradictions before they become problems.

Types of Inconsistencies

Common Design Inconsistencies
Inconsistency Type	Example	Detection Method
Behavioral contradiction	Component A expects sync response; Component B only provides async	Interface contract review
Data model mismatch	Order ID is UUID in Service A but integer in Service B	Schema consistency check
Assumption conflict	Service A assumes eventual consistency; Service B assumes strong consistency	Consistency model review
Protocol mismatch	Component A speaks HTTP/1.1; Component B requires gRPC	Technology stack audit
Timing assumptions	Service A expects 100ms response; Service B has 1s SLA	Latency budget analysis
Capacity mismatch	Producer generates 10K events/sec; Consumer handles 1K/sec	Throughput modeling

The Consistency Verification Process

Interface Contract Review: Every interface between components must have matching expectations on both sides. Document request/response schemas, error conditions, timeout behaviors, and retry policies.
Data Model Alignment: Trace each data entity through the system. Verify that identifiers, types, and formats are consistent across service boundaries.
Consistency Model Agreement: When multiple components access shared data, ensure they agree on the consistency model (strong, eventual, causal).
Timing Analysis: Sum up latency budgets along critical paths. If the total exceeds the end-to-end requirement, the design is inconsistent with performance goals.
Capacity Flow Analysis: Trace throughput requirements through the system. Verify that downstream components can handle the load generated upstream.

The Hidden Consistency Killer

The most dangerous inconsistencies are implicit assumptions. Component teams often make assumptions about how they'll be called without documenting them. During verification, force these assumptions to be explicit: 'Service X assumes callers will retry on 503 with exponential backoff.' If callers don't know this, the system will fail under load.

Verification Techniques and Tools

Principal engineers employ a variety of techniques to verify requirements systematically. The choice of technique depends on the complexity of the system and the criticality of the requirements.

Document-Based Techniques

•Traceability Matrices — Formal mapping of requirements to design elements
•Design Review Checklists — Structured verification against known patterns
•Architecture Decision Records (ADRs) — Document why decisions were made
•Interface Specification Documents — Formal contract definitions
•Capacity Models — Spreadsheet-based throughput analysis

Review-Based Techniques

•Architecture Review Boards — Formal review by senior engineers
•Stakeholder Walkthroughs — Present design to requirement owners
•Threat Modeling Sessions — Security-focused review (STRIDE, etc.)
•Failure Mode Analysis — Systematic 'what if' questioning
•Red Team Reviews — Adversarial review to find weaknesses

Automated Verification Approaches

Modern systems can leverage automation for certain verification tasks:

Schema validation: OpenAPI/AsyncAPI schemas can be validated for consistency across services
Contract testing: Tools like Pact can verify that service contracts are compatible
Architecture fitness functions: Automated checks that verify architectural constraints (e.g., 'no service in tier A may directly call tier C')
Dependency analysis: Tools that verify dependency graphs match documented architecture
Configuration validation: Verify that configuration values are consistent across environments

architecture-fitness-function.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
// Example: Architecture fitness function to verify tiered access rules
interface ServiceDependency {
  source: string;
  target: string;
  tier: 'presentation' | 'application' | 'domain' | 'infrastructure';
}
 
interface ServiceMetadata {
  name: string;
  tier: 'presentation' | 'application' | 'domain' | 'infrastructure';
}
 
const TIER_ORDER = {
  'presentation': 0,
  'application': 1,
  'domain': 2,
  'infrastructure': 3,
} as const;
 
function verifyTieredArchitecture(
  services: ServiceMetadata[],
  dependencies: ServiceDependency[]
): { valid: boolean; violations: string[] } {
  const serviceMap = new Map(services.map(s => [s.name, s]));
  const violations: string[] = [];
  
  for (const dep of dependencies) {
    const source = serviceMap.get(dep.source);
    const target = serviceMap.get(dep.target);
    
    if (!source || !target) {
      violations.push(`Unknown service in dependency: ${dep.source} -> ${dep.target}`);
      continue;
    }
    
    // Rule: Services can only depend on same tier or lower tiers
    if (TIER_ORDER[source.tier] > TIER_ORDER[target.tier]) {
      violations.push(
        `Tier violation: ${source.name} (${source.tier}) cannot depend on ` +
        `${target.name} (${target.tier}) - lower tiers cannot call higher tiers`
      );
    }
    
    // Rule: Presentation tier cannot directly access infrastructure tier
    if (source.tier === 'presentation' && target.tier === 'infrastructure') {
      violations.push(
        `Layer skip violation: ${source.name} (presentation) cannot directly ` +
        `access ${target.name} (infrastructure) - must go through application layer`
      );
    }
  }
  
  return {
    valid: violations.length === 0,
    violations,
  };
}
 
// Usage in CI/CD pipeline
const services: ServiceMetadata[] = [
  { name: 'web-gateway', tier: 'presentation' },
  { name: 'order-service', tier: 'application' },
  { name: 'inventory-domain', tier: 'domain' },
  { name: 'postgres-adapter', tier: 'infrastructure' },
];
 
const dependencies: ServiceDependency[] = [
  { source: 'web-gateway', target: 'order-service', tier: 'application' },
  { source: 'order-service', target: 'inventory-domain', tier: 'domain' },
  { source: 'inventory-domain', target: 'postgres-adapter', tier: 'infrastructure' },
  // This would be a violation if uncommented:
  // { source: 'web-gateway', target: 'postgres-adapter', tier: 'infrastructure' },
];
 
const result = verifyTieredArchitecture(services, dependencies);
console.log('Architecture valid:', result.valid);
if (!result.valid) {
  console.error('Violations:', result.violations);
  process.exit(1);
}

The Verification Gate

Requirements verification should be treated as a gate—a formal checkpoint that must be passed before proceeding to detailed design or implementation. This isn't bureaucracy; it's risk management.

Gate Criteria

A design passes the verification gate when:

Verification Gate Criteria

•All functional requirements trace to implementing components — No orphaned requirements
•All non-functional requirements are quantified and verifiable — No vague quality attributes
•The traceability matrix is complete and reviewed — Stakeholders agree the coverage is adequate
•Implied requirements have been surfaced and addressed — Operational, observability, compliance concerns covered
•No unresolved consistency issues — Interface contracts align, timing budgets balance
•Known gaps are documented with mitigation plans — If something is intentionally deferred, it's explicit
•Verification method is defined for each requirement — How will we know implementation is correct?

When Verification Fails

Failing the verification gate is not failure—it's success. You've discovered a problem before it became expensive. When verification identifies gaps:

Document the gap clearly: What requirement is unsatisfied? What's missing?
Assess impact: Is this a blocking issue or a known risk we can accept?
Return to design: Modify the design to address the gap
Re-verify: Confirm the modification satisfies the requirement without breaking others

The Verification Mindset

Principal engineers approach verification with intellectual honesty. They actively look for what's wrong, not confirmation of what's right. They ask 'What did we miss?' not 'Can we check this off?' This adversarial mindset is what separates designs that survive production from designs that fail under real-world pressure.

Summary: Requirements Verification

Requirements verification is the systematic process of ensuring that your design actually solves the problem it was created to solve. It bridges the gap between 'design that looks complete' and 'design that is complete.'

Key Takeaways

•The cost of requirement defects grows exponentially — An hour of verification saves days of rework
•Traceability matrices are essential — Every requirement must map to implementing components
•NFRs must be quantified to be verifiable — 'Fast' means nothing; 'P99 < 200ms' is verifiable
•Completeness includes unstated requirements — Operational concerns, observability, compliance
•Consistency verification catches hidden conflicts — Interface mismatches, timing contradictions
•Verification is a gate, not a checkbox — Formal criteria determine passage
•Finding gaps is success — Better now than in production

What's Next

With requirements verified, we turn to the next validation dimension: bottleneck analysis. A design can satisfy all requirements on paper while containing hidden capacity constraints that will cause failure under load. The next page explores how to identify and address these bottlenecks before they become production incidents.

Page Complete

You now understand how to systematically verify that a system design satisfies all stated and implied requirements. You can construct traceability matrices, identify gaps, verify consistency, and apply the verification techniques used by principal engineers in mission-critical systems. Next, we'll examine how to analyze your design for performance bottlenecks.