编辑导读：产品经理每天都在与需求打交道，《软件需求工程》是产品经理的必修课。本文是针对新人产品经理的简介性文章，目的是让产品经理在开始需求分析工作之前，对软件需求的相关常识有所理解。希望文章对你有帮助。
需求分析的重要性毋庸置疑。在20世纪80年代，逐步形成了软件工程的子学科——软件需求工程。90年代后，需求工程成为软件界研究的重点之一。从1993年起，每两年举办一次需求工程国际研讨会（ISRE）；1994年起，每两年举办一次需求工程国际会议（ICRE）。一些关于需求工程的工作小组相继成立，使需求工程的研究得到了迅速进展。
1.1 需求的定义IEEE软件工程标准词汇对需求的定义：
- 用户解决问题或达到目标所需的条件或能力；
- 系统或部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力；
- 反映上述的条件或能力的文档说明（SRS，软件需求规格说明书）。
业界对需求的通俗解释 ：
- 需求来源于用户的一些“需要”；
- 这些“需要”被分析、确认后形成完整的文档；
- 该文档详细地说明了产品“必须或应当”做什么。
需要说明的是：并没有一个清晰的、无二义的“需求”术语定义存在。真实的“需求”实际上在人们的脑海中，甚至在脑海深处自己都不知道。
“任何文档形式的需求（比如：需求规格说明书）都只是一个模型/一种叙述。”
——Lawrence 1998
我们需要确保的是所有项目风险承担者（stakeholders，干系人）在描述需求的文字的理解上务必达成共识。
1.2 需求的三个层次
- 业务需求是高层用户（即客户）提出的，比较笼统、宽泛，在项目视图与范围文档中说明。
- 用户需求是最终用户（实际使用者）提出的，已经比较具体了，在实例文档或方案脚本中说明。
- 产品需求是开发团队需要的（甲方监理也需要），定义了开发人员要实现的软件功能，使得用户能完成他们的业务，从而满足业务需求。
业务需求和用户需求都是用通俗语言描述的，即用户能看懂的语言；产品需求是用技术语言描述的，是开发人员能看懂的语言。用户和开发人员是在用不同的视角观察需求的，他们看到的内容是不一样的。就软件而言，这里的产品需求就是软件需求。
这样的解释可能还不容易理解，我来举个“咖啡店新老板要更换定制咖啡杯”的例子。
业务需求：
咖啡店老板要订做一种咖啡杯。
找高层用户调查和确认需求是一件痛苦的事，因为他们不关注需求具体内容，甚至常常不知道具体需求，他们关注的是“高屋建瓴”的比较务虚的内容，例如：咖啡杯要好用、要漂亮之类的。
真正去调研需求，需要先识别出产品的最终用户群，选出用户代表，对用户代表进行调研。这里的用户代表为：消费者，喝咖啡；服务员，端咖啡；洗碗工，洗杯子。针对消费者调研可以采用问卷调查的方式来获取用户需求；针对服务员和洗碗工可以采用用户访谈的方式来获取用户需求。
用户需求：
- 消费者希望“杯子不能烫手”。消费者反馈：原来的杯子手柄很短，杯身隔热效果很差，拿杯子的时候，手指容易被烫。
- 服务员希望“杯子在托盘上要稳，不容易滑倒”。服务员反馈：原来的杯子瘦且高，杯底很滑，用托盘端盛满咖啡的杯子时，杯子在托盘上容易打滑或倾倒。
- 洗碗工希望“杯子要容易清洗”。洗碗工反馈：原来的杯子内壁不够光滑，咖啡渍很难清洗。
这样的用户需求似乎很清楚了，但是你得明白这只是针对用户侧，对开发人员来说还是不清楚，因为这是自然语言描述的内容，不是技术语言描述的内容，开发人员无法针对此开展工作。
你还需要把以上内容翻译成为技术语言描述的产品需求：
- 采用隔热材料，导热率λ < 1.22 W/(m.K)，厚度> 5mm。经过原型测试，采用了这样的材料和厚度做成的杯子，加入100℃的热咖啡时，杯子外壁的温度大约50℃，轻微触碰时不会感觉烫手。
- 杯底的静摩擦系数 µ > 0.5，满杯的重心高度 h < 10cm。经过原型测试，符合这种要求的杯子在装满咖啡时，不容易打滑或倾倒。
- 杯内壁表面粗糙度 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.7 软件需求工程框架
CMMI对软件需求的描述集中在两个PA里：需求开发RD（3级），需求管理REQM（2级）。
- 需求获取：从用户获取、挖掘需求。
- 需求分析：提炼用户需求，分析转化，需求分析的过程重视用户参与。
- 需求定义：把分析得到的需求文档化，编制需求规格说明书。
- 需求验证：确定需求准确、完整，得到实现，对应测试活动。
- 需求变更控制：对需求的变更进行控制，降低影响。
- 需求跟踪：监控需求在开发过程中不走样、不遗漏。
SG1 干系人的需要、期望、约束与接口得到收集并转化为客户需求。
– SP1.1 挖掘干系人对产品生命周期所有阶段的需要、期望、约束与接口。
– SP1.2 将干系人的需要、期望、约束与接口转换为划分了优先级的客户需求。
SG2 客户需求得到提炼与细化，以开发产品与产品组件需求。
– SP2.1 依据客户需求，建立并维护产品与产品组件需求。
– SP2.2 为各产品组件分配需求。
– SP2.3 功能之间（或者是对象或其它逻辑实体之间）的接口进行了识别。
SG3 需求得到分析与确认。
相比“需求获取”，我个人更喜欢“需求挖掘”这个词。因为“需求获取”让我感觉需求就是树上的果子、地里的庄稼，只要产品经理去采摘就可以了。这样的描述，未免低估和轻视了得到需求的困难。反之，“需求挖掘”让我感觉需求是地里的金子等矿藏，需要产品经理去弯腰、埋头挖掘，而且挖掘了也不一定有成果，因为你需要寻找正确的地方挖，否则只能是徒劳。另外，在很多人都挖过的地里，你只有挖得更深才可能挖到矿藏。
常见的需求挖掘方法有：客户交流、竞品分析、市场调研、问卷调查、技术引导及其他。
客户交流是最常用的需求挖掘方法。大多数情况下，用户虽然知道自己的需求，但他们并不一定能或者也不想准确表达他们的需求是什么。如果用户第一次告诉你需求就是这些了，不要轻信，继续刨根问底，直到你们都筋疲力尽。
产品经理作为一个需求分析者，所谓的聆听客户需求，指必须透过客户所提出的表面需求理解他们的真实需求，避免理解不同会带来的期望差异。尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分，甚至要逐字逐句去理解，以明确客户没有表达清楚但又想加入的特性或特征。
有经验的产品经理能深入地理解客户的业务（可以提取做大量准备工作），这样他才能通过询问客户一些合适的问题（需要提前设计），从而挖掘出高价值的用户需求。
2.3 需求分析方法需求分析方法大致分为两类：模型法和原型法，都可以从不同角度说明需求，把一些模糊的需求变得清晰，便于理解，减少返工。不管是模型，还是原型，都是用来增强自然语言描述的需求规格说明，而不是代替。
模型一般分为面向过程的模型和面向对象的模型两类。建立需求模型的分析过程，称为“需求建模”。建模的目的是把模糊的东西搞清晰，把复杂的东西搞简化，而不是把简单的东西搞复杂（这是商务人员做的事，比如：电信运营商的话费套餐）。
原型法是一种减少软件项目失败风险的技术，它可以加快开发进度，增加用户满意度，减少需求错误和用户界面缺陷。
2.4 需求建模常用的面向过程的需求建模方法（结构化分析）：
- 功能模型：数据流图DFD
- 行为模型：流程图Flow Chart
- 状态模型：状态迁移图STD
- 数据模型：实体关系图ERD
常见的面向对象的需求建模方法：
- 功能模型：用例图
- 行为模型：活动图
- 状态模型：状态图
- 交互模型：时序图（也叫“顺序图”）
建立原型的目的是为了解决在产品开发早期需求不确定的问题，利用这些不确定来判断系统中那一部分需要建立原型和希望从用户对原型的评价中获得什么信息。其优点是能减少软件项目失败风险，加快开发进度，增加用户满意度，减少需求错误，尤其是界面错误。其风险是当用户或项目经理看到一个正在运行的原型，会以为产品即将完成。
对于发现和解决需求中的二义性，原型是一种很好的方法。关于原型，不在这里赘述了，后面会另起一文。
常用的原型设计方法：草图（手绘图）、线框图、交互原型、高保真原型。
原型法不仅是需求分析方法，同时是需求验证方法。
2.6 需求定义的方法- 采用需求文档模板。
- 指明需求的来源。
- 为每项需求建立编号。
- 设定需求优先级。
- 记录业务规范。
- 创建需求跟踪矩阵。
- 其他方法。
- 清晰：不同的读者只能从需求文档中得到唯一的解释说明，没有二义。所以表述中不要出现“也许、大概、可能、左右”之类的表述模糊的词语，比如：响应时间5秒左右，宽度大概10米。
- 完整：一个不能少，所有功能都要描述。
- 一致：上下文一致，局部与整体一致。
- 可行：每一项需求必须在已知系统和环境的限制范围内可以实现，不能是空中楼阁。
- 可验证：每一项需求必须能够用测试用例或其他方法来验证是否按定义实现了。
- 可跟踪：每一项需求必须能与HLD、LLD、Code、UT、IT、ST等各阶段工作产品对应跟踪。
SG 1 管理需求
– SP 1.1 理解需求
– SP 1.2 获得对需求的承诺
– SP 1.3 管理需求变更
– SP 1.4 维护需求的双向可追溯性
– SP 1.5 确保项目工作与需求间的协调一致
- 确定需求变更控制过程，建立CCB（需求变更控制委员会）。
- 进行需求变更影响分析，跟踪变更影响的工作产品。
- 建立需求基准版本和需求控制版本文档。
- 维护需求变更的历史记录，跟踪每项需求的状态。
- 使用需求管理工具，衡量需求稳定性。
- 其他方法。
大师说：“没有不变的需求，世上的软件都改动过3次以上，唯一只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。”
需求变更是正常的，但不加控制的需求变更是不正常的。所以，不怕需求变更，但要严格控制，要让客户知道变更的代价（影响和成本），客户在理解变更的代价后再拍板会理智很多。
需求变更的原因：客户说不清楚需求；需求自身经常变动；分析人员或客户理解有误。
需求变更控制不是为变更设置障碍，而是建立一个渠道和过滤器，保护客户和开发者双方的权益，减低变更的影响。
参考资料：
CMMI-DEV 1.3
作者：叔宝，微信公众号“叔宝说”，专注产品设计和PPT设计。
本文由 @叔宝 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Pexels，基于CC0协议。