edit | blame | history | raw

需求设计

创建人员:<创建人员>
文件职责:记录需求事项的设计方案、输入输出、处理口径、验收方式和进入下游体系的条件。
管理规范/模板:../../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 下游去向 最新结论
<设计名称> 草案 / 待审 / 通过 / 驳回 / 暂停 需求 / 开发 / 实验 / 案例分析 / 归档 <一句话结论>

3. 需求设计记录模板

<设计名称>

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

3.0 流程分流判断

本事项属于:

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

判断理由:

<为什么走这条流程。>

需要先写的需求文档:

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

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 下游交接

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

交接说明:

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

3.9 审核记录

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