Part 5: Requirements, Specifications & the WRSPM Model

Introduction — Why Requirements Matter

Here is a statistic that should alarm every software professional: according to the Standish Group's CHAOS Report, over 60% of software project failures trace back not to bad code, not to poor architecture, not to infrastructure problems — but to requirements issues. Incomplete requirements. Ambiguous requirements. Wrong requirements. Missing requirements.

The cost multiplier is devastating. A requirements error caught during the requirements phase itself costs roughly $1 to fix. Caught during design, it costs $5. During coding, $10. During testing, $20. In production? $100 to $1,000. This is the famous "1-10-100" rule, validated repeatedly by researchers from Barry Boehm (1981) to modern empirical studies.

The Requirements Gap

The requirements gap is the distance between what stakeholders actually need and what the development team actually builds. This gap exists because:

• Stakeholders can't articulate what they want — they know it when they see it, but they can't describe it precisely in advance
• Engineers assume context — they fill in gaps with their own assumptions, often incorrectly
• Language is inherently ambiguous — the word "fast" means something different to a UX designer, a database administrator, and an end user
• Requirements change — the business environment shifts, competitors launch new features, regulations evolve
• Translation loss — every time requirements pass from one person to another (stakeholder → analyst → architect → developer), information degrades

flowchart LR
    A[What stakeholders
actually need] --> B[What stakeholders
say they want]
    B --> C[What analysts
document]
    C --> D[What architects
design]
    D --> E[What developers
build]
    E --> F[What users
actually get]

    style A fill:#3B9797,color:#fff
    style F fill:#BF092F,color:#fff
                            

At every arrow in this diagram, information is lost, assumptions are injected, and the gap widens. Requirements engineering exists to minimise this gap systematically.

What Are Requirements?

Requirements answer the question: "What should the system do?" — not "How should the system do it?" This distinction is fundamental. Requirements live in the problem space; solutions live in the solution space.

Consider these examples:

• Requirement: "Customers must be able to track their order status in real time."
• NOT a requirement: "The system shall use WebSockets to push order status updates to a React frontend component."

The first describes a user need. The second describes an implementation decision. Both are valid and necessary — but they belong in different documents, are owned by different people, and change for different reasons.

The Bridge Metaphor

Think of requirements as a bridge between two worlds that speak different languages:

• The Business World — speaks in terms of revenue, customers, compliance, competitive advantage, user satisfaction
• The Engineering World — speaks in terms of APIs, databases, latency, throughput, error handling, scalability

Requirements are the translation layer. They take business intent and express it in terms precise enough for engineers to build against, while remaining understandable to business stakeholders. This dual-audience nature is what makes requirements hard.

Requirements vs Specifications

Many engineers use "requirements" and "specifications" interchangeably. This is a mistake that leads to confusion, scope creep, and miscommunication. They are different artefacts with different purposes.

A requirement says what the user needs. A specification says precisely how the system will satisfy that need at the boundary between the system and its environment.

Here is a concrete example:

Notice the leap in precision. The specification adds timing constraints, security properties, rate limiting, and specific trigger conditions — all of which are engineering decisions that refine the original user need.

Comparison Across Dimensions

Functional vs Non-Functional Requirements

Requirements divide into two fundamental categories: functional (what the system does) and non-functional (how well the system does it). This distinction shapes architecture, testing strategies, and project priorities.

Functional Requirements

Functional requirements describe specific behaviours or functions of the system — the features users interact with directly. They answer: "What should the system do when X happens?"

• Users can create an account with email and password
• The system processes credit card payments via Stripe
• Administrators can export reports as CSV files
• The search function returns results ranked by relevance
• Users receive email notifications when their order ships

Non-Functional Requirements (Quality Attributes)

Non-functional requirements (NFRs) describe qualities or constraints on how the system performs its functions. They are often called "quality attributes" or "-ilities" (reliability, scalability, maintainability, etc.).

The FURPS+ Model

Hewlett-Packard developed FURPS+ as a comprehensive classification system for requirements. It remains widely used in enterprise software:

• F — Functionality (features, capabilities, security)
• U — Usability (aesthetics, consistency, documentation, responsiveness)
• R — Reliability (availability, failure rate, recoverability, predictability)
• P — Performance (speed, throughput, capacity, resource consumption)
• S — Supportability (testability, extensibility, adaptability, maintainability, configurability)
• + — Design constraints, implementation constraints, interface requirements, physical requirements

The "+" covers constraints that don't fit neatly into the five categories — things like "must use Java 17", "must integrate with SAP", or "must run on hardware with ≤ 512MB RAM".

Requirements Elicitation Techniques

Elicitation is the process of drawing out requirements from stakeholders, domain experts, and existing systems. It's harder than it sounds — stakeholders often don't know what they need, can't articulate what they know, or disagree with each other.

Choosing the Right Technique

In practice, you combine multiple techniques. A typical elicitation strategy might look like:

1. Domain analysis first — understand the landscape before talking to people
2. Interviews with key stakeholders — build rapport, uncover high-level needs
3. Workshops to resolve conflicts between stakeholder groups
4. Prototyping to validate understanding — "Is this what you meant?"
5. User stories or use cases to document agreed requirements
6. Observation to catch what people forgot to mention

