| | |
| | | # 需求规范 |
| | | # 需求规范 |
| | | |
| | | 创建人员:Codex |
| | | 文件职责:定义通用需求文档写法、需求审核流程、需求进入编码阶段的条件。 |
| | | 管理规范/模板:../../全局规范.md;产品规范.md;产品审核规范.md;需求文档范本.md。 |
| | | 引用文件:产品规范.md;产品审核规范.md;需求文档范本.md;../dev-doc/编码规范.md。 |
| | | 管理规范/模板:../../全局规范.md;需求规范.md;需求审核规范.md;需求文档范本.md。 |
| | | 引用文件:需求规范.md;需求审核规范.md;需求文档范本.md;../dev-doc/编码规范.md。 |
| | | 记录方式:全局需求写作规范;需求写法、需求审核流程或进入编码阶段的条件变化时更新。 |
| | | |
| | | ## 1. 目标 |
| | |
| | | |
| | | 需求按规模分两类处理,不要把所有需求都套进重流程。 |
| | | |
| | | 需求文档进入审核前,必须先判断上游产品流程: |
| | | 需求文档进入审核前,必须先判断上游需求流程: |
| | | |
| | | 1. 大量产品修改:必须先有产品方案文档,且产品审核通过。 |
| | | 2. 少量产品修改:可以直接改需求文档,但必须记录修改背景和一致性检查结论。 |
| | | 3. 第一版复杂产品交付:必须先有架构文档、模块说明文档、核心流程文档,且产品审核通过。 |
| | | 4. 第一版轻量产品交付:可以直接进入需求文档书写流程。 |
| | | 1. 大量需求修改:必须先有需求方案文档,且需求审核通过。 |
| | | 2. 少量需求修改:可以直接改需求文档,但必须记录修改背景和一致性检查结论。 |
| | | 3. 第一版复杂需求交付:必须先有架构文档、模块说明文档、核心流程文档,且需求审核通过。 |
| | | 4. 第一版轻量需求交付:可以直接进入需求文档书写流程。 |
| | | |
| | | 如果对应上游文档不存在,需求文档必须说明“不适用”和原因,不能假装已经参考。 |
| | | |
| | |
| | | 3. 写清输入、输出、字段、状态、错误处理。 |
| | | 4. 写清核心处理流程和不做事项。 |
| | | 5. 写清验收标准,区分主流程必过项和外部诊断项。 |
| | | 6. 对照产品方案或三大文档做一致性检查。 |
| | | 6. 对照需求方案或三大文档做一致性检查。 |
| | | 7. 检查需求之间是否存在冲突或重复定义。 |
| | | 8. 交审核员审核。 |
| | | 9. 审核员通过后,需求完成。 |
| | |
| | | |
| | | 如果实现者可能按两种方式理解,就还不是合格需求。 |
| | | |
| | | ## 13A. 产品上游一致性检查 |
| | | ## 13A. 需求上游一致性检查 |
| | | |
| | | 无论新写需求还是修改需求,都必须做产品上游一致性检查。 |
| | | 无论新写需求还是修改需求,都必须做需求上游一致性检查。 |
| | | |
| | | 检查对象: |
| | | |
| | | 1. 产品方案文档:有就参考,没有就说明不适用。 |
| | | 1. 需求方案文档:有就参考,没有就说明不适用。 |
| | | 2. 架构文档:有就参考,没有就说明不适用。 |
| | | 3. 模块说明文档:有就参考,没有就说明不适用。 |
| | | 4. 核心流程文档:有就参考,没有就说明不适用。 |
| | | 5. 产品总纲里的目标、背景、边界和关键聊天要求。 |
| | | 5. 需求总纲里的目标、背景、边界和关键聊天要求。 |
| | | 6. 相关旧需求文档。 |
| | | |
| | | 检查结论必须能回答: |
| | | |
| | | 1. 需求是否和产品方案一致。 |
| | | 1. 需求是否和需求方案一致。 |
| | | 2. 需求是否和架构、模块说明、核心流程一致。 |
| | | 3. 是否有冲突。 |
| | | 4. 是否漏写必须实现的需求。 |
| | | 5. 是否引入产品文档没有授权的新口径。 |
| | | 5. 是否引入需求文档没有授权的新口径。 |
| | | 6. 是否把小需求写成重型系统。 |
| | | |
| | | 推荐在需求文档中增加“产品上游一致性检查”小节。轻量需求也要写,但可以很短。 |
| | | 推荐在需求文档中增加“需求上游一致性检查”小节。轻量需求也要写,但可以很短。 |
| | | |
| | | ## 14. 公式、规则和阈值 |
| | | |