需求，这真的是“需求”吗？——论需求的层次及若干问题（1）

需求的漫画：

关于需求问题，有一幅漫画十分生动地展现了这些问题（这幅漫画我其实最早是在07年一次“敏捷中国”一次软件开发技术人员日上上见到的），如果我们认真剖析后面的东西，还是会给我们的工作带来许多启发的：

究其原因，这幅漫画给人最大的启示就是在需求沟通过程中产生了严重的失真，从客户的描述到项目经理的理解、分析员分析并文档化、程序员的编码、商业顾问的诠释，每个角色都根据自己的特点和需求对信息进行了不同的加工（想当然的去理解和发挥）。

看了这幅漫画之后，我在思考一个问题，也就是需求工作是不是可以成为一项规范化的动作，而使得没有个需求分析员在进行分析之后都是一样的结果？在需求从客户到开发人员、测试人员如何做到不失真？如果能做到，我可以该怎么做？

我们首先定义下，什么是软件需求：

在定义需求的时候，我们发现需求其实也是分对象的，分层次的！

一、软件需求及其层次

1、软件需求的定义：

IEEE 软件工程标准词汇表（ 1 9 9 7 年）中定义软件需求为：
    （1）用户解决问题或达到目标所需的条件或能力（ C a p a b i l i t y）。
    （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
    （3）一种反映上面（1）或（2）所描述的条件或能力的文档说明。

2、软件需求的层次

所谓层次可以分为需求本身的层次，是业务需求、用户需求还是功能需求，也可以按照需求提出者，也是需求满足的受众来分为来自管理层的需求还是来来自执行层的需求。

软件需求包括3个层次：业务需求、用户需求和功能需求。
    (1)业务需求反映了组织机构或客户对系统高层次的目标要求。业务需求描述了为什么要实现这个系统，即希望通过该系统的实现达到什么目标。业务需求可以记录在项目视图与范围文档里，有时也被称为项目合约或市场需求文档。
    (2)用户需求描述了用户使用产品所能完成的任务。可以使用用例、方案脚本以及时间—响应表来说明用户需求。因此，用户需求定了用户可以使用系统做什么。
    (3)功能需求说明了软件的功能，用户使用这些功能以完成任务。功能需求将在软件需求说明中进行描述，软件需求说明书(SRS)将会尽可能详细的描述整个系统的行为。

　　作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。

上面的业务需求一定我们所说的来自管理层的“管理类需求”，一般是通过系统或者软件的上线之后带给公司的收益或者可以得到的报表来体现的，比如：

降低了成本；
降低的风险；
带来某种或某些机会；
增加了管理的可视性；
流程更加规范化；
达到了管控的目标；
提高了员工或者客户的客户的满意度；
通过了某些认证或者审计等。

还有一类是来自于操作层的需求，主要包括用户需求和功能需求，以及非功能需求。但是，需要指出的是，有一部的非功能需求其实是来自非业务人员的，可以视为一种管理需求，但这种管理需求不是来自于系统或者软件上线之后带来的使用价值和报表体现的。典型的是一些约束，比如只能是开放的架构和技术！

二、常见的需求风险及征兆

如果你发现你的一些做法或者与之相似，或者又如下的风险信号那么，那很不幸，您需要注意了，赶快去分析问题！

无足够用户参与，你们先开发，这个问题先放放

　　客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。究其原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。但还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。最重要的就是用户必须要重视他的软件，必须让他明白：如果失败，他的损失最大(当然你的损失也不小，但这时候你必须让他重视这项工作)。如果用户不够重视，想办法解决，否则你就不用再继续了。

我所知道好多政府项目，进度延期，往往是这个原因！

用户需求的不断增加

　　在开发中若不断地补充需求，项目就越变越庞大以致超过其计划及预算范围。这使得问题更难解决。实际上，问题根源在于用户需求的改变和开发者对新需求所作的修改。要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。

　　产品开发中不断延续的变更会使其整体结构日渐紊乱，变更也使得整个程序难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原则，特别是如果项目配置管理工作不完善的话，收回变更和删除特性会带来问题。如果你尽早地区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码，同时也有利于减少因变更导致质量的下降。

模棱两可的需求，开发人员之间的理解都不同

　　模棱两可是需求规格说明中最为可怕的问题(Lawrence 1996)。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。

　　模棱两可的需求会使不同的风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。一位系统测试人员曾告诉我，她所在的测试组经常对需求理解有误，以致不得不重写许多测试用例并重做许多测试。

　　模棱两可的需求带来不可避免的后果便是返工—重做一些你认为已做好的事情。返工会耗费开发总费用的40%，而70%～85%的重做是由于需求方面的错误所导致的(leffingwell 1997)。想像一下如果你能减少一半的返工会是怎样的情况？你能更快地开发出产品，在同样的时间内开发更多、更好的产品，甚至能偶尔回家休息休息。

　　处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍。仅仅简单浏览一下需求文档是不能解决模棱两可问题的。如果不同的评审者从不同的角度对需求说明给予解释，但每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被发现，那时再发现的话会使得更正代价很大。

