韩万江《软件项目管理案例教程》第2章-范围计划.pptVIP

本章要点 2.1 关于软件需求 2.2 需求管理过程 2.3 编写需求规格的方法 2.4 任务分解定义 2.5 任务分解的方法 2.6 任务分解结果的检验 2.7 案例分析 软件需求 软件需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么样的性能。 软件需求的层次 从上到下越来越详细，细化。 业务需求（Business requirement）表示组织或客户高层次的目标。 比如：提高效率，节约成本。完成预期任务（做工资）。 用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。 比如：完成输入修改计算工资，出工资表工资条。 功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。 比如：增删改，查询，报表，数据库备份与恢复。 系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。 比如：顶级菜单；类似于业务需求。综合概括需求。 质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性。比如：要提供用户手册。 约束（constraint）限制了开发人员设计和构建系统时的选择范围。 比如：必须选用ASP.NET技术. 非功能性需求：比如性能要求，1000人同时访问网站。 本章要点 2.1 关于软件需求 2.2 需求管理过程 2.3 编写需求规格的方法 2.4 任务分解定义 2.5 任务分解的方法 2.6 任务分解结果的检验 2.7 案例分析 倘若没有需求管理 需求管理过程 需求获取 需求获取是通过与用户交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。 “排课系统”为例：与排课用户交谈得知，旧排课系统存在的问题（人数限制1000人，排课冲突，数据要手工导入,课表十分简单，与新网站不兼容），提出新系统应当具备的功能。 “工资系统”为例：原来用网络上下载的工资系统，出现错误无法解决，手工调整错误结果。不能定制功能，不能手工导入Excel数据。 需求调查的常用方式 问答列表邮件提问 电视电话会议 专题讨论会 自行搜集需求 需求分析定义 需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。 需求分析模型 需求规格说明书 需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。 软件需求规格说明的原则 从现实中分离功能，即描述要“做什么”而不是“怎样实现” 采用一定的需求规格说明语言，比如UML等 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在需求规格说明的描述之中 需求规格说明应该包括系统运行环境 需求规格说明应该容许不完备性、并允许扩充 软件需求规格说明书 引言 系统定义 应用环境 功能规格 性能需求 产品提交 实现约束 质量描述 其它 签字认证 需求验证 需求验证包括以下内容： 需求是正确的吗？ 需求是一致的吗？ 需求是完全的吗？ 需求是实际可行的吗？ 需求是必要的吗？ 需求是可检验的吗？ 需求总在变化 需求基线不是写出来的，而是在需求规格说明书评审通过以后所形成的，具体的步骤是开发人员先完成需求规格说明书的写作，然后组织相关人员对需求进行评审，在评审通过以后就纳入到配置库进行管理，形成需求基线 。 基线是一个状态,也就是相当于一个标准,基线化后就不能改动(改动需要变更控制委员会通过才可以)，大家工作向基线化后的代码,需求说明书,设计说明书等看齐,这样便也工作一致性 。 类似于“草稿”之后的“定稿”，“试行条例”之后的“条列”。 需求变更管理 建立需求基线 确定需求变更控制过程 建立变更控制委员会 进行需求变更影响分析 跟踪所有受需求变更影响的工作产品 建立需求基准版本和需求控制版本文档 维护需求变更的历史记录 跟踪每项需求的状态 衡量需求稳定性 本章要点 2.1 关于软件需求 2.2 需求管理过程 2.3 需求建模的方法 2.4 任务分解定义 2.5 任务分解的方法 2.6 任务分解结果的检验 2.7 案例分析 需求建模的基本方法 原型分析方法 结构化分析法 用例分析法 功能列表法 其他方法 本章要点 2.1 关于软件需求 2.2 需求管理过程 2.3 需求建模的方法 2.4 任务分解定义 2.5 任务分解的方法 2.6 任务分解结果的检验 2.7 案例分析 编制进度计划的三步曲 任务分解 资