软件需求分析——需求的理论基础

Posted 2022-12-10 _瞳孔

如果有兴趣了解更多相关内容，可以来我的个人网站看看：瞳孔空间

一：需求的涵义

研究对象：软件加强型系统中的软件

软件加强型系统：泛指由计算机技术支持的互相联系着的一组人类活动组成的系统。与物理设备和人类社会活动相关。比如：游戏软件与物理设备、用户ERP(企业资源计划)系统与组织运作过程

需求的定义：

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

问题域与解系统：

• 软件系统与外部环境
  
• 当现实的状况与人们期望的状况产生差距时，就产生了问题
• 要解决问题，就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序
• 这些实体和状态构成了问题解决的基本范围，称为该问题的问题域（Problem Domain）
• 软件系统通过影响问题域，能够帮助人们解决问题，称为解系统
  

共享现象：软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分的具有模拟特性。换句话说，软件系统当中含有问题域某些部分的模型（或模拟），常见的模型包括数据模型、对象模型、处理模型等。问题域中的某些信息能够和模型中的信息建立映射关系，这些通过映射建立的共同知识，就是问题域和解系统之间的共享现象

需求：需求是用户对问题域当中的实体状态或事件的期望描述。包括直接需求与间接需求。
例如：

• 一旦书籍被借出，在归还之前它不能被再次借阅
• 在归还的书超过30天的归还期限时，归还后应该进行超期处罚
  

规格说明：规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征

• 主要包括两个部分
  • 对共享现象（模型）的描述
  • 系统对共享现象所施加的操作的描述
• 也可以看作是一种需求
  • 完全针对系统行为发出的期望
  • 一种理想的、完全不需要进行任何额外努力即可转换为系统行为的需求
    

问题域特性：问题域自治的规律性称为问题域特性，包括结构特性和行为特性等

• 问题域特性的重要性
  • 要想解决问题，它就需要了解问题域特性，将解决方案和问题域特性结合起来
  • 要防止解系统的引入在问题域当中引发未预见的连锁反应
• 需要关注的问题域特性
  • 间接约束
  • 约束和假设

从问题域、需求和规格说明的关系看需求工程：设描述明确的问题域特性为E，定义良好的系统行为为S，预期的需求为R，

• 需求工程的目的就是根据E，构建S，使得E，S -> R。
• 需求工程的困难之处
  • 不存在描述明确的E
  • 不存在确定的针对S的评估标准R
  • E, R => S是一个创造性的过程
• 需求工程的主要工作
  • 需求开发，确定R
  • 研究问题背景，描述问题域特性E
  • 构建解系统，描述解系统行为S，使得E, S => R

二：需求的类型

2.1：分类方式

有以下分类方式：

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

三类问题和三种需求变化方式：

• S类型程序（可说明的）
  • 问题能够被形式地和完全地陈述出来
  • 接受：按照这个规格说明，这个程序是正确的吗
  • 这种软件不会进化，对规格说明的改变定义一个新的问题，因而是新的程序
• P类型程序（问题求解）
  • 现实世界问题的不精确陈述
  • 接受：对这个问题来说，这个程序是一个可以接受的解决方案吗
  • 这种软件很可能要连续地进化
    • 因为这个方案是决不会完美的，并且是能够被改进的
    • 因为现实世界要变化，所以这个程序也要变化
• E类型程序（被嵌入的）
  • 一个变成它建模世界的一部分的系统
  • 接受：完全依赖于观点和判断
  • 这个软件是固有的进化的，软件和世界的变化相互影响

2.2：功能需求

功能需求具有层次性：

业务需求：

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

用户需求：

• 执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么
  • 直接用户
  • 间接用户
• 对所有的用户需求，都应该有充分的问题域知识作为背景支持
• 特性
  • 模糊、不清晰
  • 多特性混杂
  • 多逻辑混杂

系统需求：

• 用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求
• 系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么
• 将用户需求转化为系统需求的过程是一个复杂的过程
  • 首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型
  • 然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求
  • 该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动

从功能需求的层次性看需求开发：

2.3：性能需求

