Requirements Engineering

10 min read · Updated 2026-04-25

Requirements engineering turns abstract business ideas into concrete specifications that engineering can deliver against. Skip this step and the system you ship will be technically excellent and functionally wrong.

Three types of requirements shape every architectural decision:

Functional
What the system does. Specific actions, features, capabilities that deliver business value.
Quality
How well it does it. Performance, security, scalability, reliability — the non-functional characteristics.
Constraints
What limits the design. Technical, regulatory, organizational forces that bound the solution space.

Functional Requirements: What the System Does

Functional requirements describe the specific actions, features, and capabilities that deliver business value. They look simple — “the system should let users search for products” — but the devil’s in the details.

The FAB structure: Feature, Advantage, Benefit

For each functional requirement, ask three questions:

Feature
What can the system do? The technical capability.
Advantage
What does the user get? The user-visible improvement.
Benefit
Why does the user want it? The underlying motivation.

Example. In a mobile payment system, biometric authentication is the feature. The advantage is removing PIN entry. The benefits are faster transactions and stronger security. All three matter — features alone get over-built; benefits alone get under-specified.

Event Storming — surfacing implicit knowledge

Event Storming is a collaborative workshop technique for discovering business processes and the functional requirements that support them. Different colored sticky notes for:

Domain events
Things that happen ("Order Placed", "Payment Completed").
Commands
Actions that trigger events.
Actors
People or systems initiating commands.
External systems
Outside services involved in flows.
Policies
Rules that fire when events happen.
Read models
The views people need to make decisions.

Lean Canvas for strategic context

Where Event Storming excels at process-level requirements, Lean Canvas provides strategic context — what problems are we solving, for which customers, with what unique value, through which channels and revenue streams. Use it to keep requirements anchored in business goals rather than feature wishlists.

Architecturally significant requirements

Not all functional requirements are equal. A few force fundamental architectural decisions affecting the whole system. Watch out for these classes:

Integration
Must talk to external systems.
Real-time
Must process events in real or near-real time.
Security
Sensitive data, special compliance.
Multi-platform
Multiple platforms or devices.
Scale
Must scale to dramatically higher volumes than today.

Practical techniques

User journey mapping
Understand functional requirements in scenario context. Surfaces missing requirements; clarifies feature connections.
Open-ended interviews
Detailed requirements after broad scope is understood. Ask open questions about goals and motivation, not closed questions confirming assumptions.
Mockups and prototypes
Make abstract requirements concrete. A simple prototype routinely surfaces dozens of implicit requirements that no document would capture.

Quality Requirements: How Well It Works

Quality requirements (the non-functional kind) define how well the system performs its functions. Unlike functional requirements — which can usually be added incrementally — quality requirements often demand architectural decisions made up front.

The invisibility problem

Visible until they fail
Why quality is overlooked
Users don't think about response time until pages load slowly. They don't think about security until there's a breach. They don't think about availability until the system is down.
The fix
Make them explicit
Concrete, measurable scenarios. "Scalability" and "performance" are just words until you write a testable scenario.

Quality attribute scenarios

A complete scenario has six parts:

Step 01
Source
Who or what initiates the scenario.
Step 02
Stimulus
The event requiring system reaction.
Step 03
Artifact
The system component being tested.
Step 04
Environment
The operational context.
Step 05
Response
Expected system behaviour.
Step 06
Response measure
Concrete, measurable success criteria.

If you can’t write a test for your scenario, it isn’t specific enough.

The Quality Attribute Workshop (QAW)

A structured method for surfacing and prioritizing quality attributes early.

Step 01
Business presentation
Sets context and goals so technical teams understand which qualities matter to the business.
Step 02
Architecture presentation
Stakeholders see the current or proposed design.
Step 03
Scenario brainstorm
Generate quality attribute scenarios from all participants.
Step 04
Consolidate and prioritize
Remove duplication; identify the most important attributes.

A few hours in a QAW typically saves months of expensive re-architecting.

SRE: from requirement to operational reality

SRE provides a framework for measuring and managing quality in production:

SLI
Service Level Indicator — measurable metric (request latency, error rate, availability).
SLO
Service Level Objective — target for SLI over a window. "99.9% in <500ms over rolling 30 days."
Error budget
Quantifies allowable unreliability within SLO. Ship faster while budget remaining; pause when burning down.

We go much deeper on SRE in Section 6. For now: SRE turns “we want it reliable” into something measurable.

Discovery techniques for quality requirements

Stakeholder interviews
Different people care about different qualities
End users focus on performance. Ops teams worry about reliability. Leaders care about cost. Talk to each — and weigh different priorities.
Architectural risk analysis
Where the architecture might miss
Examine proposed or existing architecture for risks against quality measures. Where might decisions affect quality outcomes?

Quality attributes pull against each other

High availability
Demands redundancy and complexity.
Strong security
Adds latency and friction.
Scalability
Can sacrifice strong consistency.
Pick your battles
Optimize the right qualities for your context. Don't maximize all of them — they conflict.

Constraints

Constraints are the limits that bound your design space.

Technical constraints
Existing systems, platform limits, technology choices the org has standardized on.
Regulatory constraints
GDPR, HIPAA, SOC 2, PCI DSS — each shapes what data lives where, who sees it, how it's protected.
Resource constraints
Budget, team size, available expertise, time to market.
Operational constraints
Deployment windows, SLAs already in place, integration cadence with other teams.

Principles for Successful Requirements Engineering

Step 01
Shared understanding
Between business stakeholders and technical specialists — not just a written spec passed back and forth.
Step 02
Right techniques per type
Event Storming for processes. Mockups for UI. QAW for quality attributes. Don't use one technique for everything.
Step 03
Collaborative workshops
Beat sequential handoffs. Everyone in the room produces better requirements than a chain of write-and-review.
Step 04
Structured scenarios
For quality attributes. Vague is unmeasurable.
Step 05
Systematic constraint identification
Don't let unstated constraints emerge halfway through implementation.

The goal isn’t perfect requirements. It’s shared understanding that survives the inevitable evolution of the system.

Recap