Requirements Engineering
Structured approaches for capturing what to build before how to build it.
Core Principle
Specify WHAT, not HOW. Requirements describe outcomes and behaviors, not implementation details.
EARS Format
Easy Approach to Requirements Syntax - structured acceptance criteria.
Pattern Template Use Case
Event-driven WHEN [event] THEN [system] SHALL [response] User actions, triggers
Conditional IF [condition] THEN [system] SHALL [response] Business rules
State-driven WHILE [state] [system] SHALL [response] Ongoing behaviors
Ubiquitous WHERE [feature] [system] SHALL [response] Always-true rules
Unconditional [system] SHALL [response] Basic capabilities
Examples
Type Example
Event WHEN user clicks "Submit" THEN system SHALL validate all required fields
Conditional IF user is not authenticated THEN system SHALL redirect to login
State WHILE file is uploading system SHALL display progress indicator
Ubiquitous WHERE data is displayed system SHALL use consistent date format
User Story Format
As a [role] I want [capability] So that [benefit]
Good vs Bad
Bad Good
As a user I want to login As a returning customer I want to login with my email so that I can access my order history
As a user I want a button As a content creator I want a publish button so that I can share my work publicly
Key concept: The "so that" clause reveals the actual need - often the stated "want" isn't what's really needed.
Requirements Document Structure
Section Content
Problem Statement What problem are we solving?
User Stories Who wants what and why?
Acceptance Criteria How do we know it's done? (EARS)
Non-Functional Performance, security, accessibility
Out of Scope What we're NOT building
Success Metrics How do we measure success?
Constitution (Governing Principles)
For complex projects, establish guiding principles before features:
Element Purpose
Core Values What matters most (simplicity > cleverness)
Technical Principles Architecture standards
Decision Framework How to make trade-offs
Quality Standards Testing, review requirements
Key concept: Constitution prevents scope creep and ensures consistency across features.
Clarification Techniques
Before implementation, resolve ambiguities:
Technique When to Use
Ask "what if" Edge cases, error scenarios
Present options Multiple valid approaches
Challenge assumptions "Is this actually required?"
Define boundaries What's in/out of scope
Questions to Ask
-
What happens when [edge case]?
-
What does success look like?
-
What's the minimum viable version?
-
What can we defer to later?
Non-Functional Requirements
Category Questions to Answer
Performance Response time? Throughput? Concurrent users?
Security Authentication? Authorization? Data protection?
Accessibility WCAG level? Screen reader support?
Scalability Expected growth? Peak load?
Reliability Uptime requirements? Recovery time?
Anti-Patterns
Don't Why
Specify implementation "Use React" locks in decisions
Assume requirements Validate with stakeholders
Skip edge cases They become bugs later
Mix requirements with design Conflates what with how
Write vague criteria "System should be fast" is untestable
Testable vs Untestable
Untestable Testable
"Fast response" "Response under 200ms"
"User-friendly" "Task completable in <3 clicks"
"Secure" "Passwords hashed with bcrypt"
"Scalable" "Handles 10K concurrent users"
Key concept: If you can't write a test for it, it's not a requirement - it's a wish.