被发现了不必要的特性或者功能

　　“画蛇添足”是指开发人员力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能。经常发生的情况是用户并不认为这些功能性很有用，以致在其上耗费的努力“白搭”了。

　　开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路，具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡，开发人员应努力使功能简单易用，而不要未经客户同意，擅自脱离客户要求，自作主张。

　　同样，客户有时也可能要求一些看上去很“酷”，但缺乏实用价值的功能，而实现这些功能只能徒耗时间和成本。为了将“画蛇添足”的危害尽量减小，应确信：你明白为什么要包括这些功能，以及这些功能的“来龙去脉”，这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能。

　　时刻记住：软件成功的标准是是否解决用户的问题，而不是它有多Cool的功能。

过于精简的规格说明，表达不清楚或者部分需求遗漏

　　有时，客户并不明白需求分析有如此重要，于是只作一份简略之至的规格说明，仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况(McConnell 1996)，不过商业应用大多都不是这种情况。在大多数情况下，这会给开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作)，也会给客户带来烦恼(他们无法得到他们所设想的产品)。

不准确的计划，进度经常delay

　　“上述是我对新产品的看法，好，现在你能告诉我你什么时候能完成吗？”许多开发人员都遇到这种难题。对需求分析缺乏理解会导致过分乐观的估计，而当不可避免的超支发生时，会带来颇多麻烦。据报道，导致需求过程中软件成本估计极不准确的原因主要有以下五点：频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析(Davis 1995)。

　　对不准确的要求所提问题的正确响应是“等我真正明白你的需求时，我就会来告诉你”。基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右。要作出估计时，最好还是给出一个范围(如最好的情况下，很可能的，最坏情况下)或一个可信赖的程度(我有9 0 %的把握，我能在8周内完成)。未经准备的估计通常是作为一种猜测给出的，听者却认为是一种承诺。因此我们要尽力给出可达到的目标并坚持完成它。

大家认为需求的评审只是形式，领导说了算

这也是一种风险的信号，表示没有重视用户需求和功能需求，需求的评审流于形式，没有起到实施方和客户一起review需求，发现问题的目的。

<未完，待续！>

需求，这真的是“需求”吗？——论需求的层次及若干问题（1）相关推荐

需求的最初形式：12306ng的需求小说
"什么是需求的最初形式?"这是和网友讨论的时候引发的问题,我的观点是:最容易理解的需求描述形式就是需求的最初形式.如果你是一个需求分析师(BA),客户嘴里说出来的需求被称为是&qu ...
【指标需求思考】如何做好指标类需求建设
简介:大家一直所说的[需求]究竟有哪些?用户需求.业务需求.系统需求...... 但是今天我要给大家介绍一种我自认为一种别出心裁的需求![指标类需求]在庞大的需求体系里,一个完整的系统设计流程是非常必 ...
需求处理的三个步骤：需求梳理、需求分析、需求放大
明确细准的需求是做好产品的前提. 需求要根据实际情况,进行侧重点的划分.我平时遇到是将重点放在当需求出现时,如何更好的梳理需求,并正确的分析需求.首先我们应该将需求从"确认出现", ...
什么是软件需求，什么是功能需求？——论需求的三个层次和三个方面（2）
我们的软件产品或者项目,其需求都有三个层级和三个方面. 一.我们首先看需求的三个层次软件需求包括3个不同的层次――业务需求.用户需求和功能需求. 业务需求(Business requirement) ...
近几年好的需求管理工具有哪些？不错的需求管理工具推荐！
一款好的需求管理工具,能称之为好,我认为肯定是解决我们需求管理中的经常出现的痛点,这是必备条件之一.而我要推荐的,就是这么一个神器--PingCode,这也是我经历过的几家公司都在使用的工具之一. 下 ...
产品经理如何基于需求迭代产品（上篇）：需求调研的四个步骤
作者简介: 周文熙老师,携程商业产品经理,多年工作经验, 公众号:vency不二掘金专栏:https://juejin.im/user/58cb4b612f301e007e3cc287/posts ...
需求管理之如何对客户的需求进行分类
不要指望你的客户会给需求分析者提供一个简洁.完整.组织良好的需求清单.分析者必须把代表客户需求的许多信息分成不同的类型,这样他们就能合理地编写信息文档并把它们用于最合理的方式上.那些不属于这些类型的信 ...
企业服务年年这么多“大会”，真的都了解企业数字化需求？
文|曾响铃来源|科技向令说(xiangling0815) 越是激烈变革的时代,企业们越需要交流和碰撞的机会. 这些年来,行业内颇具影响力的企业服务商们,通过各种大会来为诸多B端企业提供思想碰撞.经验 ...
软件需求规格说明书通用模版_通用需求挑战和机遇
软件需求规格说明书通用模版 When developing applications there will be requirements that are needed on more than o ...

需求，这真的是“需求”吗？——论需求的层次及若干问题（1）

需求，这真的是“需求”吗？——论需求的层次及若干问题（1）相关推荐

最新文章

热门文章