软件需求工程考试复习资料：需求工程.docVIP

需求的分类 功能需求（Functional Requirement）： 和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。 性能需求（Performance Requirement）： 系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。 质量属性（Quality Attribute）： 系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。 对外接口（External Interface）： 系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。 约束 进行系统构造时需要遵守的约束，例如编程语言、硬件设施等 系统需求（System Requirement） 硬件需求（Hardware Requirement） 软件需求（Software Requirement） 其他需求 业务需求 系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统 为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature） 参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision） 特性说明了系统为用户提供的各项功能，它限定了系统的范围（Scope） 用户需求 执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么 直接用户 间接用户 对所有的用户需求，都应该有充分的问题域知识作为背景支持 特性 模糊、不清晰 多特性混杂 多逻辑混杂 系统需求 用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求 系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么 将用户需求转化为系统需求的过程是一个复杂的过程 首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型； 然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。 该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。 性能需求 速度（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秒内发出警报 质量属性 系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量 质量属性是为了度量质量要素而选用的特征 质量模型就是能够为质量需求的描述和评价提供工作基础的特征集及特征之间的联系 质量属性的重要性 对设计的影响很大 对越复杂的系统越为重要 [Robert19901] ：真实的现实系统中，在决定系统的成功或失败的因素中，满足非功能属性往往被满足功能性需求更为重要。 对外接口 解系统和其他系统之间的软硬件接口 接口的用途 接口的输入输出 数据格式 命令格式 异常处理要求 用户界面 利用专门的人机交互设计文档记录 约束 总体上限制了开发人员设计和构建系统时的选择范围 系统开发及运行的环境。 包括目标机器、操作系统、网络环境、编程语言、数据库管理系统等。 问题域内的相关标准。 包括法律法规、行业协定、企业规章等。 商业规则。 用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围 需求工程的路线 问题分析和背景分析 发现问题比发现需求要简单的多 进行背景分析，以更好的理解用户的问题 问题分析 明确问题。 定义业务需求。 制定解决方案。 确定系统特性。 需求获取 根据项目范围，确定问题域的范围 确定需求获取的源头 确定获取的主题和内容 选择需求获取的方法 围绕获取的内容，运用需求获取的方法，从源头获取需求 对获取过程中出现的分歧和问题，在项目前景的指导下进行解决 经过需求获取过程，可以得到获取