04需求工程资料.pptVIP

4.6 定义软件的质量属性 需要引起重视的是：在需求规格说明书中，定量地描述用户期望的质量属性，能够起到约束设计，提高质量，从而提高用户满意度的作用。 福州大学 亓晓静 * 交易系统要求在交易时间内系统的有效性达到99.95%。 有效性 网站在高峰期，能够应对自如。高效性 一个具有6个月以下开发经验的软件维护人员能够在4个小时之内为系统添加一个统计报表（数据项不超过20项，表不超过5个） 灵活性/可修改性 只有具有查账特权的用户才能够进行库存统计查询。 安全性 由于软件失效引起的库存成本计算错误的概率不能超过千分之一。 可靠性 福州大学 亓晓静 * 当远程用户向中心数据库发送信息被线路故障中断后，系统每隔10秒重新连接一次中心数据库，直到数据库被连接上，然后重新发送所有要发送的信息。 健壮性 软件的操作菜单必须有热键。 易用性 一个新用户经过不到30分钟的环境适应就可以进行基本的查询操作。 代码与注释的比例为2:1。 可维护性 尽量不使用运行环境提供的库函数。可移植性 一个模块的最大循环复杂度不能超过20。 可测试性 福州大学 亓晓静 * 属性之间的影响关系 福州大学 亓晓静 * 4.7 需求优先级 需求优先级：P85 高 中 低 用户 需求实现的受益程度，失败造成的损失程度 开发人员 实现需求的费用和可能的风险 福州大学 亓晓静 * 4.8需求验证 两种需求评审方法 需求评审的步骤 审查人员的职责 福州大学 亓晓静 * 4.9需求管理 1.管理需求变更 2.需求跟踪与回溯 福州大学 亓晓静 * 例 一个5人的项目组，有1人负责数据库开发，4人负责应用程序开发，因为某项需求的变化，数据库开发人员修改了数据库表的内容，但是没有及时将变更通知应用程序开发人员，导致4个人编写了一周的程序全部重写。 福州大学 亓晓静 * 例 测试人员在进行产品测试时发现了大量的问题，经过调查发现开发人员使用了变更后的需求规格说明书，而变更没有通知测试人员，导致测试人员的测试用例无法使用。 福州大学 亓晓静 * 例 在每周项目检查例会上，项目经理问一名开发人员：“你本周的工作计划完成了吗？” 我没有按计划完成我的工作，因为用户打电话要我增加一个由入库单到合同单的确认，我原来认为这件事情比较简单，就没有让他申请需求变更。而我在添加这项功能的过程中意识到相关联的地方太多，一会这里有问题，一会那里有问题，越来越乱，我自己都被搞晕了 福州大学 亓晓静 * 需求变更可能影响的开发活动和文档 福州大学 亓晓静 * 结论 几乎所有项目都会有需求变更 降低需求变更的影响 控制需求变更的过程 减少因需求变更带来的风险 福州大学 亓晓静 * 1.管理需求变更 变更控制委员会 组成：P88 负责评估变更的影响，决定是否批准变更 专人管理 负责变更请求的受理等事务性工作 流程 受理 评估 实施 福州大学 亓晓静 * 变更请求 变更原因 变更内容 变更可能影响的软件元素 变更工作量统计 变更影响分析报告 变更控制委员会 需求变更问题表 福州大学 亓晓静 * 2.需求跟踪与回溯 每项需求可能与其他元素相关 其他需求 其他设计部件 源程序模块 测试用例 文档 跟踪 了解与每个需求有关的其他元素有哪些 回溯 最终的设计模块、代码段、测试对应哪个需求 福州大学 亓晓静 * 需求跟踪能力矩阵 福州大学 亓晓静 * * 因为需求是开发的基础，所以需要严谨。 这些需求陈述的约束，对开发人员而言是可以接受的，但对于用户而言显得苛刻。 因此有需求分析师，负责分析用户的陈述，将其表达成有效的需求。并且除了文字之外，还配上各种模型。 而用户的陈述往往凌乱、非系统化，所以系统分析员还必须依靠对业务知识的学习和以往经验的积累，来完成任务。 * 书中的业务需求，实际上是问题的初步定义，很笼统，仅是一个目标要求 用户需求，最终用户想用该软件做什么，但用户的表述凌乱、冗余 功能需求，软件分析人员表达的系统必须实现的功能，开发人员据此进行设计与编码 * 最终需求，除了功能需求外，还包括许多非功能性需求 * * 有时，系统的业务需求就是问题的定义，一个初步的想法。两个简单例子进行说明 * 初步看到涉及到的业务有：基金交易、申购与赎回、网上交易 但并不全面，要通过了解确定拟建系统涉及哪些业务，在下一章的例子 * 初步看到涉及到的业务有：图书馆藏书管理、借阅管理、网上查询 但并不全面，要通过了解确定拟建系统涉及哪些业务，在下一章的例子 * 初步看到涉及到的业务有：成绩管理、学生信息、课程管理、教师管理、专业管理