@chongyan/autospec 1.0.2 → 1.0.4

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

@@ -1,344 +0,0 @@
-# 需求提案：{需求名称}
-
-> **版本**: 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