软件工程之美--需求分析

我们知道在瀑布模型中，第二个阶段就是需求分析阶段，同时需求分析的结果也决定了后续的系统设计、开发、测试等阶段能否顺利如期进行。需求是整个产品的源头，所以需求分析的结果往往决定了产品的成败。软件项目中很多问题都和需求相关，比如说需求不明确，需求变更。这些问题轻则导致返工造成浪费，重则导致项目失败带来巨大损失。对于我们程序员来说，就是没日没夜的加班，同时也很少得到成就感，所以在软件工程中，搞明白需求是一件至关重要的事。

• 需求分析到底要分析什么？
• 我们怎么样才能做好需求分析，抓住用户的真实需求，做出来客户想要的软件产品，避免失败或浪费。
• 如何应对需求变更

1. 什么是需求分析

我们日常在项目中，经常会听到“需求”这个词，比如说：

• 项目经理对产品经理说：用户给我们提了一个需求，想要一个给三个孩子玩的秋千，你分析一下
• 产品经理对架构师说：我们现在有一个需求，在树上栓两绳子，再吊一块板子，你做一下设计

很明显，这两个需求的意思不一样，前面这个需求是用户需求，后面这个需求是产品需求，那么什么用户需求和产品需求，还有我们程序员关注的设计需求是个怎么样的关系呢？各自的约束条件是什么？

• 用户需求：基于客户认知，更多是客户的直观要求，体现了用户个体的诉求，往往是理想状态。一般是由用户直接提出来的，期望满足自身一定需要的要求。用户需求往往无法直接开发实现，同时用户对自己的需求往往也是模糊的，所以需要对其进行分析提炼，最终形成产品需求。
• 产品需求：产品需求就是在分析提炼用户真实需求后，提出的符合产品定位的解决方案。IPD流程中把产品需求定义为“产品包需求”，之所以叫“产品包需求”，是因为我们给客户交付的不是一个孤立的产品，而是一个解决方案。产品需求要求广而不深，需要把产品相关的方方面面都要考虑清楚，而不是要针对一点定义的多么精细，需要更多从客户购买决定的全过程来思考，所以一般就会涉及到：价格、渠道、包装、性能、易用性、保证、服务、品牌等。
• 设计需求：设计需求故名就是设计+需求，开发人员经常会说设计与需求有时候很难区分，其实到了设计需求，设计和需求已经融合在一起了，同时也正是融合在一起，需求才能落实为设计，设计也才能承载需求。设计需求定义时，一定要在深度上下功夫，细化到能够通过设计来实现，并且落实到具体的物理模块上。那么设计需求怎么来的呢？一般是通过产品需求分解而来，根据IPD需求工程定义，一个产品需求通常从如下：功能、环境、强健性、可靠性、可维护性、可用性、安全性、重量、电源、尺寸大小、可运输性/可移动性、灵活性等方面进行分解(当然并不是每个产品需求度要一定分解成这些方面)，分解后就形成了与此产品需求相对应的设计需求清单。

规格和需求的区别

我们经常讲：软件需求规格书，说明需求和规格书本来就是一体化的，规格就是需求的具体说明，例如：OA要支持IE浏览器是需求，那么如果具体定义，需要具体支持ie6、ie7、ie8，那么就叫做规格；声音要达到120分贝~190分贝，这本身就是需求+规格。

功能需求

功能需求其实是设计需求的一个类别，软件行业基本都是功能需求，就是第一步干什么，下一步做什么，然后再做什么的场景描述，所以功能需求就这么产生了。功能需求与其他的需求定义时，核心不同点是，功能需求需要详细定义场景描述，其中包含正常场景、异常场景，业界通用定义方法是Usecase法。

测试需求

很多人认为测试需求是基于对产品需求的分析，测试人员提炼出来的需要重点测试的点，正确的定义时需求定义人员详细定义产品需求和设计需求，而同时测试设计人员直接针对此需求分析该需求如何测试，重点测试哪些内容，所以测试需求，本身应该叫：需求的可测试性分析

2. 如何做需求分析

每一个需求分析方法基本相似，本章以用户需求为例，其实对用户需求的分析，不是一个动作，而是一个过程。需求分析，就是对用户需求进行提炼分析，最终形成产品需求的过程。而针对每个用户需求的需求分析过程，需要经过三个步骤。

• 1.挖掘真是需求

大部分用户提的需求，都不见得是其真实的需求，需要透过现象看本质，去挖掘其背后真实的需求。要分析用户的真实需求，可以从三个角度入手。

• 目标用户：用户不同，诉求也不一样
• 使用场景：使用场景不一样，解决方案也会有所不同
• 想要解决的问题：用户背后想要解决的问题是什么

福特汽车创始人亨利福特说过的：

