项目需求工程V1..pptx

项目需求工程V1..pptx

《项目需求工程V1..pptx》由会员分享，可在线阅读，更多相关《项目需求工程V1..pptx（65页珍藏版）》请在冰豆网上搜索。

项目需求项目需求项目需求项目需求工程工程工程工程2-65故事故事1131243-65故事故事11唯一不变的只有变化本身！

FrederickBrooks人月神话5677用户或市场人员很难能够清楚地描述自己的需求，且需求在不断变化！

需求很难获取！

4-65故事故事221.销售的承诺2.客户提及的需求3.项目经理理解的需求4.设计人员的设计5.程序员完成的代码123456789106.文档7.安装包8.成本9.支持10.客户真正需要的东西需求的理解，仁者见仁智者见智（差异）！

需求很难管控！

5-65需求的重要性需求的重要性软件开发中的问题：

6-65需求的重要性需求的重要性需求问题代价：

15102050200需求设计编码单元测试验收测试系统维护1个需求错误的代价=5个设计失误的代价=200个系统维护的代价需求如此重要-是项目成败的重要原因！

项目需求需要进行科学的管理！

7-65什么是需求？

8-65需求的定义需求的定义什么是需求？

IEEE软件工程标准词汇表用户解决问题或达到目标所需要的条件或者能力。

系统或者系统部件要满足合同、标准、规范或者其他正式规定文档所需要的条件或者能力。

一种反应以上或所描述的条件或能力的文档说明。

9-65需求层次需求层次产品需求规格说明书u需求层次10-65需求层次概念需求层次概念反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

业务需求文档描述了用户使用产品必须要完成的任务，这在用例文档或方案脚本说明中予以说明。

用户需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

功能需求11-65需求层次差异需求层次差异n业务需求:

系统应该做什么的高层描述说明开发软件的目的、业务原理、战略、愿景、范围和期望的价值作为项目的指导和用户需求的基础n用户需求:

详细的业务需求要执行的任务描述需要满足用户的功能n软件需求:

高层架构功能和非功能需求定义系统内的功能和特性详细架构、设计和测试计划的来源不同需求规格的重点12-65需求层次实例解释需求层次实例解释可能是：

“用户能够有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能表明“这是个满足业务需求的拼写检查器”。

业务需求可能是：

“找出文档中的拼写错误，并通过一个提供的替换列表来供选择替换拼写的词”。

用户需求还有其他功能需求，如：

找到并高亮提示错词的操作；显示提供替换词的对话框，以及实现整个文档范围的替换。

功能需求u一个字处理程序例子一个字处理程序例子13-65需求开发需求开发需求收集模型需求收集模型n无关需求:

n客户对这类需求是否实现不太关心。

实现这类需求会增加不必要的成本，并且也会带来风险。

n基本需求:

n基本需求是客户认为在产品中应该满足的需求。

如果产品没有满足这些基本需求，顾客就很不满意。

相反，当产品满足基本需求时，也不会提升客户满意度。

n期望需求:

n这类需求在产品中实现得越多，客户就越满意。

所以这类需求实现得越多越好，它可能成为战胜其他产品的决定性因素。

n魅力需求:

n如果这类需求没有被实现，客户不会不满意，但是如果产品满足了这类需求，客户就会对产品非常满意。

这些需求会使产品与竞争对手的产品区分开来，并且可以提升价值和价格。

需求的类型与定义功能不全卡诺图魅力需求期望需求基本需求满意的客户不满意的客户功能完备14-65需求如何获取？

需求如何管理？

15-65需求工程需求工程需求开发需求获取需求分析需求文档编写需求验证需求管理需求变更版本控制需求跟踪需求状态跟踪需求工程n需求工程：

指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。

需求工程，是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。

n需求工程分为需求开发过程和需求管理过程。

