Requirements and Design: Hypotheses, Constraints, and Operability
The Requirements and Design domain tests how teams turn uncertain needs into testable slices and choose architectures that support flow, operability, and change. Expect questions on user stories, acceptance criteria, non-functional requirements, Conway's Law, loose coupling, and designing for operations and security.
Core rules
- Treat requirements as hypotheses to validate, not fixed contracts. A useful story states the user, the need, and the value, with acceptance criteria that can become automated tests.
- Make non-functional requirements measurable: availability target, latency percentile, throughput, recovery point objective, recovery time objective, security and compliance constraints.
- Define "done" to include operational readiness: monitoring, alerts, runbooks, rollback, support ownership, and documentation. Code-complete is not done.
- Design for loose coupling and high cohesion so teams can change components independently. APIs and contracts matter more than internal implementation.
- Conway's Law says system design mirrors communication structures. Use it deliberately: shape team boundaries and interfaces together, and expect architecture to evolve.
- Microservices are an option, not a default. They trade deployment independence for distributed-system complexity, which requires operational maturity.
- Shift security, privacy, and compliance left as design constraints and automated checks, not late approvals.
Worked example
A retailer expects 10x order growth. Four teams share one codebase, and operations has limited observability. A proposal recommends microservices for scalability. The team instead designs a modular monolith with explicit module APIs, a defined SLO of 99.9% availability and p95 latency of 300 ms, RPO of 5 minutes and RTO of 30 minutes, plus a game day before launch. Reasoning: microservices would add network failure, tracing, and deployment overhead beyond current operational capability. The modular boundaries preserve a future split when team ownership and observability mature.
Traps that cost marks
- Collecting a complete requirements document upfront and freezing it.
- Leaving non-functional requirements as vague adjectives such as "fast" or "secure".
- Choosing microservices because they are fashionable, without matching operational maturity and team boundaries.
- Ignoring Conway's Law, then fighting constant cross-team coordination.
- Declaring a feature done when code is merged, without monitoring, rollback, or support ownership.