Requirements Engineering

The Problem With "Fast"

When Amazon's product team interviewed users for a new checkout flow, every user said the same thing: "Make it faster." The team built a 40% faster checkout engine, deployed it, and conversion rates barely moved.

Then a UX researcher watched actual users. "Faster" did not mean page load time. It meant fewer steps. Users were abandoning at the fourth form page, not because the pages were slow, but because there were too many of them. Amazon introduced one-click ordering — the fewest possible steps — and conversions jumped.

The lesson: customers describe their pain, not the solution. Requirements engineering is the discipline of bridging that gap — understanding what people actually need, not just what they say.

Why Requirements Matter

The Standish Group's CHAOS Report — surveying thousands of projects over three decades — consistently finds:

• 56% of defects trace to poor or missing requirements
• The cost to fix a defect grows 10× from requirements phase to design, and 100× from requirements phase to production
• 45% of features in shipped software are never used — requirements that were specified but not validated

Requirements engineering is not a bureaucratic formality. It is the highest-leverage investment a team can make.

Types of Requirements

Requirements divide into three categories. Every project has all three.

Functional Requirements

What the system must do.

Examples:

• "Users can reset their password via email link"
• "The system calculates shipping cost based on weight and destination"
• "Admins can export user data as CSV"

Functional requirements are testable: you can write a test that verifies whether the system does the thing.

Non-Functional Requirements (Quality Attributes)

How well the system does it.

Non-functional requirements are the ones teams skip — and then spend months fixing in production.

Constraints

What the system must live within.

• Technical: "Must integrate with SAP via existing REST APIs"
• Regulatory: GDPR (EU data protection), HIPAA (US healthcare), PCI-DSS (payment cards)
• Business: "Budget is $400K" or "Must launch before Q4"
• Environmental: "Must run on existing AWS infrastructure"

Requirements Elicitation Techniques

Elicitation is the active process of discovering what stakeholders need. Stakeholders do not hand you a complete specification — you extract it through deliberate techniques.

Use Cases

A Use Case describes an interaction between an actor (user or external system) and the system to accomplish a goal.

Use Case: Purchase Item

• Actor: Registered Customer
• Precondition: Customer is logged in, item is in stock
• Main Flow: Customer adds item to cart → proceeds to checkout → selects shipping → enters payment → confirms order → system processes payment → system sends confirmation email
• Alternative Flow: Payment fails → system shows error → customer re-enters payment details
• Postcondition: Order recorded in database, inventory decremented

Use cases are technology-neutral — they describe what happens, not how the system implements it.

User Stories and Acceptance Criteria

In Agile, use cases give way to User Stories combined with acceptance criteria written in BDD (Behaviour-Driven Development) format.

User Story:

As a returning customer, I want my shipping address pre-filled at checkout so that I do not have to re-enter it each time.

Acceptance Criteria (Given/When/Then):

Given I am a returning customer with a saved shipping address
When I proceed to checkout
Then my default shipping address is pre-filled in the shipping form

Given I am a new customer with no saved address
When I proceed to checkout
Then the shipping address form is empty and all fields are editable

This format — popularised by tools like Cucumber and SpecFlow — serves as both a requirement and an automated test specification.

Requirements Specification: IEEE 830

For formal projects, the IEEE 830 Software Requirements Specification (SRS) standard provides a structured document template:

1. Introduction (purpose, scope, definitions)
2. Overall description (product perspective, user characteristics, constraints)
3. Specific requirements (functional, non-functional, interface requirements)
4. Appendices

While few Agile teams write full SRS documents, the structure is valuable for regulated industries (medical devices, financial systems) where requirements must be auditable.

Prioritisation Techniques

Not all requirements are equally important. Teams need explicit methods to decide what gets built first.

MoSCoW Method:

Kano Model: Categorises features by user satisfaction impact:

• Basic (must-have): absence causes dissatisfaction (checkout button)
• Performance: more is better (faster load time = more satisfaction)
• Excitement (delighter): unexpected feature that drives delight (Amazon's one-click patent)

Requirements Traceability Matrix

A Requirements Traceability Matrix (RTM) links every requirement to the design elements that implement it and the test cases that verify it. This ensures nothing gets built without a requirement and nothing is specified without being tested.

Amazon's "Working Backwards" Approach

Amazon famously requires that new products begin with a press release — written from the future, announcing the product as if it already exists and is a success. The press release must answer:

• Who is the customer?
• What is the customer problem or opportunity?
• What is the most important customer benefit?
• How does the customer experience work?

This forces requirements thinking before any architecture or implementation discussions begin. If you cannot write a compelling press release, the product concept is not ready. The press release is, in effect, the highest-level requirements document.

Key Takeaways

• The Standish Group found 56% of defects trace to poor requirements — making requirements engineering the highest-leverage activity in software development.
• Requirements divide into functional (what the system does), non-functional (how well it does it), and constraints (what it must live within).
• Elicitation techniques — interviews, workshops, observation, prototyping — are active methods for surfacing hidden needs.
• Use cases and user stories with BDD acceptance criteria translate requirements into testable specifications.
• MoSCoW prioritisation forces explicit trade-offs; the Kano Model reveals which features merely satisfy vs which ones delight.
• The Requirements Traceability Matrix ensures every requirement is implemented and tested — critical for regulated systems.
• Amazon's "Working Backwards" approach proves that starting from the customer outcome produces better requirements than starting from technology.