2. 需求类型与层次：业务需求、用户需求、功能需求、非功能需求、需求层次模型

做需求分析这么多年，我见过太多团队在需求上翻车。说白了，很多人连「需求」到底是什么都没搞清楚。

你想想看，产品经理说要「做一个登录功能」，开发就直接开干了。结果做出来，老板说这不是我想要的，用户说这玩意儿太难用。为什么会这样？

嗯，问题就出在——需求是有层次和类型的。不同层次的需求，对应不同角色的关注点。今天我就带你把这层窗户纸捅破。

2.1 业务需求：老板到底想要什么？

业务需求，是最高层次的需求。它回答的是「为什么要做这个系统」。

我在项目中遇到过最典型的例子：某电商平台说要「重构用户中心」。业务需求是什么？不是「把页面做漂亮点」，而是「提升用户复购率15%」。这才是真正的业务需求。

业务需求一般写在《项目章程》或《商业需求文档》里。我建议你拿到需求时，先问三个问题：

1. 这个系统解决了什么业务问题？
2. 怎么衡量成功？指标是什么？
3. 不做会有什么损失？

问完这三个问题，80%的伪需求就现原形了。

2.2 用户需求：用户到底想怎么用？

用户需求，是第二层。它回答的是「用户需要系统做什么」。

举个例子：业务需求是「提升复购率15%」，那用户需求可能就是「用户能快速找到之前买过的商品」「系统能推荐相似商品」「下单流程不超过3步」。

我个人习惯，在收集用户需求时，一定要区分「用户说的」和「用户真正需要的」。

用户需求通常用「用户故事」来描述：

作为 [用户角色]
我希望 [功能描述]
以便 [业务价值]

比如：

作为 老客户
我希望 能一键复购历史订单
以便 节省挑选时间，快速完成购买

2.3 功能需求：系统到底要做什么？

功能需求，是第三层。它回答的是「系统具体要提供什么功能」。

说白了，功能需求就是把用户需求翻译成系统能理解的语言。

用户需求是「一键复购」，功能需求就是：

• 系统提供「历史订单列表」页面
• 每个订单项显示「再次购买」按钮
• 点击后自动将原订单商品加入购物车
• 支持修改数量后再提交

这里要注意，功能需求必须可测试、可验证。我曾经见过一个需求写「系统要流畅」，这根本没法测。应该写成「页面加载时间不超过2秒」。

2.4 非功能需求：系统到底要有多好？

非功能需求，很多人会忽略。但它往往是项目成败的关键。

它回答的是「系统要运行得多好」。包括：

类型	说明	示例
性能	响应速度、吞吐量	并发1000用户时，响应时间<2s
可用性	系统正常运行时间	全年可用性99.9%
安全性	数据保护、权限控制	用户密码必须加密存储
可维护性	代码易读、易修改	模块间耦合度低，支持独立部署
可扩展性	支持未来增长	支持水平扩展，增加节点即可提升性能

非功能需求有个特点：你不提，开发就不会做。但用户用起来就会骂。

我记得有个项目，功能都做完了，上线第一天就崩了。为什么？因为没考虑并发。业务需求说「支持100万用户」，但非功能需求里没写「并发1000时系统不崩溃」。结果上线当天搞活动，直接宕机。

2.5 需求层次模型：怎么串起来？

好了，四种需求都讲完了。但它们不是孤立的，而是有层次关系的。

我常用的需求层次模型是这样的：

业务需求（Why）
    ↓ 分解
用户需求（Who & What）
    ↓ 细化
功能需求（How）
    ↓ 补充
非功能需求（How Well）

你想想看，这个模型就像盖房子：

• 业务需求：为什么要盖房子？（解决居住问题）
• 用户需求：谁住？需要几个房间？（用户画像和场景）
• 功能需求：具体怎么盖？几室几厅？（功能列表）
• 非功能需求：房子要抗震几级？隔音效果如何？（质量标准）

缺了任何一层，房子都盖不好。

2.6 一个完整的例子

最后，我给你一个完整的例子，把四种需求串起来：

项目：某在线教育平台的「作业提交系统」

需求类型	内容
业务需求	提升学生作业完成率20%，减少老师批改工作量30%
用户需求	学生：能快速提交作业，支持图片/文档格式 老师：能在线批改，支持批注和打分
功能需求	1. 学生端：上传文件、查看作业要求、查看批改结果 2. 老师端：查看提交列表、在线批注、打分、发布成绩
非功能需求	1. 支持1000人同时提交，响应时间<3s 2. 文件上传大小限制50MB 3. 数据加密传输，防止泄露

你看，这样一梳理，整个需求就清晰了。开发知道要做什么，测试知道要测什么，老板知道钱花在哪。

嗯，这就是需求层次模型的价值。下一章，我会讲怎么用工具把这些需求管理起来。到时候你就知道，光靠Excel是搞不定的。