(CEN)第一章软件需求概述.ppt

1.5 优秀的团队遇到糟糕的需求 需求问题导致的主要后果是返工——重复做您认为早已做好的事情。 返工的成本占了总开发成本的30%～50%(Boehm和Papaccio 1988)，而对于返工的情况，70%～80%是因需求错误引起的(Leffingwell 1997)。 从下图可以看出，在项目末期才发现缺陷，对其进行改正的成本要比在缺陷刚产生不久时修改的成本高得多。 1.5.1 用户参与不足 开发人员往往也不重视用户的参与，原因是他们认为与用户打交道不像写代码那么有趣，或者自以为已经知道了用户想要什么。 用户参与不足将导致不能在项目早期及时发现需求中的缺陷，从而延误项目的完成。 在整个项目开发过程中，开发团队必须始终与实际用户直接合作。 1.5.2 用户需求扩展 由于开发过程中需求的不断发展与增加，项目往往会落后于计划的进度并超出预算。 出现这种情况是因为没有依据对需求的规模和复杂度的实际评估来制订计划，而不断修改需求又使情况变得更糟。 问题的责任部分在于用户不断提出修改需求的要求，部分在于开发人员处理这种要求的方式。 要控制项目范围的改变： 首先应明确项目的业务目标、全局规划、范围、限制、成功标准以及产品的预计用途。 然后参考这一框架对所有新特性和需求变更进行评估。 1.5.3 有岐义的需求 岐义表现为同一读者可以对一项需求声明作出多种解释，或者不同的读者对同一需求产生不同的理解。 岐义会导致以下几点： 涉众对产品怀有不同的期望。因此最终交付的产品会让部分人感到意外。 有岐义的需求使开发人员的时间浪费在解决无需解决的问题上。 有岐义的需求导致测试人员与开发人员对产品功能的理解不同，从而使测试人员也要浪费时间来解决这些差异。 消除歧义的办法之一是让代表不同观点的人对需求作正式的检查 。 1.5.4 镀金问题 开发人员为产品添加了一项需求说明中没有提到的功能，他认为“用户肯定会喜欢的”。这就是所谓的“镀金问题(gold plating)”。 开发人员和需求分析员不应擅自添加特性，应该把创意和备选方案提交给客户，让他们做决定。 要避免镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功能。 1.5.5 过于抽象的需求 营销人员或经理经常喜欢只给出一个粗略的说明，他们希望开发人员在开发过程中充实它。 这种方式对研究性项目或需求特别灵活的项目或许管用，但是需要紧密合作的团队，而且仅限于开发小型系统(McConnell 1996)。 大多数情况下，这种做法的结果是使开发人员受挫，让客户失望。 1.5.6 忽略了某类用户 用户所使用的产品特性、产品的使用频率以及用户自身的经验水平不尽相同。 因此，多数产品都拥有不同的用户群。如果一开始没能找出产品的所有重要用户群，就会有某些用户需求得不到满足。确定所有用户群后，还要保证获得各类用户的需求 。 1.5.7 不准确的计划 不能充分理解需求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。 造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确，以及对需求的分析不透彻(Davis 1995)等。 1.6 需求规格说明 软件需求规格说明也称软件需求规约或功能规格说明。是需求工程最终产生的结果。 需求规格说明是软件所应满足的全部需求，并用文档的方式完整和精确地陈述这些需求。 需求规格说明是项目相关人员对将要开发的软件系统所达成的共识,是进行系统设计\实现、测试和验收的基本依据,也是整个软件开发过程中最重要的文档. 每一项用户需求、业务需求和功能需求都应具备下列性质 : (1) 完整性 每一项需求都必须完整地描述即将交付使用的功能。 (2) 正确性 每一项需求都必须准确地描述将要开发的功能。 (3) 可行性 需求必须能够在系统及其运行环境的已知能力和约束条件内实现。 (4) 必要性 每一项需求记录的功能都必须是用户的真正需要，或者是为符合外部系统需求或某一标准而必须具备的功能。 (5) 有优先次序 为每一项功能需求、特性或用例指定一个实现优先级，以表明它在产品的某一版本中的重要程度。 (6) 无歧义 一项需求声明对所有读者应该只有一种一致的解释，然而自然语言却极易产生歧义。 (7) 可验证性 看看您能否设计一些测试方法或使用其他验证方法，如检查或演示来判断产品是否正确实现了需求。 需求规格说明中所包含的整体需求集还必须具备下列特性: (1) 完整性 不能遗漏任何需求或必要的信息。 需求遗漏问题很难被发现，因为它们并没有列出来。 (2) 一致性 需求的一致性是指需求不会与同一类型的其他需求或更高层次的业务、系统