一、需求分析基础：什么是系统需求

说实话，做了这么多年软件架构，我见过太多项目栽在需求分析这个环节上。很多人觉得需求分析就是「客户说要什么，我们就做什么」，其实远没那么简单。

系统需求，说白了就是用户期望系统能做什么、做到什么程度。它不只是几行文字描述，而是整个软件工程的起点。我有个习惯，每次接手新项目，第一件事就是问自己：这个系统到底要解决谁的什么问题？

举个例子，你接到一个「开发在线商城」的需求。如果只理解到「能卖东西」这个层面，那后面肯定要翻车。你得搞清楚：是给谁用的？是B2C还是B2B？支付流程怎么走？库存怎么管？这些都属于系统需求的范畴。

二、需求的层次结构

我刚开始做项目时，经常把不同层次的需求混在一起讲，结果就是开发出来的东西跟用户想的完全两码事。后来我总结了一套分层方法，这里分享给你。

2.1 业务需求

业务需求是最高层级的。它回答的是：为什么要做这个系统？

比如，一家物流公司想开发一套调度系统。业务需求可能是「降低运输成本20%」或「将配送时效提升到4小时内」。这些需求通常来自企业的高层管理者，他们关心的是商业价值。

我在项目中遇到过这样的情况：客户说「我们要做一个智能客服系统」。深入聊下去才发现，他们真正的业务需求是「减少人工客服的重复劳动，把客服成本降低30%」。你看，如果只盯着「智能客服」这个功能，很可能做出来的东西跟业务目标对不上。

2.2 用户需求

用户需求是中间层。它回答的是：用户能用系统做什么？

还是拿物流调度系统举例。用户需求可能是：

• 调度员能查看所有待配送订单
• 调度员能根据路线自动分配司机
• 司机能在手机上接收派单通知

你想想看，用户需求描述的是用户与系统的交互过程。它不涉及具体的技术实现，只关心用户的目标和任务。

嗯，这里要注意：用户需求不等于用户说的每一句话。用户可能会说「我想要一个红色的按钮」，但真正的需求可能是「我希望在紧急情况下能快速触发报警」。所以，做需求分析时一定要学会翻译用户语言。

2.3 功能需求

功能需求是最底层的。它回答的是：系统具体要做什么？

功能需求是开发人员直接参考的。它必须足够详细，能指导编码和测试。比如：

• 系统支持按订单号、客户姓名、配送地址进行模糊搜索
• 系统在分配司机时，自动排除当天已满负荷的司机
• 系统每5分钟刷新一次订单状态

三层需求的关系

这三层需求是层层递进的。业务需求驱动用户需求，用户需求又细化成功能需求。我习惯用一张表格来梳理它们的关系：

层次	关注点	典型提问	产出物
业务需求	商业价值	为什么要做？	项目愿景、商业目标
用户需求	用户目标	用户要做什么？	用户故事、用例图
功能需求	系统行为	系统如何响应？	功能列表、验收标准

三、需求获取的常用方法

需求不会自己从天上掉下来。你得主动去「挖」。我这些年试过不少方法，有些好用，有些踩过坑。下面这几个是我觉得最实用的。

3.1 用户访谈

这是最直接的方法。找几个关键用户，坐下来聊。但别以为就是随便聊天，我建议你提前准备好问题清单。

比如，你想了解物流调度系统的需求，可以问：

• 你现在每天是怎么安排配送路线的？
• 最让你头疼的问题是什么？
• 如果有一个新系统，你希望它帮你解决什么？

访谈时有个技巧：多问「为什么」。用户说「我想要一个地图功能」，你追问「为什么需要地图？」，他可能说「因为我想知道司机到哪了」。你看，真正的需求是「实时追踪司机位置」，而不是「地图」本身。

3.2 问卷调查

当用户数量多、分布广时，问卷是个好选择。但问卷设计有讲究：

• 问题要封闭式为主，比如选择题、评分题
• 避免引导性问题，比如「你觉得我们的系统好用吗？」
• 留一个开放题，让用户自由发挥

3.3 观察法

这个方法我特别推荐。你亲自去用户的工作现场，看他们是怎么操作的。有时候用户自己都说不清楚的问题，你一看就明白了。

我记得有一次做医院挂号系统的需求分析。用户说「系统很好用」，但我去医院观察了一上午，发现护士每次挂号都要切换好几个页面，操作步骤特别繁琐。这就是观察法的价值——发现用户习以为常的痛点。

3.4 原型演示

光靠文字描述，用户很难想象最终产品长什么样。我习惯先做一个低保真原型，拿给用户看。用户看到原型后，往往会说「哦，这里不对，应该是这样...」——这时候真正的需求才浮出水面。

原型不一定要多精美。用Axure或甚至纸笔都行。关键是让用户有东西可指指点点。

好了，关于需求分析的基础就聊到这里。下一章我们会讲如何把这些需求整理成结构化的文档，以及怎么避免需求变更带来的灾难。到时候我会分享一个我亲身经历的「需求变更血泪史」，保证让你印象深刻。