About this article
As the second installment of the âSolution Architectureâ category in the series âArchitecture Crash Course for the Generative-AI Era,â this article explains bridging requirements to design.
Requirements-definition failure becomes 10x cost in later phases. This article handles the practice of converting business âwant to doâ into tech design - hearings, As-Is/To-Be, MoSCoW priorities, scope management, requirements traceability - the first job of solution architects.
Other articles in this category
Why requirements definition is needed
Business and tech speak different languages
Even when business says âthe system has problems,â the real problem may be the business process. Conversely, even when tech says âtechnically canât,â reviewing requirements often makes it possible. A translation specialist is needed.
Even the requester doesnât know
Business departments also donât fully know what they want - typical. The architectâs job is drawing out requirements through dialogue.
Multiple design choices exist
For the same requirement, 5x cost differences emerge from tech choice. Grasping the essence of business requirements lets you propose cheap, fast, easy-to-operate options.
3 tiers of requirements
Requirements have a hierarchical structure. The principle is clarifying in order from upper to lower - mixing here results in shaky design.
flowchart TB
BIZ["Business requirements<br/>why do it, purpose<br/>e.g.: increase revenue 10%"]
USER["User requirements<br/>who, what to do<br/>e.g.: customers can find products"]
SYS["System requirements<br/>what the system does<br/>e.g.: provide product-search API"]
BIZ --> USER --> SYS
BAD[Start from system requirements<br/>= worst pattern building unclear-purpose]
BAD -.|antipattern| SYS
classDef biz fill:#fef3c7,stroke:#d97706,stroke-width:2px;
classDef user fill:#dbeafe,stroke:#2563eb;
classDef sys fill:#dcfce7,stroke:#16a34a;
classDef bad fill:#fee2e2,stroke:#dc2626;
class BIZ biz;
class USER user;
class SYS sys;
class BAD bad;| Tier | Content | Example |
|---|---|---|
| Business requirements | Why do it, purpose | Increase revenue 10% |
| User requirements | Who, what to do | Customers can find products |
| System requirements | What the system does | Provide product-search API |
Starting from system requirements is the worst - the cause of building with unclear purpose. Always descend from business requirements.
Business hearings
The starting point of requirements definition is careful hearings to business departments. Not one-way questioning - combine field observation, Q&A, document analysis.
| Hearing technique | Content |
|---|---|
| Interview | Deep-dive 1-on-1 |
| Workshop | Discussion with multiple |
| Field observation | See actual operations |
| Document analysis | Existing manuals, Excel |
| Competitor analysis | Other-company cases |
Field observation is often most valuable. Verbally âwe input in Excelâ but observing reveals complexity like âwe go back and forth across 3 Excel files.â
Requirements prioritization (MoSCoW)
Implementing all requirements is impossible. The framework clearly prioritizing is MoSCoW. Narrow by objective criteria, not vibe.
| Rank | Meaning | Content |
|---|---|---|
| Must | No value without it | Include in MVP (Minimum Viable Product) |
| Should | Usable without | Add in v1.1 |
| Could | Nice to have | If margin |
| Wonât | Not doing this time | Out of scope explicitly; future consideration |
The explicit Wonât is important - promising not to do prevents scope creep.
User stories
The technique describing requirements as user-perspective stories. Standard format for engineers and business to share understanding.
As a [role],
in order to [purpose],
I want [function].
Example:
As a sales rep,
in order to confirm history before customer visits,
I want to view customer info on mobile.Co-write acceptance criteria to clarify the criteria for âcompletion.â Define producing business value as completion, not ârunning = complete.â
AS-IS analysis and To-Be
Requirements definition draws both current state (AS-IS) and target (To-Be). Without considering current state, alignment with existing operations / systems breaks down.
| AS-IS analysis | To-Be design |
|---|---|
| Current business flow | New business flow |
| Current system composition | New system composition |
| Issues and constraints | Solutions |
| KPI (Key Performance Indicator) actuals | KPI targets |
| Bottlenecks | Improvement scope |
Detailing AS-IS too much without reaching To-Be is typical failure. Practical to stop at granularity needed for issue identification in AS-IS.
Business flow / data flow
Drop requirements as diagrams into business flow and data flow. Text alone breeds misunderstanding - visualize for agreement.
| Diagram | Use |
|---|---|
| Business flow (BPMN, international standard for business-process description) | Business flow, who does what |
| Use case diagram (UML, Unified Modeling Language) | Relationship of users and system |
| Data flow diagram (DFD, Data Flow Diagram) | Data flow |
| Sequence diagram | Order of screens / processing |
| Wireframe | Screen composition |
The ideal: business and tech departments discussing same diagrams. Miro / Figma / Lucidchart are better for collaborative editing than PowerPoint.
Countermeasures against requirement gaps
Requirements gaps become fatal in later phases. Use checklists to comprehensively identify.
| Viewpoint | Items to confirm |
|---|---|
| Happy path | Main business flow |
| Error path | Error handling, exceptions |
| Boundaries | Max value, min value, 0 items |
| Security | Authentication, authorization, audit |
| Performance | Response time, concurrent users |
| Operations | Backup, monitoring |
| Retirement | Data deletion, service end |
âDefining only happy path and finishingâ is typical failure. Error path is worth spending time defining.
How to descend to design
Once requirements are settled, drop into tech design. The iron rule here is producing multiple cases for comparison - with just 1 case, you canât judge âif itâs optimal.â
| Design-case viewpoints | Content |
|---|---|
| Functional implementation scope | How far to implement |
| Tech stack | Languages, FW, DB |
| Buy / Build / Subscribe | Off-the-shelf / self-build / SaaS |
| Cloud / on-prem | Execution environment |
| In-house / outsource | Implementation regime |
| Deadline, cost | Constraints |
The iron rule for solution architects is at least 3 cases - 2 cases decide via superiority, 3+ allow considering middle cases.
Requirements-definition document composition
The final output of requirements definition is the requirements-definition document. Generally created with the following composition. Templates vary by company, but essential items are common.
| Chapter | Content |
|---|---|
| 1. Background and purpose | Why do it |
| 2. Scope | What to do, what not to do |
| 3. Stakeholders | Relevant parties, roles |
| 4. Business requirements | Goals, KPI |
| 5. Functional requirements | What can be done |
| 6. Non-functional requirements | Performance, availability, etc. |
| 7. Constraints | Budget, deadline, tech |
| 8. Migration / operations | Migration plan from existing |
Non-functional requirements is an important area covered in detail in the next article.
Decision criterion 1: project scale
Requirements-definition detail varies with project scale. Excessive detail at small scale makes writing longer than building.
| Scale | Recommended |
|---|---|
| Small (~3 months) | User stories + screen mockups |
| Mid-size (3-12 months) | Standard requirements doc |
| Large (1+ years) | Detailed requirements + design doc + verification plan |
| Super-large | Phased requirements definition + PoC co-use |
Decision criterion 2: agile vs waterfall
Approach varies with requirement-change frequency. Operations with little change firm up requirements and proceed; areas with intense change suit phased-evolution approaches.
| Change | Recommended |
|---|---|
| Low (core operations) | Waterfall requirements definition |
| Mid (general B2B = enterprise business) | Hybrid |
| High (B2C = consumer business / new business) | Agile, per-sprint review |
How to choose by case
Small web service / within 3 months
User stories + Figma wireframes + MoSCoW for prioritization. Requirements doc unneeded, 1 Notion page enough. Roughly grasp AS-IS via 1-day field observation + several interviews, build To-Be prototype early to verify.
Mid-size B2B SaaS / 6-12 months
Requirements doc (standard template) + BPMN business flow + use-case diagrams + acceptance criteria. Periodic workshops with 3-5 business-side key persons, agree implementation scope via MoSCoW, define non-functional requirements early too. Consensus-build via collaborative editing on Figma / Miro.
Large core-system reform / 1-3 years
AS-IS detailed analysis + To-Be design doc + PoC co-use + phased-release plan. Dedicated user representatives from business departments, 3-6 months for requirements-definition phase alone, BPMN L1-L3 layered, prepare doc set including migration plan and data-conversion specs.
New business / B2C product
Lean canvas + MVP user stories + per-sprint review. On premise of not fixing requirements, early-release minimum features â add via user feedback. Prototype and real data over spec docs, operations of PM and engineers sitting together.
Common misconceptions
Asking users completes requirements definition
Users canât accurately say what they want. Need to draw out via observation / prototype.
Just deciding functional requirements lets you design
Without non-functional requirements, performance / availability fails. Both needed.
Requirements canât be changed later
Todayâs premise is changing. Design change process from the start.
Many diagrams = high quality
Diagrams not used in decisions are waste. Whether functions as discussion tool is the value criterion.
For a request âwant to web-ize Excel-based customer management,â firming requirements via interviews alone and starting development - when going to field observation as development progressed, the staff was working with 3 Excel files lined up, visually cross-checking color-coded cells - cases reported. The reality of the verbally-described âExcel managementâ was not a simple list but implicit business logic running on macros and human eyes - the case. A typical case suggesting requirements definition without field observation is dangerous - desk-heard requirements are mostly the tip of the iceberg.
Requirements-definition effort / period numerical gates
Note: Industry baseline values as of April 2026. Will become outdated as technology and the talent market shift, so requires periodic updates.
The empirical rule: requirements definition is 20-30% of project period. Below are per-scale guidelines.
| Project scale | Requirements-definition period | Effort ratio | Output |
|---|---|---|---|
| Small (~3 months) | 1-2 weeks | 10-15% | User stories + Figma wireframes |
| Mid-size (6-12 months) | 1-3 months | 15-25% | Standard requirements doc + BPMN |
| Large (1-3 years) | 3-6 months | 25-30% | AS-IS / To-Be detail + PoC co-use |
| Super-large / core reform | 6 months-1 year | 30%+ | Multi-stage requirements definition + multiple PoC |
| Agile new business | Per-sprint | Continuous | Lean canvas + MVP |
Metrics measuring requirements-definition quality: acceptance-criteria numerical-rate 90%+, scope (Wonât) explicit-rate 100%, field-observation rate (business-flow verification) 80%+, prototype/wireframe-share rate 100%. Stating Wonât in MoSCoW is the strongest weapon preventing scope creep.
Requirements-definition failure is 10x cost in later phases. Initial care is everything.
Requirements-definition pitfalls and forbidden moves
Typical accident patterns in requirements definition. All have destructive power at the level of losing half the project.
| Forbidden move | Why itâs bad |
|---|---|
| Requirements definition with just interviews without field observation | The Target Canada 2013-2015 withdrawal incident ($2B loss) pattern |
| Build with unclear purpose starting from system requirements | Confusion of purpose and means, âthis isnât itâ after completion |
| Donât state MoSCoW Wonât | Budget / deadline explode from scope creep |
| Write 1,500-page requirements doc | Field reality unreflected, halted in 9 years GBP 12B like NHS NPfIT |
| Decide functional requirements only and postpone non-functional | Fire after completion on performance / availability, non-functional adds 10x cost |
| Donât clarify acceptance criteria | Becomes ârunning is complete,â no business value emerges |
| Spend too much time on AS-IS, donât reach To-Be | Typical failure stopping at current-state analysis |
| Submit just 1 design case | Without comparison, canât judge optimum, at least 3 cases |
| Define requirements IT-alone without business involvement | Diverges from field reality, completed system unused |
| Start without designing requirement-change process upfront | Todayâs premise is changing, change-management mechanism required |
The 2013-2015 Target Canada withdrawal incident (sloppy SAP-core-system requirements definition, mass missing product-master field data, stores opened with empty shelves, $2B loss in 2 years) and UK NHS NPfIT project 2002-2011 (1,500-page requirements doc, halted after 9 years GBP 12B) show the fatal cost of requirements definition skipping field observation.
Desk-heard requirements are the tip of the iceberg. Requirements definition without field observation is dangerous.
AI-era perspective
When AI-driven dev (vibe coding) and AI usage are the premise, bridging requirements to design is designed on the premise that AI can write massive code. With implementation speed becoming 10x, requirements-definition accuracy is the biggest differentiation.
| Favored in the AI era | Disfavored in the AI era |
|---|---|
| Numerically-quantified requirements | âMake it niceâ requirements |
| Acceptance criteria clear | Vague completion criteria |
| Machine-readable specs | PPT hand-drawn specs |
| Early prototype creation | Months on paper requirements |
In the era when AI writes code, the bottleneck is âdeciding what to build.â In the era when specs become prompts as is, vague requirements are fatal.
In the AI era, spec clarity decides implementation quality. Write requirements deliverable to AI.
What to decide - what is your projectâs answer?
For each of the following, try to articulate your projectâs answer in 1-2 sentences. Starting work with these vague always invites later questions like âwhy did we decide this again?â
- Hearing method (interviews, workshops)
- Prioritization (MoSCoW etc.)
- Description format (user stories, business flow)
- Requirements-doc template (in-house standard)
- Acceptance-criteria definition method
- Change-management process (requirement-change approval)
- AS-IS / To-Be granularity
Authorâs note - cases of ârequirements-definition failureâ sinking enterprises
Cases showing how heavy a price requirements-definition laxness produces are repeatedly carved into industry history.
The Target Canada 2013-2015 withdrawal incident is a symbolic case where requirements-definition failure erased one business itself. US retail giant Target entered Canadian market in 2013, deploying 133 stores at once. But the requirements definition for the new SAP-core system was sloppy, with mass missing product-master field data (size / barcode / weight), continuing the situation of stores opening with empty shelves. The direct cause was writing requirements without seeing operational reality, withdrawing in 2 years with 17,600 jobs and about $2B in losses - studied as a failure remaining in management history.
Another, the UK NHS (National Health Service) NPfIT project 2002-2011 is also a famous case. The UK government ordered a national unified electronic-medical-record system, ending up as a 1,500-page-plus lengthy requirements-definition document, with the result that operational realities differing per regional hospital couldnât be reflected, and after 9 years and an estimated GBP 12B, the project was halted. A case slapping home that âperfect requirements on paperâ and âfield-usable designâ are completely different things.
Both have requirements definition skipping field observation as the lethal blow, showing that implicit business logic uncatchable via desk interviews alone decides projectsâ life or death.
How to make the final call
The core of bridging requirements to design is the thinking of descending from business requirements, drawing out via observation and prototype. On the premise that business departments also canât fully verbalize what they want, combine field observation, document analysis, and prototypes - not just interviews - to draw out requirements. Descend in 3 tiers (business requirements â user requirements â system requirements), prioritize via MoSCoW, state Wonât to prevent scope creep. Requirements-definition failure becomes 10x cost in later phases, so initial care decides everything. Practical to stop AS-IS at granularity needed for issue identification, investing time in To-Be.
Another decisive axis is the world where specs become prompts as is. In the era when AI writes code, the bottleneck of 10x implementation speed shifts to âdeciding what to buildâ - vague âmake it niceâ requirements become fatal. Numerically-quantified requirements, clear acceptance criteria, and machine-readable specs decide AI-era solution quality. Rather than months on paper requirements, the rational approach is firming up via dialogue with early prototype creation.
Selection priorities
- Descend from business requirements - donât start from system requirements, from purpose to tech
- State Wonât in MoSCoW - prevent scope creep, promise not to do
- AS-IS rough, time on To-Be - donât stop at current-state analysis, invest in solutions
- Numerically-quantified acceptance criteria - specs deliverable to AI, objectify completion judgment
âDescend from business, write specs deliverable to AI.â Vague requirements are fatal.
Summary
This article covered bridging requirements to design, including 3 tiers, MoSCoW, field observation, acceptance criteria, and AI-era spec meaning.
Descend from business requirements, state Wonât, AS-IS rough, write specs deliverable to AI. That is the practical answer for requirements definition in 2026.
Next time weâll cover âNon-functional requirements design.â Plan to dig into the practice of numerically defining performance, availability, security, and operations, plus numerical gates preventing flame-ups from âslowâ / âstops.â
I hope youâll read the next article as well.
đ Series: Architecture Crash Course for the Generative-AI Era (76/89)