第二讲 需求管理

1. 第二讲 需求管理

2. 内 容 • 软件发展的三个时期 • 软件生存期过程 • 软件开发过程 • 软件需求 • 需求工程 • 需求管理 • CMM2级需求管理关键过程域

3. 时期 年代 阶段 涉及 注重 主要使用语言 标准 模型 初期 50-60 程序设计 点 编程 技巧 ALGOL FORTRAN COBOL BASIC 中期 70-80 软件开发 线 结构化 模块化 PASCAL GB8566 软件开发 规范 瀑布 原型 现代 90- 软件过程 面 过程 能力 C,C++ JAVA VB、VC ISO/IEC 12207 软件生存期过程 ISO9000 螺旋 CMM 一、软件发展的三个时期 表一

4. 二、软件生存期过程 ISO/IEC12207 信息技术－软件生存期过程 基本过程 软件生存期过程 支持过程 图1-1 组织过程

5. 获取过程 ⑴ 供应过程 ⑵ 基本过程 开发过程 ⑶ 运行过程 ⑷ 图1-2 维护过程 ⑸

6. 文档编制过程 ⑹ 配置管理过程 ⑺ ⑻ 质量保证过程 验证过程 ⑼ 支持过程 确认过程 ⑽ 联合评审过程 ⑾ 图1-3 审核过程 ⑿ 问题解决过程 ⒀

7. 管理过程 ⒁ 基础设施过程 ⒂ 组织过程 改进过程 ⒃ 图1-4 培训过程 ⒄

8. 三、软件开发 过程 1.计算机系统 人员 （剧作家、导演） 硬件 软件 数据 传输 机构 执行 机构 （舞台 剧本 演员 道具） 图2 计算机系统

9. ⑴系统需求分析 ⑵系统结构设计 ⑶软件需求分析 建立软件需求 评价软件需求 联合评审 ⑷软件结构设计 ⑸软件详细设计 ⑹软件编码和测试 ⑺软件集成 ⑻软件鉴定测试 ⑼系统集成 ⑽系统鉴定测试 ⑾软件安装 ⑿软件验收支持 2.软件开发过程： 活动－任务

10. 软件开发面临的实际问题

11. 软件开发面临的实际问题

12. 软件开发面临的实际问题

13. 3 定义软件开发过程的步骤 （1）确定软件模型 （2）确定活动 （3）确定活动间的关系 （4）文档化每个活动的其他有用信息 （5）文档化剪裁过程 （6）文档化改善过程 （7）获得过程的认可 （8）不断使用和改善过程

14. 3.1 确定软件模型 编码修复模型 瀑布模型 增量模型 迭代模型 3.2 确定活动 3.3 确定活动间的关系 3.4 活动的有用信息文档化

15. 3.5 剪裁过程文档化 3.6 改善过程文档化 3.7 过程获得认可并培训员工 3.8 不断使用和改善过程

16. 4．当前软件开发项目的特点 ――规模大：LOC 1万几十万  HP 激光打印驱动软件 4万110万 ――复杂 ――质量要求高 满足客户需求和期望 客户满意度统计 ――开发和维护成本 缺陷后期发现 返工成本 ――延误交付期

17. 四、软件需求 1. 系统需求分析 客户 最终用户 系统工程组 系统需求 分配 软件工程组 软件 系统需求(1) 硬件 系统需求(2) 其它成分 系统需求(n) 软件需求 图3 系统需求分配

18. 2.软件需求 • ⑴定义（IEEE-STD-610） • 用户为解决某个问题、或为实现某一目标， • 要求软件必须满足的条件或能力。 • ⑵ 软件需求的三个层次 • 业务需求 • 用户需求 • 功能需求和非功能需求

19. 过程需求：交付需求，实现需求，遵循的标准 过程需求：交付需求，实现需求，遵循的标准 性能需求：速度，容量，可靠性 外部需求：互操作性，伦理性， 机密性，安全性， 使用要求 非功能需求

20. 业务需求 业务说明 用户需求 使用实例 约束条件 功能需求 非功能需求 软 件 需 求 规 格 说 明 图 4 软件需求的层次

21. ⑶质量功能展开（QFD－Quality Function Development） 客户需求 • 常规需求：客户明确提出 • 期望需求：并未明确提出的潜在需求， • 不 言而喻的需求 • 兴奋需求：客户未想到，若实现客户 • 感到意外