u需求获取及管理的科学方法需求工程16-65需求开发与需求管理的关系需求开发与需求管理的关系需求开发需求管理RequirementDevelopment（需求开发）17-65需求开发需求获取需求分析需求文档编写需求验证需求管理需求变更版本控制需求跟踪需求状态跟踪需求工程18-65需求开发需求开发流程流程确认并验证需求通过验证的需求软件需求开发软件需求业务需求记录业务需求开发用户需求用户需求分析需求分析后的需求19-65需求开发需求开发n开发客户需求收集干系人需要、期望、限制和接口的要求并翻译成客户需求。

n需求开发过程需求收集：

在生命周期的各个阶段收集干系人需要、期望、限制和接口的要求。

需求转换：

将收集到的要求转换成客户需求。

20-65需求开发需求获取需求分析需求文档编写需求验证需求管理需求变更版本控制需求跟踪需求状态跟踪需求工程21-65需求获取需求获取归纳和整理用户提出的各种问题和要求；弄清用户企图通过软件达到的目的；借助各种工具和方法，陈述用户提出的实际需求，并标定软件的作用范围。

u需求获取主要工作最终目的弄明白要“做什么”。

22-65需求获取需求获取确定产品的不同用户类型确定用户需求的来源挑选出每一类用户和其他涉众的代表并与他们一起工作分析谁是项目需求的决策者（干系人）u获取需求应采用的步骤23-65需求获取需求获取n客户购买产品的人n用户使用产品的人n向谁收集需求？

u干系人客户VS用户需求收集对象n对于项目n对于产品甲方甲方客户、用户合作方客户、用户市场部门已有产品的竞争对手合作伙伴24-65需求获取需求获取u需求分析中重要内容接口需求识别25-65需求获取需求获取u引导需求六边形法则26-65需求获取需求获取组织结构：

企业为进行相应的业务流程所做的人员的组织安排。

业务流程：

企业开展业务所必须的各个环节及在每个环节中的具体做法。

业务数据：

企业内部经营信息的存储和流动形式。

业务地点分布：

反映企业在什么地方开展业务以及业务流程中的各个环节之间的地点关系。

业务应用：

企业以什么样的应用软件处理业务流程中的各个环节。

技术基础设施：

企业在信息技术基础设施上的状况。

u需求调研的六边形法则27-65需求获取需求获取n深入浅出对企业的需求调研，要尽可能的全面、细致，调研的需求是个全集系统真正实现的各个子集。

调研的细致，并不等于在分析时，面面俱到地将调研的内容全部纳入到系统中,而有可能实现的很少。

n以流程为主线应该用流程将所有的内容串起来，如单据、信息、组织结构、处理规则等；流程的描述既要有宏观，又要有微观。

28-65需求获取需求获取制定并落实调研计划在调研前和用户讲清楚调研的意义、过程、以及需要注意的问题发问时以一人为主,其他人注意记录与查找问题在用户讲解时,不要中断用户,使对方有充分的演说机会对询问的问题要有记录，记录要点u需求获取过程中的注意事项29-65需求获取需求获取和用户进行访谈和调研，通常是适用于任何环境下的最重要、最直接的方法之一。

通过几次这样的访谈，开发人员和系统分析员能获得一些问题域中的知识，对要解决的问题有进一步的理解。

u需求获取方法1访谈和调研30-65需求获取需求获取专题讨论会，是一种可用于任何情况下的软件需求调研方法。

专题讨论会的目的：

是鼓励软件需求调研并且在很短的时间内对讨论的问题达成一致。

专题讨论会一般由开发团队的成员主持，主要讨论系统应具备的特征或者评审系统特性。

专题讨论会前的准备工作是能否成功的举行会议的关键。

u需求获取方法2专题讨论会31-65需求获取方法需求获取方法33脑力风暴，是一种获取新观点或创造性的解决方案，非常有用的方法。

通常，专题讨论会的一部分时间是用于进行脑力风暴，找出关于软件系统的新想法和新特征。

脑力风暴包括两个阶段：

想法产生阶段和想法精化阶段。

