requirement-engineering

需求工程

把模糊想法转化为完整、无歧义、可验证的需求文档。包含两个阶段：收集（brainstorming）和验证（validation）。

只负责"要做什么"，不负责"怎么做"——技术方案在 architecture-designer / writing-plans 完成。

协调

# 建 session（若尚未创建）
node scripts/orchestration/session.cjs init <任务名>
# 需求文档写入 .orchestration/<session>/architect/requirements.md
# 验证结论追加到同文件；通过后进入方案设计 phase

阶段 1：收集（brainstorming）

1. 探索项目上下文 — 读 文件、文档、近期提交，了解现状
2. 逐个提问澄清 — 每条消息只问一个问题，优先选择题
3. 识别用户场景 — 谁用？什么场景？期望什么结果？
4. 定义功能边界 — 做什么、不做什么、优先级
5. 撰写需求文档 — 保存到 .orchestration/<session>/architect/requirements.md

需求文档结构

# [功能名] 需求文档

## 背景与目的
为什么做？解决什么问题？

## 用户场景
- 场景 1：作为 [角色]，我希望 [行为]，以便 [价值]

## 功能需求（每条可验证）
- [ ] FR-1：[具体描述 + 通过/不通过标准]

## 约束条件
- 性能 / 兼容性 / 安全要求

## 非功能需求
- ...

## 范围排除（不做什么）
- ...

## 成功标准
- ...

阶段 2：验证（validation）

对收集到的需求逐条验证，不通过不得进入设计。

维度	检查项
完整性	每场景有对应 FR？异常/非功能需求齐全？范围排除明确？
可行性	技术可实现？时间合理？与现有系统兼容？
无歧义性	每条只有一种理解？数值/行为边界明确（"快速"→"200ms 内"）？
一致性	条目间有矛盾？约束冲突？优先级清晰？
可验证性	有明确通过/不通过标准？

验证结论（追加到需求文档末尾）

---

## 需求验证结论

**验证日期**：YYYY-MM-DD
**结论**：通过 / 有条件通过 / 不通过

- [x] 完整性 / 可行性 / 无歧义性 / 一致性 / 可验证性：通过

### 发现的问题（如有）
1. [问题] → [修正方案]

### 修改记录
- [修改内容]

铁律

1. 此阶段不做技术方案设计、不选择技术栈、不讨论架构
2. 每条消息只问一个问题
3. 每条需求必须可验证（明确通过/不通过标准）
4. 必须产出需求文档并获得用户确认才能推进
5. 验证发现的问题必须现场修正，不得留到后续阶段

Red Flags — 停下来

信号	行动
开始讨论技术方案	技术方案属于设计阶段，打住
用户说"直接做吧"	先完成最小需求文档
需求描述了多个独立系统	先帮用户拆解为子项目
需求中有"待定""之后再说"	现在确定或标记为明确的开放问题
需求可以被两种方式理解	选定一种并明确
需求之间有矛盾	与用户澄清并修正
想跳过用户确认	用户确认是必须的门禁
想跳过验证直接设计	不允许

与其他 skill 的协作

• 若涉及 UI/UX，可派遣对应 design agent 参与需求收集
• 通过验证的需求文档是 architecture-designer / writing-plans 的核心输入