需求分析师培训资料.pptx

需求分析师 培训 软件需求实作要点与误区分析Agenda不同软件项目的需求视图软件需求误区与应对之道需求工程组织与实作要点Agenda不同软件项目的需求视图软件需求误区与应对之道需求工程组织与实作要点软件需求误区与应对之道软件需求误区与应对之道需求问题的症状 1症状：在软件项目中，变更频繁，而且集中出现在项目的中后阶段。分析要点： 变更是对原需求的背离，还是补遗(需求不完整)? 背离发生在什么方面(流程间/流程内/数据使用…)？ 这些变更是需求阶段是否可能预见的? 是否存在无效的变更响应(管理有问题)?改进方向： 变更的可预测性?需求阶段标识(需求捕获/分析) 变更渠道单一化、统一化(需求管理)需求问题的症状 2症状：软件项目上线运行时遇到很多阻力。分析要点： 是否为组织因素? 阻力源于操作层还是管理层?改进方向： 清晰的业务需求导向 (需求定义) 面向不同层面的需求分析 正确识别组织因素(需求捕获)需求问题的症状 3症状：软件项目上线运行后效果很差。分析要点： 为什么不使用(用户界面/功能/手工系统)? 使用者的成本/效益分析?改进方向： 抓准业务需求(需求定义) 不同层面用户的分析(需求捕获/分析)需求问题的症状 4症状：产品二次开发量大。分析要点： 二次开发量最要集中于什么方面(业务规则/用户界面/流程顺序/流程细节/报表格式)?改进方向： 工作流模型?顺序/细节 弹性设计?业务规则/UI 报表格式?理解数据模型需求问题的症状 5症状：产品/项目完全不可用或崩溃。分析要点： 忽略了哪方面非功能需求?改进方向： 性能与能力 操作环境 可靠性 ……软件需求误区与应对之道需求:导致项目失败的罪魁祸首根据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%)软件需求曾经让我们如此狼狈-软件需求误区与应对之道需求是什么?业务需求业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求 。背景描述：XX保险公司希望充分利用日益完善的移动通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。业务需求/目标 ：通过该系统的实施，将人工保费续缴、投保手续办理两项业务运转周期缩短10％以上，使企业内部沟通效率大幅改善，以帮助企业运转效率得以提高。业务需求就是系统目标现状：功能分解盛行的今天，常常会犯“盲人摸象”的错误，这使得需求太过脆弱，难以经受考验。目标！目标！还是目标！--系统开发应目标驱动！目标是团队唯一的行动纲领。目标的定义不能够流于形式，应该具有以下特征：业务导向、可度量、合理、可行。要注意目标太夸大会浪费资源，目标太缩小会影响士气。（教堂与小屋）目标通常就是业务需求！用户需求用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。 用户有不同类型： 管理型、事务型 信息系统、人 决策层、使用层 常用者、偶用者组织方法：用例、用户故事、特性例子：对快到期的客户，系统将通过短信将续保信息发给该客户的代理人软件需求从系统实现的角度描述的需求。开发人员（设计及分析人员）在业务需求、用户需求的基础上生成的。有时还需要考虑相关联的硬件、环境方面的需求功能需求功能需求是需求的主体，是需求的本质功能需求定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作 零散（需求项）?整理（特性、用例）敏捷方法：用户故事质量属性产品必须具备的属性或品质 可靠性：成熟性、容错性、易恢复性易使用性：易理解性、易学习性、易操作性效率：时间特性、资源特性可维护性：易分析性、易更改性、稳定性、易测试性可移植性：适应性、易安装性、一致性、易替换性McC