软件项目管理―需求管理课件

《软件项目管理―需求管理课件》由会员分享，可在线阅读，更多相关《软件项目管理―需求管理课件（97页珍藏版）》请在金锄头文库上搜索。

1、软件项目管理,王颖,2,软件项目管理,什么 是 项目 ？,如何 获得 项目 ？,如何 管理 项目 ？,怎样 提交 项目 ？,结项后 应做 什么 ？,需求前延,质量检验过程,项目需求的实际验证,课程体系,3,如何管理项目？ (how to manage a project?),4,需求管理基础知识,5,软件项目管理的关键技术,需求管理,项目估算,进度管理,成本管理,配置管理,风险管理,质量管理,资源管理,6,需求管理的内容,什么是需求工程 什么是需求开发 什么是需求管理 需求管理所要完成的任务 需求管理的问题 如何进行需求管理,7,一、什么是需求工程,在项目或产品开发过程中，一般地来讲，把与需求

2、直接相关的活动统称为需求工程。 需求工程的目的是通过与用户广泛地交流确定应用系统的目标。 需求活动以“工程化”的方法被提出、分析和组织，它鼓励用户以一种积极的方式参与需求分析活动中，并在整个软件生命周期强调用户参与和领域专家的指导作用，促使目标系统最大地满足用户需求。,8,软件需求的定义,Rational 把需求定义为“（正在构建的）系统必须符合的条件或具备的功能”。 软件需求： 用户解决某一问题或达到某一目标所需的软件功能。系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。 简单的说，软件需求就是确定系统需要做什么；严格意义上，软件需求是系统或软件必须达到

3、的目标与能力。,9,软件需求与其它软件过程的关系,项目计划过程：需求是制定项目计划的基础，开发资源和进度安排的估计都要建立在对最终产品的真正理解之上。 跟踪控制过程：监控每项需求的状态，以便项目管理者能发现设计和验证是否达到了预期的要求。 变更控制过程：在需求编写成文档以后，所有接下来的变更都应通过确定的变更控制过程来进行，以确保变更的影响是可以接受的、受到变更影响的所有人都接到通知并明白这一点、由合适的人选来做出接受变更的正式决定、资源按需进行调整、保持需求文档是最新版本并是准确的更新文档。,10,软件需求与其它软件过程的关系,系统测试过程：软件需求是系统测试的重要参考。系统测试是一种方法，

4、可以验证计划中所列的功能是否按预期要求实现了。同时，也验证了用户任务是否能正确地执行。 文档编制过程：产品的需求是编写文档的重要参考，低质量和拖延的需求会给编写用户文档带来极大的困难。 系统构建过程：软件项目最终交付的主要是可执行软件，而不是需求说明文档。但需求文档是所有设计、实现工作的基础，需要根据需求文档来确定模块设计，而模块又要作为编写代码的依据。系统构建过程需要跟踪每项需求与相应的设计和软件代码。,11,软件需求的抽象层次,软件设计描述,系统需求,用户需求,原始问题描述,原始问题描述,解决方案空间,12,软件需求的抽象层次,原始问题描述：是对要解决的问题的叙述，它是软件需求的基础。 用

5、户需求：是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束。 系统需求：用详细术语给出系统要提供的服务及受到的约束，系统需求文档应该是精确的，可以为系统的实现提供依据，因而系统需求文档也称为功能描述，可能成为用户和软件开发组织之间合同的重要内容。 软件设计描述：是在系统需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述。,13,软件需求的抽象层次,用户需求：从用户的角度描述系统的需求，原则： 标准的格式 使用一致的语言 使用特殊文本 尽量避免专业术语,14,软件需求的抽象层次,系统需求的分类： 功能需求:描述系统所应提供的功能和服务,包括

