项目需求工程V1.

1、项目需求项目需求工程工程2-65故事故事1 131243-65故事故事1 1唯一不变的只有变化本身！ Frederick Brooks 人月神话5677用户或市场人员很难能够清楚地描述自己的需求，且需求在不断变化！需求很难获取！4-65故事故事2 21.销售的承诺2.客户提及的需求3.项目经理理解的需求4.设计人员的设计5.程序员完成的代码123456789106. 文档7. 安装包8. 成本9. 支持10.客户真正需要的东西需求的理解，仁者见仁智者见智（差异）！需求很难管控！5-65需求的重要性需求的重要性软件开发中的问题：6-65需求的重要性需求的重要性需求问题代价/p>

2、需求设计编码单元测试验收测试系统维护1个需求错误的代价=5个设计失误的代价= =200个系统维护的代价需求如此重要-是项目成败的重要原因！项目需求需要进行科学的管理！7-65什么是需求？8-65需求的定义需求的定义什么是需求？IEEE软件工程标准词汇表 用户解决问题或达到目标所需要的条件或者能力。 系统或者系统部件要满足合同、标准、规范或者其他正式规定文档所需要的条件或者能力。 一种反应以上 或 所描述的条件或能力的文档说明。9-65需求层次需求层次产品需求规格说明书u 需求层次10-65需求层次概念需求层次概念反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说

3、明。业务需求文档描述了用户使用产品必须要完成的任务，这在用例文档或方案脚本说明中予以说明。用户需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。功能需求11-65需求层次差异需求层次差异n 业务需求: 系统应该做什么的高层描述说明开发软件的目的、业务原理、战略、愿景、范围和期望的价值作为项目的指导和用户需求的基础n 用户需求: 详细的业务需求 要执行的任务描述 需要满足用户的功能n 软件需求: 高层架构功能和非功能需求定义系统内的功能和特性详细架构、设计和测试计划的来源不同需求规格的重点12-65需求层次实例解释需求层次实例解释可能是：“用户能够有效地纠正文档

4、中的拼写错误”，该产品的包装盒封面上可能表明“这是个满足业务需求的拼写检查器”。业务需求可能是：“找出文档中的拼写错误，并通过一个提供的替换列表来供选择替换拼写的词”。用户需求还有其他功能需求，如：找到并高亮提示错词的操作；显示提供替换词的对话框，以及实现整个文档范围的替换。功能需求u 一个字处理程序例子一个字处理程序例子13-65需求开发需求开发需求收集模型需求收集模型n 无关需求:n客户对这类需求是否实现不太关心。实现这类需求会增加不必要的成本，并且也会带来风险。n 基本需求:n基本需求是客户认为在产品中应该满足的需求。如果产品没有满足这些基本需求，顾客就很不满意。相反，当产品满足基本需求

5、时，也不会提升客户满意度。 n 期望需求:n这类需求在产品中实现得越多，客户就越满意。所以这类需求实现得越多越好，它可能成为战胜其他产品的决定性因素。n 魅力需求:n如果这类需求没有被实现，客户不会不满意，但是如果产品满足了这类需求，客户就会对产品非常满意。 这些需求会使产品与竞争对手的产品区分开来，并且可以提升价值和价格。需求的类型与定义功能不全卡诺图魅力需求期望需求基本需求满意的客户不满意的客户功能完备14-65需求如何获取？需求如何管理？15-65需求工程需求工程需求开发需求获取需求分析需求文档编写需求验证需求管理需求变更版本控制需求跟踪需求状态跟踪需求工程n需求工程：指应用已证实有效的

6、技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。需求工程，是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。n需求工程分为需求开发过程和需求管理过程。u 需求获取及管理的科学方法需求工程16-65需求开发与需求管理的关系需求开发与需求管理的关系需求开发需求管理Requirement Development（需求开发）17-65需求开发需求获取需求分析需求文档编写需求验证需求管理需求变更版本控制需求跟踪需求状态跟踪需求工程18-65需求开发需求开发流程流程确认并验证需求通过验证的需求软件需求开发软件需求业务需求记录

7、业务需求开发用户需求用户需求分析需求分析后的需求19-65需求开发需求开发n 开发客户需求收集干系人需要、期望、限制和接口的要求并翻译成客户需求。n 需求开发过程需求收集：在生命周期的各个阶段收集干系人需要、期望、限制和接口的要求。需求转换：将收集到的要求转换成客户需求。20-65需求开发需求获取需求分析需求文档编写需求验证需求管理需求变更版本控制需求跟踪需求状态跟踪需求工程21-65需求获取需求获取 归纳和整理用户提出的各种问题和要求； 弄清用户企图通过软件达到的目的； 借助各种工具和方法，陈述用户提出的实际需求，并标定软件的作用范围。u 需求获取主要工作最终目的弄明白要“做什么”。22-6

