[计算机软件及应用]ch01.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%) 软件需求让我们如此狼狈 我们应该怎么办？ 对“需求”建立正确的认识； 客户和供应商—一根绳子上的两个蚂蚱； 和客户一起建立起“共同的目标”； 寻找并使用正确的、有效的需求捕获、描述（建模）、管理方法； 动态、持续地适应需求的变化； 第1章 软件需求基础知识 软件或系统项目涉众(stake holder，产品或项目相关人员)的利益之间的相互作用在需求过程中表现得最为强烈。项目涉众包括： 客户: 为达到其公司的业务目标而投资项目或购买产品。 用户：直接或间接与产品打交道，是客户的一部分。 需求分析员：负责编写需求并传达给开发团队。 开发人员：设计、实现和维护产品。 测试人员：确定产品的行为是否与预计的相一致。 文档编制人员：负责编写用户手册、培训资料和系统帮助。 项目经理：制定项目计划并带领开发人员获得成功。 法律人员：确保产品符合所有相关法规。 生产人员：制造包含该软件的产品。 市场营销: 技术支持及其他与产品和客户打交道的人员。 1.1 软件需求的定义 软件行业存在这样一个问题，用于描述需求工作的术语没有统一的定义。 对同一项需求，不同的人会有不同的描述，称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。 客户对需求的定义，在开发人员看来可能只是高级别的产品概念；而开发人员的需求概念对用户来说也许就是详细的用户界面设计。 1.1.1 对需求的不同解释 IEEE(Institute of Electrical and Electronics Engineers) 美国电气和电子工程师协会的软件工程标准术语表(1990)则将需求定义为: 用户为解决某个问题或达到某个目标而需具备的条件或能力。 系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。 上述第一项或第二项中定义的条件和能力的文档表达。 系统所要实现的功能以及相应的非功能需求.(上世纪60年代末) 为了解决用户的问题或者达成业务的目的,而提供的功能和相应的非功能需求. (1997年) 1.1.2 需求的层次 软件需求包括3个不同的层次——业务需求、用户需求和功能需求: 除此之外，每个系统还有各种非功能需求。图1.1中的模型给出了各种需求关系的示意图。 业务需求(Business requirement)表示组织或客户高层次的目标。 用户需求(user requirement)描述的是用户的目标，或用户要求系统必须能完成的任务。 功能需求(funetional requirement)规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。 术语系统需求(system requirement)用于描述包含多个子系统的产品(即系统)的顶级需求。 业务需求 业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求 。 背景描述：XX保险公司希望充分利用日益完善的移动通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。 业务需求/目标 ：通过该系统的实施，将人工保费续缴、投保手续办理两项业务运转周期缩短10％以上，使企业内部沟通效率大幅改善，以帮助企业运转效率得以提高。 业务目标示例 业务需求就是定义系统目标 现状：功能分解盛行的今天，常常会犯“盲人摸象”的错误，这使得需求太过脆弱，难以经受考验。 目标！目标！还是目标！--系统开发应目标驱动！目标是团队唯一的行动纲领。 目标的定义不能够流于形式，应该具有以下特征：业务导向、可度量、合理、可行。要注意目标太夸大会浪费资源，目标太缩小会影响士气。（教堂与小屋） 目标通常就是业务需求！ 业务需求就是定义系统目标 目标在哪里？业务需求是构建在“项目发起人”的脑子里的，也就是谁提出项目，谁就拥有对“业务需求”的最清晰的理解。