走出需求分析的泥潭

 

走出需求分析的泥潭

作者：李红

需求分析在软件产品开发过程中起着举足轻重的作用，需求分析的好坏直接影响着一个产品或者项目的成败，如何走出需求分析的泥潭，找到一个适合自己的需求方法呢？下边就让我们一起来探索一下需求之路吧！

 

找到需求分析中的泥潭

       我们先来看一个小故事：

A软件上市公司M项目开始启动了，产品经理到用户那里做了需求调研，并且很认真的写了需求备忘录，不过，总结下来，也不过就是十几句话，每一条需求也就是几句简单的描述。该产品的开发小组拿到了这份备忘录，系统分析员开始犯难了，这么几条需求，如何来写需求规格说明书呢？于是，系统分析员根据自己平时在该产品上积累的经验，写了一份需求规格说明书，并提交开发小组进行评审。于是大家在对系统没有任何认识的情况下听系统分析员讲述了需求规格说明书，听完以后大家确实对系统有了一定的了解，但是谁也提不出来什么问题来，觉得这样写还可以，于是需求评审就这样通过了。设计人员拿到了需求规格说明书，根据需求说明并添加了自己的理解，形成了设计文档，同样的也通过了评审。接下来就该代码开发了，而这时代码开发人员还不知道要做一个什么样的系统，于是匆匆得向设计人员询问了一下，就开始编码了。编到一半，不知道该如何进行了，于是就去查设计说明书，发现说明书上并没有明确的设计思路，于是又去查需求规格说明书，发现也只是简单的几句描述，于是代码开发人员根据自己的理解，将代码开发完了。这时，系统分析员拿到了开发出来的系统，发现与原来需求有很大的出入，于是又找到代码开发人员，开始了下面的一段对话：

系统分析员问，“这个系统和需求上要求的怎么不一样啊？”

代码开发人员回答，“需求规格说明书上没有写啊，设计书上也没写啊？”

这时系统分析员和设计员都不相信自己没有写，就找出来那部分的需求描述，说，“你看这不是吗？描述得很清楚，这样做才是合适的。”

这时代码开发人员恍然大悟，“我理解成那样的了……”

最终结果是代码开发人员重新返工，项目不得不推迟了进度。

我们一起来分析一下上边的故事，针对需求分析过程，你发现有什么泥潭和陷阱吗？

泥潭一：只有业务需求，没有功能需求；

泥潭二：需求描述含有二义性；

泥潭三：需求细化程度不够；

泥潭四：需求过程缺乏沟通；

在我们日常工作中或多或少的会出现故事中所提到的一个或多个问题，我们也曾多次看到过有关描述需求与最终产品差异的幽默漫画。我们有时候也会思考为什么投入了那么多人力物力项目进度总是一拖再拖，总也没有完成的时候，很多人开始抱怨软件开发真是个谜团，有些人开始找理由说软件与硬件开发不同，软件有特殊性。其实，归根结底我们是没有找到一个好的方法。软件开发确实有特殊性，这个特殊性就是人的思维和语言的障碍。如果我们要建一座大楼，工程师会测量很多数据，并且画出非常标准的工程图，工程图的标准是唯一的，甚至到每条线的粗细都有非常严格的规定。而软件产品的描述却没有一个统一的描述语言，也没有统一的标准，完全根据个人的理解。如果在这种情况下我们的文档描述不清晰或者相互之间缺乏沟通的话，确实很难想象最终产品与用户需求之间的差异到底会有多大。

 

避免陷入泥潭的方法

 

泥潭找到了，我们怎么才能避免呢？怎样才能把好需求关呢？

对需求进行分类

       首先我们先看看泥潭一，故事中提到产品经理做完需求调研以后形成的需求备忘录，实际上那并不是用户需求，而只是业务需求。业务需求反映了组织机构或客户对系统、产品高层次的目标要求。而用户需求描述了用户使用产品必须要完成的任务。从用户角色上这两个需求也有所不同，业务需求一般从企业的技术处那里得到，而用户需求必须从真正使用系统的用户那里得到。当系统分析员拿到产品经理写的需求备忘录以后，应该将其整理为业务需求，并利用关联图界定需求范围，另外需要到真正使用该系统的用户那里再进行需求调研，形成用户需求，根据用户需求再形成功能需求。

       例如一个小型超市需要一个产品的查询系统。这个系统的业务需求就是进货人员需要查询商品库存以便保证及时进货，收银员需要查询商品的销售价格以便结帐，超市的老板需要查询商品的销售情况，盈利情况。

