requirements-clarification
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseRequirements Clarification for TDD
TDD的需求澄清
Purpose
目的
Before writing tests (RED phase), ensure requirements are understood well enough to:
- Know WHAT behavior to test
- Identify edge cases and boundaries
- Understand acceptance criteria
- Avoid rework from misunderstood requirements
在编写测试(RED阶段)之前,确保充分理解需求,以便:
- 明确需要测试的行为
- 识别边缘情况和边界条件
- 理解验收标准
- 避免因需求理解错误导致的返工
When to Use
适用场景
Initiate clarification when:
- Feature description is less than 2 sentences
- No acceptance criteria provided
- Ambiguous terms like "should handle errors appropriately"
- Business logic without specific rules defined
- No example inputs/outputs given
在以下情况时启动需求澄清:
- 功能描述不足2句话
- 未提供验收标准
- 存在“应适当处理错误”这类模糊表述
- 业务逻辑未定义具体规则
- 未给出示例输入/输出
When to Skip
跳过场景
Skip clarification when:
- Requirements explicitly define acceptance criteria
- User provides detailed test scenarios
- Simple CRUD with clear schema
- Bug fix with clear reproduction steps
- User requests "skip clarification" or "proceed directly"
在以下情况时可跳过需求澄清:
- 需求中明确定义了验收标准
- 用户提供了详细的测试场景
- 简单CRUD操作且有清晰的 schema
- Bug修复有明确的复现步骤
- 用户要求“跳过澄清”或“直接进行”
Question Categories
问题分类
1. Functional Requirements
1. 功能需求
| Question | Purpose |
|---|---|
| What is the primary happy path behavior? | Establish main test scenario |
| What inputs does this feature accept? | Define parameter validation tests |
| What outputs/results are expected? | Define assertion expectations |
| What side effects should occur? | Identify integration points |
| Are there any business rules or constraints? | Identify validation logic |
| 问题 | 目的 |
|---|---|
| 主要的正常流程行为是什么? | 确立核心测试场景 |
| 该功能接受哪些输入? | 定义参数验证测试 |
| 预期的输出/结果是什么? | 定义断言预期 |
| 会产生哪些副作用? | 识别集成点 |
| 是否有任何业务规则或约束? | 识别验证逻辑 |
2. Edge Cases and Boundaries
2. 边缘情况与边界条件
| Question | Purpose |
|---|---|
| What happens with null/empty input? | Null handling tests |
| What are the boundary values (min/max)? | Boundary condition tests |
| What if required dependencies are unavailable? | Error handling tests |
| Are there concurrency or timing concerns? | Thread safety tests |
| 问题 | 目的 |
|---|---|
| 输入为null/空值时会发生什么? | 空值处理测试 |
| 边界值(最小/最大)是多少? | 边界条件测试 |
| 若所需依赖不可用会怎样? | 错误处理测试 |
| 是否存在并发或时序相关问题? | 线程安全测试 |
3. Error Handling
3. 错误处理
| Question | Purpose |
|---|---|
| What exceptions should be thrown and when? | Exception tests |
| How should invalid input be handled? | Validation tests |
| What error messages should users see? | User feedback tests |
| 问题 | 目的 |
|---|---|
| 应抛出哪些异常,在什么场景下抛出? | 异常测试 |
| 应如何处理无效输入? | 验证测试 |
| 用户应看到哪些错误信息? | 用户反馈测试 |
4. Technical Clarification
4. 技术澄清
| Question | Purpose |
|---|---|
| What interfaces/abstractions already exist? | Understand dependencies |
| What existing patterns should be followed? | Consistency with codebase |
| Are there existing tests to follow as examples? | Test style consistency |
| What is the target test scope (unit/integration)? | Test organization |
| 问题 | 目的 |
|---|---|
| 已存在哪些接口/抽象? | 理解依赖关系 |
| 应遵循哪些现有模式? | 与代码库保持一致性 |
| 是否有可参考的现有测试示例? | 保持测试风格一致 |
| 目标测试范围是什么(单元/集成)? | 测试组织规划 |
Clarification Workflow
澄清工作流
┌─────────────────────────────────────────────────────────────────┐
│ CLARIFICATION PHASE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Analyze │───▶│ Identify │───▶│ Present │ │
│ │ Requirements │ │ Gaps │ │ Questions │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │
│ ┌──────────────┐ │ │
│ │ Collect │◀──────────┘ │
│ │ Answers │ │
│ └──────────────┘ │
│ │ │
│ ┌──────────────┐ │
│ │ Sufficient? │ │
│ └──────────────┘ │
│ │ │ │
│ YES NO │
│ │ │ │
│ ▼ └──────▶ Ask Follow-up │
│ ┌──────────────┐ │
│ │ Proceed to │ │
│ │ RED Phase │ │
│ └──────────────┘ │
│ │
│ EXIT: Requirements clear enough to define test scenarios │
└─────────────────────────────────────────────────────────────────┘┌─────────────────────────────────────────────────────────────────┐
│ CLARIFICATION PHASE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Analyze │───▶│ Identify │───▶│ Present │ │
│ │ Requirements │ │ Gaps │ │ Questions │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │
│ ┌──────────────┐ │ │
│ │ Collect │◀──────────┘ │
│ │ Answers │ │
│ └──────────────┘ │
│ │ │
│ ┌──────────────┐ │
│ │ Sufficient? │ │
│ └──────────────┘ │
│ │ │ │
│ YES NO │
│ │ │ │
│ ▼ └──────▶ Ask Follow-up │
│ ┌──────────────┐ │
│ │ Proceed to │ │
│ │ RED Phase │ │
│ └──────────────┘ │
│ │
│ EXIT: Requirements clear enough to define test scenarios │
└─────────────────────────────────────────────────────────────────┘Output Template
输出模板
After clarification, document understanding:
markdown
undefined澄清完成后,记录对需求的理解:
markdown
undefinedClarified Requirements for {Feature}
{功能名称}的澄清后需求
Understanding Summary
理解总结
{Brief summary of what the feature should do}
{该功能应实现的简要概述}
Inputs and Outputs
输入与输出
- Inputs: {List with types}
- Outputs: {Expected results}
- Validation Rules: {Business rules}
- 输入:{带类型的列表}
- 输出:{预期结果}
- 验证规则:{业务规则}
Identified Test Scenarios
已识别的测试场景
| Scenario Type | Description | Priority |
|---|---|---|
| Happy Path | {description} | High |
| Edge Case | {description} | Medium |
| Error Case | {description} | Medium |
| Boundary | {description} | Medium |
| 场景类型 | 描述 | 优先级 |
|---|---|---|
| 正常流程 | {描述} | 高 |
| 边缘情况 | {描述} | 中 |
| 错误场景 | {描述} | 中 |
| 边界条件 | {描述} | 中 |
Ready for RED Phase
可进入RED阶段
undefinedundefinedMinimum Questions (Always Consider)
必问问题(需始终考虑)
- What is the expected behavior for the happy path?
- What inputs does this accept and what outputs does it produce?
- How should errors/invalid input be handled?
- 正常流程的预期行为是什么?
- 该功能接受哪些输入,产生哪些输出?
- 应如何处理错误/无效输入?