第二章 需求基础

2.1 需求的定义

IEEE的定义：

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

强调了需求两个不可分割的方面：

• 需求是以用户为中心的，是与问题相联系的
• 需求要被清晰、明确地写在文档上

2.2 满足需求就是解决问题

1. 问题与需求

   • 当现实的状况与人们期望中的状况产生差距时，就产生了问题

   • 要解决问题，就要改变这些事情、事物的状态，或者改变其状态变化的演进顺序，使其达到期望的状态和理想的演进顺序

   • 解决问题、改善现状、满足用户期望的条件和能力就是需求

2. 问题域与解系统

   1. 问题域

      软件系统只需要与现实世界中的一部分互动，即问题的发生地，也是问题解决的基本范围——解决问题必须设计的事物和事件，被称为问题域

      问题域是需求的背景，要理解需求要先理解问题域

      问题域的背景信息被称为问题域特性，他有自己的运行规律，不会因为解系统改变，是既定现实，可以改善不能忽视不能违背

   2. 解系统

      软件系统通过影像问题域帮人们解决问题，所以叫解系统，是软件解决方案在通用计算机上的实现

      解系统不是问题域的一部分，但是可以与问题域之间存在相互影响的借口，实现交互活动

   3. 问题域与需求

      需求是对问题域中的实体状态或事件的期望描述，应尽可能使用问题域的语言

   4. 解系统与需求规格说明

      解系统的核心是软件解决方案和解决方案在通用计算机上的实现

      需求工程所关心的仅仅是解决方案，不设计软件的实现部分

      解决方案被称为需求规格说明，定义了一个能够解决用户问题、满足用户需求的软件对外交互方案，是后续软件开发活动的工作基础

      • IEEE对规格的定义：以一种完全的精确的课验证的方法规定系统或不见的需求、设计、行为或者其他特性的文件，并经常指明判定这个规定是否满足的过程
      • IEEE对需求规格说明的定义：规定系统或不见的需求的文档，典型地包括功能需求、性能需求、接口需求、设计需求和开发标准
        

3. 问题解决的基础——模拟与共享现象

   问题域能够形成互动的基础是解系统部分模拟了问题域，被称为共享现象

   二者的交互性是人在意识中强制建立的，软件系统必须得到用户的认可，否则就会失去价值

   

   解系统也有一些并非来自于现实模拟的特征，不对应于任何问题域知识，却必不可少

4. 问题解决的方法——直接与间接

   1. 直接：模拟并操纵共享现象
   2. 间接：软件系统操纵共享现象影像问题域的一部分，然后利用问题域内在的规律性自动的影响另一部分

   选择直接还是间接，取决于其成本

5. 问题解决方案——需求规格说明

   需求规格说明主要包括两部分：

   • 对共享现象（模型）的描述——数据
   • 对系统对共享现象所施加的操作的描述——功能

6. 问题解决的困难性

   1. 不存在明确的问题域特性
   2. 不存在确定的针对定义良好的系统行为的评估标准
   3. 根据问题域特性和系统行为推测系统应用效果是简单的推理过程，但根据问题域特性和期望的系统应用效果构建系统行为的过程是困难的

   这些困难说明了需求工程的主要工作

   • 进行需求开发，确定用户的期望效果
   • 研究问题背景，描述问题域特性
   • 构建解系统，描述系统行为

2.3 需求和问题都有层次性

需求最常见的抽象层次有三层：

1. 业务需求：对整个业务的期望
2. 用户需求：针对具体任务的期望
3. 系统级需求：针对用户与系统一次交互的期望

1. 战略问题与业务需求

   1. 描述了系统的目标与收益
   2. 业务需求必须是可验证的，可以用数值验证，也可以根据有无验证
   3. 为了满足业务需求，定义系统特性，指出系统建立方向，各方达成一致建立共同前景。系统特性限定系统范围。

2. 任务问题与用户需求

   1. 用户需求就是执行实际工作的用户对系统所能完成的具体任务的期望，描述系统能够帮助用户做些什么
   2. 用户任务应该是有价值、有目标性的活动
   3. 用户需求特点：
      1. 模糊、不清晰
      2. 多特性混杂
      3. 多逻辑混杂
   4. 需要补充问题域知识

3. 系统行为问题与系统级需求

   1. 关注软件系统的行为，尤其是系统与外界的交互行为
   2. 比用户需求更加详细和准确，包含更多的技术细节
   3. 定义相应业务需求及用户需求的解决方案，构成需求规格说明的主体部分

4. 需求开发要遵从层次性

   

2.4 需求的分类与表述

1. 需求的分类

   1. 广泛意义的需求谱系

      

      • 项目需求：针对作为项目核心的计划，包括项目的成本、资源、时间和进度
      • 过程需求：针对软件开发过程，包括开发人员、工具和方法
      • 不切实际的需求：
        • 技术上不可行
        • 在有限的恶资源条件下不可行
        • 超出了软件所能影响的问题域范围

   2. 严格意义上的软件需求分类

      1. 功能需求：主要表现为系统和环境之间的行为交互
      2. 性能需求：系统整体或其组成部分应该拥有的性能特征
      3. 质量需求：系统完成工作的质量，如可靠性程度和可维护性程度
      4. 对外接口：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口和数据库接口等
      5. 约束：进行系统构造是需要遵守的约束，如编程语言和硬件设施等

      还可能出现逻辑数据需求等其他特殊类型的需求

      除功能需求外的其他4种需求被称为非功能需求，其中质量属性对系统影响极大

2. 功能需求

   1. 最常见和最重要的需求，也是最复杂的需求

   2. 功能需求是软件产品得以存在即原因，是软件系统能够解决用户问题和产生价值的基础，是整个软件开发工作的基础

   3. 三个抽象层次进行展开

      目标——任务——交互

3. 性能需求

   常见的性能需求

   1. 速度：系统完成任务的时间
   2. 容量：系统能够存储的数据量
   3. 吞吐量：系统在连续的时间内完成的事务数量
   4. 负载：系统可以承载的并发工作量
   5. 实时性：严格的实时要求

   定义要适合于运行环境，给予一定的灵活性或者不同层次的目标要求

   因为具有动态性所以将其划分为独立的类别，文档化为独立的部分

4. 质量属性

   1. 概念

      显式要求：功能需求

      隐式要求：非功能需求

      成功的软件系统必须满足显式的以及隐含的各种要求

      系统为满足显式的及隐含的要求而需要具备的要素称为质量，一般会对某些质量要素进行量化处理，建立质量特征，被称为质量属性

      质量属性包含性能需求

   2. 质量模型

3. 质量属性的重要性

   满足非功能属性往往比满足功能更为重要

   质量属性对设计的影响很大，软件设计必须根据需求的质量属性在多种方案中选择一个最优的方案

4. 质量属性需求的开发

   用户并不能明确地提出对铲平质量的期望

   用户在描述中使用的形容词和副词通常意味着质量属性的存在

   进行质量属性的定义时，应当将其与相联系的功能需求关联起来

5. 常见的质量属性需求

   1. 可靠性：在规定时间间隔内和规定条件下，系统或部件执行所要求功能的能力
   2. 可用性：软件系统在投入使用时可操作和可访问的程度，或能够实现其制定系统功能的概率
   3. 安全性：软件组织对其程序和数据进行未授权访问的能力
   4. 可维护性：为排除故障、改进质量或适应环境变化而修改软件系统的容易程度，包括可修改性、可扩展性
   5. 可移植性：系统或不见能从一种硬件或软件环境转换到另一种环境的特性
   6. 易用性：与用户使用软件所花费的努力及其对使用的评价相关的特性

6. 对外接口

   1. 对软硬件接口需要说明以下内容
      1. 接口的用途
      2. 接口的输入输出
      3. 数据格式
      4. 命令格式
      5. 异常处理要求
   2. 用户界面有时作为一种特殊的接口

7. 约束

   1. 是不受系统影响，却会给解系统带来极大影响的问题域特性。约束在总体上显示了开发人员设计和构建系统时的选择范围。

   2. 常见的约束：

      • 系统开的及运行的环境：包括计算机、操作系统、网络环境、编程语言和数据库管理系统
      • 问题域的相关标准：包括法律法规、行业协定和企业规章等
      • 商业规则
      • 社会性因素

   3. 规则描述样式与示例

7. 其他需求

   1. 安装需求

   2. 培训需求

   3. 数据需求

      其中数据需求最为常见

2.5 优秀需求的特性

1. 完备性

   优秀的需求不需要做更多的扩展就可以充分说明用户所需要的系统功能

   判断标准：需求是否描述了开发人员设计和实现这项功能所需的所有信息

   对不同类型的需求可以从不同的方面来保障需求描述的完备性

   1. 对功能需求要注意：

   

   2. 对数据需求（或功能描述中的数据内容）要注意：

   

   3. 对对外接口要注意

   
   

   4. 对质量属性（含性能）要注意

      

   5. 要注意与需求源头和相关事项的专家确认

2. 正确性

   每一项需求都必须正确描述所需要的系统功能，要真实反映用户的意图，又被称作真实性

   1. 难以达到正确性的原因

      • 用户在表达自己需要时，可能会在潜意识下进行一定的加工

        ——需求工程师要进行问题分析，尽力发现问题背后的问题

      • 人际交流中，信息会发生自然衰减，甚至扭曲，导致需求工程师理解的并非是用户所表达的

        ——再需求传递给开发人员之前，请提出需求的用户进行仔细检查和确认

   2. 发现真实需求的方法

      1. 多问用户“为什么”，将涉众的需求描述从具体环境、技术环境等约束中抽离出来，发现涉众更广范围和更高层次上的目标
      2. 从业务方面描述需求，而不是从技术方面描述需求
      3. 关注射中的想法
      4. 再演化中理解需求
      5. 通过量化手段准确理解需求

   3. 可行性

      需求必须能够在系统及其运行环境的已知条件和约束下实现

      不可行的需求被称为不切实际的期望，是实践中常见的需求定义问题，而且在很大程度上影响着项目的成败

   4. 必要性

      每一项需求都应该是必要的，它是满足用户的业务需求所必须的

      不必要的需求出现的原因：

      1. 用户用不需要的需求进退取舍来作为筹码
      2. 用户害怕遗漏信息，从而表达各种各样的需要
      3. 需求开发人员画蛇添足，添加“用户肯定会喜欢”的功能

   5. 无歧义

      需求能够正确传递知识的前提是传递者和受众能够形成共同的理解，因此每一项需求都应该有且只有能有一种解释

      通常在需求开发中要定义一个词汇表

   
   

   对于用户立场冲突的正确解决方法是在项目前景的指导下，醋精用户之间的协商解决

   6. 可验证性

      可以通过分析、检查、模拟或者测试等方法能够判断需求是否被满足

      不可验证的需求往往是因为描述模糊或过于抽象