u需求获取方法3脑力风暴32-65需求开发需求获取需求分析需求文档编写需求验证需求管理需求变更版本控制需求跟踪需求状态跟踪需求工程33-65需求分析需求分析n需求分析包括提炼、分析和仔细审查已收集到的需求，为最终用户所看到的系统建立一个概念模型，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。

n分析用户需求应该执行以下活动：

绘制系统关联图分析需求可行性确定需求的优先级别为需求建立模型创建用户接口原型建立数据字典u需求分析34-65需求分析需求分析u分析需求准则完整性：

完整描述即将交付使用的功能正确性：

经过用户或用户信任的代理人审阅可行性：

在已知能力和约束条件中实现必要性：

每项需求记录的功能都应是用户真正需要的有优先次序：

提供了实现优先级无歧义：

对所有读者只有一种一致的解释可验证性：

可以设计测试方法来检查35-65需求分析需求分析问答分析方法问答分析方法很简单：

刨根究底地问，如果问题都被解答了，那么需求也就分析清楚了。

一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。

问答分析最重要的问题是：

“是什么”和“为什么”。

每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。

如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。

追究“是什么”和“为什么”的目的是获得正确、清楚的需求。

其它常见的问题有：

需求存在二义性吗？

需求文档的上下文有矛盾吗？

需求完备吗？

需求是必要的吗？

需求可实现吗？

需求可验证吗？

需求的优先级确定了吗？

u需求分析方法1问答分析法36-65需求分析需求分析软件需求分析者利用场景或经历来描述用户和软件系统的交互方式，并以此来获取软件需求。

使用用例的分析方法来源于面向对象的思想。

用例分析方法最大的特点在于面向用例，在对用例的描述中引入了场景、角色的概念。

u需求分析方法2用例分析法原型法是为了快速开发系统而推出的一种开发模式，旨在改进传统的结构化生命周期法的不足，缩短开发周期，减少开发风险。

u需求分析方法3原型分析法37-65需求开发需求获取需求分析需求文档编写需求验证需求管理需求变更版本控制需求跟踪需求状态跟踪需求工程38-65需求规格说明书编写需求规格说明书编写u需求规格说明书编写软件需求规格说明，是阐述一个软件系统必须提供的功能和性能，以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。

需求分析完成的标志是提交一份完整的软件需求规格说明书。

软件需求规格说明作为产品需求的最终成果必须包括所有的需求。

在开发人员的组织中要为编写软件需求文档定义一种标准模板。

要求：

正确：

正确地反映用户的真实意图；清楚：

易读易懂；无二义性完备:

没有遗漏一些必要的需求；可实现：

“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束；确定优先级：

确定高中低三个级别，将风险降到最低。

阐述“做什么”而不是“怎么做”39-65需求规格说明书编写需求规格说明书编写u需求规格说明书模板40-65需求开发需求获取需求分析需求文档编写需求验证需求管理需求变更版本控制需求跟踪需求状态跟踪需求工程41-65需求验证需求验证验证是为了确保需求说明准确、无二义性，并完整地表达系统功能以及必要的质量特性。

需求验证要求客户代表和开发人员共同参与，对提交后的需求规格说明进行验证，分析需求的正确性，完整性以及可行性等。

需求验证中的活动一般包括：

审查需求文档以需求为依据编写测试用例编写用户手册确定合格的标准最后的签字u需求验证42-65需求管理需求管理u管理需求ManageRequirements（管理需求）获取和理解需求获取对需求的承诺管理需求变更维护需求的双向可跟踪性识别工作产品和需求的跟踪跟踪距阵需求43-65需求管理需求管理n获取对需求的理解与需求提供者就需求的含义，对系统开发的需求进行理解n获取对需求的承诺从项目的参与者处获取承诺n管理需求变更当需求在项目中逐渐被开发时，管理需求变更n维护双向的需求跟踪在需求和工作产品之间维护双向的可跟踪性n识别项目工作和需求之间的不一致识别存在与项目计划、工作产品和需求之间的不一致u需求管理44-65需求管理需求管理u需求管理的原则及主线n建立需求基线n控制对需求基线的变更n保持项目计划与需求一致n