The WRSPM Reference Model

The WRSPM model (pronounced "wrist-pm") is a formal reference framework from requirements engineering that clarifies where requirements fit in the relationship between the real world and software. It was developed by Gunter, Gunter, Jackson, and Zave (2000) and remains one of the most rigorous ways to think about what requirements really mean.

The Five Layers

W — World (Domain/Environment): The real-world environment in which the system operates. This includes physical laws, business rules, human behaviour, organisational policies, and domain knowledge that exists independently of the software. World assumptions are things we take for granted — gravity exists, users have email addresses, banks close on weekends.

R — Requirements: What stakeholders need the system to achieve in the world. Requirements describe desired changes to the world state. "Customers can track their packages" is a requirement — it describes something that should be true in the world.

S — Specifications: The precise description of system behaviour at the interface boundary between the software and the environment. Specifications describe what the system does in response to inputs and what outputs it produces — expressed solely in terms of phenomena observable at that interface.

P — Program (Software): The actual implementation — source code, algorithms, data structures, frameworks. The program is the engineer's creation that (hopefully) satisfies the specification.

M — Machine (Hardware/Platform): The computing platform on which the program executes — servers, operating systems, networks, devices. Machine properties include processing speed, memory limits, network latency, and failure modes.

flowchart LR
    W["W
World
(Environment)"] <--> R["R
Requirements
(Stakeholder Needs)"]
    R <--> S["S
Specifications
(System Interface)"]
    S <--> P["P
Program
(Software)"]
    P <--> M["M
Machine
(Hardware)"]

    style W fill:#3B9797,color:#fff
    style R fill:#16476A,color:#fff
    style S fill:#132440,color:#fff
    style P fill:#BF092F,color:#fff
    style M fill:#666666,color:#fff
                            

The Key Insight: Separation of Concerns

The power of WRSPM is that it forces you to ask: Which layer am I working in right now? Problems arise when layers are conflated:

• Confusing R with S: Writing specifications when you should be understanding requirements (premature solution design)
• Confusing W with R: Treating domain assumptions as requirements (they're not — they're givens)
• Confusing S with P: Putting implementation details in specifications (over-constraining the solution)
• Ignoring W: Building a system that works perfectly in theory but fails in the real world because world assumptions were wrong

Variables and Interfaces

WRSPM introduces four types of variables that describe how information flows between the world and the machine:

The distinction between monitored/controlled and input/output variables is crucial. Monitored and controlled variables exist in the world — they're real physical phenomena. Input and output variables exist at the machine interface — they're digital representations. The gap between them is where sensors, actuators, and physical constraints live.

Concrete Example: Smart Thermostat

flowchart TD
    subgraph World
        A[Room Temperature
Monitored Variable]
        B[Heater State
Controlled Variable]
        C[User Comfort
Preference]
    end
    subgraph Interface
        D[Sensor Reading
Input Variable]
        E[Relay Signal
Output Variable]
        F[API Request
Input Variable]
    end
    subgraph Machine
        G[PID Algorithm]
        H[Schedule Engine]
        I[REST API Server]
    end

    A -->|DHT22 Sensor| D
    D --> G
    G --> E
    E -->|Relay Module| B
    C -->|Mobile App| F
    F --> H
    H --> G
                            

Notice how the world assumptions (thermal mass, lag time) affect the specification (±1°C tolerance, 0.5°C hysteresis). If we ignored the world — for instance, assuming instant heating — our specification and program would fail in reality.

WRSPM Applied: Real-World Systems

Example 1: ATM System

Where WRSPM catches gaps: Consider the world assumption "physical cash exists in denominations." If the ATM only stocks £20 notes, a customer requesting £30 cannot be served — even though the requirement ("withdraw cash") is met and the software is correct. The gap is between W (available denominations) and R (any amount withdrawal). Without explicitly modelling the world, this gap hides until deployment.

Example 2: Ride-Sharing Application

Where WRSPM catches gaps: The world assumption "GPS has ±5m accuracy" directly impacts the specification. If the matching algorithm assumes exact driver positions, it will make poor matches in areas with GPS inaccuracy (tunnels, downtown high-rises). By explicitly modelling the world, the specification accounts for location uncertainty — perhaps requiring drivers to confirm they've arrived rather than relying purely on GPS proximity.

Requirements Documentation

Once requirements are elicited and analysed, they must be documented in a form that's accessible, unambiguous, and maintainable.

The Software Requirements Specification (SRS)

The IEEE 830-1998 standard (now superseded by ISO/IEC/IEEE 29148:2018) defined the classic SRS document structure:

1. Introduction — Purpose, scope, definitions, references, overview
2. Overall Description — Product perspective, functions, user characteristics, constraints, assumptions
3. Specific Requirements — Functional requirements, non-functional requirements, interface requirements
4. Appendices — Supporting information, analysis models

While formal SRS documents are still used in regulated industries (aerospace, medical devices, defence), most modern software teams use lighter-weight alternatives.

Modern Alternatives

User Stories with Acceptance Criteria:

Story: As a customer, I want to reset my password so that I can 
       regain access to my account.

Acceptance Criteria:
  - Given I am on the login page
    When I click "Forgot Password"
    Then I see a form asking for my email address

  - Given I enter a registered email address
    When I submit the form
    Then I receive a password reset email within 2 minutes

  - Given I click the reset link in the email
    When the link is less than 30 minutes old
    Then I can set a new password

  - Given I click the reset link in the email
    When the link is more than 30 minutes old
    Then I see an "expired link" message with option to request again

BDD (Behaviour-Driven Development) Format:

# Feature: Password Reset
# Scenario: Successful password reset request

Given the user "john@example.com" has a registered account
And the user is on the login page
When the user clicks "Forgot Password"
And enters "john@example.com" in the email field
And clicks "Send Reset Link"
Then the system sends a password reset email to "john@example.com"
And the email contains a unique token valid for 30 minutes
And the system displays "Check your email for reset instructions"

Decision Records (ADRs) for NFRs:

{
  "title": "ADR-007: Response Time Requirements",
  "status": "accepted",
  "context": "Users report frustration with page load times. Analytics show 40% bounce rate when pages take >3s.",
  "decision": "All API endpoints must respond within 200ms at P95. Page loads must complete within 2s on 4G connections.",
  "consequences": "Requires caching layer, CDN for static assets, database query optimisation. May limit feature complexity per page."
}

Requirements Validation

Validation ensures that documented requirements actually represent what stakeholders need and that they're of sufficient quality to build against. The "VCCUUT" qualities of good requirements are:

Validation Techniques

• Requirements Reviews: Formal inspections where stakeholders, analysts, and engineers walk through requirements together, checking for completeness and consistency
• Prototyping: Building throwaway or evolutionary prototypes to validate understanding — "Is this what you meant?"
• Model Validation: Using formal models (state machines, sequence diagrams, Petri nets) to check for impossible states or deadlocks
• Test-First Validation: Writing acceptance tests before implementation — if you can't write a test, the requirement isn't clear enough
• Traceability Matrices: Mapping every requirement to its source (business need) and its verification method (test case)

Common Requirements Pitfalls

After decades of requirements engineering practice, the same failure patterns repeat across organisations and industries:

1. Scope Creep

Requirements grow continuously without corresponding adjustments to timeline, budget, or team size. Each individual addition seems small, but cumulatively they transform the project. The antidote: a formal change control process and a definition of "done" for the requirements phase.

2. Gold Plating

Engineers adding features that weren't requested because they seem "obvious" or "cool." This wastes effort and complicates testing. The antidote: strict adherence to documented requirements — if it's not written down, it doesn't get built.

3. Ambiguous Language

4. Missing Non-Functional Requirements

Teams document what the system does but not how well it should do it. Performance, security, scalability, and maintainability requirements are left implicit — which means they're left to individual developers' judgement (which varies wildly).

5. Assumption Bias

Both stakeholders and engineers bring assumptions from their previous experience. A stakeholder who previously used System A assumes the new system will work similarly. An engineer who previously built microservices assumes the new system needs them. These assumptions go unexamined until they clash with reality.

6. Stakeholder Conflicts

Different stakeholders want different things. Sales wants features fast. Security wants everything locked down. Operations wants simplicity. Finance wants cost minimisation. Without explicit conflict resolution, requirements become contradictory.

7. Requirements Churn

Requirements changing faster than the team can implement them. This indicates either premature implementation (building before requirements are stable) or a genuinely volatile domain (where iterative/agile approaches are essential).

AI-Enhanced Requirements Engineering

Large Language Models and AI tools are beginning to augment (not replace) requirements engineering practices. Here's how practitioners are using them today:

• Generating acceptance criteria from user stories: Given a user story, AI can generate comprehensive Given/When/Then scenarios including edge cases that humans often miss
• Ambiguity detection: AI can flag vague language ("should be fast", "many users") and suggest quantitative alternatives
• Completeness checking: AI can identify categories of requirements that are missing — "You have performance requirements but no security or accessibility requirements"
• Consistency analysis: AI can detect contradictions between requirements documents written by different teams
• Test case generation: AI can generate test cases directly from specifications, improving requirements-to-test traceability
• Requirements rewriting: Converting informal stakeholder language into structured, testable specifications

Exercises

Conclusion & Next Steps

Requirements engineering is where software projects are won or lost. The WRSPM model gives you a rigorous framework for understanding where requirements sit in the chain from real-world needs to running software. By separating world assumptions from requirements, requirements from specifications, and specifications from implementation, you prevent the most common and costly class of software failures.

Key takeaways from this article:

• Requirements ≠ specifications — requirements describe what stakeholders need; specifications describe precise system behaviour
• Non-functional requirements often matter more than functional ones for system success
• The WRSPM model separates World, Requirements, Specifications, Program, and Machine into distinct layers with clear interfaces
• Monitored and controlled variables bridge the gap between the physical world and the digital system
• Validation ensures requirements are complete, consistent, unambiguous, verifiable, and traceable
• Ambiguous language is the enemy — always quantify, always ask "how would we test this?"