软件项目管理—需求管理综述

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

1、软件项目管理 王颖 2 软件项目管理 什么什么 是是 项目项目 ？ 如何如何 获得获得 项目项目 ？ 如何如何 管理管理 项目项目 ？ 怎样怎样 提交提交 项目项目 ？ 结项后结项后 应做应做 什么什么 ？ 需求前延质量检验过程 项目需求的实际验证 课程体系 3 如何管理项目？如何管理项目？ (how to manage a project?)(how to manage a project?) 4 需求管理基础知识 5 软件项目管理的关键技术 需求管理 项目估算 进度管理 成本管理 配置管理 风险管理 质量管理 资源管理 管 理 配 置 管 理 风 险 管 理 质 量 管 理 资 源 管 理

2、需 求 估 算项 目 管 理进 度 管 理成 本 6 需求管理的内容 l什么是需求工程 l什么是需求开发 l什么是需求管理 l需求管理所要完成的任务 l需求管理的问题 l如何进行需求管理 7 一、什么是需求工程 l在项目或产品开发过程中，一般地来讲，把与需求直 接相关的活动统称为需求工程。 l需求工程的目的是通过与用户广泛地交流确定应用系 统的目标。 l需求活动以“工程化”的方法被提出、分析和组织，它 鼓励用户以一种积极的方式参与需求分析活动中，并 在整个软件生命周期强调用户参与和领域专家的指导 作用，促使目标系统最大地满足用户需求。 8 软件需求的定义 lRational 把需求定义为“（正

3、在构建的）系统必须符合的 条件或具备的功能”。 l软件需求： 用户解决某一问题或达到某一目标所需的软 件功能。系统或系统构件为了满足合同、规约、标准或其 他正式实行的文档而必须满足或具备的软件功能。 l简单的说，软件需求就是确定系统需要做什么；严格意义 上，软件需求是系统或软件必须达到的目标与能力。 9 软件需求与其它软件过程的关系 l项目计划过程：需求是制定项目计划的基础，开发资 源和进度安排的估计都要建立在对最终产品的真正理 解之上。 l跟踪控制过程：监控每项需求的状态，以便项目管理 者能发现设计和验证是否达到了预期的要求。 l变更控制过程：在需求编写成文档以后，所有接下来 的变更都应通过

4、确定的变更控制过程来进行，以确保 变更的影响是可以接受的、受到变更影响的所有人都 接到通知并明白这一点、由合适的人选来做出接受变 更的正式决定、资源按需进行调整、保持需求文档是 最新版本并是准确的更新文档。 10 软件需求与其它软件过程的关系 l系统测试过程：软件需求是系统测试的重要参考。系 统测试是一种方法，可以验证计划中所列的功能是否 按预期要求实现了。同时，也验证了用户任务是否能 正确地执行。 l文档编制过程：产品的需求是编写文档的重要参考， 低质量和拖延的需求会给编写用户文档带来极大的困 难。 l系统构建过程：软件项目最终交付的主要是可执行软 件，而不是需求说明文档。但需求文档是所有设

5、计、 实现工作的基础，需要根据需求文档来确定模块设计 ，而模块又要作为编写代码的依据。系统构建过程需 要跟踪每项需求与相应的设计和软件代码。 11 软件需求的抽象层次 软件设计描述 系统需求 用户需求 原始问题描述 原始问题描述原始问题描述 解决方案空间解决方案空间 12 软件需求的抽象层次 l原始问题描述：是对要解决的问题的叙述，它是软件 需求的基础。 l用户需求：是用自然语言和图表给出的关于系统需要 提供的服务及系统的操作约束。 l系统需求：用详细术语给出系统要提供的服务及受到 的约束，系统需求文档应该是精确的，可以为系统的 实现提供依据，因而系统需求文档也称为功能描述， 可能成为用户和软

