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.

The Requirements Engineering Frameworks Landscape

WRSPM is the primary reference model for this article — but it sits within a rich ecosystem of frameworks, each approaching the requirements problem from a different angle. Some use formal mathematics to prove correctness; others use visual models, agile backlogs, or goal hierarchies. Understanding the landscape lets you choose the right tool for your context — or combine tools from multiple traditions.

The frameworks organise into four broad categories:

Formal & Academic Reference Models

Formal reference models apply mathematical rigour to requirements engineering — using logic, set theory, and formal semantics to make requirements reasoning precise and verifiable. They dominate in safety-critical domains where ambiguity is unacceptable.

The Four-Variable Model (Parnas & Madey)

Published by David Parnas and Jan Madey in 1995, the Four-Variable Model predates WRSPM and provides a mathematical framework for understanding how software systems relate to their environment. It defines four sets of variables:

• Monitored (MON): Environmental quantities the system observes but cannot change — temperature, pressure, user inputs, arriving packets
• Controlled (CON): Environmental quantities the system changes — actuator positions, display content, output files, signals sent
• Input (IN): Digital representations of monitored variables as seen by the program — the ADC reading, the parsed HTTP request
• Output (OUT): Digital representations of what the program sends to the environment — the control word written to a register, the HTTP response bytes

The model expresses four fundamental relationships:

flowchart TD
    MON["Monitored Variables"]
    IN["Input Variables"]
    SOFT["SOFT — Software"]
    OUT["Output Variables"]
    CON["Controlled Variables"]
    MON -->|"NAT: Physical sensing"| IN
    IN --> SOFT
    SOFT --> OUT
    OUT -->|"NAT': Physical actuation"| CON
    MON -.->|"REQ: desired relationship"| CON
    style MON fill:#3B9797,color:#fff
    style IN fill:#16476A,color:#fff
    style SOFT fill:#BF092F,color:#fff
    style OUT fill:#16476A,color:#fff
    style CON fill:#3B9797,color:#fff
                            

Compared to WRSPM, the Four-Variable Model focuses specifically on the sensing and actuation relationships between world and machine. Where WRSPM's W layer captures the entire domain context, the Four-Variable Model drills into the precise mathematical relationships between observed phenomena and system actions — making it the preferred foundation for formally verified real-time control systems.

The Twin Peaks Model (Nuseibeh)

Bashar Nuseibeh proposed the Twin Peaks model in 2001 to address a fundamental weakness in linear requirements engineering: the assumption that requirements must be complete before architecture begins. He observed that in practice, requirements and architectural design must evolve together in progressive feedback loops.

flowchart LR
    R1["Requirements v1"] -->|"Arch constraints"| A1["Architecture v1"]
    A1 -->|"Reveals req gaps"| R2["Requirements v2"]
    R2 -->|"Refines arch"| A2["Architecture v2"]
    A2 -->|"Validates feasibility"| R3["Requirements v3"]
    R3 -->|"Finalises design"| A3["Architecture v3"]
    style R1 fill:#16476A,color:#fff
    style R2 fill:#16476A,color:#fff
    style R3 fill:#16476A,color:#fff
    style A1 fill:#3B9797,color:#fff
    style A2 fill:#3B9797,color:#fff
    style A3 fill:#3B9797,color:#fff
                            

The Twin Peaks model has strong practical support. It aligns with the reality of agile development — where sprints involve both refining requirements and designing architecture — and with modern systems engineering practices like iterative prototyping and architectural spikes.

Where it complements WRSPM: WRSPM defines the layers (W, R, S, P, M) and their logical relationships at a point in time. Twin Peaks describes the process by which those layers are populated and refined. You can apply WRSPM to understand what layer you're working in, while Twin Peaks explains how you move between those layers iteratively over multiple sprints.

KAOS: Goal-Oriented Requirements Engineering

KAOS (Keep All Objectives Satisfied) is a formal goal-oriented requirements engineering framework. Where WRSPM starts from the environment and asks "what phenomena must the system monitor and control?", KAOS starts from strategic objectives and asks "what goals must the system achieve, and how do we decompose them into precise requirements?"

KAOS structures requirements around a goal refinement tree:

• Goals — High-level objectives expressed in linear temporal logic: "The train shall always stop before a closed barrier"
• Sub-goals — Refined decompositions (AND/OR) until goals are assigned to individual agents
• Agents — Components responsible for satisfying goals (software components, humans, devices)
• Operations — Behaviours of agents that satisfy assigned goals
• Obstacles — Conditions that prevent goal achievement, used for safety hazard analysis