8、5需求获取需求获取 确定产品的不同用户类型 确定用户需求的来源 挑选出每一类用户和其他涉众的代表并与他们一起工作 分析谁是项目需求的决策者（干系人）u 获取需求应采用的步骤23-65需求获取需求获取n 客户购买产品的人n 用户使用产品的人n 向谁收集需求？u 干系人客户 VS 用户需求收集对象n 对于项目n 对于产品 甲方 甲方客户、用户 合作方 客户、用户 市场部门 已有产品的竞争对手 合作伙伴 24-65需求获取需求获取u 需求分析中重要内容接口需求识别25-65需求获取需求获取u 引导需求六边形法则26-65需求获取需求获取 组织结构：企业为进行相应的业务流程所做的人员的组织安排。 业务

9、流程：企业开展业务所必须的各个环节及在每个环节中的具体做法。 业务数据：企业内部经营信息的存储和流动形式。 业务地点分布：反映企业在什么地方开展业务以及业务流程中的各个环节之间的地点关系。 业务应用：企业以什么样的应用软件处理业务流程中的各个环节。 技术基础设施：企业在信息技术基础设施上的状况。u 需求调研的六边形法则27-65需求获取需求获取n 深入浅出对企业的需求调研，要尽可能的全面、细致，调研的需求是个全集系统真正实现的各个子集。调研的细致，并不等于在分析时，面面俱到地将调研的内容全部纳入到系统中, 而有可能实现的很少。n 以流程为主线应该用流程将所有的内容串起来，如单据、信息、组织结构

10、、处理规则等；流程的描述既要有宏观，又要有微观。28-65需求获取需求获取 制定并落实调研计划 在调研前和用户讲清楚调研的意义、过程、以及需要注意的问题 发问时以一人为主,其他人注意记录与查找问题 在用户讲解时,不要中断用户,使对方有充分的演说机会 对询问的问题要有记录，记录要点u 需求获取过程中的注意事项29-65需求获取需求获取和用户进行访谈和调研，通常是适用于任何环境下的最重要、最直接的方法之一。通过几次这样的访谈，开发人员和系统分析员能获得一些问题域中的知识，对要解决的问题有进一步的理解。u 需求获取方法1访谈和调研30-65需求获取需求获取专题讨论会，是一种可用于任何情况下的软件需求

11、调研方法。专题讨论会的目的：是鼓励软件需求调研并且在很短的时间内对讨论的问题达成一致。专题讨论会一般由开发团队的成员主持，主要讨论系统应具备的特征或者评审系统特性。专题讨论会前的准备工作是能否成功的举行会议的关键。u 需求获取方法2专题讨论会31-65需求获取方法需求获取方法3 3脑力风暴，是一种获取新观点或创造性的解决方案，非常有用的方法。通常，专题讨论会的一部分时间是用于进行脑力风暴，找出关于软件系统的新想法和新特征。 脑力风暴包括两个阶段：想法产生阶段和想法精化阶段。u 需求获取方法3脑力风暴32-65需求开发需求获取需求分析需求文档编写需求验证需求管理需求变更版本控制需求跟踪需求状态跟

12、踪需求工程33-65需求分析需求分析n 需求分析包括提炼、分析和仔细审查已收集到的需求，为最终用户所看到的系统建立一个概念模型，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。n 分析用户需求应该执行以下活动：绘制系统关联图分析需求可行性确定需求的优先级别为需求建立模型创建用户接口原型建立数据字典u 需求分析34-65需求分析需求分析u 分析需求准则 完整性：完整描述即将交付使用的功能 正确性：经过用户或用户信任的代理人审阅 可行性：在已知能力和约束条件中实现 必要性：每项需求记录的功能都应是用户真正需要的 有优先次序：提供了实现优先级 无歧义：对所有读者只有一种一致

13、的解释 可验证性：可以设计测试方法来检查35-65需求分析需求分析问答分析方法 问答分析方法很简单：刨根究底地问，如果问题都被解答了，那么需求也就分析清楚了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。 问答分析最重要的问题是：“是什么”和“为什么”。每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。 其它常见的问题有： 需求存在二义性吗？ 需求文档的上下文有矛盾吗？ 需求完备吗？

