编辑导读：产品经理每天都在与需求打交道，《软件需求工程》是产品经理的必修课。本文是针对新人产品经理的简介性文章，目的是让产品经理在开始需求分析工作之前，对软件需求的相关常识有所理解。希望文章对你有帮助。

一、需求工程

需求分析的重要性毋庸置疑。在20世纪80年代，逐步形成了软件工程的子学科——软件需求工程。90年代后，需求工程成为软件界研究的重点之一。从1993年起，每两年举办一次需求工程国际研讨会（ISRE）；1994年起，每两年举办一次需求工程国际会议（ICRE）。一些关于需求工程的工作小组相继成立，使需求工程的研究得到了迅速进展。

1.1 需求的定义

IEEE软件工程标准词汇对需求的定义：

• 用户解决问题或达到目标所需的条件或能力；
• 系统或部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力；
• 反映上述的条件或能力的文档说明（SRS，软件需求规格说明书）。

业界对需求的通俗解释 ：

• 需求来源于用户的一些“需要”；
• 这些“需要”被分析、确认后形成完整的文档；
• 该文档详细地说明了产品“必须或应当”做什么。

需要说明的是：并没有一个清晰的、无二义的“需求”术语定义存在。真实的“需求”实际上在人们的脑海中，甚至在脑海深处自己都不知道。

“任何文档形式的需求（比如：需求规格说明书）都只是一个模型/一种叙述。”

——Lawrence 1998

我们需要确保的是所有项目风险承担者（stakeholders，干系人）在描述需求的文字的理解上务必达成共识。

1.2 需求的三个层次

• 业务需求是高层用户（即客户）提出的，比较笼统、宽泛，在项目视图与范围文档中说明。
• 用户需求是最终用户（实际使用者）提出的，已经比较具体了，在实例文档或方案脚本中说明。
• 产品需求是开发团队需要的（甲方监理也需要），定义了开发人员要实现的软件功能，使得用户能完成他们的业务，从而满足业务需求。

业务需求和用户需求都是用通俗语言描述的，即用户能看懂的语言；产品需求是用技术语言描述的，是开发人员能看懂的语言。用户和开发人员是在用不同的视角观察需求的，他们看到的内容是不一样的。就软件而言，这里的产品需求就是软件需求。

这样的解释可能还不容易理解，我来举个“咖啡店新老板要更换定制咖啡杯”的例子。

业务需求：

咖啡店老板要订做一种咖啡杯。

找高层用户调查和确认需求是一件痛苦的事，因为他们不关注需求具体内容，甚至常常不知道具体需求，他们关注的是“高屋建瓴”的比较务虚的内容，例如：咖啡杯要好用、要漂亮之类的。

真正去调研需求，需要先识别出产品的最终用户群，选出用户代表，对用户代表进行调研。这里的用户代表为：消费者，喝咖啡；服务员，端咖啡；洗碗工，洗杯子。针对消费者调研可以采用问卷调查的方式来获取用户需求；针对服务员和洗碗工可以采用用户访谈的方式来获取用户需求。

用户需求：

• 消费者希望“杯子不能烫手”。消费者反馈：原来的杯子手柄很短，杯身隔热效果很差，拿杯子的时候，手指容易被烫。
• 服务员希望“杯子在托盘上要稳，不容易滑倒”。服务员反馈：原来的杯子瘦且高，杯底很滑，用托盘端盛满咖啡的杯子时，杯子在托盘上容易打滑或倾倒。
• 洗碗工希望“杯子要容易清洗”。洗碗工反馈：原来的杯子内壁不够光滑，咖啡渍很难清洗。

这样的用户需求似乎很清楚了，但是你得明白这只是针对用户侧，对开发人员来说还是不清楚，因为这是自然语言描述的内容，不是技术语言描述的内容，开发人员无法针对此开展工作。

你还需要把以上内容翻译成为技术语言描述的产品需求：

1. 采用隔热材料，导热率λ < 1.22 W/(m.K)，厚度> 5mm。经过原型测试，采用了这样的材料和厚度做成的杯子，加入100℃的热咖啡时，杯子外壁的温度大约50℃，轻微触碰时不会感觉烫手。
2. 杯底的静摩擦系数 µ > 0.5，满杯的重心高度 h < 10cm。经过原型测试，符合这种要求的杯子在装满咖啡时，不容易打滑或倾倒。
3. 杯内壁表面粗糙度 Ra < 1.0。经过原型测试，符合这样要求的陶瓷表面不容易附着咖啡液体，很容易清洗。

拿到这样的产品需求，开发人员就可以开展工作了：

• 根据产品需求1，开发人员可以从工厂常用的陶瓷材料里选择符合要求的，然后把杯子设计为略高于指定厚度。
• 根据产品需求2，开发人员可以把咖啡杯的底座设计为条纹或其他形式来加大摩擦系数，然后把咖啡杯设计为较矮、较宽的外形，以满足在满杯时的重心要求。
• 根据产品需求3，开发人员可以对咖啡杯的内壁采用某种抛光或镀釉的工艺来达到表面比较光滑的要求。

