The Two Types of Requirements
| Type | Definition | Examples |
|---|---|---|
| Functional | What the system must do | Process an order, generate a report, authenticate a user |
| Non-functional (NFRs) | How the system must behave | < 200 ms response time, 99.9 % uptime, PCI-DSS compliant |
Watch out
Ignoring NFRs is the most common cause of architectural failure. A system that meets every functional requirement but crashes under load, leaks data, or cannot be deployed is not successful.
Gathering Requirements
Techniques
| Technique | Best For | Time Investment |
|---|---|---|
| Interviews | Uncovering hidden needs from key stakeholders | 30-60 min each |
| Workshops | Aligning groups, discovering conflicts | 2-4 hours |
| Document analysis | Understanding existing systems, SLAs, contracts | Varies |
| Event Storming | Complex domains with many business events | 2-6 hours |
| User story mapping | Visualising user journeys end-to-end | 2-4 hours |
The RINSE Technique
A simple checklist for each requirement:
- R — Relevant to the business outcome?
- I — Independent of implementation (what, not how)?
- N — Negotiable (not a hard constraint)?
- S — Specific enough to test?
- E — Estimated (rough size known)?
Managing Trade-offs
Requirements often conflict. Faster delivery may mean less flexibility. Higher security may mean worse UX. Use a trade-off matrix to make these explicit:
| Decision | Benefit | Cost | Risk |
|---|---|---|---|
| Managed database (RDS) | Reduced ops burden | Vendor lock-in, higher cost | Medium |
| Self-hosted database | Full control, lower cost | Ops overhead, scaling effort | High |
| Serverless functions | No infra management | Cold starts, vendor coupling | Low |
| Kubernetes | Portability, ecosystem | Operational complexity | Medium |
Stakeholder Management
Stakeholder Map
Identify every group that cares about the system:
| Group | Cares About | Key Concern |
|---|---|---|
| Sponsors | Budget and timeline | ROI, delivery date |
| Users | Usability and performance | Does it make my job easier? |
| Operations | Reliability and observability | Can I keep it running? |
| Security | Compliance and threat posture | Are we exposed? |
| Developers | Clarity and autonomy | Can I build this without friction? |
Communication Plan
| Stakeholder | Frequency | Format | Focus |
|---|---|---|---|
| Sponsors | Monthly | Slide deck | Budget, timeline, risks |
| Product team | Weekly | Walkthrough | Feature alignment |
| Developers | Ongoing | ADRs, diagrams | Design decisions |
| Operations | Per release | Runbooks | Deployment, monitoring |
Pro tip
Create a RACI matrix (Responsible, Accountable, Consulted, Informed) for every major architectural decision. It prevents surprises and ensures the right people are involved at the right time.