第1章需求问题(免费阅读).pptVIP

软件需求 需求:导致项目失败的罪魁祸首 根据Standish Group对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。 而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。 也就是说，有近45%的项目最终因为需求的问题最终导致失败。 我们在哪里重重摔了一跤 在Standish Group的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关： 不完整的需求(13.1%)； 缺乏用户的介入(12.4%)； 不实际的客户期望(9.9%)； 需求和规范的变更(8.7%)； 提供了不再需要的(7.5%)缺乏资源(10.6%),没有执行层支持(9.3%),缺少规划(8.1%) 项目成功的因素 用户的参与：15.9% 管理层支持：13.9% 清晰的需求描述(13.0%)； 合适的规划(9.6%)； 现实的客户期望(8.2%)； 较小的里程碑(7.7%)； 有才能的员工(7.2%) 第1章 需求问题 ? 了解软件需求开发中使用的一些关键名词。 ? 警惕在软件项目中可能出现的与需求相关的一些问题。 ? 知道优秀的需求规格说明应该具有的特点。 ? 明白需求开发与需求管理之间的区别。 需求问题 需求是软件项目成败的关键所在。 越早发现需求错误，越早改正它，其代价越小 需求是系统必须具有的能力。 好需求的特征：无歧义、完整、一致、可检验、确定、可跟踪的，正确的，可行的和必要的。 需求问题的症状 1 症状：在软件项目中，变更频繁，而且集中出现在项目的中后阶段。 分析要点： 变更是对原需求的背离，还是补遗(需求不完整)? 背离发生在什么方面(流程间/流程内/数据使用…)？ 这些变更是需求阶段是否可能预见的? 是否存在无效的变更响应(管理有问题)? 改进方向： 变更的可预测性?需求阶段标识(需求捕获/分析) 变更渠道单一化、统一化(需求管理) 需求问题的症状 2 症状：软件项目上线运行时遇到很多阻力。 分析要点： 是否为组织因素? 阻力源于操作层还是管理层? 改进方向： 清晰的业务需求导向 (需求定义) 面向不同层面的需求分析 正确识别组织因素(需求捕获) 需求问题的症状 3 症状：软件项目上线运行后效果很差。 分析要点： 为什么不使用(用户界面/功能/手工系统)? 使用者的成本/效益分析? 改进方向： 抓准业务需求(需求定义) 不同层面用户的分析(需求捕获/分析) 需求问题的症状 4 症状：产品二次开发量大。 分析要点： 二次开发量最要集中于什么方面(业务规则/用户界面/流程顺序/流程细节/报表格式)? 改进方向： 工作流模型?顺序/细节 弹性设计?业务规则/UI 报表格式?理解数据模型 需求问题的症状 5 症状：产品/项目完全不可用或崩溃。 分析要点： 忽略了哪方面非功能需求? 改进方向： 性能与能力 操作环境 可靠性 …… 中国有句谚语： “好的开始就等于成功的一半 软件开发的目标 软件开发的目标，简单而言，就是满足用户的需要 。 项目失败与成功的原因 三种最经常使项目“遇到困难”的因素是： 缺乏用户介入：占所有项目的13% 不完整的需求和规格说明：占所有项目的12% 不断改变的需求和规格说明：占所有项目的12% 三种项目最主要的“成功因素”是： 用户介入：占所有成功项目的16% 高层管理的支持：占所有成功项目的14% 需求陈述清晰：占所有成功项目的12% 2-8 原则 80%的工程活动是由20%的需求消耗的 80%的软件成本是由20%的构件消耗的 需求在项目中的作用 在项目开发中，所有的涉众（Stakeholder）都对需求分析阶段备感兴趣。 未真正明白这些问题就开始编码，结果没有人对产品满意 。 需求缺陷造成的成本增加 重新进行需求规格说明 重新设计 重新编码 重新测试 改变订单——告诉用户将以一个修正后的版本来替代有缺陷的版本。 纠正活动——消除由于不准确的特定系统的错误造成的危害，可能涉及到赔偿客户损失。 报废——包括对于已经完成的代码、设计和测试，当发现它们是根据不正确的需求进行的时候，这些工作成果不得不被丢弃。 收回有缺陷的软件产品以及相关的用户手册。 产品赔偿或保修的成本。 重新安装新版本的成本。 重新建档的成本。 “喂，是王经理吗？我是人力资源部的小李，我们在使用你编写的职员系统时遇到一个问题，一个职员想把她的名字改成高李丽娜，而系统不允许，你能帮帮忙吗？” “她嫁给了一个姓高 的人吗？” 王经理问道。 “不，她没有结婚，而仅仅是要更改她的名字，”小李回答。 “就是这问题，好像我们只能在婚姻状况改变时才能更改姓名。” “当然是这样，我从没想过谁会莫