6、系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。 非功能需求:是指那些不直接与系统的具体功能相关的一类需求，是功能需求的补充。 领域需求:其来源不是系统的用户，而是系统应用的领域，反应了该领域的特点。领域需求可能是功能需求，也可能是非功能需求，其确定需要领域知识。,15,软件需求质量评价,我们需要在软件需求规格说明书建立之后，就对软件需求的质量进行评价，一个好的需求集应该包括用户解决问题需要的功能和服务，而且尽量避免涉及软件设计与软件是实现的细节。,16,软件需求质量评价,软件需求质量度量的9个元素： 正确性 无歧义 完备性 一致性 根据重要性和稳定性分级 可验证性 可修改性 可

7、跟踪性 可理解性,17,软件需求质量评价,正确性 需求集是正确的当且仅当其中每条需求都代表了构建软件系统所要完成的事情。,18,需求工程发展历程,20世纪80年代中期，软件工程的子领域需求工程（RE）逐步形成。它是一个包括创建和维护需求文档所必须的所有活动的过程，是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。 对应用问题及其环境进行理解与分析 为问题所涉及的信息和功能建立模型 将用户需求精确化和标准化 编写需求规格说明书 进入20世纪90年代后，需求工程成为研究热点。,19,需求工程发展历程,需求工程的发展趋势是对象化、形式化和自动化，并将向纵深发展和综合发展。,20,需求工程需

8、求开发 + 需求管理,需求工程研究内容,21,需求开发与需求管理之间的界限,22,二、什么是需求开发,23,需求获取,需求获取是需求开发的第一个步骤，是一切工作的开始。从确定需求开发过程，确定如何组织需求的收集、分析、细化并核实的步骤，到将它编写成文档，主要的活动和展现成果有11项。,24,需求获取,确定需求开发过程 编写项目视图和范围文档 用户群分类 选择产品代表 建立核心队伍 确定使用实例 召开应用程序开发联系会议 分析用户工作流程 确定质量属性 检查问题报告 需求重用,25,需求获取 编写项目视图和范围文档,项目视图说明使所有项目参与者对项目的目标能达成共识；范围则是作为评估需求或者潜在

9、特性的参考。,26,需求获取 用户群分类,什么是客户与用户 客户：直接或间接从产品中获得利益的个人或组织。 用户：软件系统的最终用户，是特殊的客户，他们是产品的直接使用者、操作者，是属于客户组织中操作层面上的成员。 用户群分类 不同的用户在很多方面存在着差异，可以根据差异将用户分成用户类，用户类不一定都是指人，其他应用程序或系统接口所用的硬件组件也可以看成是附加用户类的成员。,27,需求分析,需求分析包括提炼、分析和仔细审查已收集到的需求，以确保所有的项目参与者都明白其含义并找出其中的错误、遗漏或其他不足的地方。 绘制关联图 创建用户接口原型 分析可行性 确定需求优先级 建立需求模型 编写数据

10、字典 应用质量功能调配,28,需求分析 数据流图,数据流程图中有以下几种主要元素： ：数据流。数据流是数据在系统内传播的路径，因此由一组成分固定的数据组成。如订票单由旅客姓名、年龄、单位、身份证号、日期、目的地等数据项组成。由于数据流是流动中的数据，所以必须有流向，除了与数据存储之间的数据流不用命名外，数据流应该用名词或名词短语命名。 ：数据源（终点）。代表系统之外的实体，可以是人、物或其他软件系统。 ：对数据的加工（处理）。加工是对数据进行处理的单元，它接收一定的数据输入，对其进行处理，并产生输出。 ：数据存储。表示信息的静态存储，可以代表文件、文件的一部分、数据库的元素等,29,需求分析

11、数据字典,数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。,30,编写需求文档,软件需求文档包括用户需求和详细的系统需求描述，是对软件系统要求的正式陈述。编写需求文档应注意以下几点： 语句和段落尽量简短 表达时采用主动语态 语句要完整，语法、标点等要正确 使用的术语要与词汇表中定义保持一致 陈述时要采用一致的格式 避免模糊的、主观的术语，如性能“优越” 避免使用比较性的词汇,需求之用例图,31,编写需求文档（续）,32,编写需求文档（续）,IEEE标准830-1998,33,编写需求文档（续）,需求文档实例： 进销存系统需求规格说明书 oa办公自动化系统需求规格