6、件开发组织之间合同的重要内容。 l软件设计描述：是在系统需求的基础上加入更详细的 内容构成的，它作为软件详细设计和实现的基础，是 对软件设计活动的概要描述。 软件需求的抽象层次 用户需求：从用户的角度描述系统的需求，原则： l标准的格式 l使用一致的语言 l使用特殊文本 l尽量避免专业术语 13 14 软件需求的抽象层次 系统需求的分类： l功能需求:描述系统所应提供的功能和服务,包括系统 应该提供的服务、对输入如何响应及特定条件下系统 行为的描述。 l非功能需求:是指那些不直接与系统的具体功能相关的 一类需求，是功能需求的补充。 l领域需求:其来源不是系统的用户，而是系统应用的领 域，反应了

7、该领域的特点。领域需求可能是功能需求 ，也可能是非功能需求，其确定需要领域知识。 软件需求质量评价 我们需要在软件需求规格说明书建立之后 ，就对软件需求的质量进行评价，一个好的需 求集应该包括用户解决问题需要的功能和服务 ，而且尽量避免涉及软件设计与软件是实现的 细节。 15 软件需求质量评价 16 软件需求质量度量的9个元素： l正确性 l无歧义 l完备性 l一致性 l根据重要性和稳定性分级 l可验证性 l可修改性 l可跟踪性 l可理解性 软件需求质量评价 正确性 需求集是正确的当且仅当其中每条需求都代表了构 建软件系统所要完成的事情。 17 需求工程发展历程 20世纪80年代中期，软件工程

8、的子领域需求工 程（RE）逐步形成。它是一个包括创建和维护需求文档 所必须的所有活动的过程，是将用户非形式化的软件需 求转变为形式化的需求规格说明的过程。 对应用问题及其环境进行理解与分析 为问题所涉及的信息和功能建立模型 将用户需求精确化和标准化 编写需求规格说明书 进入20世纪90年代后，需求工程成为研究热点。 18 需求工程发展历程 需求工程的发展趋势是对象化、形式化和自 动化，并将向纵深发展和综合发展。 19 20 l需求工程需求开发 + 需求管理 需求工程 获取需求 分析需求 定义需求 验证需求 需求变更控制 需求跟踪 需求状态跟踪 需求文档版本控制 需求开发 需求管理 需求工程研究

9、内容 21 需求开发与需求管理之间的界限 用户/系统市场管理者 初始需求变更的需求 获取,分析 ,定义,验 证需求 控制需求 变更 需求规格说明 项目环 境 需求开发需求管理 22 二、什么是需求开发 需求获取 需求获取是需求开发的第一个步骤，是一切 工作的开始。从确定需求开发过程，确定如何 组织需求的收集、分析、细化并核实的步骤， 到将它编写成文档，主要的活动和展现成果有 11项。 23 需求获取 l确定需求开发过程 l编写项目视图和范围文档 l用户群分类 l选择产品代表 l建立核心队伍 l确定使用实例 l召开应用程序开发联系会议 l分析用户工作流程 l确定质量属性 l检查问题报告 l需求重

10、用 24 需求获取 编写项目视图和范围文档 项目视图说明使所有项目参与者对项目的目标能 达成共识；范围则是作为评估需求或者潜在特性的参 考。 25 需求获取 用户群分类 l什么是客户与用户 客户：直接或间接从产品中获得利益的个人或组织。 用户：软件系统的最终用户，是特殊的客户，他们是 产品的直接使用者、操作者，是属于客户组织中操作 层面上的成员。 l用户群分类 不同的用户在很多方面存在着差异，可以根据差异将 用户分成用户类，用户类不一定都是指人，其他应用 程序或系统接口所用的硬件组件也可以看成是附加用 户类的成员。 26 需求分析 需求分析包括提炼、分析和仔细审查已收集到的需 求，以确保所有的

11、项目参与者都明白其含义并找出其 中的错误、遗漏或其他不足的地方。 l绘制关联图 l创建用户接口原型 l分析可行性 l确定需求优先级 l建立需求模型 l编写数据字典 l应用质量功能调配 27 需求分析 数据流图 数据流程图中有以下几种主要元素： l ：数据流。数据流是数据在系统内传播的路径，因此由一组 成分固定的数据组成。如订票单由旅客姓名、年龄、单位、身份 证号、日期、目的地等数据项组成。由于数据流是流动中的数据 ，所以必须有流向，除了与数据存储之间的数据流不用命名外， 数据流应该用名词或名词短语命名。 l ：数据源（终点）。代表系统之外的实体，可以是人、物 或其他软件系统。 l ：对数据的加

