SRE02-需求工程概述.pptVIP

SRE02-需求工程概述 内容 软件需求定义 需求工程定义 软件需求类型 软件需求属性 软件需求开发主要困难与对策 一 软件需求定义 软件需求定义 什么是软件需求？ 待开发软件产品的目标用户对该软件产品的功能、性能、设计约束和其它方面的期望和要求 说明 目标用户 实际操作该软件的用户(图书管理员) 用户方的负责人 用户代表(市场经理)，…… 必须是用户所需的 例如，网上图书借阅(想法很好，用户不需要，也不现实) 软件需求定义 关于软件需求的注意事项 软件需求关注用户的期望、要求和需要，不是解决方案 要区分what和How 例如，要采用什么算法，不是用户需求 并不是所有方面的要求都是软件需求 例如，重量、软件大小等不是用户需求 并不是所有用户的期望和要求都是软件需求 用户需求必须中肯，有意义 例如，记录图书的厚度等不是用户需求 软件需求定义 软件需求的表现形式 功能需求 性能需求 易用性、质量、性能、安全性，移植性、可重用性等 设计约束 运行环境 开发环境 其它要求：如开发周期 需求类型模型 用例模型的主要元素 角色 角色描述 用例 用例描述 简要说明、前置条件、主事件流、备选事件流、后置条件 用例之间的关系(使用、扩展、泛化) 用例模型的UML可视化 用例图 可视化角色、用例、用例关系和系统边界 活动图 可视化用例事件流的结构 顺序图 可视化用例事件流的(动作序列)交互过程，分解对象、消息和动作 类图 可视化用例实体结构关系 4 非功能性需求 大约有八类非功能性需求： 观感需求： 易用性需求： 性能需求： 可操作性需求： 可维护性和可移植性需求： 安全性需求： 文化和政策需求： 法律需求： 60 * 非功能性需求 非功能性需求 非功能性软件需求典型地用来表示详细描述定义中的“系统的属性”或者“系统环境的属性”。 非功能性软件需求主要包括和归纳为以下四种： (1).易用性 (2).可靠性 (3).性能 (4).可维护性 60 * (1) 易用性需求 描述系统可以被预想的用户学习和操作的简单性非常重要。可用性需求可包含如下子类别： 人员因素 美观 用户界面的一致性? 联机帮助和环境相关帮助 向导和代理 用户文档 培训材料和培训时间 易用性需求 例如： 指出普通用户和高级用户要高效地执行特定操作所需的培训时间 指出在符合公认的可用性标准方面的需求 60 * (2) 可靠性需求 可靠性需求应该描述系统到底以哪种用户能够接受的程度运转。 需要考虑的可靠性需求有： 可用性 平均故障间隔时间（MTBF） 平均修复时间 准确性 错误和缺陷率 每类错误 平均故障间隔时间 通常以小时为单位指定,也可以以天、月或年为单位指定。 要强调的是,这需要精确:需求必须仔细地定义什么是故障。 平均修复时间 允许系统出故障后不运转的时间有多长? 例如,用户可能会规定90%的系统故障要在5分钟内可修复,99.9%的系统故障要在一小时内修复 在这里,精确仍然非常重要:需求必须指明修复是否意味着所有用户都可以再一次访问所有服务或者是否完全恢复的子集是可接受的 准确性 产生数字输出的系统要求有多高的精确度?例如,金融系统的结果必须准确到分还是厘? (3) 性能需求 性能需求可对功能性需求强加条件。 性能需求通常包括以下几类: 事务的响应时间:平均值,最大值。 吞吐量:每秒事务数。 容量:系统可容纳的客户总数或事务数。 退化模式:当系统被降级时,可接受的运转模式。 如果新的系统必须和其他系统用共享硬件资源,则还要对系统到底能够在多大程度上文明地使用类似CPU、内存、信道、磁盘空间以及带宽等稀有资源加以规定。 性能需求 速度（Speed），系统的响应时间，例如PR2.3.3-1。 PR2.3.3-1：所有的用户查询都必须在10秒内完成。 容量（Capacity），系统所能存储的数据量，例如PR2.3.3-2。 PR2.3.3-2：系统应该能够存储至少10万条销售记录。 吞吐量（Throughput），系统在连续的时间内完成的事务数量，例如PR2.3.3-3。 PR2.3.3-3：解释器每分钟应该至少解析5000条没有错误的语句。 负载（Load），系统可以承载的并发工作量，例如PR2.3.3-4。 PR2.3.3-4：系统应该允许200个用户同时进行正常的工作。 实时性（Time-Critical），严格的实时要求，例如PR2.3.3-5。 PR2.3.3-5：监测到病人异常后，监控器必须在0.5秒内发出警报。 从用例角度识别性能指标体系 评估性能风险 确定关键用例 选择关键性能场景 建立性能目标 增加软件资源需求 增加计算机资源需求 验证和确认模型 修改产品构思 修正性能目标 60 * (4) 可维护性需求 可维修性是指为了升级或