4. 需求分析
需求分析是QMS系统开发中最容易被低估、却最决定成败的环节。制造业的质量管理并非一张表单那么简单，它横跨来料、制程、成品、客诉、供应商、体系审核等多个场景，涉及质检员、工艺工程师、质量经理、供应商、客户等多类角色。若需求分析只停留在“做一个不合格品记录页面”，系统上线后必然面临流程走不通、数据对不上、报表没人看的尴尬。本节围绕质量痛点识别、用户故事拆解、功能与非功能需求划分，以及需求规格说明书（SRS）的编写方法展开。
一、从质量痛点出发，而不是从功能出发
制造业质量痛点通常集中在四类：数据孤岛（检验数据在Excel、纸质单据、设备本地系统中分散）、追溯断链（客诉发生时无法快速定位批次、工序、原料、设备参数）、响应滞后（不合格品已流入下道工序才被发现）、责任模糊（异常处理无闭环、无时限、无升级机制）。需求分析的第一步，是把这些痛点转译为可验证的业务目标，例如“将客诉追溯时间从2天缩短到10分钟”“将不合格品处置闭环率提升到98%”。
二、用户故事：把角色诉求写成可验收的句子
用户故事推荐采用“作为<角色>，我希望<目标>，以便<价值>”的格式，并附上验收条件。QMS中典型用户故事如下：
- 作为IQC检验员，我希望扫描来料批次条码后自动带出供应商、物料、检验标准，以便减少手工录入错误。
- 作为制程质量工程师，我希望SPC超控时系统自动触发异常单并通知责任人，以便在30分钟内介入。
- 作为质量经理，我希望按供应商、产线、缺陷代码查看月度PPM趋势，以便在管理评审中定位重点改善对象。
- 作为体系工程师，我希望内审不符合项自动关联整改任务与验证证据，以便闭环留痕。
用户故事不是需求清单的终点，而是与业务方对齐的沟通载体。每个故事应能映射到具体的验收场景，避免“系统要灵活”“报表要好看”这类无法验收的表述。
三、功能需求与非功能需求的分层
功能需求回答“系统做什么”，非功能需求回答“系统做到什么程度”。QMS的功能需求通常按模块划分：供应商管理、来料检验、制程检验、成品检验、不合格品处理、纠正预防措施（CAPA）、SPC、量具管理、审核管理、客诉管理、质量报表。非功能需求则包括性能、并发、可用性、安全、合规、可维护性等。
| 需求类型 | 典型条目 | 验收指标示例 |
|---|---|---|
| 功能需求 | 不合格品自动触发CAPA并分派责任人 | 触发成功率100%，分派延迟≤5秒 |
| 功能需求 | 批次正反向追溯（原料→成品、成品→原料） | 单次追溯响应≤3秒，覆盖≥5级BOM |
| 非功能需求 | 检验数据并发写入 | 200并发用户下写入响应≤2秒 |
| 非功能需求 | 质量记录留存与审计 | 记录不可篡改，留存≥10年，操作日志可查 |
| 非功能需求 | 与ERP/MES集成 | 接口可用率≥99.5%，异常自动重试 |
非功能需求若不在需求阶段量化，后期往往变成“性能优化”的无底洞。建议对每条非功能需求写明度量方式、测试条件和阈值。
四、需求规格说明书（SRS）的编写
SRS是需求分析的正式输出，也是开发、测试、验收的共同基线。一份可落地的QMS SRS通常包含：范围与目标、干系人与角色、业务流程与场景、功能需求清单、非功能需求、数据字典与接口、验收标准、假设与约束、变更记录。编写时遵循“可追溯、可验证、无歧义”三原则：每条需求有唯一编号，能追溯到用户故事或痛点，并能设计出对应测试用例。
需求编号：QMS-FR-012
需求名称：不合格品处置闭环
来源故事：US-007 制程异常自动触发
优先级：高
描述：当检验判定为不合格时，系统自动生成不合格品单，
按缺陷等级分派至责任工序，要求24小时内提交原因分析与纠正措施，
超时自动升级至质量经理。
验收条件：
1) 不合格判定后5秒内生成单据；
2) 责任人收到站内信与邮件通知；
3) 超24小时未处理，状态变为“已升级”并通知质量经理；
4) 处置完成后需上传验证证据方可关闭。
关联接口：MES工单接口、ERP物料批次接口
五、案例与常见误区
某汽车零部件企业在QMS一期中，业务方提出“所有检验都要能自定义”。开发团队照做后，系统配置项超过300个，质检员培训成本极高，上线三个月仍有大量数据未录入。复盘发现，真正高频的检验场景只有12类，其余属于低频长尾。二期改为“标准场景预置+少量可配置”，录入效率提升明显。这说明需求分析要区分高频刚需与低频弹性，不能把“灵活”当作默认答案。
需求分析的质量，直接决定QMS是“能用”还是“好用”。把痛点讲清楚、把故事写具体、把需求分层次、把SRS写成可验收的基线，后续的设计、开发与验证才有稳固的起点。