这个查询系统的用户主要有三类，一类是进货人员，一类是收银员另外就是超市老板，这三类用户怎样去查系统，查询哪些信息，查询这些信息以后还希望进行哪些操作，不同的人员所能查询的内容有哪些？这些需求都属于用户需求，必须对真正使用该系统的用户进行需求调研才能够获得。

有了用户需求以后，就需要将其转化为功能需求了，功能需求定义了开发人员必须实现的软件功能。比如需要建立一个小型的数据库来存储数据，需要一个界面来显示信息等。

除了上边所说的三种需求外，还有一个大家比较容易忽视的就是非功能需求，非功能需求主要指系统需要达到的效率要求、可扩展性能、可维护性要求等，这一部分也需要在需求中进行描述，这一部分的需求直接影响到设计中的需求实现方法，因此，这部分需求是不能忽视的。

 

正确描述用户需求

       我们再来看看泥潭二，描述语言存在二义性，这确实是件让我们非常头疼的事情，那么有了需求以后，如何编写用户需求规格说明书，如何描述这些需求才能减少二义性，才能减少代码的返工呢？其实一个优秀的需求文档并没有现成的固定的模式，但是在编写需求文档时，我们还是应该注意以下几个方面：首先要使句子和段落简短，试想一个很长的句子，我们看起来弄懂句子的意思都非常困难，还怎么弄懂真正的需求呢？另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，我们就将其拆分成多个小句子。另外注意句子中不能有语法错误，还要注意标点符号，有时，标点符号点错了，就完全成了另外一个意思了。这一点我们在初中语文上就学过，所以就不再举例了。还有就是尽量采用主动式的表达方式，需求是什么就是什么，必须怎样做，需要怎样做，要采用主动式的肯定语句，不要自己都含糊不清，让设计人员自己去选择。另外注意引用的术语和词汇前后要一致，比如前面介绍数据库存储的数据时，称数据库中的数据为“资产”，而后边介绍时又变成了“内容”，这时别人就很难知道是不是指的同一个对象。最后就是尽量避免一些形容词、比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的，界面友好的，减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围。

当然一个好的需求规格说明书离不开好的工具，采用一个标准的工具将需求进行图形化描述，也是减少理解偏差的一个方法。目前大家普遍采用的工具主要有Rational rose、Microsoft Visio、Enterprise Architect等。以Rational为例，描述业务需求和用户需求的图形包括Business Use Case、Activity框图。Business Use Case用来确定业务范围，所涉及到的角色，角色与系统之间的关系。Activity框图用来描述业务流程。描述功能需求的比较常用的有Interaction框图，该框图又分为Sequence和Collaboration框图。Sequence框图按照时间排序，侧重流程的顺序。Collaboration侧重于对象之间的关系。

以超市的简单的销售系统为例，收银员需要将客户所购买的产品的编号及数量输入进系统，系统返回产品的价格，客户将现金给收银员，收银员将现金金额输入到销售系统中，销售系统返回找零余额。这个系统涉及到的用户角色有两种，一个是系统的使用者收银员，另一个就是系统对外提供者客户。如图1所示。

图1 Business Use Case图

用Activity框图来表示整个业务流程，如图2所示。

图2 Activity框图

用Sequence框图来表示系统实现的功能需求描述。如图3所示。

图3 Sequence框图

对应的Collaboration框图如图4所示。

图4 Collaboration框图

除了这些图形之外，我们也可以利用一些其他的工具来绘制一些用户界面，这样一份需求规格说明书就比较完整而清晰了。

 

合理细化需求规格说明书