flowchart TD
    G0["Passengers reach destinations safely"]
    G0 -->|"AND"| G1["Train stops when obstacle detected"]
    G0 -->|"AND"| G2["Speed stays within limits"]
    G1 -->|"AND"| G3["Obstacle sensor reports hazards within 500ms"]
    G1 -->|"AND"| G4["Brake system activates within 200ms"]
    G2 -->|"ASSIGN TO"| G5["Agent: Speed Controller"]
    G3 -->|"OBSTACLE"| O1["Obstacle: Sensor blocked by debris"]
    O1 -->|"RESOLUTION"| G3
    style G0 fill:#132440,color:#fff
    style G1 fill:#16476A,color:#fff
    style G2 fill:#16476A,color:#fff
    style G3 fill:#3B9797,color:#fff
    style G4 fill:#3B9797,color:#fff
    style G5 fill:#BF092F,color:#fff
    style O1 fill:#666666,color:#fff
                            

KAOS is particularly powerful for safety and security requirements — the obstacle analysis forces engineers to enumerate what could go wrong, producing a comprehensive hazard register alongside the requirements. Industrial tools like DOORS and ObJECTive KAOS support KAOS modelling at scale. The Trace-Based Reification Model extends KAOS by using execution traces and reachability rules to formally verify that goal refinements are mathematically consistent with the WRSPM chain.

Methodological & Conceptual Alternatives

While formal models focus on mathematical rigour, methodological frameworks focus on how to structure the thinking process around requirements — how to decompose a problem, how to model stakeholder relationships, and how to translate between problem and solution spaces.

Jackson's Problem Frames

Michael Jackson developed Problem Frames as the sister methodology to WRSPM. While WRSPM defines what requirements engineering must achieve (the W→R→S→P→M chain), Problem Frames provide a systematic way to classify and decompose the problem before choosing a solution.

The core insight is that most software problems are instances of a small set of standard archetypes. Recognising the archetype tells you what questions to ask, what world assumptions to document, and what specification structure to use:

Most real systems are composite frames — combinations of several archetypes. An e-commerce checkout, for example, combines Transformation (cart → order), Information Display (inventory levels), and Required Behaviour (payment processing) frames. By identifying the component frames, you can apply the appropriate requirements technique to each part independently.

Goal-Oriented Requirements Engineering (GORE) & i*

Goal-Oriented Requirements Engineering (GORE) shifts the fundamental question from "What should the system do?" to "Why is this system needed, and what goals must it achieve?" It treats requirements as goals at different levels of abstraction, progressively refined from strategic business objectives to precise system behaviours.

The i* (i-star) framework, developed by Eric Yu, is a prominent GORE technique that models the environment as a network of interdependent social actors. Rather than treating the software system in isolation, i* models the entire socio-technical system: who the actors are, what they want, and how they depend on each other. It produces two models:

• Strategic Dependency (SD) model: Shows relationships between actors — which actor depends on which other for what goal, task, or resource
• Strategic Rationale (SR) model: Shows the internal reasoning of each actor — how their goals, tasks, resources, and softgoals interrelate

i* is particularly useful for requirements in multi-stakeholder systems where organisational politics and competing objectives are as important as technical constraints — enterprise ERP systems, healthcare platforms, government services.

Use Case / Actor-Boundary Model (UML)

The Use Case model, formalised in UML, is the most widely used requirements notation in object-oriented software development. It provides a pragmatic, widely-understood notation for capturing actor-system interactions at the system boundary — bypassing the deep environmental modelling of WRSPM in favour of communication clarity.

The Use Case model's strength is communication clarity with non-technical stakeholders. Its weakness — which WRSPM explicitly addresses — is that it says little about world assumptions: what environmental context makes actors behave as they do, what physical constraints bound the system, and what happens when the real world doesn't conform to the model.

Model-Driven Architecture & MBSE Approaches

Model-Based Systems Engineering (MBSE) replaces text-heavy specifications with formal, integrated digital models that link requirements, architecture, behaviour, and verification in a single authoritative source. These approaches dominate in systems engineering domains — aerospace, defence, automotive, and complex infrastructure.

SysML — Systems Modeling Language

SysML is a visual modelling language (an extension of UML) specifically designed for systems engineering. Its key innovation is the Requirements Diagram — a first-class diagram type that connects natural-language requirements directly to the architectural and behavioural elements that satisfy them, enabling automated traceability checking.

SysML models in tools like Cameo Systems Modeler or IBM Rhapsody support automated traceability checking — verifying that every requirement traces to a satisfying architectural element and a verifying test case. This automation is what makes MBSE attractive for large, complex programmes where manual traceability is impractical.

Capella & the Arcadia Method

Capella is an open-source MBSE workbench (developed by Thales) that implements the Arcadia method — a structured, four-layer approach that begins with operational analysis and progressively refines to physical implementation. Each layer answers a specific question:

