第7讲 软件需求管理 软件项目管理课程 之 毛新军 xjmao21@21cn.com http://software.nudt.edu.cn/~xjmao 计算机科学与技术系602教研室 0731-(45)73649

讲授内容 项目案例 什么是软件需求 如何进行软件需求分析 软件需求管理 CMM对需求管理的要求 本讲小结 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

项目案例 案例角色和人物 小王：软件项目负责人 老王：公司技术老总 开发小组：小李，老赵，小田，小谢 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

第7讲 软件需求管理 要对软件需求进行管理(1/2) 按照初步的项目计划，老赵带领项目组的部分成员(需求分析小组)开始进驻用户场地，开展需求调查工作，但在需求分析和后续开发过程中陆续出现了许多与用户需求有关的一系列问题，影响软件项目的实施 整个项目规模比较庞大，需求分析小组不知如何开展工作？从何处下手？对需求分析的复杂性和难度估计不足。 需求分析小组不能有效工作：不知哪些属于用户需求，哪些不是？不知怎样才能获取用户需求？如何把它分析清楚？ 不知应该按照怎样的规范书写软件需求规格说明书? 得到的软件需求质量不高：说不清，遗漏，矛度，罗嗦…. 需求评审不严格，导致遗漏了许多需求，获取的用户需求不一致、描述的不清晰和准确 ©Copyright Xinjun Mao 2005

第7讲 软件需求管理 要对软件需求进行管理(2/2) 更为糟糕的是，由于用户没有参加需求评审，使得许多软件需求没有得到用户的认可，最终所开发出的软件不能满足用户的要求，用户拒绝接收软件，并拒绝付款 由于软件需求的不准确性、不一致性和二义性，在软件开发阶段，软件设计人员不得不通过用户再次确认需求 在开发过程中，用户的需求仍然在改变，需求分析小组负责获取改变了的用户需求，然而这些改变了的需求没有得到有效的管理和控制，没能将变化的需求及时反馈给软件开发小组，导致这些需求未能在待开发的软件中得到体现 由于需求未能得到有效管理，在最终项目验收过程中出现了令人不愉快的情况，实际开发的软件没能完全反映用户的需求，导致用户不满意，项目延期 ©Copyright Xinjun Mao 2005

案例提示我们 需求分析是极为重要的 需求分析是困难和复杂的 用户需求经常性的变更是正常的 第7讲 软件需求管理 案例提示我们 需求分析是极为重要的 需求分析是困难和复杂的 用户需求经常性的变更是正常的 为了保证软件需求的质量，必须对需求分析的人、过程和产品进行有效管理 需求管理的不善将会导致严重后果 ©Copyright Xinjun Mao 2005

项目项目管理问题 什么是软件需求？ 如何进行软件需求分析？ 软件需求管理的内容? 如何对软件需求进行管理? 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

讲授内容 项目案例 什么是软件需求 如何进行软件需求分析 软件需求管理 CMM对需求管理的要求 小结 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

软件需求 什么是软件需求？ 获取软件需求的重要性 获取软件需求的复杂性和面临的问题 解决的方法和手段 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

什么是软件需求(1/4) 什么是软件需求？ 说明 待开发软件产品的目标用户对该软件产品的功能、性能、设计约束和其它方面的期望和要求 目标用户 第7讲 软件需求管理 什么是软件需求(1/4) 什么是软件需求？ 待开发软件产品的目标用户对该软件产品的功能、性能、设计约束和其它方面的期望和要求 说明 目标用户 实际操作该软件的用户(图书管理员) 用户方的负责人 用户代表(市场经理)，…… 必须是用户所需的 例如，网上图书借阅(想法很好，用户不需要，也不现实) ©Copyright Xinjun Mao 2005

什么是软件需求(2/4) 关于软件需求的注意事项 软件需求关注用户的期望、要求和需要，不是解决方案 并不是所有方面的要求都是软件需求 第7讲 软件需求管理 什么是软件需求(2/4) 关于软件需求的注意事项 软件需求关注用户的期望、要求和需要，不是解决方案 要区分what和How 例如，要采用什么算法，不是用户需求 并不是所有方面的要求都是软件需求 功能、性能、设计约束、时间进度等 例如，重量、软件大小等不是用户需求 并不是所有用户的期望和要求都是软件需求 用户需求必须中肯，有意义 例如，记录图书的厚度等不是用户需求 ©Copyright Xinjun Mao 2005

什么是软件需求(3/4) 软件需求的表现形式 功能需求 性能需求 设计约束 其它要求：如开发周期 第7讲 软件需求管理 什么是软件需求(3/4) 软件需求的表现形式 功能需求 性能需求 易用性、质量、性能、安全性，移植性、可重用性等 设计约束 运行环境 开发环境 其它要求：如开发周期 ©Copyright Xinjun Mao 2005

什么是软件需求(4/4) 软件需求例子－图书馆管理系统 功能需求 性能需求 设计约束 其它要求 办理读者借书证, 借阅图书，… 第7讲 软件需求管理 什么是软件需求(4/4) 软件需求例子－图书馆管理系统 功能需求 办理读者借书证, 借阅图书，… 性能需求 查询操作延迟时间不超过1秒钟, … 设计约束 前台运行在windows OS下，… 其它要求 开发时间6个月, … ©Copyright Xinjun Mao 2005

获取软件需求的重要性 软件开发的基础和前提 制定软件开发计划的基础 最终目标软件系统验收的标准 第7讲 软件需求管理 获取软件需求的重要性 软件开发的基础和前提 只有在明确了软件需求之后才能开展有针对性的软件开发工作 没有需求无法进行设计和编码 制定软件开发计划的基础 只有知道你想做什么，才能知道做这些东西需要多少工作量？ 不知道软件需求也就不知道工作量的大小，因而不能制定计划 最终目标软件系统验收的标准 只有知道你想做什么，才能知道你最终是否做好了 没有定义明确的需求，就不知道最终基于什么进行验收 ©Copyright Xinjun Mao 2005

获取软件需求的复杂性(1/2) 系统复杂和庞大 片面, 不完全 模糊, 不准确 不一致, 歧义 及时性 如何将软件需求得到？描述清楚？ 第7讲 软件需求管理 获取软件需求的复杂性(1/2) 系统复杂和庞大 如何将软件需求得到？描述清楚？ 片面, 不完全 如何保证得到了所有的软件需求？ 模糊, 不准确 如何保证把需求说清楚和准确？ 不一致, 歧义 如何保证所描述的需求是不矛盾的？ 及时性 当需求变更时，如何让相关人员都知道需求已经变更？ ©Copyright Xinjun Mao 2005

获取软件需求的复杂性(2/2) 软件需求变动带来的问题 波动性 放大性 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

解决的方法和手段 技术层面 管理层面 形成新的研究领域：需求工程 需求分析方法、技术和工具 对需求分析中的人、活动和产品进行管理 第7讲 软件需求管理 解决的方法和手段 技术层面 需求分析方法、技术和工具 方法：数据流、面向对象 技术：抽象、建模、多视点、原型、…… 工具：UML，Rose，Word，Excel，RequisitePro 管理层面 对需求分析中的人、活动和产品进行管理 形成新的研究领域：需求工程 ©Copyright Xinjun Mao 2005

讲授内容 项目案例 什么是软件需求 如何进行软件需求分析 软件需求管理 CMM对需求管理的要求 小结 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

软件需求分析 什么是软件需求分析 软件需求分析的任务 软件需求分析的目标 软件需求分析的过程 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

什么是软件需求分析 什么是软件需求分析？ 需求分析是指从用户处获得需求、形成与用户需求相一致的、可供阅读的软件需求规格说明书的过程 SRS 第7讲 软件需求管理 什么是软件需求分析 什么是软件需求分析？ 需求分析是指从用户处获得需求、形成与用户需求相一致的、可供阅读的软件需求规格说明书的过程 SRS ©Copyright Xinjun Mao 2005

软件需求分析的任务 通过对应用问题及其环境的理解和分析，准确、一致和完全地刻划用户需求，并达成一致，形成软件需求规格说明书SRS SRS 第7讲 软件需求管理 软件需求分析的任务 通过对应用问题及其环境的理解和分析，准确、一致和完全地刻划用户需求，并达成一致，形成软件需求规格说明书SRS SRS ©Copyright Xinjun Mao 2005

软件需求分析的目标 全面性 一致性 准确性 认同 文档化 没有遗漏 没有矛盾 说清楚 共同、相互认可 书面文档 SRS 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

软件需求分析的过程 收集软件需求 软件需求建模 文档化软件需求 评审软件需求 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

步骤1:收集和获取软件需求(1/2) 任务 来源 成果 从用户处收集、获取软件需求, 帮助用户发现潜在的软件需求 软件用户 初步需求描述 第7讲 软件需求管理 步骤1:收集和获取软件需求(1/2) 任务 从用户处收集、获取软件需求, 帮助用户发现潜在的软件需求 来源 软件用户 成果 初步需求描述 ©Copyright Xinjun Mao 2005

步骤1:收集和获取软件需求(2/2) 技术手段 访谈 会议 参观 实践 …… 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

步骤2:软件需求建模(1/2) 任务 来源 对收集的用户软件需求进行建模，发现并纠正不一致、不准确和不全面的软件需求，形成准确的需求描述 第7讲 软件需求管理 步骤2:软件需求建模(1/2) 任务 对收集的用户软件需求进行建模，发现并纠正不一致、不准确和不全面的软件需求，形成准确的需求描述 来源 初步的软件需求描述 ©Copyright Xinjun Mao 2005

步骤2:软件需求建模(2/2) 技术手段 成果 面向数据流和面向对象的建模方法 多视点 原型 软件需求模型 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

步骤3:文档化软件需求(1/2) 任务 来源 根据软件需求初步描述和软件需求模型，撰写软件需求规格说明书 软件需求初步描述 软件需求模型 第7讲 软件需求管理 步骤3:文档化软件需求(1/2) 任务 根据软件需求初步描述和软件需求模型，撰写软件需求规格说明书 来源 软件需求初步描述 软件需求模型 ©Copyright Xinjun Mao 2005

步骤3:文档化软件需求(2/2) 技术手段 成果 软件需求规格说明书编写规范 软件需求规格说明书 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

步骤4:评审软件需求(1/2) 任务 来源 由多方对软件需求规格说明书进行评审，发现其中的问题，并就其中的软件需求达成一致 第7讲 软件需求管理 步骤4:评审软件需求(1/2) 任务 由多方对软件需求规格说明书进行评审，发现其中的问题，并就其中的软件需求达成一致 来源 软件需求规格说明书 ©Copyright Xinjun Mao 2005

步骤4:评审软件需求(2/2) 技术手段 成果 需求评审原则 可纳入配置的软件需求规格说明书 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

讲授内容 项目案例 什么是软件需求 如何进行软件需求分析 软件需求管理 CMM对需求管理的要求 小结 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

需求管理 为什么需要对软件需求进行管理 需求管理的内容 收集软件需求 软件需求建模 撰写软件需求规格说明书(SRS) 评审软件需求 第7讲 软件需求管理 需求管理 为什么需要对软件需求进行管理 需求管理的内容 收集软件需求 软件需求建模 撰写软件需求规格说明书(SRS) 评审软件需求 控制软件需求的变更 ©Copyright Xinjun Mao 2005

为什么需要对软件需求进行管理 软件需求非常重要 获取软件需求非常复杂和困难 第7讲 软件需求管理 为什么需要对软件需求进行管理 软件需求非常重要 获取软件需求非常复杂和困难 在需求获取过程中涉及到人、活动和过程，只有对它们进行管理才能确保有效地进行需求分析，确保软件需求的质量 软件需求经常变更，为了确保软件需求处于受控状态 ©Copyright Xinjun Mao 2005

需求管理的内容 参与需求分析和评审的人员 软件需求文档 需求分析过程 需求变更 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

收集软件需求 如何收集软件需求？ 文档化所收集的软件需求 软件需求收集的注意事项 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

如何收集需求？ 确定哪些用户角色会对软件提出需求 用户方要成立相应的需求分析小组 和相关角色的人员进行交流 第7讲 软件需求管理 如何收集需求？ 确定哪些用户角色会对软件提出需求 例如图书馆的馆长，图书管理员，书库管理员，读者管理员，系统管理员；而不是图书馆的清理工 用户方要成立相应的需求分析小组 和相关角色的人员进行交流 会议、探讨、观察、实践、听取意见 在交流的过程中要有记录，要对记录进行整理 文字，录音，整理，写成文档 ©Copyright Xinjun Mao 2005

文档化所收集的软件需求(1/3) 描述需求内容 定义软件需求编号(结构化) 例如，查询图书 按照图书名字查询 例如，10(查询图书) 第7讲 软件需求管理 文档化所收集的软件需求(1/3) 描述需求内容 例如，查询图书 按照图书名字查询 定义软件需求编号(结构化) 例如，10(查询图书) 10.1(按照图书名字查询) 10.2(按照图书的书号查询) 10.3 (按照作者查询) ©Copyright Xinjun Mao 2005

文档化所收集的软件需求(2/3) 描述软件需求特性 例如，查询图书软件需求 重要性(高、中、低)，用于制定计划 第7讲 软件需求管理 文档化所收集的软件需求(2/3) 描述软件需求特性 例如，查询图书软件需求 重要性(高、中、低)，用于制定计划 紧迫性(短期、中期、长期)，用于制定计划 工作量(10个人月)，用于估算工作量、制定计划 ©Copyright Xinjun Mao 2005

文档化所收集的软件需求(3/3) 工具：word, excel, RequisitPro(Rational) 初步需求描述编写规范 第7讲 软件需求管理 文档化所收集的软件需求(3/3) 工具：word, excel, RequisitPro(Rational) 初步需求描述编写规范 ©Copyright Xinjun Mao 2005

软件需求收集的注意事项(1/2) 如果应用规模较大，可分成几个需求调查小组同时进行，最后对结果进行汇总 第7讲 软件需求管理 软件需求收集的注意事项(1/2) 如果应用规模较大，可分成几个需求调查小组同时进行，最后对结果进行汇总 一定要和用户进行充分的交流，尽可能获取足够多的信息和资料，发现问题要及时沟通 在该阶段要和用户打成一片，进行充分的合作，建立起良好的合作关系 如果发现多个软件需求相互矛盾，要能找到仲裁人，或者决策人 ©Copyright Xinjun Mao 2005

软件需求收集的注意事项(2/2) 需求调查应遵循先整体后部分、先抽象后具体的原则 帮助用户发现潜在的需求 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

软件需求建模 为什么需要对软件需求进行建模？ 如何对软件需求进行建模？ 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

为什么需要对软件需求进行建模 需求调查所获取和文档化(文字)的软件需求不能有效地描述软件需求 第7讲 软件需求管理 为什么需要对软件需求进行建模 需求调查所获取和文档化(文字)的软件需求不能有效地描述软件需求 文字描述的局限性(不准确、二义、歧义、不能直观揭示关联) 不准确 不一致 不全面 ….. ©Copyright Xinjun Mao 2005

如何对软件需求进行建模(1/2) 需求建模技术 面向数据流的需求建模技术 面向对象的需求建模技术 UML Use case 图 第7讲 软件需求管理 如何对软件需求进行建模(1/2) 需求建模技术 面向数据流的需求建模技术 面向对象的需求建模技术 UML Use case 图 交互图(顺序图，协作图) 类图 状态图 活动图 ©Copyright Xinjun Mao 2005

如何对软件需求进行建模(2/2) 案例分析 需求建模的例子(图书管理系统，UML，Rose) 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

撰写SRS(1/2) 为什么要撰写成SRS 记录软件需求 便于交流 便于管理 便于控制 便于验证 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

撰写SRS(2/2) SRS应该作为一种规范和标准 企业和组织要明确说明如何撰写软件需求规格说明书 一个SRS的编写规范 第7讲 软件需求管理 撰写SRS(2/2) SRS应该作为一种规范和标准 企业和组织要明确说明如何撰写软件需求规格说明书 一个SRS的编写规范 ©Copyright Xinjun Mao 2005

评审软件需求 为什么需要对软件需求进行评审？ 如何进行评审？ 评审结果 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

为什么需要对软件需求进行评审？ 发现软件需求规格说明书中的问题 共同认可软件需求 不全面 不一致 不准确 不可验证 书写不规范 第7讲 软件需求管理 为什么需要对软件需求进行评审？ 发现软件需求规格说明书中的问题 不全面 不一致 不准确 不可验证 书写不规范 共同认可软件需求 ©Copyright Xinjun Mao 2005

如何进行评审(1/3) 参与评审人员 应该提前将SRS送给参与评审人员 项目经理 用户方(代表) 需求分析小组 软件设计小组 软件测试小组 第7讲 软件需求管理 如何进行评审(1/3) 参与评审人员 项目经理 用户方(代表) 需求分析小组 软件设计小组 软件测试小组 软件质量保证小组…… 应该提前将SRS送给参与评审人员 ©Copyright Xinjun Mao 2005

