# 需求设计

创建人员：<创建人员>  
文件职责：记录需求事项的设计方案、输入输出、处理口径、验收方式和进入下游体系的条件。  
管理规范/模板：../../common/pro-doc/需求规范.md；../../common/pro-doc/需求设计模版.md。  
引用文件：需求总纲.md；需求执行日志.md；需求审计报告.md；需求问题记录.md；需求规范.md；需求文档范本.md。  
记录方式：append-only；每个需求事项或设计版本追加一条设计记录，最新设计放在文档末尾。

## 1. 文档作用

本文件用于回答：

1. 这个需求事项准备怎么做。
2. 设计是否能满足需求总纲里的目标。
3. 输入、输出、边界、验收是什么。
4. 是否需要转成需求、开发、实验或案例分析。
5. 审核员应该按什么口径审核。

## 2. 设计索引

| 设计 ID | 需求事项 ID | 设计名称 | 当前状态 | 审计 ID | 下游去向 | 最新结论 |
|---|---|---|---|---|---|---|
| <DESIGN-PRO-001-V1> | <PRO-001> | <设计名称> | 草案 / 待审 / 通过 / 驳回 / 暂停 | <AUDIT-ID> | 需求 / 开发 / 实验 / 案例分析 / 归档 | <一句话结论> |

## 3. 需求设计记录模板

### <DESIGN-PRO-001-V1> <设计名称>

记录时间：<YYYY-MM-DD HH:mm:ss>  
设计人：<AI 或人员>  
关联需求事项：<PRO-001>  
当前状态：草案 / 待审 / 通过 / 驳回 / 暂停  

#### 3.0 流程分流判断

本事项属于：

1. 大量需求修改：是 / 否。
2. 少量需求修改：是 / 否。
3. 第一版复杂需求交付：是 / 否。
4. 第一版轻量需求交付：是 / 否。

判断理由：

```text
<为什么走这条流程。>
```

需要先写的需求文档：

| 文档 | 是否需要 | 原因 | 路径 |
|---|---|---|---|
| 需求方案文档 | 是 / 否 | <原因> | <路径或不适用> |
| 架构文档 | 是 / 否 | <原因> | <路径或不适用> |
| 模块说明文档 | 是 / 否 | <原因> | <路径或不适用> |
| 核心流程文档 | 是 / 否 | <原因> | <路径或不适用> |

#### 3.1 目标对齐

需求总纲目标：

1. <从需求总纲引用的目标>

本设计如何满足目标：

1. <设计动作和目标之间的关系>

#### 3.2 设计原则

原则：

1. 不把需求设计写成代码实现细节。
2. 不把轻量需求做成重型流程。
3. 不把实验、开发、案例分析的职责塞回需求体系。
4. 关键口径必须能被审核员复核。

项目补充原则：

1. <如有>

#### 3.3 输入

| 输入项 | 来源 | 必需 | 说明 |
|---|---|---|---|
| <输入项> | <路径 / 聊天 / 上游结论> | 是 / 否 | <说明> |

#### 3.4 输出

| 输出项 | 类型 | 路径或命名 | 是否正式产物 | 说明 |
|---|---|---|---|---|
| <输出项> | 需求文档 / 需求文档 / 策略说明 / 规则说明 / 其他 | <路径> | 是 / 否 | <说明> |

#### 3.5 处理流程

1. <步骤 1>
2. <步骤 2>
3. <步骤 3>

关键节点必须写入 `需求执行日志.md`。

#### 3.6 边界和不做事项

不做：

1. <不做事项>

不允许：

1. <不允许事项>

#### 3.7 验收方式

验收标准：

1. 设计目标能覆盖需求总纲目标。
2. 输入输出清楚。
3. 下游去向清楚。
4. 不存在会导致实现分叉的模糊口径。
5. 不存在不必要的重型 gate 或层层加码。

需要审核：

1. 需求设计审核。
2. 如产出需求文档，还需要需求口径审核。

#### 3.8 下游交接

是否进入需求文档：是 / 否  
是否进入开发体系：是 / 否  
是否进入实验体系：是 / 否  
是否进入案例分析体系：是 / 否  
是否仅归档：是 / 否  

交接说明：

```text
<交接给哪个体系、交接什么、边界是什么。>
```

#### 3.9 审核记录

| 审核 ID | 审核人 | 结论 | 关键问题 | 复审状态 |
|---|---|---|---|---|
| <AUDIT-ID> | <审核人> | 通过 / 驳回 / 有条件通过 | <问题摘要> | <状态> |