22. ⑷ 分配需求的实例 系 统 需 求 ACCS应能使汽车保持在预期车速的2KMH范围内行驶 分配给硬件的需求 硬件应能使车速在规定的精确度1.5KMH范围内 分配给软件的需求 软件应能在车速超出预期车速0.5KMH时给硬件加/减速命令 软 件 需 求 软件应能： 读入当前车速值 计算当前车速与预期车速之差 若差值0.5KMH给出加/减速命令 图5 汽车限速系统ACCS的需求分配

23. 3．CMM 2级关键过程域需求管理（KPA RM）中对软件需求的解释： 分配需求（allocated requirements）： 分配给软件的系统需求

24. （1）分配需求包括： • ――影响和确定软件项目活动的非技术性需求 • （在合同条款中规定），如： • 要交付的产品 • 交付日期 • 里程碑 • ――软件的技术需求，如： • 最终用户、操作人员、支持或集成的功能 • 性能需求 • 设计约束条件 • 编程语言 • 界面需求 • ――用于确认软件产品满足分配需求的验收准则

25. （2）分配需求应当是： • 以软件来实现是可行的，而且是适合的； • 已得到清晰而正确的阐述； • 相互之间是一致的； • 可以测试的。 • 同时，分配需求应当： • 被管理和控制（如必要可纳入软件配置管理） • 是制定软件开发计划SDP的基础 • 是制定软件需求的基础

26. （3）与分配需求相关的组： • 软件评估组 • 系统工程组 • 系统测试组 • 软件质量保证组SQA • 合同管理组 • 文档支持组

27. 五、需求工程 1．需求工程＝需求开发＋需求管理 获取需求 分析需求 需求开发 定义需求 验证需求 需求工程 需求变更控制 需求跟踪 需求管理 需求状态跟踪 需求文档版本控制 图6 需求工程的构成

28. 市场 用户/系统 管理者 初始需求 变更的需求 项目环境 获取,分析,定义,验证需求 控制需求变更 需求规格说明 需求开发 需求管理 图7 需求开发与需求管理

29. 2．需求开发 • （1）获取需求 • 确定目标用户、服务对象 • 明确用户代表 • 用户培训 • 了解实际业务和业务需求 • （2）分析需求 • 分清功能需求、性能需求、使用需求…… • 必要性 • 可行性

30. （3）定义需求 • 编写软件需求规格说明（SRS） • 作用 • 要求：完整、正确、可行、无歧意、可验证 • 形式：图、表、文字 • （4）验证需求 • 联合评审

31. 六、需求管理 • 需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与工作成果的一致性，并控制需求的变更。 • 包括：需求确认 • 需求变更控制 • 需求跟踪 • 1、需求确认 • 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。

32. 需求确认步骤： • （1）非正式需求评审 • 项目经理先在项目内部组织人员进行非正式的需求评审，消除明显的错误和分歧。 • （2）正式需求评审 • 项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的意愿。 • （3）获取需求承诺 • 通过正式评审后，开发方负责人（项目经理）和客户对需求文档做书面承诺，使之具有商业合同效果。

33. 例如： • 本需求文档建立在双方对需求的共同理解基础上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，我们将按照“需求变更控制规程”执行。我明白，需求的变更将导致双方重新协商成本、资源和进度等。 • 甲方负责人签字 • 乙方负责人签字

34. 2、需求变更控制 什么是需求变更？ 对问题的 初始理解 对问题的 新理解 初始需求 变更的需求 时间 图8 需求的变更

35. 需求变更原因分析 • 单纯的用户因素 • 市场形势变化 • 系统因素 • 工作环境和要求变化 • 需求开发的缺陷 • ★需求分析、定义和评审不充分 • ★与用户沟通不畅

36. 需求变更对软件开发的影响 ⑴使变更前开发工作和成果失效 ⑵返工成为被迫采取的对策 ⑶工作量及资源投入的增加使开发成本提高 ⑷项目完成时间后延

37. 需求文档V1 需求变更 系统实现 V2 系统实现 V1 需求变更失控可能导致的后果 ⑴未受控的需求变更引起需求和实现不一致

38. 需求变更 需求文档V1 需求文档V2 系统实现 V1 系统实现 V2 ⑵受控的需求 变更使需求和实现一致 图7 未受控及受控的需求变更

39. 项目开发工作 项目开发组织 用户 * 产品后续开发工作的基础 * 产品维护工作的重要参考 * 对用户的承诺 * 关系到项目开发工作的投入、交付期和产品质量 * 关系到能否如期获得所需的产品 * 作为合同的附件，关系到双方的权益 * 是产品验收的依据 降低需求变更风险的策略 ⑴ 与用户充分沟通 ★与用户共同明确确定的需求的意义 ★向用户说明需求不确切或频繁变更对开发工作的冲击 ★使用户理解过多变更最终对用户不利

40. ⑵与用户共同确定需求，作为合同附件， 签字生效 ⑶合同中含有对需求变更的条款 ⑷采用原型方法开发，或螺旋模型开发 ⑸项目计划中适当留有余地（时间进度、人力投入、 费用等） ⑹严格实施变更控制

41. 需求变更控制要求 变更控制的策略 （1）所有需求变更必须遵循需求变更控制规程实施变更。 （2）需求变更提出后是否被接受，应由专门的组织―变 更控制委员会（CCB－Change Control Board）审查决定。 （3）不得以任何理由删除和修改需求变更的原始文件。 （4）应将已接受的需求变更通知到所有相关人员。 （5）已接受的需求变更应能追溯到批准的变更请求。 （6）对项目的需求赋予状态属性，以利于需求变更的控制。

42. 需求变更影响的控制 • 按CMM2级RM KPA的要求，由于分配需求的变更导致软件计划、工作产品和活动的变更，都应对其作： • 识别 • 评价 • 风险分析 • 编制文档 • 制定计划 • 传达给受影响的小组和人员 • 跟踪直至结束

43. 变更控制的步骤 • （1）提出变更请求 • （2）审理变更请求，进行变更影响评估。评估内容包括： • 变更所需人力投入 • 变更对原计划安排的影响 • 估计变更引起的成本增加 • （3）批准变更请求 • （4）取得用户的认可 • （5）修订项目计划 • （6）实施变更 • （7）验证变更

44. 提出变更请求 变更影响评估 评审评估报告 批准 审批 用户认可 拒绝 修订项目计划 实施变更 修正 验证 变更结束 图10 需求变更控制流程

45. 需求变更控制实施 • 需求变更请求 • （1）内容 • 申请号 • 变更说明 • 变更类别 • 影响分析 • 变更请求状态 • 变更请求日期

46. 项目名：XYZ 变更申请号 11 日期：23 Feb 1998 变更说明 IS-41 分析器对CDMA的支持 影响分析 对CDMA的配置模块和分析器无影响 TDMA码可复用 受影响的模块是： ――CGAAPP模块，需对IS-41单独进行规范性分析 ――CDMAPP01模块 （a）TRIS41R01按TRCDMARS 41R01复制 （b）使用纯虚拟对TRCDMAR01建立 （c）Actual Call Mode Manager 并重新定义 ――SILVER 06 GUIAPP++ 模块：在资源表中加入IS-41 工作量 5 人日 计划时间 无需重大变动 状态 将并入新的CDMA软件包 需求变更请求实例（表三）

47. 需求变更累积影响的跟踪 • （1）需求变更累积影响跟踪的意义和作法 • 累积影响 • 变更累积表 • （2）需求变更累积表实例（表四）

48. 需求变更号 需求变更时间 变更说明 工作量 状态 1 18/2 规定使用情况统计 3 22/2结束 2 演示期 用户阻塞 2 未结束 3 演示期 用户强迫退出 2 未结束 4 18/2 用户信息归档 5 27/2结束 5 演示期 关闭窗口 1 未结束 6 演示期 保存扩展数并在需要时恢复 10 未结束 7 演示期 能够在特定节点启动 2 未结束 8 演示期 删除时列出所有节点 1 未结束 9 18/2 注释（建立删除批准修改等） 10 未结束 10 23/2 PENETCONFIG――支持netconfig 格式 10 未结束 11 23/2 IS-41分析器――IS-41分析器对CDMA的支持 5 1/3结束 总计 51 表四需求变更累积表

49. 需求控制流 • （1）需求状态及其演变 • 软件需求在后继阶段开发工作中将逐步展开，加以实现。 • 在不同的开发阶段软件需求以不同的形式进行着状态的演变。例如： • ――需求阶段――从获取的需求到定义的需求 • ――建议阶段――制定出项目计划以后演化为承诺的需求 • ――设计阶段――设计工作完成并在验收后成为设计的需求 • ――编码阶段――完成编码和单元测试后成为实现的需求 • ――测试阶段――完成确认测试后成为完成的需求

50. 开发 阶段 需求 建议 设计 编码 测试 获取 定义 承诺 设计 实现 完成 需求 状态 图11 生存期各阶段需求 状态的演变