14、需求是必要的吗？ 需求可实现吗？ 需求可验证吗？ 需求的优先级确定了吗？ u 需求分析方法1问答分析法36-65需求分析需求分析软件需求分析者利用场景或经历来描述用户和软件系统的交互方式，并以此来获取软件需求。使用用例的分析方法来源于面向对象的思想。用例分析方法最大的特点在于面向用例，在对用例的描述中引入了场景、角色的概念。u 需求分析方法2用例分析法原型法是为了快速开发系统而推出的一种开发模式，旨在改进传统的结构化生命周期法的不足，缩短开发周期，减少开发风险。u 需求分析方法3原型分析法37-65需求开发需求获取需求分析需求文档编写需求验证需求管理需求变更版本控制需求跟踪需求状态跟踪需求工程

15、38-65需求规格说明书编写需求规格说明书编写u 需求规格说明书编写软件需求规格说明，是阐述一个软件系统必须提供的功能和性能，以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。需求分析完成的标志是提交一份完整的软件需求规格说明书。软件需求规格说明作为产品需求的最终成果必须包括所有的需求。在开发人员的组织中要为编写软件需求文档定义一种标准模板。要求：正确：正确地反映用户的真实意图；清楚：易读易懂；无二义性完备:没有遗漏一些必要的需求；可实现： “可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束；确定优先级：确定高中低三个级别，将风

16、险降到最低。阐述“做什么”而不是“怎么做”39-65需求规格说明书编写需求规格说明书编写u 需求规格说明书模板40-65需求开发需求获取需求分析需求文档编写需求验证需求管理需求变更版本控制需求跟踪需求状态跟踪需求工程41-65需求验证需求验证验证是为了确保需求说明准确、无二义性，并完整地表达系统功能以及必要的质量特性。需求验证要求客户代表和开发人员共同参与，对提交后的需求规格说明进行验证，分析需求的正确性，完整性以及可行性等。需求验证中的活动一般包括：审查需求文档以需求为依据编写测试用例编写用户手册确定合格的标准最后的签字u 需求验证42-65需求管理需求管理u 管理需求Manage Requ

17、irements（ 管理需求）获取和理解需求获取对需求的承诺管理需求变更维护需求的双向可跟踪性识别工作产品和需求的跟踪跟踪距阵需求43-65需求管理需求管理n 获取对需求的理解与需求提供者就需求的含义，对系统开发的需求进行理解n 获取对需求的承诺从项目的参与者处获取承诺n 管理需求变更当需求在项目中逐渐被开发时，管理需求变更n 维护双向的需求跟踪在需求和工作产品之间维护双向的可跟踪性n 识别项目工作和需求之间的不一致识别存在与项目计划、工作产品和需求之间的不一致u 需求管理44-65需求管理需求管理u 需求管理的原则及主线n 建立需求基线n 控制对需求基线的变更n 保持项目计划与需求一致n 控

18、制单个需求及需求文档的版本情况n 管理需求和联系链之间的联系或管理单个需求和其它项目可交付品之间的依赖关系。n 跟踪基线中需求的状态（已实现、已验证、已删除等）注释：基线，是在软件工程环境中，基线是指在软件开发过程中的里程碑，这些里程碑的标志是一项或多项经过正式的技术评审并一致认同的软件制品的提交。45-65需求管理需求管理u 需求管理版本控制n 版本控制是管理需求的一个必要方面。n 需求文档的每一个版本必须被统一确定。n 组内每个成员必须能够得到需求的当前版本，必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。例： 一位开发人员在项目的每周例会上说：“我终于实现了库存报告中重排序的

19、功能。”项目管理者说：“噢，用户在两周前就取消这个功能了。你没看改过的软件需求规格说明吗？”46-65需求管理需求管理u 需求管理需求变更管理n 是否给予变更，谁来判断n 明确变更紧急程度，紧急变更立即处理n 变更影响分析n 不紧急变更批量处理，建议分三批需求形成基线前设计完成前试运行完成前47-65需求管理需求管理u 需求管理需求跟踪n 目的：建立和维护从用户需求到测试的一致性与完整性，确保实现都以客户需求为基础，实现的需求覆盖了预期的需求，并确保输出与用户需求的符合性。n 作用：在需求验证中，便于确保所有需求被应用有助于变更影响分析便于需求的维护便于测试时找出问题所在便于项目跟踪和减少项目