flowchart TD
    OA["OA: Operational Analysis"]
    SA["SA: System Needs Analysis"]
    LA["LA: Logical Architecture"]
    PA["PA: Physical Architecture"]
    OA -->|"Operational needs inform system missions"| SA
    SA -->|"Functions allocated to logical blocks"| LA
    LA -->|"Logical components realised physically"| PA
    style OA fill:#3B9797,color:#fff
    style SA fill:#16476A,color:#fff
    style LA fill:#132440,color:#fff
    style PA fill:#BF092F,color:#fff
                            

The Arcadia layers map naturally to the WRSPM chain: Operational Analysis corresponds to W (world and stakeholders), System Needs to R (requirements), Logical Architecture to S (specifications), and Physical Architecture to P/M (program and machine). Capella enforces traceability between layers, making it possible to trace any hardware choice back to the original operational need that justified it.

CIM / MDA — Computation Independent Model

The Object Management Group's Model-Driven Architecture (MDA) framework decomposes the modelling space into three levels of abstraction, separating business concerns from technical implementation:

MDA's key contribution to requirements engineering is the CIM — a model of the business world that is entirely independent of any software decision. By maintaining an explicit CIM, organisations can change their technology stack (PSM) without affecting core business rules (CIM), and can validate that every system capability traces to a genuine business need.

Agile & Iterative Requirements Frameworks

Agile frameworks embrace change as a constant. Rather than attempting to document requirements completely upfront, they treat requirements as a living backlog — progressively refined, continuously reprioritised, and verified through working software. The two most impactful agile requirements frameworks are BDD (which you've seen in the Documentation section as a notation) and User Story Mapping.

BDD / Gherkin — Executable Specifications

Behaviour-Driven Development (BDD), popularised by Dan North, solves a longstanding requirements problem: specifications that are written down but never verified against the running system. BDD replaces static specifications with executable Given/When/Then tests — requirements documents that can be run as automated acceptance tests.

BDD tools (Cucumber, SpecFlow, Behave) parse Gherkin scenarios and execute them as automated tests, creating a living specification — a document that simultaneously serves as requirements, acceptance criteria, and regression test suite.

User Story Mapping

Jeff Patton's User Story Mapping technique addresses a critical weakness of simple backlogs: a flat list of user stories has no structure, making it impossible to see the "big picture" of the user experience or plan coherent, releasable product increments.

Story maps organise stories in two dimensions:

• Horizontal axis (backbone): User activities in narrative order — the user journey spine, from first touch to goal completion
• Vertical axis (depth): Stories at different priority levels — from the minimum viable skeleton down to edge cases and enhancements

flowchart LR
    A["Browse Products"] --> B["Add to Cart"] --> C["Checkout"] --> D["Track Order"]
    A --> A1["View product list"]
    A --> A2["Filter by price"]
    B --> B1["Update quantity"]
    C --> C1["Enter payment"]
    D --> D1["View order status"]
    style A fill:#132440,color:#fff
    style B fill:#132440,color:#fff
    style C fill:#132440,color:#fff
    style D fill:#132440,color:#fff
    style A1 fill:#3B9797,color:#fff
    style A2 fill:#3B9797,color:#fff
    style B1 fill:#3B9797,color:#fff
    style C1 fill:#3B9797,color:#fff
    style D1 fill:#3B9797,color:#fff
                            

Story maps answer a question that flat backlogs cannot: "If we only build the stories in this horizontal slice, do we have a coherent, releasable product?" Each horizontal slice through the map represents a release candidate — not a random collection of features, but a complete (if minimal) user journey.

Choosing Your Framework — Comparison

No framework covers every requirements engineering need perfectly. Here is a comparative guide across the key dimensions that matter in practice:

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. This article has surveyed the full landscape of the discipline — from the rigorous WRSPM reference model through formal academic alternatives, goal-oriented methods, model-based systems engineering, and agile iterative practices. No single framework covers every context: the art of requirements engineering lies in choosing and combining the right tools for the project at hand.

Key takeaways from this article:

• Requirements ≠ specifications — requirements describe what stakeholders need; specifications describe precise system behaviour at the system boundary
• Non-functional requirements often matter more than functional ones for system success
• The WRSPM model separates World, Requirements, Specifications, Program, and Machine — forcing explicit documentation of world assumptions that other frameworks ignore
• Formal models (WRSPM, Four-Variable, KAOS) provide mathematical rigour for safety-critical systems; conceptual frameworks (Problem Frames, GORE, i*) structure the thinking process
• Twin Peaks reminds us that requirements and architecture must co-evolve — neither can be finalised in isolation
• MBSE approaches (SysML, Capella/Arcadia, CIM) automate traceability from business need to physical component
• BDD and User Story Mapping make requirements executable and user-journey-structured for agile teams
• Ambiguous language is the enemy — always quantify, always ask "how would we test this?"