4、需求整理与结构化：需求分类、优先级排序与SRS编写要点
需求收集阶段结束后，我们往往面对的是大量零散、口语化、甚至相互矛盾的原始信息。如果直接进入方案设计，极易出现“理解偏差”和“范围蔓延”。需求整理与结构化的核心价值，在于将“用户说了什么”转化为“系统需要做什么”的严谨工程语言。本章将围绕需求分类、优先级排序（MoSCoW与KANO模型）以及需求规格说明书（SRS）的编写要点展开，帮助您建立一套从“混沌输入”到“结构化输出”的标准化处理流水线。
4.1 需求分类：建立统一的理解框架
4.1.1 核心原理：为什么分类是结构化的第一步
原始需求往往混杂着用户的愿望、抱怨、技术设想甚至临时起意。若不进行分类，后续的优先级排序和方案设计将无从下手。分类的本质是为每个需求打上可管理的标签，使团队能够用统一的语言讨论“做什么”和“做到什么程度”。常见的分类维度包括功能、性能、体验和约束，这四类需求在方案设计中的关注点和验证方式截然不同。
4.1.2 四类需求的判断方法与操作流程
| 需求类型 | 判断标准（回答什么问题） | 典型示例 | 验证方式 |
|---|---|---|---|
| 功能需求 | 系统“做什么”？输入→处理→输出 | “用户可以通过手机号+验证码登录” | 功能测试用例 |
| 性能需求 | 系统“做到多快/多稳”？可量化指标 | “登录接口P95响应时间小于800ms” | 压测/性能基准 |
| 体验需求 | 用户“感觉如何”？主观+可度量 | “新用户首次登录引导不超过3步” | 可用性测试/问卷 |
| 约束条件 | 系统“必须在什么限制下做”？ | “必须兼容iOS 15及以上版本” | 环境检查/合规审计 |
操作流程建议：在需求评审会上，逐条朗读原始需求，由产品经理、技术负责人和测试负责人共同判定类型。对于模糊需求，使用“如果……那么……”句式进行澄清。例如，“系统要快”应转化为“如果用户点击查询按钮，那么系统应在2秒内返回结果”。
4.1.3 案例拆解：一个“简单”报表需求的分类过程
背景：某制造企业客户提出：“我们需要一个生产报表，能看每天的产量和不良率。”
初始现象：需求看似简单，但直接开发后客户反馈“不是我们想要的”。
分析过程：通过追问，将原始需求拆解为四类：
- 功能：按日期、产线、班次维度展示产量与不良率；支持导出Excel。
- 性能：报表打开时间不超过3秒；数据刷新延迟不超过5分钟。
- 体验：关键指标（不良率）需用红色高亮；支持图表切换（柱状图/折线图）。
- 约束：数据源来自现有MES系统数据库，只读权限；报表需嵌入现有OA系统。
结果对比：分类前，开发团队按“做一个报表页面”理解，耗时2周；分类后，明确性能约束（3秒打开）导致需要增加数据预聚合表，体验需求（图表切换）需要引入前端图表库。最终方案调整后，客户验收一次通过。
复盘经验：分类不是文书工作，而是风险识别过程。性能与约束类需求往往决定技术架构，功能与体验类需求决定交互细节。
4.1.4 常见误区与总结
总结：需求分类是后续所有工作的地基。建议使用“四象限检查法”：每一条需求都问自己——它改变系统行为吗？（功能）它影响系统效率吗？（性能）它影响用户感受吗？（体验）它受外部限制吗？（约束）。至少命中一个象限，否则该需求应被质疑其必要性。
4.2 需求优先级排序：MoSCoW与KANO模型实战
4.2.1 核心原理：为什么不能“都要”
资源（时间、人力、预算）永远有限。优先级排序的目标是在约束条件下最大化交付价值。MoSCoW法从项目成功标准出发，回答“哪些需求是项目存活的关键”；KANO模型从用户满意度出发，回答“哪些需求能带来惊喜”。两者结合，既能保证底线，又能创造亮点。
4.2.2 判断方法：MoSCoW操作清单
- Must Have（必须有）：如果没有该需求，解决方案无法上线或失去核心价值。例如，支付系统的“订单创建”功能。
- Should Have（应该有）：重要但可临时绕过，有变通方案。例如，报表的“导出PDF”功能，可先让用户截图。
- Could Have（可以有）：锦上添花，提升体验但非核心。例如，深色模式。
- Won't Have（这次不做）：明确排除，防止范围蔓延。例如，客户提出的“AI智能预测”功能，本阶段不实现。
4.2.3 KANO模型：识别“惊喜点”
| 需求属性 | 用户感知 | 提供时 | 不提供时 | 策略 |
|---|---|---|---|---|
| 基本型 | 理所当然 | 无感 | 极度不满 | 必须做，但不必宣传 |
| 期望型 | 线性相关 | 满意度提升 | 满意度下降 | 投入越多越好，是竞争关键 |
| 兴奋型 | 惊喜 | 满意度大幅提升 | 无感 | 选择性投入，制造差异化 |
操作流程：设计KANO问卷时，对每个功能设置正向和反向两个问题（“如果提供此功能，您感觉如何？”/“如果不提供，您感觉如何？”）。根据回答组合查表判定属性。例如，正向回答“喜欢”，反向回答“无所谓”，则为兴奋型。
4.2.4 常见误区与总结
总结：优先级排序是业务价值与技术风险的平衡。建议采用“双维度打分法”：业务价值（1-5分）× 技术风险（1-5分），价值高且风险低的需求优先做，价值低且风险高的需求坚决不做。
4.3 需求规格说明书（SRS）编写要点
4.3.1 核心原理：SRS是“契约”而非“文档”
SRS（Software Requirements Specification）是需求方与开发方之间的技术契约。它的核心质量属性是可验证性——每一条需求都应能通过测试或检查来确认“是否实现”。一份好的SRS能有效减少开发过程中的需求变更，降低返工成本。
4.3.2 SRS编写的关键操作流程
- 定义系统边界：明确“系统做什么”和“系统不做什么”。使用上下文图或用例图辅助。
- 编写功能需求：使用“用户+动作+对象+约束”的句式。例如，“已登录用户（用户）可以（动作）下载（对象）PDF格式的月度报表（约束）”。
- 量化性能指标：避免“响应快”这类模糊描述，必须写“在100并发用户下，登录接口的P95响应时间小于2秒”。
- 定义外部接口：包括硬件接口、软件接口、通信接口。明确协议、数据格式、频率。
- 列出验收标准：每个功能模块对应一条可执行的验收测试场景。
4.3.3 SRS编写模板与案例拆解
| SRS章节 | 编写要点 | 反面示例 | 正面示例 |
|---|---|---|---|
| 1. 引言 | 目的、范围、术语 | “本系统旨在提高效率” | “本SRS定义XX生产管理系统的功能与非功能需求，适用于XX工厂的A车间” |
| 2. 总体描述 | 产品视角、用户特征、约束 | “用户是操作工” | “用户为车间班组长，具备基础电脑操作能力，需在10分钟内完成班次报工” |
| 3. 功能需求 | 编号、描述、优先级 | “系统应支持报工” | “FR-001：班组长选择产线、班次后，录入合格数与不良数，点击提交，系统校验总和不超过计划数” |
| 4. 性能需求 | 可量化指标 | “系统响应要快” | “PR-001：在100用户并发下，报工提交接口的P95响应时间≤1.5秒” |
| 5. 验收标准 | 可测试场景 | “界面友好” | “AC-001：使用Chrome浏览器，输入正确账号密码，点击登录，3秒内跳转至首页” |
4.3.4 常见误区与总结
总结：SRS编写的黄金法则是“测试人员能根据SRS写出测试用例，开发人员能根据SRS写出代码”。在评审SRS时，邀请测试负责人提前介入，从“可测试性”角度审视每一条需求。如果一条需求无法设计测试用例，说明它写得太模糊。