软件需求讲义-第一部分(部分).pptVIP

软件需求 从谚语开始 中国有句谚语：“好的开始就等于成功的一半” 西方的谚语是：“Garbage in, garbage out！” 内容概要 软件需求的基本概念 需求工程与需求工程过程 需求获取与需求分析 需求文档与需求质量验证 软件需求管理 软件需求参考书 第一部分 软件需求的基本概念 需求问题 需求的层次 第1章 需求问题 需求是软件项目成败的关键所在 越早发现需求错误，越早改正它，其代价越小 需求的定义 好需求的特征：无歧义、完整、一致、可检验、确定、可跟踪的，正确的，可行的和必要的。 软件开发中的错误观点 只要掌握了1-2门程序设计语言，进行软件开发就没有问题。 只要有最好的开发工具、最好的计算机，一定能做出优秀的软件。 软件需求分析很困难，不管三七二十一，先把软件做了再说，反正软件是灵活的，随时可以修改。 总之，错误认为：软件就是程序，开发软件就是编写 程序。 项目失败与成功的原因* 三种最经常使项目“遇到困难”的因素是： 缺乏用户介入：占所有项目的13% 不完整的需求和规格说明：占所有项目的12% 不断改变的需求和规格说明：占所有项目的12% 三种项目最主要的“成功因素”是： 用户介入：占所有成功项目的16% 高层管理的支持：占所有成功项目的14% 需求陈述清晰：占所有成功项目的12% *[Standish Group ，1994] 软件开发的目标 软件开发的目标，简单而言，就是满足用户的需要 。 需求在项目中的作用 未真正明白这些问题就开始编码，结果没有人对产品满意 。 在项目开发中，所有的涉众（Stakeholder）都对需求分析阶段备感兴趣。（没有理所当然的需求） 2-8 原则：举足轻重 2-8 原则* 80%的工程活动是由20%的需求消耗的 80%的软件成本是由20%的构件消耗的 *[Royce，1998] 需求错误的代价 需求缺陷造成的成本增加 重新进行需求规格说明 重新设计 重新编码 重新测试 改变订单——告诉用户将以一个修正后的版本来替代有缺陷的版本。 纠正活动——消除由于不准确的特定系统的错误造成的危害，可能涉及到赔偿客户损失。 报废——包括对于已经完成的代码、设计和测试，当发现它们是根据不正确的需求进行的时候，这些工作成果不得不被丢弃。 收回有缺陷的软件产品以及相关的用户手册。 产品赔偿或保修的成本。 重新安装新版本的成本。 重新建档的成本。 高质量的需求过程带来的好处 在开发后期和整个维护阶段的重做的工作大大减少了 。 让用户积极参与需求收集过程能使产品更富有吸引力，而且能建立起更加忠实的客户关系 。 用户的参与能弥补用户期望和开发者实际开发之间的“鸿沟”（期望差异）。 将确定的系统需求明确地分配到各软件子系统，确保软硬件系统功能匹配适当。 有效的变更控制也能降低需求变更带来的负面影响 。 将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量 。 需求定义 [IEEE 1997] IEEE软件工程标准词汇表定义需求为： 用户解决问题或达到目标所需的条件或能力。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 一种反映上面(1)或(2)所描述的条件或能力的文档说明。 需求定义[Thayer, Dorfman. 1997] Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义： 用户解决某一问题或达到某一目标所需的软件功能。 系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。 好的需求应具有的特性 无歧义性 完整性 一致性 可检验性 确定性 可跟踪性 正确性 可行性 必要性 无歧义性 产生歧义的原因 同一个词具有多种含义 编写人员会下意识假设所有人对某个主题都具有和自己一样的认知水准 缩写 叙述不够具体 …… 无歧义性（续） 示例：系统只允许保留5个有效地相关记录和保障计划，它必须包括最新的。 无歧义性（续） 消除歧义的方法 对感到模糊的地方刨根问底 关键字技术 其他技术 完整性 不能遗漏任何需求或必要的信息 如果不能确定某项需求，务必用TBD（to be determined，待确定）来标识 项目开发前，必须解决需求中所有的TBD项 每项需求必须完整描述即将交付使用的功能 遗漏需求将很难查出来 完整性（续） 防止遗漏的方法 注重用户的任务而不是系统的功能。 将高层需求分解足够细，让用户真正的需求显示出来：“应该、将要、可能” →“将、必须”。 务必让所有用户类都提出意见，确保每个用例都至少有一个执行者。 用多种方式表达需求：UML模型、数据流图、判定表 （树）、E-R图等。 跟踪系统需求、业务规则、用例，直