[讨论]什么是需求

中国IT动力,最新最全的IT技术教程

最新100篇 | 推荐100篇 | 专题100篇 | 排行榜 | 搜索 | 在线API文档

当前位置：> 程序开发 > 软件工程 > 综合文章

[讨论]什么是需求

作者:未知时间:2005-09-13 19:46 出处:ChinaUnix.net 责编:chinaitpower

摘要：[讨论]什么是需求

[color=darkblue:93682d0d5e][size=18:93682d0d5e]转贴：[b:93682d0d5e]什么是需求[/b:93682d0d5e][/size:93682d0d5e]

(来源：Linuxaid.com.cn)

一、什么是需求

软件需求
    对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”(Leffingwell 1997)。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟(期望差异)—开发者开发的与用户所想得到的软件存在着巨大期望差异。

    在软件工程中，所有的风险承担者(stakeholder)(这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人)都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。

软件需求的定义

    IEEE软件工程标准词汇表(1997年)中定义需求为：

    (1)用户解决问题或达到目标所需的条件或权能(Capability)。
    (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
    (3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。

需求的层次

    下面这些定义是需求工程领域中常见术语的定义说明。

    软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。

    作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。

    值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。

    Frederick Brooks在他1987年的经典的文章“No Silver Bullet：Essence and Accidents ofSoftware Engineering ”中充分说明了需求过程在软件项目中扮演的重要角色：

    开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。

    为什么这么说呢，因为在大多数的软件系统中，最终用户可能都不清楚他的需求是什么，这是千真万确的。如果你的用户告诉你需求就是这些了，不要相信他，继续刨根问底，直到你们都筋疲力尽了。

    虽然听上去有些不可思议，但这是教训之谈，在我从事的项目之中，没有一个用户在软件接近完成的时候打电话对我说，我看了你们的软件，我想我必须改动一些地方。在那些日子中，我甚至得了一种电话铃音恐惧症。

需求风险

    下面列出了在做需求分析时一些很危险的做法，如果你发现你的一些做法与之相似，那么，给自己一些时间，好好思考一下，这些做法会对你的软件产生致命的影响。

    1. 无足够用户参与

    客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。究其原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。但还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。

    最重要的就是用户必须要重视他的软件，必须让他明白：如果失败，他的损失最大(当然你的损失也不小，但这时候你必须让他重视这项工作)。如果用户不够重视，想办法解决，否则你就不用再继续了。

    2. 用户需求的不断增加

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

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

    最糟糕的莫过于用户觉得如果不再加点什么功能就对不起自己。我曾经看过一个数据仓库的一期工程，在设计阶段没有很好的定义范围，当我向项目管理者提出这个问题的时候，他认为都已经说好了，合同上也写清楚了，并没有加以重视。可是最后，用户提出的修改意见已经远远超出了范围，项目时间也延长了一倍。整个的项目组成员疲惫不堪，可是却不断的接到用户投诉说项目失败。

    3. 模棱两可的需求

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

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

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

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

    4. 不必要的特性

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

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

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

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

    5. 过于精简的规格说明

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

    6. 忽略了用户分类

    大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果你不能在项目早期就针对所有这些主要用户进行分类的话，必然导致有的用户对产品感到失望。例如，菜单驱动操作对高级用户太低效了，但含义不清的命令和快捷键又会使不熟练的用户感到困难。

    7. 不准确的计划

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

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

什么是优秀的需求

    讨论软件需求的文章有很多，对于需求的标准也不尽相同，这里我想用NASA的软件开发过程中的概念，软件需求过程的标准是：清楚(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)，此外还有其他的概念，如可跟踪的、可修改的等等。

    清楚：目前大多数的需求分析采用的仍然是自然语言（因为如果采用形式化语言的话，和用户的沟通将成为一个大问题，这意味着客户在开发软件之前必须先进行形式化语言培训，这是不现实的）。自然语言对需求分析最大的弊病就是它的二义性。所以我们不得不对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。说白了，需求分析中的描述让人看上去像是刚学习写作的小孩子就对了，千万不要采用疑问句、修饰这些华丽的表达方式。

    除了语言的二义性之外，主意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。

    打个比方，如果你要做一个银行的信用卡系统，你就可以这样描述软件需求：银行的卡部管理信用卡，每张信用卡只属于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。

    完整：再也没有什么比软件开发接近完成是发现遗漏了一项需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遗漏需求而不得不返工，这简直就是恶梦。可是令人遗憾的是，需求的遗漏是很经常发生的事情，不仅仅是你的问题，更多的问题发生在用户那里，他们不知道该做些什么。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。至于完整性的详细讨论，我们会在下面的章节中讨论，现在你只需要拼命的想象缺乏完整性的坏处，直到你出了一身的冷汗。出了吗？好，那我们继续。

    一致：一致性也是一个比较大的概念，很难用几句话讲清楚。还记得我们在开始的时候提到的需求的层次吗？简单的来说，就是用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。在实现过程中，我们还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。

    可测试：大家觉得一个项目的测试从什么时候开始呢？有人说从编码完成后开始。更清楚一点的说是编码的时候同时进行单元测试，编码完成后进行系统测试。这些都没有错。但是实际上测试是从需求分析过程就开始了。需求分析是测试计划的输入和参照。这就要求需求分析是可测试的。什么是可测试呢？“我们要用新的系统完成报表自动化处理”，你觉得这个需求是可测试的吗？当然不是，报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。因此这项需求是无法测试的，就是不具有可测试性。说到这里，大家可能就会明白之前的需求的几项标准都是为了保证需求的可测试性的。事实就是这样，只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。大家真正在应用一些科学的方法的时候也应该记住，任何的方法都是为了保证软件的成功，不要偏离这个目标，千万不要走火入魔了，呵呵，很容易的。
原作者:axing[/color:93682d0d5e]

sidt 回复于：2004-07-17 17:14:15

好文阿，那么大家就来讨论一下吧。

我来抛砖先了  :P

文中提到：
软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。 (图丢了？？   :shock:  )

业务需求、用户需求、功能需求，这三者之间，并不是完全并列的关系，而是在逻辑上有着从外到内、从整体到细节的深入和细化的关系。
比如：要设计一个系统-电视机，（这玩意儿大家都清楚是干么的吧， 8)  ）
1。业务需求：为用户提供看电视的服务。请注意，是服务，是用从外部的眼光，全局的性看这一需要实现的东东。
2。用户需求：为了让用户能够看到电视节目，需要提供：接受电视信号、显示到屏幕、可以换台等。这些内容都是为业务需求服务的，也是为了能够看到电视节目所必不可少的。即，用户需求，是业务需求的深入和细化。
3。功能需求：对用户需求的内容进一步细化：如何才能提供接受电视信号的功能？答：需要有信号接收器，并进行信号变化处理。如何才能显示到屏幕？答需要有显像管...

说到这里，觉的这个例子有些不合适阿  :em23:
请看下贴了

sidt 回复于：2004-07-17 17:22:21

上边举的例子，把有些内容没有讲清楚。 :oops:

因为没有把用户和使用者分开，在大系统中这都是分开的。
比如，给电信做的计费系统，用户是电信这家单位，作为用户（其代表人-单位领导）更关心业务需求，用户付钱，是因为你的产品能够提供需要的服务，而不是说为了其中某个具体的功能(在上边的例子中，就可以理解为，你购买电视机的决定性因素，是因为它能够让你看到电视节目，而不是因为它能接受电视信号，或其他单个功能)。
而作为实际使用者的各个职能部门，它只会关心自己相关的业务流程如何处理，而不关心其他内容。
在到操作人员，关心的就是更加具体了 - 填写某表格该输入那些数据等之类。

sidt 回复于：2004-07-17 22:20:08

拜托各位，吭个声阿。。。

如果同意，可以说说你的宝贵意见；如果不同意，拿砖块拍我也行啊。

虽说沉默是金，可您千万别。。只看不回阿，:(

carol1980 回复于：2004-07-19 10:00:57

哈哈~~~ sidt 不用急~

文章是要慢慢看的，讨论也是不用急于一时的~~

yutian 回复于：2004-07-21 09:43:09

呵呵，做这一行的，

怕用户没有需求（我们吃什么呀）
怕用户需求变更（还要不要我们活呀）

需求分析是一个很高的能力要求

sidt 回复于：2004-07-22 09:28:11

怕用户没有需求（我们吃什么呀）
怕用户需求变更（还要不要我们活呀）

--说得好啊。

没有需求，说明没有市场；
进入开发阶段了，而需求发生变更，那就要命了。
完全不变化，几乎是不可能的。所以我们就要在需求分析中发现潜在的变化点，在设计实现时充分考虑到这些可能变化的因素，达到设计支持变化的效果；同时，和用户作好沟通，在一定的时间段内稳固需求，使之成为当前设计和实现的基础。

amiescort 回复于：2004-07-22 11:49:59

[quote:503e3ac6e7]最糟糕的莫过于用户觉得如果不再加点什么功能就对不起自己。我曾经看过一个数据仓库的一期工程，在设计阶段没有很好的定义范围，当我向项目管理者提出这个问题的时候，他认为都已经说好了，合同上也写清楚了，并没有加以重视。可是最后，用户提出的修改意见已经远远超出了范围，项目时间也延长了一倍。整个的项目组成员疲惫不堪，可是却不断的接到用户投诉说项目失败。 [/quote:503e3ac6e7]

概念上的东西大家都懂，偶想问些实际的：上述文字中描述的情况在偶从前的项目中一直存在，不知大家的情况如何？又是怎么去克服的呢？把心得拿出来分享一下吧。

sidt 回复于：2004-07-22 14:03:06

楼上提到的情况，旁边并行的一个项目组就这样啊，搞的大家疲惫不堪，很是痛苦啊。

当时为了抢这个项目，打点了用户单位的相关人。同时也有别的竞争对手打点了其他人。最后是我们拿下了这个单子。
结果在开发实施开始后，项目组就陷入了泥潭：用户单位里面有些闹派系，被对手打点了的那些人对我们老是找麻烦，在这些“上帝”面前，你怎么做都是不对。只好再次打点他们，让他们闭嘴阿。

amiescort 回复于：2004-07-22 14:28:18

[quote:39336f9b3d="sidt"]楼上提到的情况，旁边并行的一个项目组就这样啊，搞的大家疲惫不堪，很是痛苦啊。

当时为了抢这个项目，打点了用户单位的相关人。同时也有别的竞争对手打点了其他人。最后是我们拿下了这个单子。
结果在开发实施..........[/quote:39336f9b3d]
呵呵，你说的这个好像……已经超出了软件工程的范畴了吧，偶这经常遇到的情况是用户喜欢在一些细枝末节的功能点上和我们纠缠不清，这些东西实在太过细节，说是需求变更吧，又不太说得过去，但却实实在在的影响了项目的正常进度。这种情况又该怎么处理呢？？

sidt 回复于：2004-07-22 17:46:37

哈哈，楼上说的是，那完全是技术之外的事了。

有时候面向用户时，会遇到各种可笑事。对一些细节的功能问题，用户可能会提出一些古怪的想法，要求你实现一个根本毫无用处的东西。如果关系处理的好，你给他解释后，他可能最后说，不要也罢。如果关系不好，那可能就是证明你的产品不足的一个证据。他会理志气庄的说，这个功能在**中就有，而你的产品中没有。。。而其实，他所说的**可能和你现在做的产品完全不是一类。

sidt 回复于：2004-07-22 17:52:59

这类问题，就是项目的产品经理和用户沟通的内容了。那些要做，那些不做；那些先做，那些后；那些可以免费做，那些需要再加钱才能做...

zyme 回复于：2004-08-10 10:17:10

很好

funyoung 回复于：2004-08-12 13:55:48

用户的需求不变的话，就更没有饭吃啦。

变是绝对的，不变是相对的。

ddddddddd 回复于：2004-08-17 11:15:18

它认为软件开发过程就是一个变化的过程，不能用严谨（另一个意思是死板）的语言来描述，它用用户故事这种含混自然的东西描述，同时要求用户有一个人要一直参与（这个体现了创始人的个性），用这个来保证需求的正确性。
在开发上它也有一套应付变化的东西，在4大原则上都有体现。
它始终没用需求设计编码测试维护这些典型生命期概念描述这种开发过程，也许它认为概念问题并不重要。
我觉得从这个角度讲，正常的需求变化并不可怕，可怕的是不知道如何应付需求变化，可能经验在这里就很厉害了。
我同时觉得想象客户有可能在哪些需求上有变化，在代码上留出弹性是不可取的。
当项目经理对项目涉及的问题域了然于胸的时候，在编码人员能够熟练驾驭开发工具的时候，正常的需求变化不应该是很大的障碍。

utirei 回复于：2005-03-09 10:05:57

抱歉，我想问需求分析都包括什么？只是针对客户的吗？我看这还是很模糊。可能我读书的时候，软件工程这么课程没有学习好。还有是，工作几年也没有详细接触过需求分析。不过，我认为，需求分析，应该从客户与公司两方面考虑。第一部，是客户技术上的需求？（开发环境之类等等，如果客户提出一个你根本不能实现的技术，你接单子岂不是必砸）。第二，是客户业务上的需求，从各个方面调查客户在业务上的需要，以及分界点等等。第三，完成业务需求要实现的功能以及实现程度的需求。我觉得大致是这三点，如果不对，请大家指正，互相学习。

芹菜回复于：2005-03-10 11:28:38

我看不错啊！
就是太长啦！！

关闭本页