需求工程过程.pptVIP

2 需求和各涉众组 当软件开发团队变更其需求过程时，与其他项目涉众进行沟通的接口也会发生变化。 下面列出了可能会遇到的一些抵制情况： 变更控制过程可能会被看作是开发工作的障碍而被丢弃，因此变更工作很难实施。 有些开发人员认为编写和评审需求文档纯粹是浪费时间的官僚做法，妨碍他们的“真正”工作，即编写代码。 如果用于客户支持的费用与开发过程没有联系，那么开发团队可能会缺少变更需求的动力 。 如果改进需求过程的目标之一是通过创建高质量的产品来减少技术支持费用，那么技术支持经理可能会感到很不安 。 忙碌的客户有时会声称，他们没有时间去从事需求工作 。 第二十九页，共四十三页，2022年，8月28日 3 软件过程改进的基本原则 应该牢记下面4条软件过程改进的原则(Wiegers 1996a)： 1.过程改进应该是不断演化的、连续的、周期性的 不要期望一次就能改进全部过程，要知道在第1次尝试变更时，可能无法解决所有问题。 2.只有人们和组织具有变更的动机时才可能实施变更 下面列出了一些典型的问题，也许能为需求过程的变更提供驱动力： 项目超出了最后期限，原因是需求比预期的扩展了很多，也复杂了很多。 开发人员频繁加班，原因是直到开发后期才发现了引起误解的需求和表达不明确的需求。 系统测试工作前功尽弃，原因是测试人员并没有弄清楚产品应该做什么。 虽然正确的功能都实现了，但是用户不满意，这是由于性能不好、易使用性差或存在其他质量缺陷。 维护费用很高，因为客户的对产品的许多增强要求没有在需求获取阶段确定下来。 开发组织名誉受损，因为客户不接受交付的软件。 第三十页，共四十三页，2022年，8月28日 3.过程变更要有的放矢 在开始运用更好的过程之前，一定要明确变更的目标是什么(Potter and Sakry 2002)。 4.将改进活动视作小型项目 项目的总体计划应该包括过程改进的资源和任务。与所有项目一样，改进项目也要执行计划、跟踪、测量和报告，只是规模相应地缩小了。 第三十一页，共四十三页，2022年，8月28日 第一页，共四十三页，2022年，8月28日 迭代模型与瀑布模型的差别 第二页，共四十三页，2022年，8月28日 需求开发过程 需求开发是一个迭代的过程 第三页，共四十三页，2022年，8月28日 需求工程的推荐方法 列出了近50种方法，分别属于7个类型，它们可以帮助大部分项目开发团队更好地完成他们的需求工作。 第四页，共四十三页，2022年，8月28日 知 识 需求管理 项目管理 培训需求分析员 对用户代表和管理者进行需求培训 对开发者进行应用领域相关的培训 创建术语表 定义需求变更控制进程 成立变更控制委员会 分析需求变更的影响 控制需求版本并为其建立基线 维护需求变更的历史记录 跟踪每项需求的状态 衡量需求稳定性 使用需求管理工具 创建需求跟踪矩阵 选择合适的开发周期 根据需求制订项目计划 重新协商权利或义务 管理需求风险 跟踪需求耗费的人力物力 回顾以往的教训 需求获取 需求分析 编写规格说明 需求验证 定义需求开发过程 定义项目前景和范围 确定用户群 选择用户代言人 建立核心队伍 确定用例 确定系统事件和响应 举行进一步需求获取的讨论 观察用户如何工作 检查问题报告 重用需求 绘制关联图 创建原型 分析可行性 确定需求优先级 为需求建模 创建数据字典 将需求分配至各子系统 应用质量功能调度 采用SRS模板 确定需求来源 惟一标识每项需求 记录业务规范 定义质量属性 审查需求文档 测试需求 确定合格标准 第五页，共四十三页，2022年，8月28日 知 识 技 能 开发者也应该了解产品应用领域中的基本概念和术语。 培训需求分析员 所有将要成为分析员的团队成员都应该接受需求工程方面的基本培训。 熟练的需求分析员应具备以下特点： 耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工程技术。 对用户代表和管理者进行软件需求培训 参与软件开发的用户应该接受一到两天的需求工程方面的培训。 对开发人员进行应用领域的相关培训 为了帮助开发人员对应用领域有一个基本的理解，可以安排一个研讨课程，内容是客户的业务活动、术语和产品的目标。 创建项目术语表 定义应用领域专业名称的术语表可以减少误解。 第六页，共四十三页，2022年，8月28日 需求获取 需求获取(requirement elicitation)是需求工程的主体。对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。 需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。 需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个