12、工（处理）。加工是对数据进行处理的单元 ，它接收一定的数据输入，对其进行处理，并产生输出。 l ：数据存储。表示信息的静态存储，可以代表文件、文件 的一部分、数据库的元素等 28 需求分析 数据字典 数据字典是对系统用到的所有数据项和结构的定义 ，以确保开发人员使用统一的数据定义。 29 编写需求文档 软件需求文档包括用户需求和详细的系统需求描述 ，是对软件系统要求的正式陈述。编写需求文档应注 意以下几点： l语句和段落尽量简短 l表达时采用主动语态 l语句要完整，语法、标点等要正确 l使用的术语要与词汇表中定义保持一致 l陈述时要采用一致的格式 l避免模糊的、主观的术语，如性能“优越” l避

13、免使用比较性的词汇 30 需求之用例图 编写需求文档（续） 31 32 编写需求文档（续） IEEE标 准830- 1998 编写需求文档（续） l需求文档实例： 进销存系统需求规格说明书 oa办公自动化系统需求规格说明书 33 34 需求验证 l需求验证分析需求规格说明的正确性和可行性，检验 需求能否反映客户的意愿。 l重要性 如果在构造设计开始之前通过验证基于需求的测试 计划和原型测试来验证需求的正确性及其质量，就 能大大减少项目后期的返工现象。而如果在后续的 开发或当系统投入使用时才发现需求文档中的错误 ，就会导致更大代价的返工，因为需求的变化总是 带来系统设计和实现的改变，从而使系统必

14、须重新 测试，由需求问题而对系统做变更的成本比修改设 计或代码错误的成本要大得多。 35 需求验证 l目的： 需求规约正确描述了预期的系统行为和特征； 软件需求符合业务需求或其他来源的要求； 需求是完整和高质量的； 所有对需求的看法、观点是一致的； 需求为产品设计、构造和测试提供了坚实的基础 l手段： 软件测试 软件评审 36 需求验证步骤 确定合格的标准 编写用户手册 依据需求编写测试用例 审查需求文档 37 需求验证的内容 可读性可读性 一致性一致性 完备性完备性 现实性现实性 可检验性可检验性 可跟踪性可跟踪性 可调节性可调节性 有效性有效性 38 三、什么是需求管理 l需求管理是一种获

15、取、组织并记录软件需求的系统化 方案，同时也是一个使客户与项目团队对不断变更的 软件需求达成并保持一致的过程。 l需求管理在需求开发的基础上进行，贯穿于整个软件 项目过程，是软件项目管理的一部分。 39 需求管理与其他项目过程的联系 需求管理 制定项目计划 系统测试过程 项目跟踪和 控制过程 变更控制过程 制造过程 用户编制 文档过程 基础 基础 产品可 追溯到 作为 参考 验证实现 的正确性 作为 基线 进行 变更 跟踪 状态 作为 输入 基线确定前 缩小范围 请求范围 缩减 40 l为什么要管理需求？避免失败就是一个很充 分的理由。提高项目的成功率和需求管理所 带来的其他好处同样也是理由。

16、 四、为为什么要进进行需求管理 41 需求管理的困难性 l开发软件系统最为困难的部分就是准确说明开发 什么。 l最为困难的概念性工作就是编写出详细技术需求 ，这包括所有面向用户、面向机器和其它软件系 统的接口。同时这也是一旦做错，将最终会给系 统带来极大损害的部分，并且以后再对它进行修 改也极为困难。 42 需求获取的偏差 客户如此描述需求项目经理如此理解分析员如此设计程序员如此编码商业顾问如此诠释 项目文档如此编写安装程序如此简洁客户投资如此巨大技术支持如此肤浅 实际需求原来如此 43 需求管理的困难性 l需求不总是显而易见的，而且它可来自各个方面。 l需求并不总是能容易用文字明白无误地表达。 l存在不同种类的需求，其详细程度各不相同。 l如果不加以控制，需求的数量将难以管理。 l需求之间相互关联，而且需求也和软件工程流程中的 其他可交付工件有关。 l需求有唯一的特征或特征值。例如，它们的重要性和 容易满足的程度都各不