软件需求管理部分完整版.ppt

需求开发面临的特殊难题 需求开发：是针对一个新软件或系统开发项目的情况，这种项目有时也称为零起点项目(green-field project)。 大多数组织的主要精力集中于维护现存的遗留系统，或者为已有的商业产品构建新的版本；其他组织也很少是从零开始构建一个新系统，而是对商用现货产品进行集成、定制和扩充，以满足自己的需要。 开始捕获信息 缺少精确的需求文档，那么维护人员就必须进行逆向工程，通过代码来理解系统，将此看作是软件考古学(software archaeology)。 构建一个包含当前系统部分的需求表示可达到以下3个有用的目标： 消除知识鸿沟，使将来的维护人员能更好地理解所做的变更。 收集当前系统的一些信息——当前系统在以前缺乏良好的书面文档。 提供一个指标，表明当前的系统测试集对系统功能的覆盖率。 定义质量需求 软件的质量属性和性能目标是选择解决方案时所要考虑的用户需求的另一个方面。 我们至少要研究下面几个属性： 性能 易使用性 灵活性 互操作性 完整性 尽早地而且要经常地设定优先级 客户和开发人员协同工作，共同选定功能实现的顺序，这样增量开发才会取得成功。 开发团队的目标是，将可用的功能和对质量的改进有规律地交到用户手中，因此，开发人员必须了解每次增量开发计划实现哪些功能。 设定需求优先级 每一个受资源限制的软件项目都必须对要求的产品功能定义相对优先级。 设定优先级有助于项目经理解决冲突、安排阶段性交付，并且做出必要的取舍。 讨论设定需求优先级的重要性，提出一个简单的优先级划分方案，并介绍更严格的基于价值、成本和风险的优先级分析方案。 需求和进度安排 需求管理 需求管理的原则和实践 需求管理包括在项目开发过程中维护需求约定的完整性、准确性以及保持需求约定是必威体育精装版约定的所有活动，如图所示。 软件需求管理 需求管理所要完成的任务 需求管理模型 管理变更 需求风险管理 需求跟踪 需求管理工具 需求管理所要完成的任务 需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。 需求模型实际是最终产品的抽象化表现。 用户需求的满足程度是衡量设计优劣的标准。 优秀的需求分析应当非常精确细致地对用户需求作出描述，同时也应该最大程度地给予方案设计者充分发挥的余地。 对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。 需求管理在开发周期中是自始至终存在的。需求管理必须始终保持更新。 需求管理同项目管理是密不可分的。 需求管理的任务 明确需求并达成共识； 建立关联，根据不同需求设计相应解决办法； 进行系统优化，提出设计方案； 监控和解决可能出现的问题以及需要做出的改变； 控制不同开发任务的开展； 对最终产品做出评测； 监控可能出现的重复开发； 提出项目实施时间表； 确定最终用户界面。 里程碑与项目管理 一项需求的满足就意味着一块里程碑的确立。 里程碑构造机制的基本方法之一就是进程管理 。 需求管理在开发周期中是自始至终存在的。需求管理必须始终保持更新，它构成了技术管理的基础。 需求管理同项目管理是密不可分的 。 需求管理模型 需求管理的主要活动 控制对需求基线的变动。 保持项目计划与需求一致。 控制单个需求和需求文档的版本情况。 管理需求和联系链之间的联系或管理单个需求和其它项目可交付品之间的依赖关系。 跟踪基线中需求的状态。 对待软件项目管理的组织必须确保做到以下几点： 在提交提议的需求变更之前要对其进行仔细的评估。 请合适的人员就需求变更做出周全合理的业务决策。 将已批准的变更传达给受此影响的所有人员。 项目以一致的方式将需求变更包含进来。 采用一致的变更控制方法，就可以避免相关问题，避免开发工作的返工和浪费时间等情况的发生。 变更控制委员会 变更控制委员会，有时也称为配置控制委员会(configuration control board，CCB)，已被证实是软件开发领域公认的最佳实践(McConnell 1996)。 CCB是由人组成的团体，可以由一个小组担任，也可以由多个不同的小组担任，这些人共同决定将哪些已提议的需求变更和新提议的特性在产品中付诸实现。 CCB也决定所报告的缺陷中哪些需要纠正，什么时候纠正。 CCB可以评审和批准对项目中任何基线工作产品所做的变更，项目需求文档只是其中的一个样例。 CCB的组成 CCB的成员应该能代表需要参与制定决策的所有小组，当然这些决策制定只能是在CCB的权力范围之内。 可考虑从下面这些部门中选择CCB代表： 项目或程序管理部门 产品管理或需求分析部门 开发部门 测试或质量保证部门 市场或客户代表 编写用户文档的部门 技术支持或帮助部门 配置管理部门 CCB规章 CC