@chongyan/autospec 1.0.1 → 1.0.2

package/knowledge/09-templates/00-requirement-proposal.md

@@ -0,0 +1,344 @@
+# 需求提案：{需求名称}
+
+> **版本**: v1.0
+> **模板来源**: 结构化需求分析方法 / 业界需求工程最佳实践
+> **适用范围**: 所有需求分析场景
+> **生成模式**: 业务域识别 → 需求定义 → 架构设计 → 发布准备
+
+---
+
+## 1. 背景与价值
+
+### 1.1 业务背景
+
+> 描述当前面临的问题或机会，用数据说话（当前指标、目标指标）
+
+**填写指南**：
+- 描述当前存在的问题或市场机会
+- 提供客观数据和事实支撑
+- 避免主观描述
+
+### 1.2 业务价值 (Why)
+
+> 为什么要做这个需求，预期的业务价值是什么
+
+| 价值类型 | 价值描述 | 衡量指标 | 目标值 |
+|---------|---------|---------|-------|
+| 业务价值 | | | |
+| 用户价值 | | | |
+| 技术价值 | | | |
+
+---
+
+## 2. 目标与范围
+
+### 2.1 目标 (Success Criteria)
+
+> 用 SMART 原则定义目标（具体的、可衡量的、可实现的、相关的、有时限的）
+
+| 目标类型 | 目标描述 | 衡量指标 | 目标值 | 完成时间 |
+|---------|---------|---------|-------|---------|
+| 功能目标 | 支持 X 场景 | 场景覆盖率 | 100% | |
+| 性能目标 | 响应时间 | P99 延迟 | <500ms | |
+| 业务目标 | 用户增长 | DAU | +20% | |
+
+### 2.2 范围
+
+**包含**：
+- 明确列出本次需求包含的功能
+
+**不包含**：
+- 明确排除的范围，避免范围蔓延
+
+---
+
+## 3. 业务域识别
+
+### 3.1 8 类场景检查清单
+
+在需求分析开始时，通过 8 类场景检查识别涉及的业务域：
+
+| 场景类型 | 检查问题 | 是否涉及 | 涉及业务域 | 识别依据 |
+|---------|---------|---------|-----------|---------|
+| 外部对接 | 是否涉及外部系统、第三方服务对接？ | Y/N | gateway | |
+| 账户体系 | 是否涉及用户账户、资金账户、账务处理？ | Y/N | account | |
+| 交易链路 | 是否涉及下单、支付、确认、结算？ | Y/N | trade | |
+| 资产/资源管理 | 是否涉及资产计算、估值、登记？ | Y/N | asset | |
+| 数据管道 | 是否涉及数据采集、清洗、流转、报表？ | Y/N | data | |
+| AI/模型 | 是否涉及模型训练、推理、效果评估？ | Y/N | ai/ml | |
+| 运营营销 | 是否涉及活动、营销、用户运营？ | Y/N | operation | |
+| 监控运维 | 是否涉及监控、告警、应急、部署？ | Y/N | ops | |
+
+**使用方法**：
+1. 逐条检查 8 类场景
+2. 标记"涉及"的业务域
+3. 针对每个涉及的业务域，读取对应的领域知识
+4. 在需求文档中明确标注涉及的业务域
+
+---
+
+## 4. 业务架构设计
+
+### 4.1 总体架构图
+
+> 使用 Mermaid flowchart，按功能域分层展示，标注系统边界和外部交互
+
+```mermaid
+flowchart TB
+    subgraph "系统边界"
+        A[功能模块 A]
+        B[功能模块 B]
+    end
+
+    User[用户] --> A
+    A --> B
+    B --> Ext[外部系统]
+```
+
+### 4.2 需求用例图
+
+> 使用 Mermaid flowchart，按角色分组，原子粒度用例（不可再拆分）
+
+```mermaid
+flowchart TB
+    subgraph "角色 A"
+        A1[用例 1]
+        A2[用例 2]
+    end
+
+    subgraph "角色 B"
+        B1[用例 3]
+    end
+```
+
+### 4.3 业务域拆解
+
+| 场景类型 | 是否涉及 | 业务域 | 识别依据 |
+|---------|---------|--------|---------|
+| | Y/N | | |
+
+### 4.4 资金流方案（涉及资金链路时必须）
+
+> 使用 Mermaid flowchart 或 sequence diagram，标注账户间资金流转、时间和方向
+
+```mermaid
+sequenceDiagram
+    participant U as 用户账户
+    participant S as 系统账户
+    participant B as 银行账户
+
+    U->>S: 充值
+    S->>B: 清算
+```
+
+### 4.5 用例业务流程
+
+> 每个用例一个 sequence diagram，从用户视角描述交互流程，标注异常处理分支
+
+```mermaid
+sequenceDiagram
+    participant User as 用户
+    participant System as 系统
+
+    User->>System: 发起请求
+    alt 正常流程
+        System->>System: 处理
+        System-->>User: 返回结果
+    else 异常流程
+        System-->>User: 返回错误
+    end
+```
+
+### 4.6 跨域接口（概要）
+
+| 接口名 | 调用方 | 被调用方 | 协议 | 说明 |
+|-------|--------|---------|------|------|
+| | | | HTTP/RPC/MQ | |
+
+### 4.7 数据一致性保障
+
+> 描述数据一致性方案
+
+| 方案 | 适用场景 | 实现方式 |
+|------|---------|---------|
+| 分布式事务 (2PC/SAGA) | 强一致场景 | |
+| 中间态 + 定时任务重试 | 最终一致场景 | |
+| 消息队列 | 异步解耦场景 | |
+
+---
+
+## 5. 关键决策
+
+> 记录重要技术选型和方案取舍
+
+| 决策点 | 选项 A | 选项 B | 决策 | 理由 |
+|-------|------|-------|------|------|
+| | | | | |
+
+---
+
+## 6. 风险与缓解
+
+| 风险项 | 影响 | 概率 | 缓解措施 | 负责人 |
+|-------|------|------|---------|--------|
+| | 高/中/低 | 高/中/低 | | |
+
+---
+
+## 7. 非目标与约束
+
+### 7.1 非目标
+
+> 明确说明本次需求不包含的内容，避免后续误解
+
+### 7.2 知识库缺失识别
+
+| 缺失项 | 影响 | 补充计划 |
+|-------|------|---------|
+| | | |
+
+---
+
+## 8. 需求描述规范（WHEN-THEN 规格）
+
+> 使用 Gherkin 风格描述需求，确保无歧义
+
+### 格式说明
+
+```gherkin
+场景：{场景名称}
+  给定：{前置条件}
+  当：{触发事件}
+  则：{预期结果}
+  而且：{额外预期}
+```
+
+### 示例
+
+```gherkin
+场景：用户购买产品
+  给定：用户账户余额充足
+    而且：当前账户状态正常
+  当：用户发起购买申请 100 元
+  则：创建购买订单，状态为"处理中"
+    而且：用户可用余额减少 100 元
+    而且：发送通知告知用户
+```
+
+### 使用规则
+
+1. **给定**：描述前置条件，必须可验证
+2. **当**：描述触发事件，必须具体
+3. **则**：描述预期结果，必须可测量
+4. **而且**：可多条，补充预期结果
+
+---
+
+## 9. 发布准备（三板斧）
+
+### 9.1 灰度策略
+
+| 灰度维度 | 说明 | 本需求适用 | 具体方案 |
+|---------|------|-----------|---------|
+| 用户灰度 | 按用户 ID/用户群灰度 | Y/N | |
+| 流量灰度 | 按流量百分比分流 | Y/N | |
+| 功能灰度 | 按功能开关控制 | Y/N | |
+| 数据灰度 | 按数据范围灰度 | Y/N | |
+
+### 9.2 监控指标
+
+| 指标类型 | 指标名称 | 告警阈值 | 本需求适用 | 采集方式 |
+|---------|---------|---------|-----------|---------|
+| 业务指标 | 下单成功率 | <95% | Y/N | |
+| 性能指标 | 接口响应时间 | P99>500ms | Y/N | |
+| 错误指标 | 错误日志数量 | >10/min | Y/N | |
+| 资源指标 | CPU/内存使用率 | >80% | Y/N | |
+
+### 9.3 应急预案
+
+| 风险项 | 应急操作 | 操作步骤 | 负责人 | 预计恢复时间 |
+|-------|---------|---------|--------|-------------|
+| 新功能异常 | 功能开关降级 | 1. 关闭开关 2. 验证恢复 | | 5 分钟 |
+| 性能问题 | 限流降级 | 1. 开启限流 2. 通知用户 | | 10 分钟 |
+| 数据问题 | 数据回滚 | 1. 停止写入 2. 回滚数据 | | 30 分钟 |
+
+---
+
+## 10. 需求澄清记录
+
+> 记录需求澄清过程（DP17 结构化澄清协议）
+
+### 澄清问题列表
+
+| 问题 | 优先级分数 | AI 推荐答案 | 推理过程 | 状态 |
+|------|-----------|-----------|---------|------|
+| | | | | Open/Closed |
+
+**优先级分数计算**：优先级分数 = Impact（影响）× Uncertainty（不确定性）
+- Impact：高 (3) / 中 (2) / 低 (1)
+- Uncertainty：高 (3) / 中 (2) / 低 (1)
+
+### 澄清结果更新
+
+> 每个澄清回答原子更新到需求文档的对应章节
+
+---
+
+## 11. Open Questions
+
+| 问题 | 提出人 | 日期 | 状态 | 决议 |
+|------|--------|------|------|------|
+| | | | Open/Closed | |
+
+---
+
+## 附录
+
+### A. 需求检查清单
+
+**必填章节检查**：
+- [ ] 1.1 业务背景
+- [ ] 1.2 业务价值
+- [ ] 2.1 目标
+- [ ] 2.2 范围
+- [ ] 3.1 总体架构图
+- [ ] 3.2 需求用例图
+- [ ] 4.5 用例业务流程
+
+**质量检查**：
+- [ ] 每条功能需求有明确的验收标准
+- [ ] 需求描述无歧义（不同人读到的理解一致）
+- [ ] 技术可行性已初步评估
+- [ ] 边界清晰（明确列出做什么、不做什么）
+- [ ] 非功能需求已覆盖（性能、安全、兼容性）
+- [ ] 依赖和约束已识别
+- [ ] 需求描述符合 5W 标准（Who/Where+When/What/Why）
+- [ ] 用户痛点已穿透至少两层
+- [ ] 客户价值公式成立（新方案 - 旧方案 - 转换成本>0）
+
+**三板斧检查**：
+- [ ] 灰度策略已定义
+- [ ] 监控指标已定义
+- [ ] 应急预案已定义
+
+### B. 最佳实践
+
+1. **用例原子化**: 每个用例应该是原子的，不可再拆分
+2. **流程图优先**: 能用图表达的不用文字
+3. **明确边界**: 清晰定义包含和不包含的范围
+4. **关键决策记录**: 记录重要技术选型和方案取舍
+5. **风险前置**: 提前识别风险并制定缓解措施
+6. **WHEN-THEN 格式**: 用 Gherkin 风格描述需求，确保无歧义
+7. **三板斧思维**: 发布前必须考虑灰度、监控、应急
+
+### C. 参考资料
+
+- [需求检查清单](../04-checklists/requirement.md)
+- [结构化澄清协议 (DP17)](../01-principles/05-domain-principles.md)
+- [三板斧 (DP10)](../01-principles/05-domain-principles.md)
+
+---
+
+**维护者**: 产品/需求团队
+**进化分区**: 受控区
+**版本**: v1.0