12、说明书,34,需求验证,需求验证分析需求规格说明的正确性和可行性，检验需求能否反映客户的意愿。 重要性 如果在构造设计开始之前通过验证基于需求的测试计划和原型测试来验证需求的正确性及其质量，就能大大减少项目后期的返工现象。而如果在后续的开发或当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工，因为需求的变化总是带来系统设计和实现的改变，从而使系统必须重新测试，由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大得多。,35,需求验证,目的： 需求规约正确描述了预期的系统行为和特征； 软件需求符合业务需求或其他来源的要求； 需求是完整和高质量的； 所有对需求的看法、观点是一致

13、的； 需求为产品设计、构造和测试提供了坚实的基础 手段： 软件测试 软件评审,36,需求验证步骤,37,需求验证的内容,38,三、什么是需求管理,需求管理是一种获取、组织并记录软件需求的系统化方案，同时也是一个使客户与项目团队对不断变更的软件需求达成并保持一致的过程。 需求管理在需求开发的基础上进行，贯穿于整个软件项目过程，是软件项目管理的一部分。,39,需求管理与其他项目过程的联系,需求管理,制定项目计划,系统测试过程,项目跟踪和 控制过程,变更控制过程,制造过程,用户编制 文档过程,基础,基础,产品可 追溯到,作为 参考,验证实现 的正确性,作为 基线,进行 变更,跟踪 状态,作为 输入,

14、基线确定前缩小范围,请求范围 缩减,40,为什么要管理需求？避免失败就是一个很充分的理由。提高项目的成功率和需求管理所带来的其他好处同样也是理由。,四、为什么要进行需求管理,41,需求管理的困难性,开发软件系统最为困难的部分就是准确说明开发什么。 最为困难的概念性工作就是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。,42,需求获取的偏差,客户如此描述需求,项目经理如此理解,分析员如此设计,程序员如此编码,商业顾问如此诠释,项目文档如此编写,安装程序如此简洁,客户投资如此巨大,技术支

15、持如此肤浅,实际需求原来如此,43,需求管理的困难性,需求不总是显而易见的，而且它可来自各个方面。 需求并不总是能容易用文字明白无误地表达。 存在不同种类的需求，其详细程度各不相同。 如果不加以控制，需求的数量将难以管理。 需求之间相互关联，而且需求也和软件工程流程中的其他可交付工件有关。 需求有唯一的特征或特征值。例如，它们的重要性和容易满足的程度都各不相同。 需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理。 需求会变更。,44,需求管理的目标,需求管理的目的是在客户和软件项目之间就需要满足的需求建立和维护一致的约定： 使软件需求受控，并建立供软件工程和管理使用的需求基线。必须

16、控制需求基线的变动，按照变更控制的标准和规范的过程进行需求变更控制和版本控制。 使软件计划、产品和活动与软件需求保持一致。必须对需求进行跟踪，管理需求和其它联系链之间的联系和依赖，必须就变更和软件项目各小组达成共识，对软件项目计划做出调整，其中包括人员的安排、任务的安排、用户的沟通、成本的调整、进度的调整等。,45,需求管理的原则,需求一定要分类管理 需求必须分优先级 需求必须文档化 需求一旦变化，就必须对需求变更的影响进行评估 需求管理必须与需求工程的其它活动紧密整合,46,需求管理策略,需求一定要与投入有必然的联系 需求的变更要经过出资者的认可 小的需求变更也要经过正规的需求管理流程 精确的需求与范围定义并不会阻止需求的变更,47,五、如何进行需求管理,需求管理的关键技巧 需求管理的工具,48,制定需求管理规划,编写用于需求管理活动的计划。 需求识别 变更管理过程 需求跟踪 自动化工具,49,需求管理活动,50,构建功能交叉的需求团队,与诸如测试或应用程序建模等流程不同（这些流程可在单个业务组中