信息系统项目管理师_第十七章_需求管理闫波

信息系统项目管理师需求管理闫波需求管理用户需求是软件项目成败的关键需求问题：需求的隐含错误需求不明确、含糊用户刁难、用户不断增加需求需求变更本章要点17.1需求管理概述17.2制定需求管理计划17.3需求管理规格说明的版本控制17.4需求变更管理17.5需求跟踪需求管理需求：指的是由项目接受的或项目产生的产品和产品构件需求。包括由组织征集的对项目的需求。RequirementManagement需求管理确保各方对需求的一致理解，管理和控制需求的变更，从需求到最终产品的双向跟踪。软件需求定义需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。软件需求特征：模糊性不确定性变化性主观性软件需求的层次业务需求用户需求功能需求软件需求规格非功能性需求质量特性约束和假设系统需求软件需求的类型功能需求性能需求环境需求用户界面需求资源使用需求成本消耗需求开发进度需求预先估计以后系统可能达到的目标软件需求的重要性需求管理与项目管理的关系项目需求是制定项目计划，开发项目产品和从事项目活动的依据。项目的计划、项目的开发活动及开发的产品应与项目需求保持一致，随需求的变化而调整。需求工程（RE）需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征一门学科。需求开发需求管理软件需求工程管理的过程需求分析需求定义需求验证需求获取需求管理需求开发需求管理需求获取扩展需求需求获取用户要求基线需求软件需求通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。获取需求的活动了解用户类型及潜在类型访谈和调研（要有记录）对用户需求进一步整理和提取将用户需求反馈用户注意事项识别真正的客户.正确理解客户的需求具备较强的忍耐力和清晰的思维说服和教育客户需求分析定义：需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。需求分析也称为需求建模需求分析模型需求分析的时间设计方案的时候项目开始的时候接管一个项目的时候需求变更的时候需求分析基本策略头脑风暴专家评审焦点会议组目的：进行具体的流程细化、数据项确认，必要时可以提供原型系统和明确的业务流程报告、数据项表，并能清晰的向用户描述系统的业务流设计目标。需求分析的难点问题的复杂性（不了解业务）交流的障碍不完备性和不一致性需求的易变性需求定义需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书（SRS）需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。软件需求规格说明的原则从现实中分离功能，即描述要“做什么”而不是“怎样实现”要求使用面向处理的规格说明语言（或称系统定义语言）如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中规格说明必须包括系统运行环境规格说明必须是一个认识模型规格说明必须是可操作的规格说明必须容许不完备性并允许扩充需求规格说明书文档参考1.引言2.系统定义3.应用环境4.功能规格5.性能需求6.产品提交7.实现约束8.质量描述9.其它10.签字认证需求验证开发方和用户方共同对需求文档进行评审，经双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。需求验证需求是正确的吗？需求是一致的吗？需求是完全的吗？需求是实际可行的吗？需求是客户需要的吗？需求是可检验的吗？需求是可跟踪的吗？最后的签字需求验证快速原型法需求管理需求管理中要收集需求的变更和变更的理由，维持对原有需求和所有产品及产品构件需求的双向跟踪。需求变更项目失败主要的原因在于需求变更!需求建模的方法创建体系结构的表示形式以捕获需求、就解决方案方法进行交流、以及分析所提出的系统设计。其目的是使用模型来表现系统中的关键方面。原型分析法定义：按照用户的需要，快速形成一个操作流程界面可能只是一个框架，具体的功能没有实现，只是结果静态的操作流程，以便与用户快速就需求达成一致主要考虑系统的功能需求，很少考虑非功能需求原型方法需求分析原型开发原型评价原型方法的类型进化型开发出来用于了解问题，并形成被交付软件的部分或全部的基础抛弃型开发出来获以便更多地了解问题或探究可能的方案的灵活性或者合理性，是尝试性软件，不用于被交付软件的实际部分结构化分析法定义（SA,StructuredAnalysis）20世纪70年发展起来的面向数据流的方法是一种自顶向下逐步求精的分析方法根据软件内部数据传递、变换的关系进行分析的结构化分析方法－技术数据流图(DFD)数据字典(DD)系统流程图数据流图是一种描述软件系统逻辑模型的图形符号表示数据的起始点和终点表示对数据的加工处理表示数据流,箭头表示数据的流动方向表示对数据的存储银行取款过程数据流图数据流图的层次结构为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统分层数据流图分层数据流图顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据底层流图是指其加工不需再做分解的数据流图，它处在最底层中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。数据字典描述系统中涉及的每个数据,是数据描述的集合,通常配合数据流图使用,用来描述数据流图中出现的各种数据和加工.组成：数据项:数据元素数据流:由数据项组成的数据流数据文件:表示对数据文件的存储数据字典关系符号符号含义=等于,定义为+加[]选择符,表示对[]列举的值可以任取其一{}重复符,表示对{}中的内容可视需要重复使用()可选符,表示对()中的内容可由设计员决定取舍*……*注释符,表示两个*之间的内容为对条目的注释数据流图需求分析实例建立学生管理系统学管科体检科学籍科学生处顶层数据流图学管科体检科学籍科学生管理信息系统学生处领导学生基本信息学生健康信息学生成绩学生健康情况表学生成绩单查询要求不及格人数人数统计表第0层数据流图第1层数据流图系统流程图系统包含的部分以及各个部分之间的关系是描述物理系统的工具用图形符号表示系统中的元素表达了系统中各个元素之间的信息流动情况系统流程图符号制定出访计划开始出访组团登记出访计划表?出访团组基本情况登记表是否需要办理护照护照管理护照登记表?护照卡?申请护照签证管理结束是否临时出访计划表?申请出国护照事项表申请出国签证事项表?高检院外事局出访业务流程图计划是否落实是否是否本单位人员是否结束用例分析法面向对象的软件工程（OOSE）OOAOODOOP(objectorientedprogramming)OOT…….用例（UserCase）表示一个动作序列的定义，包括执行的变量和外界交互的过程。提款机取款用例OOA是OO软件工程的第一项技术活动将现实世界的“视图”转化为用对象来描述的模型描述对象之间的各种关系，以满足软件系统的要求。用例需求分析用例需求分析方法采用一种面向对象的情景分析方法用例是系统向用户提供一个有价值的结果的某项功能所有的用例结合起来就构成了用例模型从用户角度出发考虑的功能需求用例需求分析从前：问用户希望系统为他做什么？现在：问用户利用系统做什么？UMLUnifiedModelingLanguage统一建模语言，是一种通用的模拟语言。Booch,Rumbaugh和Jocobson基础上发展起来的。1997年11月国际对象管理组织OMG批准将UML作为基于面向对象技术的标准建模语言。UML制定了一整套完整的面向对象的标记和处理方法。UML需求视图用例视图（UsecaseDiagram）顺序图（SequenceDiagram）状态图（StateDiagram）活动图（ActivityDiagram）USECASE视图用例视图主要是展示了外部行为者所观察到的系统将提交的功能.即:各类外部行为者与系统所提供的用例的连接－－－－用例（Usecase）：系统所提供的功能描述角色（Actor）：可能使用用例的人或者外部系统UML图符USERCASE实例序列（Sequence）图顺序图展示了几个对象之间的动态协作关系，主要用来显示对象之间发送消息的顺序，还显示对象之间的交互，即系统执行某一特定时间点所发生的事。Sequence实例状态视图状态图是对类描述的补充，它说明该类的对象所有可能的状态以及那些事件将导致状态的改变。它是一个类对象所可能经历的所有历程的模型图。活动（Activity）视图活动图用来描述执行工作流程中涉及的活动，展示了连续的活动流活动图例UseCase需求分析方法综述识别出系统的Actor描述主要的Usecase实现用例视图实现顺序视图，活动视图,状态视图等功能列表法对项目的功能需求进行详细说明，既可以单独使用，也可以作为用例分析方法的附加说明来详细说明用例的具体功能。为什么会有需求变更？与用户交互不够，对问题理解有差异模糊的需求用户需求增加开发方需求人员重视程度不够开发人员理解偏差有效控制变更合理的方法需求阶段尽可能采用原型或用例法明确用户需求。采用严格的需求管理变更流程。采用良好的体系结构采用面向对象思想变更申请需求方开发方忽略选择变更方式SCCB评估项目经理自行决定根据评估结果拒绝接受本次修改下个版本再修改修改合同相关信息修改相关需求修改相应的项目计划需求变更处理软件基线产品修改提交单申请人韩万江申请日期2002。10．11项目名称项目管理系统阶段名称系统设计文件名称RCR-PM-01.doc,RCR-PM-02.doc,变更简述如下修改内容1）修改测试流程控制：将2个角色，3个渠道流，改为3个角色，4个渠道流，详见RCR-PM-01.doc2）增加开发人员技能信息库管理，详见RCR-PM-02.doc验证意见同意RCR-PM-01.doc变更。RCR-PM-02.doc的变更可以推迟到下一个版本实施验证人杨炎泰验证日期2002．10．11SCCB韩万江，姜岳尊，孙泉填表人韩万江CMMI中的需求管理流程1制定需求管理计划2求得对需求的理解3求得对需求的承诺4管理需求变更5维护对需求的双向跟踪性6识别项目工作与需求之间的不一致CMMI中的需求管理流程1制定需求管理计划确定需求管理的软硬件资源、需求跟踪矩阵、需求变更请求表。CMMI中的需求管理流程2求得对需求的理解需求确认。避免需求蔓延和遗漏CMMI中的需求管理流程3求得对需求的承诺为实现需求活动所需的活动人员之间达成一致和建立承诺。CMMI中的需求管理流程4管理需求变更5维护对需求的双向跟踪性6识别项目工作与需求之间的不一致需求的属性创建需求的时间需求的版本号需求创建的作者负责认可需求的人员需求状态已建议；已批准；已实现；需求涉及到的子系统需求的稳定性……本章要点17.1需求管理概述17.2制定需求管理计划17.3需求管理规格说明的版本控制17.4需求变更管理17.5需求跟踪1建立并维护需求管理的组织方针对需求进行管理，确定项目计划与工作产品之间需求不一致之处。2确定需求管理需使用的资源人力、财力、物力3分配责任确定需求管理负责人及其责任确认需求管理员的权限责任4培训计划对需求人员的培训应用领域、需求分析、分析、审查和管理、需求管理工具、配置管理5确定需求管理的项目干系人解决对需求的共识问题，评估需求变更的影响，通报双向跟踪情况，识别项目工作与需求不一致的情况。6制定判断项目工作与需求不一致的准则和纠正规程依据此判断项目工作与需求不一致；不一致时启动纠正规程。7制定需求跟踪