Requirements Analysis for Architects – Highlights from the InfoQ Podcast

Published June 1 2026 – Podcast with Sonya Natanzon, engineering leader and independent architect
Listen on Apple Podcasts • YouTube • Spotify

---

Technical announcement

The InfoQ podcast "Requirements Analysis for Architects" aired a detailed interview with Sonya Natanzon. The episode surfaces a set of concrete practices that architects can adopt immediately:

1. Prioritize business outcomes over technology choices – the system must solve a real problem, not merely showcase a trendy stack.
2. Write problem statements, not solution statements – describe the desired or undesired state, avoid "we need X" phrasing.
3. Leverage constraints – regulatory, performance, or operational limits narrow the design space and prevent analysis paralysis.
4. Create a ubiquitous language – a shared glossary that bridges business and technical vocabularies.
5. Use lightweight DDD techniques – Event Storming or bounded‑context workshops without imposing full‑blown methodology.
6. Treat AI‑assisted coding as a tool, not a replacement – maintain intuition about where abstractions break.

These points are framed as actionable guidelines rather than abstract theory, making them directly applicable to ongoing projects.

---

Specifications & benchmarks

Aspect	Recommended practice	Example / Benchmark
Requirement capture	Continuous conversation; record statements in a shared doc (e.g., Confluence, Notion)	Minimum 1 hour workshop + weekly 15‑minute sync
Problem statement format	Good outcome not happening OR Bad outcome happening	"Patients experience >30 min wait for lab results (bad outcome)" vs. "We need a microservice for lab results" (solution statement)
Constraint identification	List regulatory, latency, cost caps early; treat as hard limits	HIPAA isolation of PHI processing modules; latency ≤ 200 ms for UI calls
Ubiquitous language	Glossary with term, definition, owner; versioned in repo	order_status = "state of a patient order, values: pending, processing, completed"
Event Storming session	2‑day virtual workshop, 8‑12 participants, sticky‑note tooling (Miro, FigJam)	Produced 45 domain events, 12 aggregates, 6 bounded contexts
AI‑code assistance	Use LLM for boilerplate only; require human review + unit‑test coverage ≥ 80 %	Copilot generated CRUD scaffolding; reviewer added validation logic and tests

Real‑world benchmark

A mid‑size healthcare platform applied Natanzon’s approach to a new patient‑intake service. By converting a vague "we need a fast intake flow" request into a problem statement – "Patients spend >5 min on manual data entry, leading to drop‑off" – the team identified a latency constraint (≤ 150 ms) and a regulatory constraint (PHI isolation). The resulting architecture used three isolated microservices, each bounded by a clear contract, and achieved a 40 % reduction in drop‑off while staying within compliance.

---

Real‑world implications

1. Faster alignment between business and engineering

When architects focus on outcomes, product owners can validate success metrics early (e.g., conversion rate, error‑rate thresholds). The shared glossary eliminates the classic "what does order mean?" confusion that often stalls sprints.

2. Reduced design churn

Constraints act as guardrails. In the healthcare case study, the isolation rule forced the team to adopt a message‑queue pattern instead of a shared database, eliminating later refactoring that would have cost weeks of effort.

3. More disciplined use of AI assistants

Natanzon stresses that AI‑generated snippets are useful for repetitive code, but architects must still review intent and performance. The practice of attaching a review ticket to every AI‑produced PR preserves the intuition needed to spot abstraction failures.

4. Lowered resistance to DDD techniques

Running an Event Storming session without naming the method sidestepped the typical "DDD is too heavyweight" backlash. Participants still surfaced domain events and aggregates, proving that the technique’s value is independent of the label.

5. Better risk management

Explicitly documenting constraints (regulatory, latency, cost) creates a living artifact that can be fed into automated compliance checks (e.g., Open Policy Agent policies). This turns a traditionally manual audit step into a CI‑time gate.

---

Takeaway checklist for architects

• Convert every stakeholder request into good/bad outcome statements.
• Capture constraints in a dedicated section of the requirements doc.
• Build a shared glossary; store it in version‑controlled repo.
• Run a lightweight Event Storming workshop for any new bounded context.
• Use AI code generation only for boilerplate; enforce 80 %+ unit test coverage.
• Review AI‑generated code with a peer before merging to main.

By embedding these habits into the early phases of a project, teams can avoid the common pitfall of “solution‑first” thinking and instead let the problem drive the architecture.

---

Sonya Natanzon continues to share her experience through talks at QCon, InfoQ webinars, and the Architecture Advice Process community. For a deeper dive into her methodology, see the full podcast transcript and the accompanying slide deck linked in the episode description.