速度(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秒内发出警报

2.4：质量属性

• 系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量
• 质量属性是为了度量质量要素而选用的特征
• 质量模型就是能够为质量需求的描述和评价提供工作基础的特征集及特征之间的联系
• 质量属性的重要性
  • 对设计的影响很大
  • 对越复杂的系统越为重要
  • [Robert19901]：真实的现实系统中，在决定系统的成功或失败的因素中，满足非功能属性往往被满足功能性需求更为重要

质量属性的开发：

• 用户并不能明确地提出他们对产品质量的期望。并不了解软件系统的开发过程，也就无从判断哪些质量属性会在怎样的程度上给设计带来多大的影响，也无法将他们对软件系统的质量要求细化成一组组的可量化的质量属性
• 需求工程师
  • 质量属性大都是和功能需求联系在一起的，因此需要对照软件的质量属性检查每一项功能需求，尽力去判断质量属性存在的可能性
  • 对于一些不和任何功能需求相联系的全局性质量属性，需求工程师要在碰到特定的实例时意识到它们的存在

2.5：对外接口

解系统和其他系统之间的软硬件接口：

• 接口的用途
• 接口的输入输出
• 数据格式
• 命令格式
• 异常处理要求

用户界面：利用专门的人机交互设计文档记录

2.6：约束

总体上限制了开发人员设计和构建系统时的选择范围

• 系统开发及运行的环境：包括目标机器、操作系统、网络环境、编程语言、数据库管理系统等
• 问题域内的相关标准：包括法律法规、行业协定、企业规章等
• 商业规则：用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围

三：需求工程的路线

问题分析和背景分析

• 发现问题比发现需求要简单的多
• 进行背景分析，以更好的理解用户的问题
• 问题分析
  • 明确问题
  • 定义业务需求
  • 制定解决方案
  • 确定系统特性

需求获取

• 根据项目范围，确定问题域的范围
• 确定需求获取的源头
• 确定获取的主题和内容
• 选择需求获取的方法
• 围绕获取的内容，运用需求获取的方法，从源头获取需求
• 对获取过程中出现的分歧和问题，在项目前景的指导下进行解决
• 经过需求获取过程，可以得到获取的文档资料，其中以获取笔录为主

需求分析

• 建立一个综合考虑了问题域特性和需求的系统模型
• 根据系统模型将用户需求转化为系统需求

文档化和验证

• 产生规格说明
• 进行验证

四：优秀需求的特性

完整性：

• 不需要做更多的扩展就可以充分的说明用户所需要的系统功能
• 每一个需求的描述都应该包含开发人员设计和实现这项功能需要的所有信息

正确性

• 真实的反映用户的意图
• 必须请需求的提出者予以确认

精确性

• 描述仅包含必要的信息
• 简洁、清晰

可行性

• 由开发人员进行检查
• 需要进行一定的分析和研究，而不是单纯的凭借经验和直觉
• 必要的时候要通过开发原型来加以验证

必要性

• 满足用户的业务需求所必需的

无歧义

• 每一项需求都应该有而且只能有一种解释
• 定义一个可以共同理解的词汇表

可验证

• 通过分析、检查、模拟或者测试等方法能够判断需求是否被满足
• 不可验证的需求往往是因为描述模糊或者过于抽象，所以在进行需求的描述时要
  • 让需求具体化
  • 小心形容词和副词的使用
  • 避免程度词的使用

五：常见的需求错误

需求并没有反映用户的真实需要

• 用户在表达自己的需要时，可能会在潜意识下进行一定的加工
• 在人际交流当中，信息会发生自然的衰减，甚至扭曲（应对方案：检查和确认）

模糊和歧义的需求

• 无意中写出模糊和歧义的需求定义往往是因为选词造句不当（应对方案：为项目中重要的词汇建立一个公共的可共同理解的词汇表）
• 有意产生的模糊和歧义的需求定义往往是为了应付对需求持有不同立场的用户（应对方案：在项目前景的指导下，促进用户之间的协商解决）

明显的信息遗漏

• 明显的信息遗漏，其主要原因在于项目的范围定义不当（应对方案：加强对业务需求的处理）
• 不明显的信息遗漏，往往是因为相关信息难以发现（应对方案：靠需求工程师的经验来加以避免）

不必要的需求

• 用户将之作为和开发人员谈判的筹码
• 用户在交流当中，用户总是倾向于表达各种各样的需要（应对方案：根据业务需求进行用户需求的过滤和选择）
• 需求开发人员“画蛇添足”（应对方案：保持以用户为中心）

不切实际的期望

• 用户并不掌握关于软件系统构建的相关技术知识，所以用户可能会提出一些已有软件技术无法实现的期望（应对方案：软件开发者提供可行性、成本等足够的技术参考信息，帮助用户对其进行取舍和调整）