这就是需求的三个层次：高层用户关注业务目标的实现，最终用户关注业务执行的效率和使用体验，开发人员关注产品需求是否准确和清晰。

产品经理就比较惨了，需要从多种角度去描述需求：高层用户视角的需求，即市场需求文档MRD；最终用户视角的需求，即业务需求文档BRD；开发人员视角的需求，即产品需求文档PRD（或软件需求文档SRS）。

“需求”，这是所有人都可以说上几句的话题。但最专业的，还是产品经理描述的需求，这正是产品经理的价值所在。

1.3 需求工程RE

应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科，即需求工程。需求工程通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

通俗地说，需求工程就是把工程方法引入到需求领域，用工程方法开发清晰的、一致的，没有冲突、重叠和遗漏的需求，用工程方法来管理需求和控制变更。

1.4 软件需求工程SRE

软件工程的子学科，一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。

需求工程是系统工程和软件工程的分支，分为系统需求工程（针对由软硬件共同组成的整个系统）和软件需求工程（专门针对纯软件部分）。我们都知道软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。软件开发的最终目的是生产出满足客户需求的软件产品，满足客户需求是软件开发的本质。

1.5 为什么有软件需求工程

软件需求是软件开发中的关键问题，没有需求就没有软件。

开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器或其他软件系统的接口，此工作一旦失误，将会带来极大的危害，修改也极其困难。

——Frederick P. Brooks，《No Silver Bullet》

备注：Frederick P. Brooks，60年代初只有29岁时就主持了被称为人类从原子能时代进入信息时代标志的IBM/360系列计算机的开发工作，取得辉煌成功，名噪一时。他作为硬件和软件的双重专家和出色的教育家始终活跃在计算机舞台上，在计算机技术的诸多领域中都做出了巨大的贡献，直到69岁才获得迟来的荣誉——1999年的图灵奖。

需求是软件项目成功的核心，良好的需求可以减少开发后期的返工和整个维护阶段的工作，做好需求等于项目成功了一半。

1.6 需求沟通是如此困难

需求是以交流为核心的工作，如果在开发过程的各个环节缺乏交流或交流不恰当，就会导致下图（如果学计算机，你必定见过此图）的效果。

1. 客户如此描述需求：我有三个小孩，我需要一个能三个人用的秋千。它由一绳子吊在我家花园里的树上。
2. 项目经理如此理解：秋千这东西太简单了，不就是一块板子，两边用绳子吊起来，挂在树的两个枝桠上嘛。
3. 分析员如此设计：真是无知的项目经理，两个树枝挂上秋千哪还能荡得起来？除非是把树从中截断再用支架支起来，这样就满足要求了。
4. 程序员如此编码：哦，两条绳，一块板，一棵大树，接在树的中段。太简单了，“啪啪啪（敲击键盘的声音）”，搞定！
5. 商业顾问如此诠释：您的需求我们已经完成了，我们通过人体工学和工程力学等多方面研究，实现了本产品。本着为顾客服务出发，我们的秋千产品在使用时，将给您带来如同游乐园里的过山车一样刺激的感受，如同你在地面上坐沙发一样的舒适与安全。
6. 资料员如此写文档：这么小的工程没有文档很正常，只要有需求说明书与合同就可以了。
7. 实施人员如此交付：我们的产品用户自己都可以完成安装，只要把绳子系在树上就可以了。
8. 客户得到如此结果：花了建过山车的投资，得到个如此产品，也是醉了。
9. 维户人员如此支持：我们提供不了什么技术支持，但我们态度很好，我们的队伍在成长中。
10. 项目完成了，真实的需求也清楚了：客户需要一个跳圈，给三个小孩养的小狗训练和玩耍。

很明显，项目开始时客户也不知道真实的需求，他表述的只是他理解的需求（小孩曾经给他说过，但显然他并没有认真聆听）。项目经理没有认真调研需求，他甚至根本不知道最终用户是谁。项目经理和分析员之间，分析员和程序员之间，明显没有良好的交流和反馈。像漏斗一样，每个环节都在遗失信息；像传声筒游戏一样，每个环节都在加入自己想当然的理解。所以，最终的结果必然的天差地别！最重要的是，他们缺一个打通各个环节的产品经理。

对于产品经理，有个常识你必须知道：

用户嘴里说的，不一定是他脑子里想的。他脑子里想的，也不一定就是业务实际运行的情况。业务的现状，不一定是合理的，也许正是客户需要你帮助改进的。

所以，我们要倾听用户，但不能完全按照用户说的去做。我们要倾听多方用户代表，特别是要关注那些互相冲突、需要妥协的部分。我们不光要听用户怎么说的，还要看他怎么做的。我们要听免费用户的免费意见，更要听付费用户的付费意见。我们要听用户的意见，更要听决定付钱的客户的意见……等等，自己总结吧，自己总结的才是最适合自己的，我不想展开了。

1.7 软件需求工程框架