Key Concepts
Requirements tell you WHAT to build. Getting them right is harder than writing the code.
Functional Requirements
What the system should DO — specific behaviors, inputs, outputs, and operations.
Non-Functional Requirements
Constraints on HOW the system works — performance, security, reliability, usability.
Requirements Elicitation
Techniques to discover what stakeholders actually need — interviews, observation, prototyping, scenarios.
Requirements Validation
Checking that requirements actually define the system the customer wants before you build it.
Concept Deep Dives
Click each concept to expand — real examples, diagrams, pros & cons.
Functional Requirements
When to Use
Always required — defines the system's core capabilities.
Real-World Example
'A user should be able to reset their password via email' — specific, testable, behavioral.
✓ Advantages
- Directly testable
- Clear acceptance criteria
- Maps to user stories
⚠ Watch Out
- Easy to over-specify (becomes design, not requirements)
- Can miss non-functional needs
Non-Functional Requirements
When to Use
Always — these define quality and are often harder to retrofit than functional features.
Real-World Example
'The login page must load in <500ms' / 'System must be available 99.9% uptime' / 'GDPR compliant'.
✓ Advantages
- Define quality standards
- Drive architectural decisions
- Prevent scope creep on quality
⚠ Watch Out
- Hard to test objectively
- Often vague ('must be fast') — need quantification
Requirements Elicitation
When to Use
Project start — before writing a single line of spec.
Real-World Example
Airbnb's founders actually stayed in people's homes to understand pain points before building features.
✓ Advantages
- Reveals hidden needs
- Uncovers conflicting stakeholder goals
- Builds shared understanding
⚠ Watch Out
- Stakeholders don't always know what they want
- Time-consuming
- Political stakeholder dynamics
Requirements Validation
When to Use
After requirements are written — before development begins.
Real-World Example
A requirements review catching a contradiction before dev saves 10-100x the cost of fixing it in production.
✓ Advantages
- Prevents costly rework
- Ensures completeness and consistency
- Aligns stakeholders
⚠ Watch Out
- Requires time and stakeholder availability
- Can be a bottleneck
Quick Reference
- 1Requirements engineering: process of establishing the services a customer requires and the constraints.
- 2Functional requirements: what the system should do — specific behaviors and outputs.
- 3Non-functional requirements: constraints on system qualities — performance, security, reliability.
- 4User requirements: high-level, natural language statements for stakeholders.
- 5System requirements: detailed technical description for developers.
- 6Requirements elicitation: interviews, scenarios, ethnography, prototyping.
- 7Requirements validation: reviews, prototyping, test case generation — done BEFORE development.
- 8Requirements always change — manage them with traceability and change control.
Quiz — Test Yourself
Think through your answer first, then reveal.