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（产出结构）

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（或拉取时间）+ 对比基线记入需求模型文件头部，流水线续跑或进入执行阶段前先核对分支未变——对旧分支建模的结论不可复用，变了则标注受影响字段并复核
• 有探索笔记（探索笔记_{主题}.md）→ 消费其"系统理解"与"风险清单"作为建模输入
• 输入缺失项列入 open_questions（如"无性能指标文档"）

2. 初读与要素提取

逐文档通读，按 Schema 的十个字段收集要素：

• goal / scope：目标与成功标准；显式的"非目标"声明单独收录（后续要转化为验证边界）
• roles：角色 × 能做 / 不能做（权限矩阵的雏形）
• inputs / outputs：数据从哪来、到哪去、谁消费（无下游消费的输出是证伪线索）
• states：状态与流转边；有代码时从代码状态字段提取实际状态机，与文档对照，差异记入澄清
• rules：业务规则逐条编号，标注 evidence
• exceptions / dependencies：错误场景行为、上下游依赖

3. 一致性检查（冲突发现）

• 文档内部矛盾：同一文档不同位置对同一功能的描述不一致
• 跨文档矛盾：PRD 与技术设计的规则 / 流程 / 字段不一致
• 文档 vs 代码（有代码时）：按 ../core/evidence.md 静态裁决规则——默认以代码为准，偏离记录并提交澄清