📄 软件需求.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0050)http://www.itisedu.com/phrase/200603061756235.html -->
<HTML><HEAD><TITLE>软件需求</TITLE>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.2873" name=GENERATOR></HEAD>
<BODY>
<CENTER>
<H1>软件需求</H1></CENTER>
<DIV>
<P align=right><FONT face=Verdana><FONT color=#f70938><FONT face=黑体><A
href="http://www.itisedu.com/phrase/200604112229525.html"
target=_new>中科永联</A>高级技术培训中心（</FONT><FONT face=黑体>www.itisedu.com</FONT><FONT
face=黑体>）<IMG src="软件需求.files/200632719853128.jpg" border=0></FONT></FONT></P>
<P><BR> <A
href="http://www.itisedu.com/phrase/200603061756235.html"
target=_new>软件需求</A>是(1)用户解决问题或达到目标所需的条件或权能(Capability)。<BR> (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。<BR> (3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。<BR> （IEEE<A
href="http://www.itisedu.com/phrase/200602281725525.html"
target=_new>软件工程</A>标准词汇表(1997年)中定义）</P>
<P><STRONG>一、<A href="http://www.itisedu.com/phrase/200604232134205.html"
target=_new>软件</A><A href="http://www.itisedu.com/phrase/200603101518295.html"
target=_new>需求</A>的发展</STRONG></P>
<P> <A
href="http://www.itisedu.com/phrase/200603282310205.html"
target=_new>需求工程</A>是随着<A
href="http://www.itisedu.com/phrase/200603021438435.html"
target=_new>计算机</A>的发展而发展的，在计算机发展的初期，软件规模不大，<A
href="http://www.itisedu.com/phrase/200603282233345.html"
target=_new>软件开发</A>所关注的是代码编写，<A
href="http://www.itisedu.com/phrase/200603062220345.html"
target=_new>需求分析</A>很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。随着<A
href="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="http://www.itisedu.com/phrase/200603141659315.html"
target=_new>视图</A>与范围文档中予以说明。用户需求(user requirement)
文档描述了用户使用产品必须要完成的任务，这在使用实例(<A
href="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="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="http://www.itisedu.com/phrase/200603061723295.html"
target=_new>框架</A>。说明中包括了对每种变更<A
href="http://www.itisedu.com/phrase/200604161444295.html"
target=_new>进行变更</A>影响因素分析的变更控制过程，有助于所有<A
href="http://www.itisedu.com/phrase/200604240830255.html"
target=_new>风险承担者</A>明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。</P>
<P> 产品开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个<A
href="http://www.itisedu.com/phrase/200604232224305.html"
target=_new>程序</A>难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原则，特别是如果项目<A
href="http://www.itisedu.com/phrase/200602271137552.html"
target=_new>配置管理</A>工作不完善的话，收回变更和删除特性会带来问题。如果你尽早地区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码，同时也有利于减少因变更导致质量的下降。</P>
<P> 最糟糕的莫过于用户觉得如果不再加点什么功能就对不起自己。我曾经看过一个<A
href="http://www.itisedu.com/phrase/200603091358275.html"
target=_new>数据仓库</A>的一期工程，在设计阶段没有很好的定义范围，当我向<A
href="http://www.itisedu.com/phrase/200604240825565.html"
target=_new>项目管理</A>者提出这个问题的时候，他认为都已经说好了，合同上也写清楚了，并没有加以重视。可是最后，用户提出的修改意见已经远远超出了范围，项目时间也延长了一倍。整个的项目组成员疲惫不堪，可是却不断的接到用户投诉说项目失败。</P>
<P><STRONG> 3. 模棱两可的需求</STRONG></P>
<P> 模棱两可是需求规格说明中最为可怕的问题(Lawrence
1996)。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。</P>
<P> 模棱两可的需求会使不同的风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。一位<A
href="http://www.itisedu.com/phrase/200603111950135.html"
target=_new>系统测试</A>人员曾告诉我，她所在的测试组经常对需求理解有误，以致不得不重写许多<A
href="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>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -