AI总结
笔记总结与重点分析
笔记总结
本笔记系统阐述了软件需求的分类体系，重点解析了功能需求的层次性（业务/用户/系统需求）、性能需求的五大维度（速度/容量/吞吐量/负载/实时性）、ISO/IEC 9126质量模型（6大特征及其子特征）、对外接口类型以及开发约束条件。通过功能需求分层模型图展示了需求转化过程，并详细说明了各类需求之间的关联性。
重点/易考点分析 (名词解释)
功能需求的层次性包括哪些部分？
业务需求：系统建立的战略出发点，表现为高层次目标，描述组织开发系统的原因；用户需求：执行实际工作的用户对系统能完成具体任务的期望；系统需求：用户对系统行为的期望，定义需要实现的功能。
ISO/IEC 9126质量模型包含哪些主要特征？
功能性（精确性、依从性、互操作性、安全性、适合性）、易用性（可理解性、可学习性、可操作性、吸引性）、可靠性（成熟性、容错性、可恢复性）、效率（时间行为、资源行为）、可维护性（可分析性、可改变性、稳定性、可测试性）、可移植性（适应性、可安装性、共存性、可替换性）。
性能需求包含哪些方面？
速度（系统响应时间）、容量（数据存储量）、吞吐量（单位时间事务处理量）、负载（并发承载能力）、实时性（严格的时间要求）。
约束包含哪些主要内容？
系统开发及运行环境（目标机器/操作系统/编程语言等）、问题域相关标准（法律法规/行业协定）、商业规则（用户任务执行中的潜在限制）。
业务需求的定义及其特点是什么？
业务需求是系统建立的战略出发点，表现为高层次目标，描述组织开发系统的原因。其特点包括：需要明确定义系统特性（Feature），限定系统范围（Scope），要求参与方对解决方案达成一致以建立共同前景（Vision）。
用户需求的主要特性是什么？
模糊不清晰、多特性混杂、多逻辑混杂，需要用问题域知识作为背景支持，使用用户语言进行描述。
系统需求的核心定义是什么？
用户对系统行为的期望，通过一系列系统行为的联合实现用户需求，可直接映射为系统行为，明确定义开发人员需要实现的功能。
ISO/IEC 9126中的可靠性包含哪些子特征？
成熟性（缺陷导致故障的频率）、容错性（故障时维持性能的能力）、可恢复性（故障后重建性能的能力）。
对外接口需要描述哪些内容？
接口用途、输入输出、数据格式、命令格式、异常处理要求，以及专门的用户界面设计文档。
质量属性的开发难点体现在哪些方面？
用户难以明确量化质量要求，需要需求工程师通过功能需求关联性分析，利用形容词/副词线索发现潜在质量属性，并识别全局性质量需求。 （我还没有掌握有关知识，此回答为大模型自动生成）
需求的分类
- 功能需求（Functional Requirement）：
- 和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。
- 性能需求（Performance Requirement）：
- 系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。
- 质量属性（Quality Attribute）：
- 系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。
- 对外接口（External Interface）：
- 系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。
- 约束（Constraint）：
- 进行系统构造时需要遵守的约束，例如编程语言、硬件设施等
- 系统需求（System Requirement）：
- 硬件需求（Hardware Requirement），
- 软件需求（Software Requirement）
- 其他需求
功能需求
功能需求的层次性
业务需求
- 系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统
- 为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature）
- 参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision）
- 特性说明了系统为用户提供的各项功能，它限定了系统的范围（Scope）
需要采取的规则：
- **目标性功能：**具体，必要的条件限定和执行过程
- **无二义性：**陈述的问题有且仅有一种解释
用户需求
- 执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么
- 直接用户
- 间接用户
- 对所有的用户需求，都应该有充分的问题域知识作为背景支持（即，使用用户的语言描述需求）
- 特性
- 模糊、不清晰
- 多特性混杂
- 多逻辑混杂
系统需求
- 用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求
- 系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么
将用户需求转化为系统需求的过程是一个复杂的过程
- 首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型；
- 然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。
- 该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。
从功能需求的层次性看需求过程
性能需求
- 速度（Speed）
- 系统的响应时间，例如PR2.3.3-1。
- 所有的用户查询都必须在10秒内完成。
- 容量（Capacity）
- 系统所能存储的数据量，例如PR2.3.3-2。
- 系统应该能够存储至少10万条销售记录。
- 吞吐量（Throughput）
- 系统在连续的时间内完成的事务数量，例如PR2.3.3-3。
- 解释器每分钟应该至少解析5000条没有错误的语句。
- 负载（Load）
- 系统可以承载的并发工作量，例如PR2.3.3-4。
- 系统应该允许200个用户同时进行正常的工作。
- 实时性（Time-Critical）
- 严格的实时要求，例如PR2.3.3-5。
- 监测到病人异常后，监控器必须在0.5秒内发出警报。
质量属性
质量属性分类
- 系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量
- 质量属性是为了度量质量要素而选用的特征
- 质量模型就是能够为质量需求的描述和评价提供工作基础的特征集及特征之间的联系
- 质量属性的重要性
- 对设计的影响很大
- 对越复杂的系统越为重要
- [Robert19901]：真实的现实系统中，在决定系统的成功或失败的因素中，满足非功能属性往往被满足功能性需求更为重要。
ISO/IEC 9126
| 特征 | 子特征 | 简要描述 |
|---|---|---|
| 功能性 | 精确性 | 软件准确依照规定条款程度，规定确定了权利、协议的结果或者协议的效果 |
| 依从性 | 软件符合法定的相关标准、协定、规则或其他类似规定的程度 | |
| 互操作性 | 软件和指定系统进行交互的能力 | |
| 安全性 | 软件阻止对其程序和数据进行未授权访问的能力，未授权的访问可能是有意，也可能是无意的 | |
| 适合性 | 指定任务的相应功能是否存以及功能的适合程度 | |
| 易用性 | 可理解性 | 用户认可软件的逻辑概念和其适用性需要花费的精力 |
| 可学习性 | 用户为了学会使用软件需要花费的精力 | |
| 可操作性 | 用户执行软件操作和控制软件操作需要花费的精力 | |
| 吸引性 | 软件吸引用户的能力 | |
| 依从性 | 同上 | |
| 可靠性 | 成熟性 | 因软件缺陷而导致的故障频率程度 |
| 容错性 | 软件在故障或者外界违反其指定接口的情况下维持其指定性能水平的能力 | |
| 可恢复性 | 软件在故障后重建其性能水平、恢复其受影响数据的能力、时间和精力 | |
| 依从性 | 同上 | |
| 效率 | 时间行为 | 执行功能时的响应时间、处理时间和吞吐 |
| 资源行为 | 执行功能时使用资源的数量和时间 | |
| 依从性 | 同上 | |
| 可维护性 | 可分析性 | 诊断软件中的缺陷、故障的原因或者识别待修改部分需要花费的精力 |
| 可改变性 | 进行功能修改、缺陷剔除或者应付环境改变需要花费的精力 | |
| 稳定性 | 因修改导致未预料结果的风险程度 | |
| 可测试性 | 确认已修改软件需要花费的精力 | |
| 依从性 | 同上 | |
| 可移植性 | 适应性 | 不需采用额外的活动或手段就能适应不同指定环境的能力 |
| 可安装性 | 在指定的环境中安装软件需要花费的精力 | |
| 共存性 | 在公共环境中同分享公共资源的其他独立软件共存的能力 | |
| 可替换性 | 在另一个指定软件的环境下，替换该指定软件的能力和需要花费的精力 | |
| 依从性 | 同上 |
质量属性的开发
- 用户并不能明确地提出他们对产品质量的期望
- 并不了解软件系统的开发过程，也就无从判断哪些质量属性会在怎样的程度上给设计带来多大的影响，也无法将他们对软件系统的质量要求细化成可量化的质量属性
- 本章实例：具体表现为无法明确要求各级警员明确并准确地提出对该系统功能期望。
- 需求工程师
- 质量属性大都是和功能需求联系在一起的，因此需要对照软件的质量属性检查每一项功能需求，尽力去判断质量属性存在的可能性
- 形容词和副词通常意味着质量属性的存在
- 对于一些不和任何功能需求相联系的全局性质量属性，需求工程师要在碰到特定的实例时意识到它们的存在
对外接口
- 解系统和其他系统之间的软硬件接口
- 接口的用途
- 接口的输入输出
- 数据格式
- 命令格式
- 异常处理要求
- 用户界面
- 利用专门的人机交互设计文档记录
约束
- 总体上限制了开发人员设计和构建系统时
- 系统开发及运行的环境
- 包括目标机器、操作系统、网络环境、编程语言、数据库管理系统等。
- 问题域内的相关标准
- 包括法律法规、行业协定、企业规章等。
- 商业规则
- 用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围。
- 系统开发及运行的环境
