📄 200603061756235.html
字号:
<html>
<head><title>软件需求</title></head>
<center><h1>软件需求</h1></center>
<div><P align=right><FONT face=Verdana><FONT color=#f70938><FONT face=黑体><a href="200604112229525.html" tppabs="http://www.itisedu.com/phrase/200604112229525.html" target="_new">中科永联</a>高级技术培训中心（</FONT><FONT face=黑体>www.itisedu.com</FONT><FONT face=黑体>）<IMG src="200632719853128.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/200632719853128.jpg" border=0></FONT></FONT></P>
<P><BR> <a href="200603061756235.html" tppabs="http://www.itisedu.com/phrase/200603061756235.html" target="_new">软件需求</a>是(1)用户解决问题或达到目标所需的条件或权能(Capability)。<BR> (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。<BR> (3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。<BR> （IEEE<a href="200602281725525.html" tppabs="http://www.itisedu.com/phrase/200602281725525.html" target="_new">软件工程</a>标准词汇表(1997年)中定义）</P>
<P><STRONG>一、<a href="200604232134205.html" tppabs="http://www.itisedu.com/phrase/200604232134205.html" target="_new">软件</a><a href="200603101518295.html" tppabs="http://www.itisedu.com/phrase/200603101518295.html" target="_new">需求</a>的发展</STRONG></P>
<P> <a href="200603282310205.html" tppabs="http://www.itisedu.com/phrase/200603282310205.html" target="_new">需求工程</a>是随着<a href="200603021438435.html" tppabs="http://www.itisedu.com/phrase/200603021438435.html" target="_new">计算机</a>的发展而发展的，在计算机发展的初期，软件规模不大，<a href="200603282233345.html" tppabs="http://www.itisedu.com/phrase/200603282233345.html" target="_new">软件开发</a>所关注的是代码编写，<a href="200603062220345.html" tppabs="http://www.itisedu.com/phrase/200603062220345.html" target="_new">需求分析</a>很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。随着<a href="200602281706245.html" tppabs="http://www.itisedu.com/phrase/200602281706245.html" target="_new">软件系统</a>规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。80年代中期，形成了软件工程的子领域——需求工程(requirement engineering, RE)。进入90年代以来，需求工程成为研究的热点之一。从1993年起每两年举办一次需求工程国际研讨会(ISRE)，自1994年起每两年举办一次需求工程国际会议(ICRE)，在1996年Springer-Verlag发行了一新的刊物——《Requirements Engineering》。一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR(Requirements Engineering Network of International Cooperating Research Groups )，并开始开展工作。</P>
<P><STRONG>二、软件需求的层次</STRONG></P>
<P> 下面这些定义是需求工程领域中常见术语的定义说明。</P>
<P> 软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目<a href="200603141659315.html" tppabs="http://www.itisedu.com/phrase/200603141659315.html" target="_new">视图</a>与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200603042249305.html \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon. \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200603042249305.html'" tppabs="http://www.itisedu.com/phrase/200603042249305.html" target="_new">use case</a>)文档或方案脚本(scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。</P>
<P> 作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。 值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。</P>
<P> Frederick Brooks在他1987年的经典的文章“No Silver Bullet：Essence and Accidents of<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200604240910235.html \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon. \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200604240910235.html'" tppabs="http://www.itisedu.com/phrase/200604240910235.html" target="_new">Software Engineering</a> ”中充分说明了需求过程在软件项目中扮演的重要角色：</P>
<P> 开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。</P>
<P> 为什么这么说呢，因为在大多数的软件系统中，最终用户可能都不清楚他的需求是什么，这是千真万确的。如果你的用户告诉你需求就是这些了，不要相信他，继续刨根问底，直到你们都筋疲力尽了。</P>
<P> 虽然听上去有些不可思议，但这是教训之谈，在我从事的项目之中，没有一个用户在软件接近完成的时候打电话对我说，我看了你们的软件，我想我必须改动一些地方。在那些日子中，我甚至得了一种电话铃音恐惧症。</P>
<P><STRONG>三、需求风险</STRONG></P>
<P> 下面列出了在做需求分析时一些很危险的做法，如果你发现你的一些做法与之相似，那么，给自己一些时间，好好思考一下，这些做法会对你的软件产生致命的影响。</P>
<P><STRONG> 1. 无足够用户参与</STRONG></P>
<P> 客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。究其原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。但还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。 最重要的就是用户必须要重视他的软件，必须让他明白：如果失败，他的损失最大(当然你的损失也不小，但这时候你必须让他重视这项工作)。如果用户不够重视，想办法解决，否则你就不用再继续了。</P>
<P><STRONG> 2. 用户需求的不断增加</STRONG></P>
<P> 在开发中若不断地补充需求，项目就越变越庞大以致超过其计划及预算范围。这使得问题更难解决。实际上，问题根源在于用户需求的改变和开发者对新需求所作的修改。要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照<a href="200603061723295.html" tppabs="http://www.itisedu.com/phrase/200603061723295.html" target="_new">框架</a>。说明中包括了对每种变更<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200604161444295.html \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon. \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200604161444295.html'" tppabs="http://www.itisedu.com/phrase/200604161444295.html" target="_new">进行变更</a>影响因素分析的变更控制过程，有助于所有<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200604240830255.html \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon. \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200604240830255.html'" tppabs="http://www.itisedu.com/phrase/200604240830255.html" target="_new">风险承担者</a>明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。</P>
<P> 产品开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个<a href="200604232224305.html" tppabs="http://www.itisedu.com/phrase/200604232224305.html" target="_new">程序</a>难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原则，特别是如果项目<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200602271137552.html \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon. \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200602271137552.html'" tppabs="http://www.itisedu.com/phrase/200602271137552.html" target="_new">配置管理</a>工作不完善的话，收回变更和删除特性会带来问题。如果你尽早地区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码，同时也有利于减少因变更导致质量的下降。</P>
<P> 最糟糕的莫过于用户觉得如果不再加点什么功能就对不起自己。我曾经看过一个<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200603091358275.html \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon. \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200603091358275.html'" tppabs="http://www.itisedu.com/phrase/200603091358275.html" target="_new">数据仓库</a>的一期工程，在设计阶段没有很好的定义范围，当我向<a href="200604240825565.html" tppabs="http://www.itisedu.com/phrase/200604240825565.html" target="_new">项目管理</a>者提出这个问题的时候，他认为都已经说好了，合同上也写清楚了，并没有加以重视。可是最后，用户提出的修改意见已经远远超出了范围，项目时间也延长了一倍。整个的项目组成员疲惫不堪，可是却不断的接到用户投诉说项目失败。</P>
<P><STRONG> 3. 模棱两可的需求</STRONG></P>
<P> 模棱两可是需求规格说明中最为可怕的问题(Lawrence 1996)。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。</P>
<P> 模棱两可的需求会使不同的风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。一位<a href="200603111950135.html" tppabs="http://www.itisedu.com/phrase/200603111950135.html" target="_new">系统测试</a>人员曾告诉我，她所在的测试组经常对需求理解有误，以致不得不重写许多<a href="200603291707535.html" tppabs="http://www.itisedu.com/phrase/200603291707535.html" target="_new">测试用例</a>并重做许多测试。</P>
<P> 模棱两可的需求带来不可避免的后果便是返工—重做一些你认为已做好的事情。返工会耗费开发总费用的40%，而70%～85%的重做是由于需求方面的错误所导致的(leffingwell 1997)。想像一下如果你能减少一半的返工会是怎样的情况？你能更快地开发出产品，在同样的时间内开发更多、更好的产品，甚至能偶尔回家休息休息。</P>
<P> 处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍。仅仅简单浏览一下需求文档是不能解决模棱两可问题的。如果不同的评审者从不同的角度对需求说明给予解释，但每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被发现，那时再发现的话会使得更正代价很大。</P>
<P><STRONG> 4. 不必要的特性</STRONG></P>
<P> “画蛇添足”是指开发人员力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能。经常发生的情况是用户并不认为这些功能性很有用，以致在其上耗费的努力“白搭”了。</P>
<P> 开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路，具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡，开发人员应努力使功能简单易用，而不要未经客户同意，擅自脱离客户要求，自作主张。</P>
<P> 同样，客户有时也可能要求一些看上去很“酷”，但缺乏实用价值的功能，而实现这些功能只能徒耗时间和成本。为了将“画蛇添足”的危害尽量减小，应确信：你明白为什么要包括这些功能，以及这些功能的“来龙去脉”，这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能。</P>
<P> 时刻记住：软件成功的标准是是否解决用户的问题，而不是它有多Cool的功能。</P>
<P><STRONG> 5. 过于精简的规格说明</STRONG></P>
<P> 有时，客户并不明白需求分析有如此重要，于是只作一份简略之至的规格说明，仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况(McConnell 1996)，不过商业应用大多都不是这种情况。在大多数情况下，这会给开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作)，也会给客户带来烦恼(他们无法得到他们所设想的产品)。</P>
<P><STRONG> 6. 忽略了用户分<a href="200603090857555.html" tppabs="http://www.itisedu.com/phrase/200603090857555.html" target="_new">类</a></STRONG></P>
<P> 大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果你不能在项目早期就针对所有这些主要用户进行分类的话，必然导致有的用户对产品感到失望。例如，菜单驱动操作对高级用户太低效了，但含义不清的命令和快捷键又会使不熟练的用户感到困难。</P>
<P><STRONG> 7. 不准确的计划</STRONG></P>
<P> “上述是我对新产品的看法，好，现在你能告诉我你什么时候能完成吗？”许多开发人员都遇到这种难题。对需求分析缺乏理解会导致过分乐观的估计，而当不可避免的超支发生时，会带来颇多麻烦。据报道，导致需求过程中软件成本估计极不准确的原因主要有以下五点：频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析(Davis 1995)。</P>
<P> 对不准确的要求所提问题的正确响应是“等我真正明白你的需求时，我就会来告诉你”。基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右。要作出估计时，最好还是给出一个范围(如最好的情况下，很可能的，最坏情况下)或一个可信赖的程度(我有9 0 %的把握，我能在8周内完成)。未经准备的估计通常是作为一种猜测给出的，听者却认为是一种承诺。因此我们要尽力给出可达到的目标并坚持完成它。</P>
<P><STRONG>四、什么是优秀的需求</STRONG></P>
<P> 讨论软件需求的文章有很多，对于需求的标准也不尽相同，这里我想用NASA的软件开发过程中的概念，软件需求过程的标准是：清楚(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)，此外还有其他的概念，如可跟踪的、可修改的等等。</P>
<P> 清楚：目前大多数的需求分析采用的仍然是自然语言（因为如果采用形式化语言的话，和用户的沟通将成为一个大问题，这意味着客户在开发软件之前必须先进行形式化语言培训，这是不现实的）。自然语言对需求分析最大的弊病就是它的二义性。所以我们不得不对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。说白了，需求分析中的描述让人看上去像是刚学习写作的小孩子就对了，千万不要采用疑问句、修饰这些华丽的表达方式。</P>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -