📚 课程目录第3章诊断前置条件与输入物

3. 诊断前置条件与输入物

3.1 适用场景

本章节内容适用于以下诊断场景中，需求分析人员在完成初始需求收集与文档化之后、执行正式偏差诊断之前：

需求文档已定稿但未评审：原始需求文档已经撰写完成，需要系统性检查理解是否一致。
多方沟通产生多个版本记录：与客户、产品经理、开发团队沟通频繁，形成多份会议纪要或聊天记录。
验收标准已初步拟定：测试团队或产品方已经起草了验收标准草案，但尚未与开发对齐。
需求变更触发重新评估：项目中后期发生需求变更，需要基于最新文档和记录进行偏差诊断。

3.2 前置条件

在执行本章诊断流程前，必须确认以下条件全部满足：

需求状态锁定：当前待诊断的需求版本已被冻结，不允许同时进行修改。
沟通记录可追溯：所有相关沟通记录（会议纪要、即时通讯截图、邮件）均已整理并归档至统一目录。
验收标准可量化：验收标准条目不得包含“大致”、“可能”、“优化”等模糊词汇。
人员角色明确：确认需求提出方、需求记录方、开发方已分别指派对应联系人。

注意：如果原始需求文档未经过至少一次内部审查（同行审阅），或沟通记录存在明显断档（如缺失关键决策会议纪要），应立即终止当前诊断流程，返回需求收集阶段进行补充。

3.3 输入物清单

每项输入物都必须满足各自的准入标准，否则视为输入物不完整，不得进入正式诊断流程。

输入物名称	定义	准入标准
原始需求文档	由需求分析人员编写，描述业务需求、功能需求和非功能需求的正式文档。	包含版本号、编写日期、编写人功能点列表完整无未解决的待办事项（TBD）
沟通记录	全量需求沟通过程记录，包括正式会议纪要、非正式线上讨论、邮件往来。	按时间线排序每条记录包含参与人、讨论结论关键决策点有明确标记
验收标准	测试团队或业务方制定的，用于判断需求是否被正确实现的通过性条件集合。	每条标准独立且可验证有明确的预期输出或行为不能含有否定性模糊条件（如“无明显问题”）

3.4 输入物之间的关系结构

以下 SVG 展示了三项输入物如何共同支撑“偏差诊断”核心流程。注意，任何一项输入物出现质量问题，都会导致诊断结果不可信。

3.5 操作步骤：输入物准入检查

正式诊断前，须对三项输入物执行以下检查步骤。任何一步检查不通过，都按异常处理规则处置。

步骤一：核对版本一致性。确认原始需求文档的版本号与沟通记录中最终确认的版本号一致，核对验收标准引用的需求编号是否在文档内存在。
步骤二：完整性扫查。逐条核对原始需求文档功能清单，对比沟通记录中所有讨论过的功能点，确保无遗漏。同时检查验收标准数量是否不少于需求文档中标注为“必须实现”的功能点数量。
步骤三：模糊性标记。阅读原始需求文档与验收标准，标记出所有含有程度副词（如“显著”、“快速”、“友好”）或未定义术语（如“适当处理”）的条目，归类为“潜在偏差区”。
步骤四：沟通回溯。针对步骤三中标记的潜在偏差区，回溯对应的沟通记录，查找是否有对应的讨论结论或决策。如果找不到，则标记为“沟通缺失”问题。
步骤五：记录基线。将检查结果填入《输入物准入检查表》，并由需求提出方、记录方、开发方三方签字确认基线。

检查表模板示例：

| 需求ID | 文档中存在 | 沟通中讨论 | 验收标准覆盖 | 潜在偏差标记 | 备注 |
|--------|------------|-------------|---------------|----------------|------|
| F-001  | 是         | 是          | 是            | 无             |      |
| F-002  | 是         | 否          | 否            | 沟通缺失       | 需补会 |
| NF-001 | 是         | 是          | 否            | 验收未覆盖     | 待补充 |

3.6 输出物

完成输入物准入检查后，必须输出以下材料：

输入物准入检查表：包含每项需求的文档、沟通、验收标记结果。
基线确认记录：三方签字确认的版本快照证明。
待处理问题清单：检查过程中发现的沟通缺失、验收标准缺失、文档模糊等问题，分优先级列出。

3.7 责任边界

角色	责任	禁止行为
需求分析人员	提供原始需求文档，主导检查流程，填写检查表。	不得在未完成基线确认的情况下提前启动诊断。
项目经理	组织沟通记录归档，确保沟通记录可追溯。	不得截留或删除任何沟通原始记录。
测试人员	提供验收标准草案，配合检查验收标准是否可量化。	不得在验收标准中使用主观性描述。
开发代表	参与基线确认，确认需求文档与验收标准可理解。	不得提出“先做再看”的粗略要求。

3.8 记录材料

所有记录材料必须存档至项目共享空间，命名规则为：[项目编号]_[日期]_输入物检查。

输入物准入检查表（Excel/CSV）
基线确认记录（PDF/带签名的扫描件）
待处理问题清单（Markdown 格式，含问题描述、提出人、提出日期、责任人）
沟通记录索引文件（指向各次沟通原始记录的链接或文件路径）

3.9 异常处理

以下异常情况应按照对应规则处理：

异常类型	具体表现	处理方式
输入物不完整	缺少沟通记录或无验收标准	暂停诊断，通知项目经理补齐材料。补齐后需重新执行3.5节步骤一至五。
版本不一致	文档版本号与沟通记录最终版本号不匹配	定位最新版本，废弃旧版本，更新所有存档后重新开始检查。
模糊性无法消解	标记的潜在偏差区在沟通记录中找不到对应决策，且当前无法联系到相关人	将该条目加入待处理问题清单，优先级设为“高”，等待相关负责人回复后再继续诊断。
基线确认无法完成	某一方拒绝在基线确认记录上签字	组织三方会议，现场解决分歧。若仍无法解决，由项目总监介入仲裁。仲裁前不得进入正式诊断。

经验提示：大多数输入物检查失败发生在“原始需求文档版本混乱”和“沟通记录缺失关键决策”这两个环节。建议在项目启动阶段就建立版本管理规范（如使用 Git 管理需求文档）和会议纪要模版（强制记录决策并附上相关需求编号）。

3.10 验收标准

完成本章节所有流程后，须满足以下验收标准：

完整性验收：输入物检查表覆盖100%的原始需求文档条目。
一致性验收：需求文档、沟通记录、验收标准中引用的需求编号和版本号完全一致。
清晰度验收：检查表中不存在“模糊”标记条目而未在待处理问题清单中记录的情况。
基线验收：三方签字确认记录已存档，签名日期不晚于本章流程启动日期+2个工作日。
归档验收：所有记录材料已按要求命名并放置在项目共享空间指定目录下。