1 需求工程

单纯的软件系统是不能解决问题的，它只有和现实世界之间形成有效互动才能实现问题的解决

需求工程的概念：所有需求处理活动的总和。它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终描述出软件被应用后与其环境互动形成的期望效应

需求工程的三个主要任务

1. 需求工程必须说明软件系统被应用的应用环境及其目标，说明用来达成这些目标的软件功能，也即要同时说明需要“做什么”和“为什么”需要做
2. 需求工程必须将目标和功能反映到软件系统当中，映射位可行的软件行为，并对软件行为进行准确的规格说明
3. 现实世界是不断变化的世界，因此需求工程还需要妥善处理目标和功能随着时间演化的变动情况

1.1 需求开发

1.1.1.1 需求获取

从人、文档或者环境当中获取需求的过程，要利用各种方法和技术来“发现”需求，需要根据问题来确定目标，通过分析利害关系人来确定目标。

用户需求获取的方法主要有：面谈、问卷、文档分析、头脑风暴、专题讨论、原型、民族志、竞品分析

1.1.1.2 需求分析

通过建模来整合各种信息，以使得人们更好的理解问题。位问题定义出一个需求集合，这个集合能够为问题界定一个有效的解决方案。检查需求当中存在的错误、遗漏、不一致等各种缺陷，并加以修正。

1.1.1.3 规格说明

需求规格说明是在系统用户之间交流需求信息，需要简洁、精确、一致和易于理解，需求工程师在这个阶段的重要工作包括：

1. 定制文档模版
2. 编写文档

1.1.1.4 需求验证

需求规格说明文档至少要满足下面几个标准：

1. 文档内每条需求都正确、准确的反映了用户的意图
2. 文档记录的需求集在整体上具有完整性和一致性
3. 文档的组织方式和需求书写方式具有可读性和可修改性

需求验证的方法主要有：同级评审、原型、模拟

1.2 需求管理

需求管理的作用主要有以下两点：

1. 保证需求作用的持续、稳定和有效发挥：在需求开发活动之后，设计、测试、实现等后续的软件系统开发活动都需要以围绕需求开展工作。
2. 进行变更控制：纳入和实现合理的变更请求，拒绝不合理的变更请求，控制变更的成本和影响范围

2 需求基础

什么是需求：IEEE对需求的定义为以下三点：

1. 用户为了解决问题或者达到某些目标所需要的条件或能力
2. 系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力
3. 对1或2中的一个条件或一种能力的一种文档化表述

需求的表述

作为一种期望，需要通常被表述为“系统应该…”、“在…时，系统应该…”、“用户可以通过系统…”等，例如：

系统应该允许客户退回已经购买的产品

需求是一种期望，源自现实又高于现实，需求是多变的可调整的，项目可以依据实际情况调整需求的实现程度。问题域是现实世界运行规律的一种反应，是需求的产生地也是需求的解决地。最终的软件产品要在现实中部署，它能够部分影响问题域，但不能任意改变现实。

软件开发必须尊重问题域，不能因为技术原因妄自修改现实世界的实际情况

规格说明是软件产品的方案描述，它以软件产品的运行机制为主要内容。它不是需求但实现需求，不是问题域但需要与问题域互动。规格说明要以关注对外交互的方式描述软件解决方案，它既需要从软件产品的角度而不是用户的角度进行描述，又不能太多地涉及软件产品的内部构造机制。

2.1 需求的层次性

需求分为三个层次，分别是：

1. 业务需求
2. 用户需求
3. 系统级需求

2.1.1 业务需求

业务需求是系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统。为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature）。参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision）。特性说明了系统位用户提供的各项功能，它限定了系统的范围（Scope）

例：R2：在系统使用3个月后，销售额度应该提高20%（单纯的一种从业务角度的期望，并没有从软件角度来描述软件应该实现成什么样）

可以建立高层次的解决方案，其系统特性如SF1～SF4所示：

SF1：管理VIP顾客信息

2.1.2 用户需求

用户需求是执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么（这里的用户可能是直接用户或者间接用户，间接用户指通用软件的销售人员和售后支持人员）。

对所有的用户需求，都应该有充分的问题域知识作为背景支持，用户需求有如下的特性：

1. 模糊、不清晰（允许适度的用形容词和副词）
2. 多特性混杂（功能和非功能的混杂）
3. 多逻辑混杂（一个任务需要多次系统交互才能完成）

例：SF1：管理VIP顾客信息。

针对每一个系统特性，都可以建立一组用户需求。例如对SF1，可以建立用户需求组如UR1.1 ～ UR1.7，它们中每一条都是用户完成具体任务所需要的功能

UR1.1：系统应该允许客户经理添加、修改或者删除会员个人信息

2.1.3 系统需求

系统需求是用户对系统行为的期望，每个系统级需求反映了一次外界与系统的交互行为，或者系统的一个实现细节。它描述了开发人员需要实现什么。

将用户需求转化为系统需求的过程是一个复杂的过程