如何进行评审(2/3) 需求评审原则 多方对软件需求达成一致 正确性 准确 无歧义性 软件需求是否是用户所需要的 第7讲 软件需求管理 如何进行评审(2/3) 需求评审原则 多方对软件需求达成一致 正确性 软件需求是否是用户所需要的 例如，一个读者最多能借10本书 准确 是否把软件需求描述清楚了 例如，一个读者包括诸多信息如名字，单位等等 无歧义性 软件需求描述是否会引起不必要的误解和认识上的偏差 例如，用户和客户 ©Copyright Xinjun Mao 2005

如何进行评审(3/3) 完全性 可验证性 一致性 可理解和可修改性 可追踪性 是否所有的需求都已经包含了 是否有手段来验证需求已经实现了 第7讲 软件需求管理 如何进行评审(3/3) 完全性 是否所有的需求都已经包含了 可验证性 是否有手段来验证需求已经实现了 例如，查询结果应该很快得到 一致性 软件需求是否会相互矛度 可理解和可修改性 软件需求描述是否简洁、直观，易于修改和维护 可追踪性 软件需求是否易于追踪 ©Copyright Xinjun Mao 2005

软件需求评审结果 软件需求评审应该要有记录，并形成软件需求评审报告 软件需求评审应该要有结论 软家需求评审报告样板 第7讲 软件需求管理 软件需求评审结果 软件需求评审应该要有记录，并形成软件需求评审报告 软家需求评审报告样板 软件需求评审应该要有结论 根据意见进一步改进，下次再次进行评审 根据意见进一步改进，无需再次进行评审 评审通过 ©Copyright Xinjun Mao 2005

第7讲 软件需求管理 控制软件需求的变更 控制SRS 控制需求的变更 ©Copyright Xinjun Mao 2005

控制SRS 作为一个基本的软件配置项纳入配置 任何对软件需求的变更必须进行仔细审查，征得同意后才能进行变更 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

控制需求的变更(1/3) 需求变更不可避免 需求变更对软件项目的开发会产生巨大的影响 软件需求本身是变化的 第7讲 软件需求管理 控制需求的变更(1/3) 需求变更不可避免 软件需求本身是变化的 在需求分析阶段对软件需求的描述和分析不全面、不准确等 需求变更对软件项目的开发会产生巨大的影响 产品功能 开发成本 开发进度 产品质量 ©Copyright Xinjun Mao 2005

控制需求的变更(2/3) 需求变更的权衡，需要和用户协商，并对计划进行变更 需求 进度 成本 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

控制需求的变更(3/3) 如何控制需求的变更 提出软件需求变更请求 对软件需求变更进行评审 变更SRS 将变更后的SRS纳入配置 第7讲 软件需求管理 控制需求的变更(3/3) 如何控制需求的变更 提出软件需求变更请求 对软件需求变更进行评审 变更SRS 将变更后的SRS纳入配置 通知受影响小组和人员 变更其他产品(软件设计文档、测试文档)和计划(软件开发计划) ©Copyright Xinjun Mao 2005

讲授内容 项目案例 什么是软件需求 如何进行软件需求分析 软件需求管理 CMM对需求管理的要求 小结 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

CMM对需求管理的要求(1/3) 需求管理是CMM 2级的一个关键过程域 CMM对需求管理的理解和定义 第7讲 软件需求管理 CMM对需求管理的要求(1/3) 需求管理是CMM 2级的一个关键过程域 CMM对需求管理的理解和定义 需求管理是指在用户和将处理“分配给软件的系统需求”的软件项目组之间建立对“分配给软件的系统需求”的共同理解，由软件工程组对“分配给软件的系统需求”进行分析、精化，按照规范详细描述“分配给软件的系统需求”，形成“软件需求规格说明”文档，并对该文档进行评审 “分配给软件的系统需求” 是指系统总体分配给软件的需求，也称软件需求 “用户”可解释为系统工程组或外部顾客等 ©Copyright Xinjun Mao 2005

CMM对需求管理的要求(2/3) “软件工程组” ：实施软件工程化开发的小组 软件需求既包括技术需求、又包括非技术需求 第7讲 软件需求管理 CMM对需求管理的要求(2/3) “软件工程组” ：实施软件工程化开发的小组 软件需求既包括技术需求、又包括非技术需求 软件需求构成项目规模和工作量估算、制定项目计划和跟踪软件项目活动的基础 每当软件需求改变时，都应调整受到影响的软件计划、工作产品和活动，使其与更新后的软件需求保持一致 对已通过评审的软件需求的任何更改都应受到管理和控制 ©Copyright Xinjun Mao 2005

CMM对需求管理的要求(3/3) 共12个关键实践 关键实践类 关键实践数目 制定方针政策 1 确保必备条件 4 实施软件过程 3 第7讲 软件需求管理 CMM对需求管理的要求(3/3) 共12个关键实践 关键实践类 关键实践数目 制定方针政策 1 确保必备条件 4 实施软件过程 3 度量和分析 检查实施情况 ©Copyright Xinjun Mao 2005

目标 使软件需求受控，建立供软件工程和管理使用的基线 软件计划、产品和活动与软件需求保持一致 第7讲 软件需求管理 目标 使软件需求受控，建立供软件工程和管理使用的基线 受控：在给定时间(过去或现在)使用的工作产品的版本是已知的(即受版本控制的)，并以受控的方式进行更动(即更动控制) “软件工程”是指软件设计、编码、测试等 “软件管理”是指项目计划制定、项目跟踪、风险等 软件计划、产品和活动与软件需求保持一致 所谓“保持一致”是指相吻合 ©Copyright Xinjun Mao 2005

制定方针政策 项目遵循一个书面的、由组织制定的方针用来管理软件需求 将软件需求写成规范化的文档 拟定参加需求评审的人员, 包括 第7讲 软件需求管理 制定方针政策 项目遵循一个书面的、由组织制定的方针用来管理软件需求 将软件需求写成规范化的文档 拟定参加需求评审的人员, 包括 项目软件负责人， 其它受影响的小组，包括系统测试组，软件工程组(如软件设计小组),软件质量保证组，软件配置管理组，文档支持组等 当软件需求发生改变时，更动软件计划、工作产品和活动，使其与软件需求的改变保持一致 ©Copyright Xinjun Mao 2005

确保必备条件(1/4) 建立和明确系统需求分析和分配的人员及其职责 ，明确 在整个项目生存期内，管理和分配系统需求，并将它们写成文档 第7讲 软件需求管理 确保必备条件(1/4) 建立和明确系统需求分析和分配的人员及其职责 ，明确 在整个项目生存期内，管理和分配系统需求，并将它们写成文档 实施对系统需求及其分配的更动，当系统需求发生更动时，应及时更动软件需求 ©Copyright Xinjun Mao 2005

确保必备条件(2/4) 将软件需求写成规范化的文档 技术需求，如软件功能、性能、设计约束、编程语言、界面需求 第7讲 软件需求管理 确保必备条件(2/4) 将软件需求写成规范化的文档 技术需求，如软件功能、性能、设计约束、编程语言、界面需求 非技术性需求(即协议、条件、和(或)合同条款),包括：要交付的产品、交付日期、里程碑等 用于确认软件产品满足软件需求的验收准则 ©Copyright Xinjun Mao 2005

确保必备条件(3/4) 提供足够的用以管理分配需求的资源和经费 指派在应用领域和软件工程方面有经验和技能的个人去管理软件需求 第7讲 软件需求管理 确保必备条件(3/4) 提供足够的用以管理分配需求的资源和经费 指派在应用领域和软件工程方面有经验和技能的个人去管理软件需求 提供可用的、能支持软件需求管理活动的工具 电子表格程序 配置管理工具 跟踪工具 测试管理工具 ©Copyright Xinjun Mao 2005

确保必备条件(4/4) 软件工程组和其它受影响组的人员接受需求管理方面的培训，如 项目所使用的方法、标准和规程 应用领域知识 第7讲 软件需求管理 确保必备条件(4/4) 软件工程组和其它受影响组的人员接受需求管理方面的培训，如 项目所使用的方法、标准和规程 应用领域知识 ©Copyright Xinjun Mao 2005

