搜索
信息系统项目管理师需求管理闫波需求管理用户需求是软件项目成败的关键需求问题：需求的隐含错误需求不明确、含糊用户刁难、用户不断增加需求需求变更本章要点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）OOAOODOOP(objectorientedprogramming)OOT…….用例（UserCase）表示一个动作序列的定义，包括执行的变量和外界交互的过程。提款机取款用例OOA是OO软件工程的第一项技术活动将现实世界的“视图”转化为用对象来描述的模型描述对象之间的各种关系，以满足软件系统的要求。用例需求分析用例需求分析方法采用一种面向对象的情景分析方法用例是系统向用户提供一个有价值的结果的某项功能所有的用例结合起来就构成了用例模型从用户角度出发考虑的功能需求用例需求分析从前：问用户希望系统为他做什么？现在：问用户利用系统做什么？UMLUnifiedModelingLanguage统一建模语言，是一种通用的模拟语言。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制定需求跟踪