《软件项目管理》课件：第4讲 需求管理

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

1、软件项目管理1软件项目管理什么什么 是是 项目项目 ？如何如何 获得获得 项目项目 ？如何如何 管理管理 项目项目 ？怎样怎样 提交提交 项目项目 ？结项后结项后 应做应做 什么什么 ？需求前延质量检验过程项目需求的实际验证课程体系2如何管理项目？如何管理项目？ (how to manage a project?)(how to manage a project?)3以项目为基础（核心） 以分析为手段（方法） 以过程为管理（控制） 以资源为质量（风险） 以需求为目标（里程碑）4以分析为手段（方法）以分析为手段（方法）5需求管理基础知识6软件项目管理的关键技术需求管理项目估算进度管理成本管理配置

2、管理风险管理质量管理资源管理管 理配 置管 理风 险管 理质 量管 理资 源管 理需 求估 算项 目管 理进 度管 理成 本7需求管理的内容l什么是需求工程l什么是需求开发l什么是需求管理l需求管理所要完成的任务l需求管理的问题l如何进行需求管理8三、什么是需求管理l需求管理是一种获取、组织并记录软件需求的系统 化方案，同时也是一个使客户与项目团队对不断变 更的软件需求达成并保持一致的过程。 l需求管理在需求开发的基础上进行，贯穿于整个软 件项目过程，是软件项目管理的一部分。 9需求管理与其他项目过程的联系需求管理制定项目计划系统测试过程项目跟踪和 控制过程变更控制过程制造过程用户编制 文档过

3、程基础基础产品可 追溯到作为 参考验证实现 的正确性作为 基线进行 变更跟踪 状态作为 输入基线确定前 缩小范围请求范围 缩减10需求管理的目标 l需求管理的目的是在客户和软件项目之间就需要满足 的需求建立和维护一致的约定：使软件需求受控，并建立供软件工程和管理使用的 需求基线。必须控制需求基线的变动，按照变更控 制的标准和规范的过程进行需求变更控制和版本控 制。使软件计划、产品和活动与软件需求保持一致。必 须对需求进行跟踪，管理需求和其它联系链之间的 联系和依赖，必须就变更和软件项目各小组达成共 识，对软件项目计划做出调整，其中包括人员的安 排、任务的安排、用户的沟通、成本的调整、进度 的调

4、整等。 11需求管理的原则l需求一定要分类管理l需求必须分优先级l需求必须文档化l需求一旦变化，就必须对需求变更的影响进行评估l需求管理必须与需求工程的其它活动紧密整合12需求管理活动需求管理活动活动的任务变更控制建议需求变更并分析其影响，做出是 否变更的决策版本控制确定单个需求和SRS的版本需求跟踪定义对于其它需求及系统元素的联系 链需求状态定义并跟踪需求的状态13四、为为什么要进进行需求管理lQuality: conformance to requirementsl定理1：“质量是免费的”l定理2：根据定理1，不管我们是否改进质量，我们 总有会改进质量的竞争对手l定理3：在相近的价格下，客

5、户会选择较高质量的产 品和服务l定理4：根据定理2和3，为了生存，我们不得不改进 质量推论：有了质量，不一定能保证我们的生存l定理5：需求管理是保证质量的首要手段l根据定理4和5，所以14为为什么要进进行需求管理l系统开发团队之所以管理需求，是因为他们想让 项目获得成功。满足项目需求即为成功打下了基 础。若无法管理需求，达到目标的几率就会降低 。l为什么要管理需求？避免失败就是一个很充分的 理由。提高项目的成功率和需求管理所带来的其 他好处同样也是理由。15需求管理的困难性l开发软件系统最为困难的部分就是准确说明开发什么 。最为困难的概念性工作就是编写出详细技术需求， 这包括所有面向用户、面向

6、机器和其它软件系统的接 口。同时这也是一旦做错，将最终会给系统带来极大 损害的部分，并且以后再对它进行修改也极为困难。lThe hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to

7、machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. 16需求管理的困难性l需求不总是显而易见的，而且它可来自各个方面。 l需求并不总是能容易用文字明白无误地表达。 l存在不同种类的需求，其详细程度各不相同。 l如果不加以控制，需求的数量将难以管理。 l需求之间相互关联，而且需求也和软件工程流程中 的其他可交付工件有关。

8、l需求有唯一的特征或特征值。例如，它们的重要性 和容易满足的程度都各不相同。 l需求涉及众多相关方面，这意味着需求要由功能交 叉的各组人员管理。 l需求会变更。 17需求管理的困难性客户如此描述需求项目经理如此理解分析员如此设计程序员如此编码商业顾问如此诠释项目文档如此编写安装程序如此简洁客户投资如此巨大技术支持如此肤浅 实际需求原来如此18需求管理的重要性许多错误是潜伏的，并且在错误产生后很长一段时 间才被检查出来在需求过程中会产生很多错误DeMarco在一份研究报告中指出，被检查出来的 错误的56产生的根源可以追溯到需求阶段。AIRMICS所进行的一项调查发现，在一份美国军 方大型管理信息

