Use before technical design or coding; applicable to requirements involving backend functionality, APIs, asynchronous tasks, storage changes, or service integration.
When to Use
- The user says "analyze this requirement" / "help me sort out the requirements" / "requirement analysis"
- Before starting technical design or coding, when requirements are not yet clear
- The user describes business goals that have not yet been translated into backend implementation boundaries
- Any new feature involving API design, data storage, asynchronous tasks, or service integration
Input
Obtain requirement content by priority:
- Conversation context: the user described the requirement in a message; use it directly
- Path provided by the user: the user specified a PRD / requirements document path; read it directly
- Auto-discovery: find the most recently modified requirements document in the current working directory
ls -t $(find . -maxdepth 3 \( -name "*prd*" -o -name "*requirement*" -o -name "*需求*" \) -name "*.md" 2>/dev/null) 2>/dev/null | head -5
If auto-discovery finds multiple candidate files, list them and ask the user to confirm. If no file is found, prompt the user to describe the requirement or provide a document path.
Goals
- Restate the business request in backend terms
- Distinguish confirmed facts, assumptions, and unknowns
- Produce implementable acceptance criteria
- Expose backend-specific risks as early as possible
Workflow
Step 1: Understand the request
Extract the following information:
- Business goal
- Actions of the user or upstream system
- Expected output
- Constraints already specified by the user
If the user's description is vague, make minimal safe assumptions and mark them as "assumptions".
EARS structuring: rewrite requirements into structured sentence patterns to eliminate ambiguity:
| Pattern | Applicable scenario | Example |
|---|---|---|
| When [event], the system shall [behavior] | Event-triggered | When the user submits an order, the system shall decrement inventory |
| While [state], the system shall [behavior] | Continuous state | While payment is pending, the system shall prohibit cancellation |
| If [condition], then the system shall [behavior] | Conditional branch | If the quota is exceeded, the system shall return 429 with retry-after |
| The system shall [behavior] | Unconditional constraint | The system shall encrypt PII fields at rest |
Each core requirement shall be expressed using at least one EARS sentence pattern.
Step 2: Break down backend dimensions
Always analyze the following dimensions:
- Domain entities and state transitions
- API or message contracts
- Read/write paths
- Data validation rules
- Permission and tenant isolation boundaries
- Consistency and idempotency requirements
- Failure handling and retry strategies
- Observability expectations
- Performance and capacity expectations
- Release and rollback constraints
Current-state verification (required)
Before producing the requirements document, verify the following three aspects of feasibility:
Data availability
- Does the required data already exist in the system?
- Is new collection or migration needed? How should historical data be handled?
Interface feasibility
- Do the upstream and downstream interfaces being depended on already exist?
- Is the contract stable (version, fields, SLA)? Is coordination with external teams needed?
Dependency readiness
- Is the required infrastructure (queues, caches, storage) ready?
- What is the current status of the dependent services (stable / in development / planned)?
Step 3: Output the requirements document
Use the following structure:
# 需求分析
## 核心结论
> **结论**：[一句话说明需求是否可行、主要约束、推荐的 MVP 范围]
>
> **关键风险**：[最高优先级的 1-3 个风险]
>
> **建议行动**：[下一步最重要的决策或确认项]
## 需求追溯表
| Req# | 需求描述 | 优先级 | 来源/假设 | 验收标准编号 |
|------|----------|--------|-----------|-------------|
| R1 | | Must | 用户明确 | AC1, AC2 |
| R2 | | Should | 假设 | AC3 |
## 目标
## 范围内
## 范围外
## 参与方与依赖
## 领域模型
## API 或事件契约
## 业务规则
## 非功能需求
## 验收标准
| AC# | 场景 | 前置条件 | 操作 | 预期结果 | 可验证 |
|-----|------|----------|------|----------|--------|
| AC1 | | | | | ✅/⚠️/❌ |
> 可验证标注：✅ 数据和接口已就绪 | ⚠️ 需前置工作 | ❌ 当前不可验证（列入待确认项）
## 风险与待确认项
Step 4: Define acceptance criteria
Good acceptance criteria should have:
- Observability (can be verified by tests or monitoring)
- Backend-verifiable (does not depend on the frontend)
- Boundary awareness (covers boundary conditions)
- Failure awareness (covers failure paths)
The following paths must be included:
- Normal path
- Invalid input path
- Duplicate request path
- Dependency failure path
- Permission failure path
Go backend focus checklist
- Are there clear request boundaries and handling entry points?
- Are DTOs separated from domain objects?
- Are state transitions clearly defined?
- Do write operations require idempotency?
- Is eventual consistency acceptable?
- Are timeout, retry, and cancellation rules defined?
- Are audit logs or metrics needed?
- Are there SLO or latency target requirements?
Output rules
- Do not move prematurely into package structure or table structure design.
- Do not write specific IDL definitions, database schemas, or code snippets— the requirements layer only describes "which parameters are needed, what types, and mutual exclusion relationships"; specific field numbers, annotations, and Go structs are left to the technical design stage.
- Do not hide unknowns; list them explicitly.
- If the requirements are too large, split them into phases: MVP, hardening, scaling.
- Prioritize giving precise acceptance criteria rather than implementation suggestions.
- Core conclusions must be placed at the top, including actionable decision recommendations.
- The requirements traceability table must come after the core conclusions, ensuring that each requirement can be traced to acceptance criteria.
Reference materials
- For a quick question checklist, see
references/checklist.md
Handoff
After requirements analysis is complete, inform the user at the end of the conversation about the optional next steps,wait for the user's explicit instruction before continuing, and do not automatically enter the next stage：
/go-backend-technical-design— component and interface design/go-backend-architecture— cross-service or long-term architecture decisions (optional)