需求分析实战（下）：需求优先级排序与SRS核心要素

上一讲我们聊了怎么把用户说的“我要一个快的系统”翻译成技术语言。但需求收集完了，问题来了——资源有限，时间紧迫，先做哪个？

我见过太多团队，一上来就铺开所有需求，结果三个月过去了，核心功能还没跑通。说白了，需求优先级排序不是“哪个老板声音大就做哪个”，它需要一套科学的方法。

MoSCoW法则：四象限里的生存智慧

MoSCoW 法则是我个人最常用的优先级排序工具。它把需求分成四类：

分类	含义	占比建议	典型例子
Must have	必须有，否则系统无法上线	20-30%	用户登录、支付核心链路
Should have	应该有，但可以找替代方案	30-40%	消息推送、数据导出
Could have	可以有，锦上添花	20-30%	深色模式、动画效果
Won't have	这次不做，以后再说	10-20%	多语言支持、第三方集成

排序实操：从需求池到优先级矩阵

光有分类还不够，你得有具体的操作步骤。我习惯这样做：

1. 先列需求池——把所有需求写下来，别管优先级
2. 做价值评估——每个需求对业务目标的贡献度，1-5 分
3. 做成本评估——开发成本、风险、依赖，1-5 分
4. 画四象限图——横轴是价值，纵轴是成本
5. 应用 MoSCoW——高价值低成本 = Must have，低价值高成本 = Won't have

需求规格说明书（SRS）的核心要素

优先级排好了，下一步就是写 SRS。很多人觉得 SRS 就是“把需求写下来”，其实不然。一份好的 SRS，是开发、测试、产品三方之间的契约。

我见过最糟糕的 SRS 是什么样？一句话：“用户可以在系统中查看订单。” 然后开发做了，测试测了，上线后用户说：“我要的是按时间筛选、按状态分组、还能导出 Excel。”——你看，一句话的 SRS 就是一颗定时炸弹。

SRS 的六大核心要素

要素	说明	常见坑
1. 功能需求	系统“做什么”，每个功能点要可验证	写得太抽象，比如“系统应支持高效查询”
2. 非功能需求	性能、安全、可用性、可扩展性	忽略性能指标，上线后才发现扛不住并发
3. 接口定义	内部模块之间、外部系统之间的交互	接口参数不明确，联调时反复改
4. 数据需求	数据模型、存储方式、数据流转	没考虑数据量增长，半年后数据库撑不住
5. 约束条件	技术栈、合规要求、硬件环境	开发到一半发现客户只能用特定数据库
6. 验收标准	每个需求怎么才算“做完”	没有验收标准，开发和测试各说各话

SRS 的编写模板（简化版）

下面是我常用的 SRS 章节结构，你可以直接拿来用：

1. 引言
   1.1 目的
   1.2 范围
   1.3 定义与缩写

2. 总体描述
   2.1 产品视角
   2.2 用户特征
   2.3 假设与依赖

3. 功能需求
   3.1 模块 A
      3.1.1 功能 A-1（优先级：Must have）
      3.1.2 功能 A-2（优先级：Should have）
   3.2 模块 B

4. 非功能需求
   4.1 性能指标
   4.2 安全性
   4.3 可用性

5. 接口需求
   5.1 内部接口
   5.2 外部接口

6. 数据需求
   6.1 数据模型
   6.2 数据字典

7. 验收标准
   7.1 功能验收
   7.2 性能验收

需求优先级与 SRS 的联动

你可能会问：优先级和 SRS 有什么关系？关系大了。

在 SRS 中，每个功能需求都应该标注优先级。这样开发团队可以按优先级排迭代，测试团队可以按优先级安排测试用例。我习惯在 SRS 的功能需求表格里加一列“优先级”，比如：

功能编号	功能名称	优先级	验收标准
F-001	用户注册	Must have	手机号+验证码，3 分钟内完成注册
F-002	用户头像上传	Could have	支持 jpg/png，大小不超过 2MB
F-003	第三方登录	Won't have	本次迭代不做，列入 Roadmap V2.0

这样做的好处是，当项目进度紧张时，你可以直接砍掉 Could have 和 Won't have 的需求，而 Must have 和 Should have 的边界是清晰的。

本章知识结构图

下面这张图展示了需求优先级排序到 SRS 编写的完整链路：

你看，整个链路是通的：从需求池出发，用 MoSCoW 法则排序，然后落到 SRS 中，每个需求都带上优先级标签。这样开发、测试、产品三方都清楚——哪些是底线，哪些可以砍。