9、系统的需求现格说明书(SRS)中 存在着500多个错误，当然这仅仅是一个软件项 目中的一次调查。19需求管理的重要性在需求阶段，代表性的错误为疏忽、不一致和二 义性美国海军研究实验室从20世纪70年代起就对软 件开发技术不断地进行研究。他们对海军A7E 它机上的”宅行操作程序进行实地测试，以 验证许多新设想的可行性。得出的研究数据表 明：A7E项目中77的需求错误特点是不明确 ：疏忽、不一致和二义性。按错误类型对这些 错误分布进行分析的结果是：49不正确的事 实，31疏忽，l 3不一致，5二义性。20五、需求管理问题l2000年对开发人员、经理和质量保证人员所做的一 次调查结果显示：无法跟踪变

10、更 71%难以编写 70%特性偏移 67%组织欠佳 54%21常见的需求管理问题l需求不总是显而易见的，而且它可来自各个方面。l需求并不总是容易用文字明白无误地表达。l存在不同种类的需求，其详细程度各不相同。l如果不加以控制，需求的数量将难以管理。l需求相互之间以及与流程的其他可交付工件之间以 多种方式相关联。l需求有唯一的特征或特征值。例如，它们既非同等 重要，处理的难度也不同。l需求涉及众多相关利益责任方，这意味着需求要由 跨职能的各组人员来管理。l需求发生变更。l需求可能对时间敏感。 22六、如何进行需求管理l需求管理过程l需求管理的关键技巧l需求管理的工具23需求管理过程24RUP的需

11、求过程RUP(Rational Unified Process,统一软件开发过程)25制定需求管理计划l编写用于需求管理活动的计划。定义角色和职责设置需求类型选择需求属性及取值范围建立跟踪机制定义要提供的状态报告定义需求变更管理机制 26专业示例计算机软件 计算机网络通讯 自控 计算机构建功能交叉的需求团队开发人员 和设计人员分析员质量保证 和测试公司管理层开发经理 和项目经理需求团队王卫红 副教授 博士 刘 波 博士 王卫红 副教授 博士 李士宁 副教授 博士覃征 教授韩毅 副教授 博士后刘波 博士技术编写人员 和文档编写人员赵 磊 硕士 王 猛 硕士 张 森 硕士 李 达 硕士 刘超飞 硕

12、士案例项目团队组成27构建功能交叉的需求团队开发人员 和设计人员分析员质量保证 和测试公司管理层开发经理 和项目经理需求技术编写人员 和文档编写人员28构建功能交叉的需求团队l与诸如测试或应用程序建模等流程不同（这些流程 可在单个业务组中进行管理），需求管理涉及了每 一个能够为开发流程提供专门技术的个人；l其中应包括那些代表客户和业务预期的人；l开发经理、产品经理、分析员、系统工程师甚至客 户都应该参与进来；l需求团队还应包括创建系统解决方案的人 - 工程师 、构架设计师、设计员、程序员、技术文档编写员 以及其他提供技术支持的个人；l测试员和其他质量保证人员应当作重要的团队成员 。 29干系人

13、需求知识培训l目的：建立对需求管理过程的共识l作用：控制客户期望保证需求过程的质量保证需求的质量l时机：正式的需求调研之前30软件客户的权利要求分析人员使用符 合客户语言习惯的表达要求分析人员了解客户系统的业务及目标要求分析人员组织需求 获取期间所介绍的信息， 并编写软件需求规格说明要求开发人员对需求 过程中所产生的工作结 果进行解释说明要求开发人员在整个 交流过程中保持和维护 一种合作的职业态度 要求开发人员对产品 的实现及需求都要提 供建议，拿出主意描述产品使其具有 易用、好用的特性可以调整需求，允许重 用已有的软件组件当需要对需求进行变 更时，对成本、影响、 得失（ trade-off）

14、有 个真实可信的评估获得满足客户 功能和质量要求 的系统，并且这 些要求是开发人 员同意的31软件客户的义务给分析人员讲 解业务及说明业 务方面的术语等 专业问题抽出时间清 楚地说明需求 并不断完善当说明系统需求时 ，力求准确详细需要时要及时对 需求做出决策要尊重开发人员的 成本估算和对需求 的可行性分析对单项需求、系统 特性或使用实例划 分优先级评审需求文 档和原型一旦知道要对项目需 求进行变更，要马上 与开发人员联系在要求需求变更时， 应遵照开发组织确定 的工作过程来处理尊重需求工程中 开发人员采用的 流程（过程）32需求员和程序员的差异l程序员喜欢对完整资料的组合和组装解决问题l需求员喜

15、欢把不完整的资料通过尝试补足提出 问题如：找出用例中所有的例外l某些人可能同时具备这两种才干，但更多的人只能 做好一种工作33范围管理l在需求超出资源能力200%时，“砍”掉50%需求的步 骤：找出25-50个概要需求(features)，先不要精化排定这些概要需求的价值(Critical, Important, Useful)，Critical需求约占三分之 一初估各个需求的工作量级别(High, Medium, Low)给出各个需求的风险级别(High, Medium, Low)综合考虑以上三个因素得出优先级，再划出分界 线，线上基本上包括所有Critical和少量 Important需求34需求的对象化管理l需求管理和配置管理的区别记录级和文件级一组完整的、可管理的对象 VS. 一篇文档每个需求项都有变更历史记录l库存管理和需求管理清楚、唯一的标识详细的出入库记录和价值记录35需求的可跟踪性管理（案例）需求跟踪矩阵项目 名称移动 协同服 务支撑 平台项目负 责人王卫红 更新 日期2004.4.15 更新