需求三层次：业务、用户与系统需求的拆解与实战

我独立带第一个项目的时候，被需求坑到半夜改设计文档。客户当初说得轻巧：“我们要做一个在线课程学习平台。”我拉着开发组列功能：课程列表、视频播放、笔记、评论、支付……六十多个功能点，原型图画了一周，开发做了一个月，上线后用户说得最多的一句话却是：“功能不少，但不是我想要的那种东西。”

后来我把《软件工程导论》翻烂了，才真正想明白一个道理：需求从来不是一个扁平的功能清单，它天生有三个层次。你不在需求阶段把这三层拆明白，后面的设计、开发、测试、上线全都会跟着歪。今天就用正反对比例子，把这个“需求三层次”一次讲透。

1. 先搞清楚：需求三层次到底在讲什么

上手之前，先问一个问题：为什么软件工程领域要给“需求”贴上三层标签？因为它对应的是不同人的不同视角。老板嘴里说的“需求”、用户心里想的“需求”、开发手头要做的“需求”，根本不是同一个东西。强行混在一个清单里，翻车只是时间问题。

1.1 一个表格讲清三层次的关系

软件工程里最常用的分层方式，是把需求拆成三层：业务需求、用户需求、系统需求。这三层分别回答三个不同的问题：为什么做、谁要用、做成什么样。

这三层不是三个孤立的清单，而是一条推导链：先定业务需求，再推导出用户需求，最后落到系统需求。随便抽掉任何一层，链条都会断。最典型的情况是，老板定了个业务目标，产品经理没拆解用户场景，直接让开发写功能，开发接到一个“看起来很清楚、实际上没头没尾”的需求清单，最后做出来的东西自然对不上所有人的预期。

1.2 为什么要拆层：不是学术洁癖，是沟通成本决定的

可能有人觉得，分层是软件工程导论里的条条框框，真实项目哪有空管这个。但恰恰是这种想法，埋下了大量返工隐患。

拆层本质上是解决沟通错位。业务需求对应的是资源投入方，他们不太关心你用什么技术、怎么设计数据库，只管结果和投入产出。用户需求对应的是真实使用者，他们不关心接口怎么写，只关心好不好用、能不能帮我解决实际问题。系统需求对应的是实现团队，他们必须有明确的输入、输出、边界和性能门槛，否则没法排期，也没法写测试用例。

如果三层信息搅在一份文档里，每个人看到的都是错位信息。老板说“提升用户体验”时，说的是业务目标；产品经理听到后理解为“改版UI”，这是在往用户需求上套；开发听到后又容易理解成“优化代码性能”，落到系统需求上了。三方想的根本不是同一件事，项目还没开工就已经各走各路。把三层拆开，本质上是让每种信息精准到达对应的人手上，让老板去确认业务目标，让产品去确认用户场景，让开发去确认系统边界。这一层想明白了，后面所有方法才有意义。

2. 一个例子看懂：在线教育平台的正反需求拆解

光讲定义没用，拿具体例子比对一下，效果立竿见影。下面用在线教育平台做例子，先给一个反面案例，再给一个正面案例，看看同一件事在三层次需求下到底差在哪。

2.1 反面案例：一份只有“功能清单”的需求文档

假设产品经理拿着老板一句“做个学习平台”，直接开工写需求。项目赶，文档也简单，最后交付给开发的是一份这样的清单：

• 课程列表页：展示课程卡片，点击进入详情页，支持收藏
• 课程详情页：展示课程介绍、讲师信息，支持购买
• 播放页：支持视频播放，支持在线记笔记
• 个人中心：展示已购课程，展示学习记录

表面看挺完整对吧？该有的页面都有。可这恰恰是典型的三层混淆，或者说只有一层：功能动作。它没回答几个最致命的问题：这个平台为什么要存在？目标是什么？谁会来用，在什么场景下用？播放卡顿到什么程度算不可接受？学习记录保留多久、按什么规则展示？