需求规格说明书的细化过程就是一个从概括性需求到低层次需求的过程。我们一般都是先知道高层次的，概括性较强的需求，但是只知道这些是根本不行的，还需要将需求进行一层层的细化，直到消除所有不确定的因素为止，用户需求规格说明书写的越详细，与用户的需求就越贴近，能够比较充分的描述用户的真正需求，但是过于详细的需求文档又会影响设计人员的实现方法，就会给设计设置很多不必要的障碍，限制了设计的思路。另外，我们的项目开发也是有进度要求的，如果需求过程花了过长的时间，那设计和编码就会相应的减少时间，所以需要找到一个平衡点，一个好的方法就是一个需求编写一些可测试用例，如果你能够想出一些相关的测试用例可以验证这个需求，那么也就达到合理的详细程度了。

例如某个产品的需求是这样的：

界面提供日期导航，当用户点击某一日期时，看到该日期下的数据。

看到这个需求描述，我们很难想出测试用例是什么？日期导航，是什么样的呢？是提供一个日期控件让用户选择呢？还是将所有日期都列出来，让用户点击呢？列出的日期又是哪些日期呢？列出一年的还是一个月的？用户点击日期后看到哪些数据呢?这些在需求中都没有进行描述。

下边我们将这个需求进行细化：

1、  后台系统根据计算机的当前日期得到当前月份；

2、  后台系统根据当前月份找到登录用户上载了自己文章的那些日期；

3、  得到这些日期的天数，由前台系统将这些天数以列表的形式显示出来；

4、  在前台系统，当用户点击列表中的某一天时。将用户上载的文章以列表形式列出来。

经过这样细化以后，将一个需求分割成了不同的小需求，每个需求我们都能想出测试用例来测试这个需求，因此这个需求细化到这个程度也就可以了。

 

重视需求过程中的沟通

将需求细化的另一个有效的方法就是与设计人员进行充分的沟通。这也是上面所提到的泥潭四，沟通在需求过程中起到了不可估量的作用，我们也常常会看到这种情况，一个气氛非常友好的开发团队，相互之间沟通比较充分，这个团队开发产品的速度也就非常快，质量也非常高。我们可能不能理解这种现象，其实这样的团队之所以成功，就是因为沟通比较顺畅，能够将需求或者设计中没有注意到的问题及时发现，并及时通过沟通来解决，这样就非常高效的避免了风险，减少了代码返工，为产品开发赢得了时间。

需求分析过程中如果能够与设计人员进行充分沟通，可以及时将需求进行细化，把系统分析员没有想到的部分再补充进来。例如系统分析员写完某个需求以后，他描述的需求设计人员是否还有不明白的地方？是否还需要更加详细的描述呢？这些都需要与设计人员进行及时的沟通。除了及时沟通以外，需求评审也是一个非常有效的沟通方式，在开始的案例中描述了评审的过程，评审人员以前根本没有看过需求规格说明书，即使系统分析员讲解一遍也是很难提出问题的，因此这样的评审其实是起不到任何作用的。做需求分析并不只是系统分析员的任务，在做需求的初期，设计人员甚至编码人员就应该参与，设计人员需要从实现的角度去查看，我需要实现某个需求还需要知道哪些信息，如果这些信息在需求中没有描述，就应该及时指出，而不是等到评审时才提出。如果设计人员没有时间参与需求编写，那么需求评审就要花费一定的时间和精力，可能需要进行多次评审，首先在评审之前系统分析员需要向设计人员讲解需求，设计人员也要在花一定的时间阅读需求规格说明书，这样在评审时才能够提出问题，如果设计人员提出的问题很多，问题也很严重，这时就需要进行需求修改，修改之后再进行评审，直到最终消除不确定问题。

由此看来沟通应该贯穿整个需求过程，沟通在需求过程中起到了文字不能达到的效果，也是消除人与人理解偏差的很重要的手段，因此在需求过程中，用户与系统分析员之间、系统分析员与设计人员和编码人员之间、设计人员与编码人员之间都需要进行充分的沟通，沟通可以解决一切。

 

好了，带大家走了一圈，您是否对需求分析过程有了一个比较清楚的认识了？您是否知道应该如何来写需求规格说明书了呢？您是否也认识到了沟通在需求分析过程中的重要性了呢？也许您现在就要马上着手准备启动一个项目了，那就赶快行动吧，不过千万要小心文章中所说的那些泥潭呦！