如果我最初是问消费者他们想要什么，他们应该是会告诉我，“要一辆更快的马车！

这里“要一辆更快的马车”就是一个典型的用户需求，但这并非是用户的真实需求，用户的真实需求，需要通过分析才能得到。我们假设目标用户是普通乘客，使用场景是日常出行，那么用户想要解决的问题其实并不简单是“要一辆更快的马车”，想要更快的马车只是用户自己能想到的解决方案，而他想解决的问题是“更快更舒适的出行方式”。

• 2.提出解决方案

我们知道了目标用户，其使用场景和想要解决的问题，就可以结合产品定位，提出相应的解决方案。比如针对想要“更快更舒适的出行方式”日常出行的乘客，我们就可以提出汽车的解决方案，而不一定要局限于马车，汽车能更好的满足用户需求。

• 3.筛选和验证方案

在选好方案后，还需要对方案进行验证，以确保方案能解决用户需求。在传统瀑布模型中，选定方案后，会写成产品设计文档，走相应的评审流程，评审完成后再进行设计、开发和测试，测试完成后会让客户再进行验收。而敏捷开发，在整个开发过程中，每个迭代或者关键的里程碑，也一样需要客户进行验收。

通过以上三步，就可以对用户需求进行提炼分析，最终形成产品需求。所以在需求分析过程中，分析的就是一个个用户的需求，找出背后的真实诉求，再有针对性的提出解决方案。

而对于软件项目的用户需求，从来就不是单一的，而是一系列需求，所以对于软件项目的需求分析，还需要增加收集整理的步骤。整个过程是迭代进行的，如下所示：

• 收集需求：对用户需求进行收集整理；
• 分析需求：对需求进行分析，挖掘用户真实需求；
• 需求评估：筛选过滤掉不可行的需求；
• 需求设计：针对用户需求提出解决方案，设计成产品方案；
• 验证需求：验证方案是否可行。

3. 需求变更的问题

在软件开发过程中，需求变更是一种常态，开发到一半，很多原始的需求慢慢的发生变化，这时候当初的设计也已经无法满足要求，很多代码需要修改，有时候框架设计都需要重新设计。为了赶项目进度，导致代码臃肿，代码质量降低，加班越来越多。目前也已经有很多管理需求变更的解决方案

• 增加需求变更流程，让需求变更规范起来：通过严格的流程，来避免一些没有意义的变更，从而达到管理需求变更的目的。
• 快速迭代，缩短版本周期：大的功能拆分，每个版本周期仅实现一部分功能需求，周期较短，这样需求发生变更时，就可以快速响应

但是这种方法真的能解决问题吗？拿软件工程和建筑工程进行对比，你可以思考一下，同样是工程，建筑项目也是有需求变更的，但却不会像软件项目这么频繁和失控。为什么呢？主要有两个原因：

• **需求的确定性：**在建筑项目中，无论提出需求还是变更需求，客户方和施工方都明确知道要做些什么工作，而软件需求常是抽象、模糊、不精确的，模糊不清的需求导致在软件开发有了雏形后，才慢慢想清楚真正的需求是什么，从而导致需求变更。
• 需求变更的成本：

那么对于我们程序员，如何解决需求变更的问题呢？首先，心态最重要，在软件项目开发中，需求变更其实是不可避免的，一味抵制需求变更也是不可取的。你能做的就是利用软件工程的知识，理解需求变更背后深层次的原因，找到合适的方案来改善，积极拥抱合理的需求变化，减少不必要的需求变更。这是大的前提条件，也是共识的基础。

既然需求变更的原因是需求不确定和需求变更成本太低，那么我们就针对性地提出相应的解决方案：

• 提升需求确定性，把需求分析做好，减少需求变更
• 提高需求变更的成本，让客户或者产品经理不能太容易就变更需求，这样就可以达到减少需求变更的目的

总之，对于需求变更，项目上对于变更需求要制定合适的变更流程，项目组要选择适合项目开发的模式，管理好需求变更，提升整个项目的开发效率，避免重复返工导致浪费。而对于开发或者测试，我们在遇到需求变更的时候，不要置身事外，抱怨需求变更，而是应该在对于需求分析或者变更的关键阶段，主动的参与其中，从开发和测试的角度提供一些专业化的建议，去思考细化需求和思考需求变更产生的背景。

4. 总结

需求是项目的源头，需求分析做的好坏，严重的影响了软件项目的成功与否。在项目开发过程中，我遇到了很多需求没有梳理清楚，导致项目返工的真实情况存在，导致项目组的成员压力很大，无休止的加班，情绪很是低落。对于需求分析，就是找出来隐藏在用户需求背后的真实需求，还要针对用户的真实需求提出解决方案的过程。而对于需求变更，需要要追本溯源，研究问题背后的原因，研究理论背后的来龙去脉。