第5章需求工程与需求汇总.pptVIP

第5章 需求工程与需求分析 软件需求工程 需求分析与建模 需求获取的常用方法 需求模型 需求描述 需求管理 需求建模示例 5.1 软件需求工程 软件需求（requirements）描述了系统应该提供的服务以及实现和运行时所受到的约束。Lethbridge定义为需求是关于系统将要完成什么工作的一段描述，它们必须经过所有相关人员的认可，其目的是彻底的解决用户的问题。 ? 需求是一段描述…：意思是每个需求是相对短小简明的一段信息，表现为一个事实。它可以是一段话或用各种图表示。一组需求的集合成为需求文档。 ?…关于系统将要完成什么工作…：需求描述了系统应当完成的任务，不描述系统将如何实现。 ?…必须经过所有相关人员的认可…：意指需求必须经过评审，才能成为正式的需求。 ?…其目的是彻底的解决用户的问题。有助于解决用户的问题，该需求才有存在的价值。 美国队每年的项目统计$2500亿开发175000个IT项目，大的200万美元，小的几十万美元，只有16%的项目按时按预算满足要求地交付，大约31%的项目在完成之前被取消，52.7%的项目成本是原来预算成本的189%。主要原因： 缺乏用户参与占所有项目的13% 不完整的需求和规格说明17% 不断改变的需求和规格说明占12% 需求的代价 需求：1-2美元 设计：5美元 编码：10美元 单元测试：20美元 验收测试：50美元 维护：200美元 据国外统计资料表明，在典型环境下开发软件，需求分析阶段的工作量大约需占整个系统开发工作量的20%。 需求分析的定义 需求是指明系统必须实现什么的规格说明，它描述了系统的行为或属性，是在开发过程中对系统的约束。 需求分析的重要性 有关软件错误的一些事实 在软件生命周期中，一个错误发现得越晚，修复的费用也越高 许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来 在需求过程中会产生很多错误 在需求阶段，代表性的错误为疏忽，不一致和二义性 需求错误是可以被检查出来的 了解客户、最终用户、间接用户 基本概念 “用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（the end user）和“间接用户”（或称为关系人）。 掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。 客户是掏钱买软件的人，所以他是“上帝” 某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位： 如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。 “现代营销学之父”菲利普?科特勒所著的《市场营销导论》是这样描述客户的： 客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。 与客户打交道的主要目的是：一是获取需求，二是签合同。不要把钱仍到水里。 了解客户、最终用户、间接用户 即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。 如果项目规模比较大，那么开发方与最终用户的来往就比较多。如从最终用户那里获取详细的需求，请最终用户试验软件，对最终用户进行培训等等。 公司新员工上产品培训课，有位小领导匆匆赶来作指示：“隔壁班正在给电信局的员工们进行培训，他们都是上帝派来的，大家要注意形象。由于休息室空间有限，请大家自觉让位。午休时他们可以躺着睡，我们只能坐在位置上打个盹儿…….。” 重视“间接用户”，千万别“大意失荆州” 间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。 例如，财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。否则即使该软件的功能是完美的，但却被政府认为是非法的。所以国家财政部就是所有财务软件的间接用户，它不仅不付钱给财务软件开发商，反而要收取鉴定费、手续费等。 同理，市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则软件开发商被逮住后戴上“非法经营”的帽子就惨了。 需求开发的主要困难与对策 知识技能问题 应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。 当需求