7-软件需求管理.pptVIP

现状 对大多数软件和系统开发团队来说,与过去自由的日子相比,20 世纪90 年代是一个强调流程的时代。 评测和验证有效的软件开发流程的标准得到推广和普及。 论述软件开发流程的书籍和文献以及关于业务建模和重构的材料纷纷出版。 软件工具已经帮助人们制定和应用有效的软件开发流程。 在这十年内，全球经济对软件的依赖程度加深，它推动着开发流程的发展， 提高了系统质量。 既然如此，那么今天频频发生的软件项目失败的事件又如何解释呢？即使不是大多数，但为什么仍有那么多的项目受到延期、预算超支和质量问题的困扰呢？随着我们的业务、国家经济和日常活动越来越依赖于系统，如何才能提高系统的质量？ 需求的噩梦 为什么要管理需求？ 简单地说，系统开发团队之所以管理需求，是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求，达到目标的几率就会降低。 也就是说，好的需求管理是项目成功的第一位因素。采用需求管理可以给项目组带来很多好处，直至项目取得成功。 Brooks[1987]，不能得到完整、正确以及无二义性的软件需求仍然是如今导致软件开发失败的一个重大原因 一组统计数据 据Standish Group的研究表明：在美国 每年大约花2500亿美元，开发17.5万个应用程序项目 大公司开发项目的平均成本是232.2万美元 中等公司的平均成本是133.1万美元 小公司则是43.4万美元 另一方面 大约31%的项目在完成之前被取消 52.7%的项目成本是项目原来预算的189% 因此 ，Standish Group估计美国公司和政府机构 在被取消软件项目上的花费，每年大约是810亿美元 同样他们为超过交付时间而需要多支付590亿美元 软件开发的问题分类 ESPITI(欧洲软件过程改进培训倡议）调查3800位人士，得出软件开发的主要问题、次要问题和不是问题的问题如图 一半以上的人认为软件的两个最大问题是： 1、需求规格说明 2、管理客户需求 项目失败的根本原因 Standish Group的研究表明：对软件项目的评价因素，可以归纳为：成功（大公司只占9%、小公司有16%)、有异议（推迟且没有达到预期的目标）、失败（取消）。 而有异议的三个主要原因是： 1、缺乏用户的参与，占所有项目的13%； 2、不完整的需求和规格说明，占所有项目的12%； 3、不断改变的需求和规格说明，占所有项目的12%。 而其他因素，则比例较小，例如： 不合理的时间进度和时间分段（4%） 人和资源不足（6%） 技术技能不够（7%） 结论：1/3的项目直接与需求的获取、建档和管理有关 需求变化分析 合理范围内的变化 用户不了解自己的需求 需求本身易变：市场、技术、竞争因素 不合理的变化 需求文档质量不高 需求分析技能、技术和管理上的缺陷 需求变化的原因 未受控制的需求变更 遗漏需求 用户交流不够 需求规约质量差 低效的需求分析 为什么要管理需求 迭代开发模式下，需求在项目各阶段所占有的比例 需求错误修复的代价 需求工程 需求开发活动 确定产品所期望的用户类别。 获取每个用户类别的需求。 了解实际用户的任务和目标以及这些任务所支持的业务需求。 分析源于用户的信息,以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。 需求开发活动（续） 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 了解相关质量属性的重要性。 商讨实施优先级的划分。 将所收集的用户需求编写成规格说明和模型。 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。 1. 需求管理活动 CMMI中需求管理的流程图 1.1 版本控制 需求文档的每一个版本必须被统一确定。 组内每个成员必须能够得到需求的当前版本。 必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。 为了尽量减少困惑、冲突、误传，应仅允许指定的人来更新需求。 需求的属性 创建需求的时间 需求的版本号 创建需求的作者 负责认可该需求的人员 需求状态 需求的原因或根据（或信息的出处） 需求涉及的子系统 需求的属性（续） 需求涉及的产品版本号 使用的验证方法或接受的测试标准 产品的优先级或重要程度（例如高、中、低或） 需求的稳定性（在将来需求可能变更的指示器，不稳定的需求意味你应给予较多的关注，因为你将面临不定的、混沌的、或不能重复的业务过程。） 建议的需求状态表 状态跟踪示例 1.2 需求变更管理 应仔细评估已建议的变更?。 挑选合适的人选对变更做出决定。 变更应及时通知所有涉及的人员。 项目要按一定的程序来采纳需求变更。 控制项目范围的扩展 –危害性 扩展需求是指在软件需求基线已经确定后又要增添