实施软件过程(1/3) 软件工程组识别、分析和细化软件需求，对它进行评审 鉴别出不完整的和遗漏的软件需求 评审软件需求，确定它们是否 第7讲 软件需求管理 实施软件过程(1/3) 软件工程组识别、分析和细化软件需求，对它进行评审 鉴别出不完整的和遗漏的软件需求 评审软件需求，确定它们是否 用软件来实现是可行的和恰当的 已被清晰和准确地阐述 相互一致、无矛盾 可验证、可测试 对任何被识别出有潜在问题的软件需求进行评审，并作出必要的更动 和受影响组一起协商解决由软件需求引出的承诺 ©Copyright Xinjun Mao 2005

实施软件过程(2/3) 将软件需求作为软件开发计划、工作产品和过程活动的基础，软件需求： 是受管理和控制的 是软件开发计划的基础 第7讲 软件需求管理 实施软件过程(2/3) 将软件需求作为软件开发计划、工作产品和过程活动的基础，软件需求： 是受管理和控制的 是软件开发计划的基础 ©Copyright Xinjun Mao 2005

实施软件过程(3/3) 对软件需求的更动进行评审，并将其纳入软件项目 评估软件需求更动对现有承诺的影响，通过协商对承诺进行适当的更改 第7讲 软件需求管理 实施软件过程(3/3) 对软件需求的更动进行评审，并将其纳入软件项目 评估软件需求更动对现有承诺的影响，通过协商对承诺进行适当的更改 对组织外的个人和组所作承诺的更改由高级管理者参与评审 和受影响组协商组织内部承诺的更改 对由于软件需求的更动所造成的对软件计划、工作产品和活动必须作的更动要进行识别、评价、风险评估、写成文档、做出计划、传达到受影响组和个人、跟踪直到结束 ©Copyright Xinjun Mao 2005

度量和分析 进行度量，并将度量结果用以确定软件需求管理活动的状态，度量内容包括 每个软件需求的状态(确认并批准、问题等) 第7讲 软件需求管理 度量和分析 进行度量，并将度量结果用以确定软件需求管理活动的状态，度量内容包括 每个软件需求的状态(确认并批准、问题等) 关于软件需求的更动活动 对用软件需求更动的累积数，包括建议的、未解决的、已批准的并已纳入系统基线的软件需求更动的总数 ©Copyright Xinjun Mao 2005

验证实施(1/3) 高级管理者定期参与对软件需求管理活动进行的评审 第7讲 软件需求管理 验证实施(1/3) 高级管理者定期参与对软件需求管理活动进行的评审 高级管理者参与定期评审的主要目的是在合适的抽象层次上及时地了解和洞察软件过程。评审间隔时间应该满足组织的需要，如果存在异常情况报告机制，间隔时间可以长些。 ©Copyright Xinjun Mao 2005

验证实施(2/3) 项目负责人可定期或者事件驱动地参与对软件需求管理活动的评审 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

验证实施(3/3) 软件质量保证组对软件需求管理活动和工作产品进行评审和(或)审计，并报告其结果 第7讲 软件需求管理 验证实施(3/3) 软件质量保证组对软件需求管理活动和工作产品进行评审和(或)审计，并报告其结果 软件需求已评审，且有关问题在软件工程组开发软件之前已得到解决 当软件需求更动时，软件计划、工作产品和活动已经适当地更动 由软件需求的更动所导致的对承诺的更动已与受影响组进行协商 ©Copyright Xinjun Mao 2005

讲授内容 项目案例 什么是软件需求 如何进行软件需求分析 软件需求管理 CMM对需求管理的要求 小结 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

本讲小结 获取软件需求对于软件项目的开发是十分重要的 一个好的软件需求应该满足许多条件 必须对软件需求进行有效的管理 第7讲 软件需求管理 ©Copyright Xinjun Mao 2005

教学目的 理解 掌握 运用 软件需求、需求分析和需求管理等概念 软件需求重要性和获取软件需求复杂性 为什么要进行需求管理 软件需求分析的过程 第7讲 软件需求管理 教学目的 理解 软件需求、需求分析和需求管理等概念 软件需求重要性和获取软件需求复杂性 为什么要进行需求管理 掌握 软件需求分析的过程 软件需求管理的内容和手段 运用 运用需求分析方法、技术和工具进行需求分析，获取软件需求 在软件项目开发过程中对软件需求进行必要的管理 ©Copyright Xinjun Mao 2005

Software Project Management 第7讲 软件需求管理 Software Project Management Q & A Practice, Practice, and Practice ©Copyright Xinjun Mao 2005