第5章 需求工程与需求分析

《第5章 需求工程与需求分析》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、第5章需求工程与需求分析软件需求工程需求分析与建模需求获取的常用方法需求模型需求描述需求管理需求建模示例15.1软件需求工程软件需求（requirements）描述了系统应该提供的服务以及实现和运行时所受到的约束。Lethbridge定义为需求是关于系统将要完成什么工作的一段描述，它们必须经过所有相关人员的认可，其目的是彻底的解决用户的问题。•需求是一段描述…：意思是每个需求是相对短小简明的一段信息，表现为一个事实。它可以是一段话或用各种图表示。一组需求的集合成为需求文档。2•…关于系统将要完成什么工作…：需求描述了系统应当完成的任务，不描述

2、系统将如何实现。•…必须经过所有相关人员的认可…：意指需求必须经过评审，才能成为正式的需求。•…其目的是彻底的解决用户的问题。有助于解决用户的问题，该需求才有存在的价值。3美国队每年的项目统计$2500亿开发175000个IT项目，大的200万美元，小的几十万美元，只有16%的项目按时按预算满足要求地交付，大约31%的项目在完成之前被取消，52.7%的项目成本是原来预算成本的189%。主要原因：缺乏用户参与占所有项目的13%不完整的需求和规格说明17%不断改变的需求和规格说明占12%4需求：1-2美元设计：5美元编码：10美元单元测试：20美

3、元验收测试：50美元维护：200美元据国外统计资料表明，在典型环境下开发软件，需求分析阶段的工作量大约需占整个系统开发工作量的20%。需求的代价5需求分析的定义需求是指明系统必须实现什么的规格说明，它描述了系统的行为或属性，是在开发过程中对系统的约束。6需求分析的重要性有关软件错误的一些事实在软件生命周期中，一个错误发现得越晚，修复的费用也越高许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来在需求过程中会产生很多错误在需求阶段，代表性的错误为疏忽，不一致和二义性需求错误是可以被检查出来的7了解客户、最终用户、间接用户基本概念“用户”

4、（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（theenduser）和“间接用户”（或称为关系人）。掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。客户是掏钱买软件的人，所以他是“上帝”某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位：如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。“现代营销学之父”菲利普•科特勒所著的《市场营销导论》是这样描述客户的：客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客

5、户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。与客户打交道的主要目的是：一是获取需求，二是签合同。不要把钱仍到水里。8了解客户、最终用户、间接用户即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。如果项目规模比较大，那么开发方与最终用户的来往就比较多。如从最终用户那里获取详细的需求，请最终用户试验软件，对最终

6、用户进行培训等等。公司新员工上产品培训课，有位小领导匆匆赶来作指示：“隔壁班正在给电信局的员工们进行培训，他们都是上帝派来的，大家要注意形象。由于休息室空间有限，请大家自觉让位。午休时他们可以躺着睡，我们只能坐在位置上打个盹儿…….。”重视“间接用户”，千万别“大意失荆州”间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。例如，财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。否则即使该软件的功能是完美的，但却被政府认为是非法的。所以国家财政部就是所有财务软件的间接用户，它不仅

7、不付钱给财务软件开发商，反而要收取鉴定费、手续费等。同理，市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则软件开发商被逮住后戴上“非法经营”的帽子就惨了。9需求开发的主要困难与对策知识技能问题应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。当需求分析员缺乏应用域知识时，他该怎么办？首先他要有勇气做事，否则连实践的机会都没有。其次他应

8、当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。态度问题相当多的开发人员习惯