开发拿到这份清单后，只能靠猜。猜的结果就是：课程推荐靠运营手动配置，用户在地铁上打开视频一直转圈，播放到一半退出，下次进来从头开始。用户学到哪了全靠自己记，平台一点忙都帮不上。

上线后客户抱怨一堆，产品经理第一反应是“开发做得不好”，但真相是需求阶段就埋了雷。需求文档没写“用户是在碎片化、移动化场景下学习”，开发根本不知道需要断点续播和弱网优化能力。没有用户需求层的场景描述，系统需求层自然一片空白。

2.2 正面案例：从业务目标倒推到系统需求

同一个在线课程平台，用三层次推导一遍，画风立刻不一样。

业务需求先定方向。公司发现注册用户很多，但是完课率只有35%，复购率连续两个季度下滑。业务目标非常明确：三个月内把完课率从35%提升到50%，带动复购率提升10%。

有了业务目标，再去拆用户需求。对用户访谈后发现，目标用户集中在在职备考的年轻人。他们最典型的使用场景是：工作日在地铁上刷课、午休看20分钟、考前集中复习。核心痛点也浮出水面：不知道自己学到哪了，经常忘记学习计划，在地铁上视频卡到怀疑人生。

用户需求清晰后，系统需求自然推导出来：

• 学习进度自动记录并展示，课程卡片上直接显示“已学X分钟/共Y分钟”
• 支持断点续播，播放器记住上次退出位置，重新进入时询问是否续播
• 弱网优化，视频根据网络情况自动切换清晰度，4G网络下首帧加载时间不超过2秒
• 学习提醒，用户连续三天未学习时，系统主动推送学习提醒

这里每一个系统需求都能回溯到上面的用户场景，再往上又能回溯到“提升完课率”的业务目标。完整链条闭合，开发知道要加哪些服务、建哪些表、写哪些接口，测试知道验收标准是什么，产品知道上线后该看哪些指标。功能点不再是拍脑袋堆出来的菜单，而是从三层需求里一步步长出来的结果。

2.3 同一个“学习进度”功能，三个层次分别怎么写

拿“学习进度”这一个功能点做对比，三层的差异非常直观：

同一件事，三个层次写法完全不同，但彼此支撑。少了业务需求，你不知道做功能图什么；少了用户需求，你不知道给谁做、解决什么场景；少了系统需求，开发不知道具体怎么实现、做到什么程度算好。

3. 三层次之间的推导逻辑：从“为什么”走到“做什么”

看例子的时候，大家觉得不难。但真正动手写需求，问题就来了：怎么写才能让三层清晰可推导？这里逐个层次拆开讲写法，顺便展示反例长什么样、正例长什么样。

3.1 第一层：业务需求必须量化

业务需求是最容易被敷衍的一层。很多人写“提升用户体验”“提高平台活跃度”就当业务需求交差，这种表述等于没写，因为没有可验证的终点。

业务需求必须数字化。选定一个指标，写清楚现状、目标值、时间窗口。反面例子是：“我们要提升用户的满意度。”满意度怎么衡量？提升到什么数字算成功？不说明，验收阶段就全靠吵架。正面例子是：“三个月内，将用户从注册到首次完成课程的比例从20%提升到40%。”这个目标是多少、周期多久、看哪个指标，全都可验证。

定业务需求不是简单把老板的话复述一遍。你需要多问几个“为什么”：指标下滑是因为产品本身问题，还是运营策略问题，还是外部竞争加剧？这决定了后面推导出来的用户需求方向。比如完课率低，如果是因为课太枯燥，那就需要加互动和反馈机制；如果是因为用户没时间学，那就需要做碎片化学习和提醒；如果是因为播放体验差，那就需要做性能优化。同一个业务目标，原因不同，推导路径完全不同。

3.2 第二层：用户需求要讲场景

用户需求最容易犯的毛病是写得太抽象，比如“用户希望系统更好用”。这个没办法落地，因为“好用”是主观体验，一千个用户有一千种“好用”。

用户需求要落地到具体的角色、场景和收益上。最经典的用户故事公式是：作为一个什么角色，我希望系统提供什么能力，以便达成什么目标。正例是：“作为在职备考学员，我希望在地铁上课程能断点续播，以便我利用碎片时间把课学完。”这比“希望系统好用”具体一百倍，因为它给出了清晰的实现方向。

写用户需求时，还要特别注意异常分支。用户故事里描述的是阳光路径，但真实使用中一定会遇到“没网了怎么办”“突然退出了怎么办”“已经学到一半又重头学怎么办”。这些异常场景不写清楚，系统需求层就漏掉一堆容错设计。很多项目上线后被吐槽“体验差”，并不是主流程不行，而是异常路径没人管。

3.3 第三层：系统需求必须可测试

系统需求是开发、测试真正拿来做事的依据，所以它必须满足一个铁律：可测试。不可测试的系统需求就是定时炸弹。

功能需求要写清楚输入、处理、输出。反例是“系统要支持视频播放”，这太宽泛，什么算支持？正例是“用户在课程列表页点击任一已购课程的播放按钮后，系统应立即进入播放页，播放器自动调起上次退出时的播放位置；若用户未学过该课程，则从第一秒开始播放。”输入是什么、处理逻辑是什么、输出是什么，一句话全部说清。

非功能需求同样要可测量。常见的坑是写“系统要流畅”“性能要好”“并发不能太低”，这些词无法测量。正例是：4G网络下，视频从点击到首帧出现的时间不超过2秒；系统需支持2000人同时在线观看课程，单个页面接口在1000并发下平均响应时间不超过500毫秒；App需兼容iOS 14及以上版本、Android 9及以上版本。每个指标都是明确的，测试可以直接设计用例来验证。

这一点不仅在传统企业级项目里重要，在Python相关软件工程里一样关键。比如一个用Python做的数据处理平台，如果不定义“每天处理多少数据量、单次任务最长执行时间多久、失败重试多少次”，同样没法验收。需求不可测试，就别指望交付能让人满意。很多Python项目翻车，不是代码写得差，而是需求从一开始就没定义清楚边界。

4. 实操落地：访谈、文档、评审三件事

概念讲明白了，接下来是实操。三层次需求不是挂在嘴上的，得靠日常三件事落地：需求访谈、需求文档、需求评审。每一件事都有具体动作和避坑点。

4.1 需求访谈：怎么问才能问出三层信息

需求访谈最容易踩的坑，就是一上来问“您需要什么功能”。用户和老板在没看见产品之前，给出来的“功能”大多是伪需求，是他们在旧方案里被逼无奈之下的临时想法。

更靠谱的问法是分层提问。先问业务目标：这个项目做成了，对公司业绩有什么影响？如果这个功能不做，后果有多严重？再问用户场景：谁会用到它？通常什么时候用？在哪儿用？用户现在遇到这个问题是怎么解决的，哪个环节最烦？最后问验收标准：做出来之后，你用哪个数据判断它成功？这个功能上线后，指标要变化多少你才满意？

这四个问题问完，三个层次的信息基本就能拼出来。而且访谈时一定要让对方讲故事，不是让对方提需求。故事里才有真实的场景、真实的情绪、真实的异常情况。对方说“我想要一个提醒功能”，你要追问：“你现在是怎么想起来学习的？是设闹钟，还是被同事催？你觉得最理想的情况是什么？”这些细节才是用户需求层的原材料。

4.2 需求文档：把三层放进同一个文档的推荐结构

需求文档要不要拆成多份，没有统一标准，但推荐的结构是把三层放在同一份文档里，用分节隔开，方便追溯。常用的结构是：

1. 背景与业务目标：写项目为什么做，业务目标是什么，量化指标是什么
2. 用户角色与核心场景：写目标用户是谁，每个角色配3到5个典型场景
3. 功能需求与非功能需求：按模块拆功能，每条都带优先级和验收标准
4. 验收标准与优先级：把需要重点验收的内容单列，方便测试提取

颗粒度方面，业务需求两三段话说明白即可，别长篇大论；用户需求按角色分场景展开，每个场景写清楚触发条件、用户动作、预期结果；系统需求按模块写，颗粒度到“一条具体规则”的程度。系统需求是最花时间也最容易被忽视的，现实中很多文档在用户需求层写了一堆故事，到系统需求层却只有几个页面名称，开发完全没法开工。

4.3 需求评审：用三层次做评审钩子

需求评审是检验需求质量最重要的一道关卡，但很多团队的评审会开成了“功能讲解会”。产品经理念一遍文档，开发问几个问题，测试还没说话，会就结束了。这种评审根本查不出需求漏洞。

用三层次做评审钩子，可以强制挨个过下面四项：

• 业务目标有没有量化？没有量化，直接要求补写，否则后面验收扯皮
• 每个功能点能不能追溯到至少一个用户场景？追不到，说明要么是伪需求，要么是场景没写全
• 每条系统需求能不能被测试？不能测，打回重写，别放过
• 非功能需求有没有人认领？性能、安全、兼容性、异常分支，至少要有一个明确责任人

这样过一轮评审，需求文档的质量会肉眼可见地提升。被问住的人当场去补，补完评审继续。虽然第一次开这样的评审会会慢很多，但后面设计、开发、测试阶段节省的时间，远大于评审会上多花的这几小时。

5. 常见误区与排查：三层次自检表

理论和实操都说完了，最后整理一下平时最常踩的几个坑。可以说，我见过的需求事故，十有八九能归到下面三个误区里。

5.1 误区一：把业务需求当成系统需求，让开发自己体会

老板说“提高转化率”，产品经理不拆用户场景，直接把“弹窗和优惠券”当需求扔给开发。开发做完，用户觉得弹窗太烦，转化率不升反降。问题出在中间跳过了用户需求层：为什么转化率低？是用户不知道买什么，还是价格不合适，还是购买流程太复杂？原因不同，解法完全不同。正确思路是业务需求只做起点，再从用户痛点和场景里推导出真正的功能，而不是把业务口号直接翻译成技术操作。

5.2 误区二：只写了功能需求，没写非功能需求

这类系统的典型症状是：测试阶段功能全通过，一上线就被并发打崩。比如“学习记录”功能写了“保存用户播放位置”，但没写“预计每天产生多少条记录、高峰期每秒钟多少并发、数据保留多久”。开发随意设计，上线第一天就遇到性能瓶颈。性能、安全、兼容性、数据保留、备份策略这些非功能需求，应该和功能需求一起写进系统需求层，哪怕先用“不超过X秒、支持X人同时在线”这种粗版本开始，也比完全没有强。

5.3 误区三：用户需求写得像小说，系统需求写得像天书

这是另一种极端：需求文档前半段全是用户故事和场景描述，后半段突然跳到数据库字段和接口细节，中间没有自然衔接。开发看前半段觉得是小说，看后半段又觉得缺上下文。正确做法是每一条系统需求都可以回溯到用户需求。能回溯，说明这条系统需求是有依据的；回溯不到，要么砍掉，要么回去补写场景。需求文档的逻辑应该是先从“人话”讲清楚场景和任务，再翻译成开发团队能执行的技术表达。

5.4 一个自检表，做需求时挨个打钩

为了实际可用，我整理了一份精简的自检表，每次需求评审或审查需求文档都按这个过一遍：

我个人的体会是，需求三层次不是教科书里专门用来考试的名词解释，它是一把特别务实的尺子。我后来带项目，每次需求评审都会把这张自检表拿出来过一遍，返工率肉眼可见地降下来。近几年经常有人问我，软件工程能不能转机器视觉，我的看法是可以，而且需求分析能力恰恰是最值得带过去的底子。你只要经历一次“客户说识别准确率要提升，你把阈值从0.9调到0.95，结果误报率暴涨”的翻车，就会明白什么叫系统需求没定义清楚。所以，不管你是做传统业务系统，还是转去做Python数据分析、机器视觉应用，都建议先把需求三层次练成本能。把“为什么做、谁用、做成什么样”这三件事问清楚，很多项目从一开始就不会偏。