20、风险简化了系统再设计，易于软件重用48-65需求管理需求管理u 需求管理需求状态跟踪n 在整个开发过程中，跟踪每个需求的状态是需求管理的一个重要方面。n 建议的需求状态表：状态值定义已建议该需求已被有权提出需求的人建议已批准该需求已被分析，估计了其对项目余下部分的影响（包括成本和对项目其余部分的干扰），已用一个确定的产品版本号或创建编号分配到相关的基线中，软件开发团队已同意实现该项需求。已实现已实现需求代码的设计、编写和单元测试已验证使用所选择的方法验证了实现的需求，例如测试和检测，审查该需求跟踪与测试用例相符。该需求现在被认为完成。已删除计划的需求已从基线中删除，但包括一个原因说明和做出删除

21、决定的人员49-65案例分析50-65案例分析案例分析本节以本节以HRMS（Human Resource Manage System）的系统为例，介绍需求的开发和管理过程。的系统为例，介绍需求的开发和管理过程。51-65案例分析案例分析HRMSHRMS系统中的需求分类系统中的需求分类52-65案例分析案例分析 以用例分析方法进行需求分析，对于每个Use Case，创建用户接口说明文档和Use case报告，同时建立这个用例的原型。u 需求分析53-65案例分析案例分析 角色1: 员工（Employee） 角色2: 雇用经理（Hiring Manager） 角色3: 部门经理（Departmen

22、t Manager） 角色4: 上级（Superior） 角色5: 分区经理（Division Manager） 角色6: 运行官（Operation Head） 角色7: 申请人（Applicant） 角色8: 人力资源经理（HR Manager） 角色9: 培训经理（Training Administrator） 角色10: 培训中心经理（Training Center）u 需求分析HRMS中的角色54-65案例分析案例分析 用例1：招聘员工（Recruit Employee） 用例2：候选人分类（Categorize Candidate） 用例3：更新面试信息（Update Interv

23、iew） 用例4：确认候选人（Confirm Candidate） 用例5：管理申请（Manage Requisition） 用例6：记录申请者信息（Register Applicant Data） 用例7：修改申请者信息（Modify Applicant Data） 用例8：确认申请信息（Validate Application）u 需求分析分析用例55-65案例分析案例分析n 为系统中的每个用例编写Use Case报告，则系统分析与设计人员可以更加清晰的掌握系统架构。u 需求分析编写Use Case报告n 格式如下：创建员工记录简短描述场景事件流特殊需求执行前条件执行后结果Use case

24、图56-65案例分析案例分析u 需求管理n 需求变更管理建立需求基准版本和需求控制版本文档。所有的需求文档都要进行版本控制，文档要包含文档类型、名称、创建者、创建时间、修改者、修改时间、版本号、评审人员等信息。在开发HRMS中，提交的需求文档包括用户界面说明文档、Use Case报告、Glossary文档、软件开发计划、Use Case模型调研以及补充说明。所有的文档采用统一的编号规则和命名规则。n 文档编号规则系统名缩写“_”文档类型缩写_模块名缩写“_”编号版本号（后文没有+版本号）。n 文档命名规则文档类型“_”文档名“_”版本号。 57-65需求工程总结58-65需求工程总结需求工程总

25、结1 1u 需求开发和需求管理的分界线59-65需求工程总结需求工程总结2 2u 国内项目面临的最主要问题n 客户普遍不成熟：项目范围定义不确切，缺乏对项目范围、进度、成本、质量的平衡需求频繁变更主要人员的变动是项目最大风险n 项目团队不成熟：项目经理多为技术出身，普遍缺乏管理意识和管理方法培训不能正确识别项目相关干系人并管理其参与项目组成员工作勤奋但普遍缺乏正确方法人员变动是项目经理最头疼的问题60-65需求工程总结需求工程总结3 3u 我们需要客户方如何做n 调查前需要客户方落实调研计划，确定参加调研人员，时间，地点，并通知其调研内容（同时要考虑人员变动的备选方案）n 需要甲方确立内部项目组需求负责人n 准备调研所用资源会议室白板投影仪n 及时组织内部人员与乙方确认调研成果61-65需求工程总结需求工程总结4 4u 需要客户方如何配合n 作为客户方，如何做？了解乙方需求变更流程，并与乙方就此流程达成一致；指定专人负责需求变更；内部形成一个需求变更流程；针对内部提交的需求变更，在提交乙方之前横向分析对业务的影响；在提交乙方之前，内部达成一致意见；需求变更必将导致乙方开发成本的增加，为保证项目