• 首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型；
• 然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求
• 该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动

例：UR1.3：系统应该允许客户经理查看会员的个人信息和购买信息

对用户需求UR1.3，可以依据任务中的交互细节将之转化为系统级需求SR1.3.1 ～ SR1.3.4
SR1.3.1：在接到客户经理的请求后，系统应该为客户经理提供所有客户的个人信息

需要注意的是：需求主要是描述用户对系统的期望，它以系统与外界的交互为主，所以即使是系统级需求也尽可能不要涉及系统的内部构造细节，例如方法、参数、按钮、菜单、界面布局等。

3 需求分类

项目需求

R5：项目的成本要控制在60万元人民币以下
R6：项目要在6个月内完成

过程需求

R7：在开发中，开发者要提交软件需求规格说明文档、设计描述文档和测试报告
R8：项目要使用持续集成方法进行开发

其它需求

R9：系统要购买专用服务器，其规格不低于…
R10：系统投入使用时，需要对用户进行一个星期的集中培训

不切实际的期望

3.1 需求的分类

软件需求的分类主要有以下几个：

1. 功能需求（Functional Requirement）：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的交互
2. 数据需求：数据需求是需要在数据库、文件或者其他介质中存储的数据描述。（数据需求如果再功能需求中描述了就不需要再单独描述）
3. 非功能需求
   1. 性能需求（Performance Requirement）：系统整体或系统组成部分应该拥有的性能特性，例如CPU使用率、内存使用率等。
   2. 质量属性（Quality Attribute）：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。
   3. 对外接口（External Interface）：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。
   4. 约束：进行系统构造时需要遵守的约束，例如编程语言、硬件设施等。

3.2 功能需求

• 最常见、最主要和最重要的需求
• 能够为用户带来业务价值和系统行为
• 最需要按照三个抽象层次（即业务需求、用户需求、系统级需求）进行展开
• 软件产品产生价值的基础

3.3 性能需求

需要进行专门模拟和测试，比如速度、容量、吞吐量、负载、实时性等

PR1：所有的用户查询都必须在10秒内完成
PR2：系统应该能够存储至少100万个销售信息

可以分为最低标准、一般标准和理想标准

3.4 质量属性

系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量。质量属性时为了度量质量要素而选用的特征，质量模型就是能够为质量需求的描述和评价提供工作基础的特征集及特征之间的联系。

比如可移植性、可维护性、功能性、可靠性、可用性等

3.4.1 可靠性

可靠性是指在规格时间间隔内和规定条件下，系统或部件执行所要求能力的能力。

QA1：在进行数据的下载和上传中，如果网络故障，系统不能出现故障

3.4.2 可用性

软件系统在投入使用时可操作和可访问的程度或能实现其制定系统功能的概率

QA2：系统的可用性要达到98%

3.4.3 安全性

软件阻止对其程序和数据进行未授权访问的能力，未授权的访问可能是有意，也可能是无意的。

QA3：VIP顾客只能查看自己的个人信息和购买记录

3.4.4 可维护性

软件系统或部件能修改以排除故障、改进性能或其他属性或适应变更了的环境的容易程度，包括可修改性（Modifiability）和可扩展性（Extensibility）。

QA4：如果系统要增加新的特价类型，要能够在2个人月内完成

3.4.5 可移植性

系统或部件能从一种硬件或软件环境转换至另外一种环境的特性

3.4.6 易用性

与用户使用软件所花费的努力及其对使用的评价相关的特性

3.4.7 质量属性的开发

用户并不能明确地提出他们对产品质量的期望，大多数用户并不了解软件系统的开发过程，也就无从判断哪些质量属性会在怎样的程度上给设计带来多大的影响，也无法将他们对软件系统的质量要求细化成一组组的可量化的质量属性

需求⼯程师

质量属性⼤都是和功能需求联系在⼀起的，因此需要对照软件的质量属性检查每⼀项功能需求，尽⼒去判断质量属性存在的可能性。形容词和副词通常意味着质量属性的存在，对于⼀些不和任何功能需求相联系的全局性质量属性，需求⼯程师要在碰到特定的实例时意识到它们的存在

3.5 对外接口

了解系统和其它系统之间的软硬件接口，包括：

1. 接口的用途
2. 接口的输入输出
3. 数据格式
4. 命令格式
5. 异常处理要求

用户界面也是一种对外接口

3.6 约束

约束在总体上限制了开发人员设计和构建系统时的选额范围，比如系统开发及运行的环境、问题域内的相关标准、商业规则等

3.7 数据需求

数据需求是功能需求的补充，如果在功能需求部分明确定义了相关的数据结构，那么就不需要再定义数据需求。数据需求是需要在数据库、文件或者其他介质中存储的数据描述，通常包括下列内容：

1. 各个功能使用的数据信息
2. 使用频率
3. 可访问性要求
4. 数据实体及其关系
5. 完整性约束
6. 数据保持要求

Reference

1. 南京大学软件学院2022春季学期《软件工程与计算二》