requirement-analysis

# 需求分析（requirement-analysis） 回答"**这个需求到底要做什么**"——建立对系统的正确理解，而不是写测试。 - **输入**：PRD、设计文档、API 文档、Bug、Issue、代码仓库；旁路场景下消费 `exploratory-testing` 的探索笔记（系统理解 + 风险清单） - **输出（落盘）**：`{项目}/需求模型.md`——按下方 Schema 组织，含澄清记录与用户裁决 - **边界**：不产出用例（→ `test-case-writing`）；澄清后仍模糊的项如实标注 `open_questions`，**不硬猜** ## When to Use - 拿到 PRD/设计文档，需要系统性理解"这个需求到底要做什么"再进入测试 - 多输入源（文档 + 代码 + Bug 单）需要交叉核对、暴露矛盾与缺口 - 为 `test-strategy` / `test-case-writing` 准备结构化的需求模型输入 ## When NOT to Use - 端到端测试整个需求 → `qa` 编排 - 已有需求模型、直接写用例 → `test-case-writing`（其阶段一内联轻量研读，够用即不必先建模） - "这个功能应该怎么测" → `test-strategy` - 完全无文档且系统陌生 → 先走 `exploratory-testing` 探索，再回来建模 ## 需求模型 Schema（产出结构） ```yaml requirement_model: goal: # 需求目标（一句话 + 成功标准） scope: # 功能范围（含明确的非目标） roles: [] # 角色 → 能做什么 / 不能做什么 inputs: [] # 输入（来源、格式、约束） outputs: [] # 输出（去向、格式、消费方） states: [] # 状态与流转（状态A --事件--> 状态B，逐条） rules: [] # 业务规则，每条带 evidence（文档章节或 文件:行） exceptions: [] # 异常情况（错误场景��预期行为） dependencies: [] # 依赖关系（上下游系统、共享数据、时序依赖） open_questions: [] # 不明确事项 → 澄清记录（含用户裁决） ``` > 证据标注（此时加载 `../core/evidence.md`）：rules / states / exceptions 每条标注 evidence（level E0–E4 + source）；用户在澄清环节的裁决记入 open_questions 的裁决字段，后续 skill 不得用代码推翻。 ## 工作流 ### 1. 输入收集与盘点 - 清点可用输入源：PRD / 设计文档 / API 文档 / Bug 单 / FAQ / 会议纪要 / 代码仓库 - 有代码仓库 → 主动索取（路径 + 分支 + 改动范围 + **对比基线 base**——阶段 7 回归范围凭它划界），代码是静态事实的最高来源；分支名 + commit（或拉取时间）+ 对比基线...