需求工程的内容

软件建立的依据

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

需求工程

概念

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

三个主要任务

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

需求工程的活动

需求开发过程模型

需求获取

  • 从⼈、⽂档或者环境当中获取需求的过程
  • 要利⽤各种⽅法和技术来“发现”需求
  • ⽬标分析
    1. 根据问题确定⽬标
    2. 通过分析利害关系⼈确定⽬标

需求获取的常见困难及解决方式

  • ⽤户和开发⼈员的背景不同，⽴场不同
    • 消除默认知识
  • 普通⽤户缺乏概括性、综合性的表述能⼒
    • 专业的需求人员
  • ⽤户存在认知困境
    • 原型
  • ⽤户越俎代庖
    • 需求是开发人员开发出来的，不是用户提出来的
    • 协商
  • 缺乏⽤户参与
    • 为用户参与提供方便

用户需求获取的方法

  • ⾯谈
  • 问卷
  • ⽂档分析
  • 头脑⻛暴
  • 专题讨论
  • 原型
  • ⺠族志
    • 走入用户的生活实际，与用户有充分的沟通交流
  • 竞品分析

需求分析

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

边界分析

  • 定义项⽬的范围
  • 系统边界的定义要保证系统能够和周围环境形成有效的互动
  • 系统⽤例图通常被⽤来定义系统的边界

需求建模

  • 建模是为展现和解释信息⽽进⾏的抽象描述活动
  • 常⽤的技术包括类图、顺序图、状态图等建模技术

需求规格说明

  • 在系统⽤户之间交流需求信息
  • 要简洁、精确、⼀致和易于理解
  • 需求⼯程师在这个阶段的重要⼯作包括:
    1. 定制⽂档模版
    2. 编写⽂档

需求验证

  • 需求规格说明⽂档⾄少要满⾜下⾯⼏个标准
    • ⽂档内每条需求都正确、准确的反映了⽤户的意图
    • ⽂档记录的需求集在整体上具有完整性和⼀致性
    • ⽂档的组织⽅式和需求的书写⽅式具有可读性和可修改性

验证的方法

  • 同级评审
  • 原型
  • 模拟

需求管理

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

需求基础

需求的定义

  • IEEE对需求的定义为[IEEE610.12-1990]
    1. ⽤户为了解决问题或达到某些⽬标所需要的条件或能⼒
    2. 系统或系统部件为了满⾜合同、标准、规范或其它正式⽂档所规定的要求⽽需要具备的条件或能⼒
    3. 对1或2中的⼀个条件或⼀种能⼒的⼀种⽂档化表述

需求的表述

  • 作为⼀种期望，需求通常被表述为“系统应该…”、 “在…时，系统应该…”、“⽤户可以通过系统…”等，例如R1
  • R1：系统应该允许顾客退回已经购买的产品

软件解决方案

  • 需求是⼀种解决问题后所能达到的期望
  • ⼀件事情的两⾯
    • 问题是糟糕的⼀⾯
    • 需求是理想的⼀⾯

需求开发的目标

需求

  • 是⼀种期望
  • 源⾃现实⼜⾼于现实
  • 需求是多变和可调整的，项⽬可以依据实际情况调整需求的实现程度

问题域

  • 现实世界运⾏规律的⼀种反映
  • 需求的产⽣地，也是需求的解决地
  • 最终的软件产品要在现实中部署，它能够部分影响问题域，但不能任意改变 现实
  • 软件开发必须尊重问题域，不能因为技术原因妄⾃修改现实世界的实际情况

问题的解决

  • 基础
    • 模拟与共享现象
  • ⽅法
    • 直接与间接
  • 解决⽅案
    • 需求规格说明

规格说明

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

需求层次性

业务需求

  • 系统建⽴的战略出发点，表现为⾼层次的⽬标（Objective），它描述了组织为什么要开发系统
  • 为了满⾜⽤户的业务需求，需求⼯程师需要描述系统⾼层次的解决⽅案，定义系统应该具备的特性（Feature）
  • 参与各⽅必须要对⾼层次的解决⽅案达成⼀致，以建⽴⼀个共同的前景（Vision）
  • 特性说明了系统为⽤户提供的各项功能，它限定了系统的范围（Scope）

用户需求

  • 执⾏实际⼯作的⽤户对系统所能完成的具体任务的期望，描述了系统能够帮助⽤户做些什么
    • 直接⽤户
    • 间接⽤户（通⽤软件的销售⼈员和售后⽀持⼈员）
  • 对所有的⽤户需求，都应该有充分的问题域知识作为背景⽀持
  • 特性
    • 模糊、不清晰（允许适度的⽤形容词和副词）
    • 多特性混杂 （功能和⾮功能的混杂）
    • 多逻辑混杂 （⼀个任务需要多次系统交互才能完成）

系统需求

  • ⽤户对系统⾏为的期望，每个系统级需求反映了⼀次外界与系统的交互⾏为，或者系统的⼀个实现细节
  • 描述了开发⼈员需要实现什么
  • 将⽤户需求转化为系统需求的过程是⼀个复杂的过程
    • ⾸先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建⽴系统的知识模型
    • 然后将⽤户需求部署到系统模型当中，即定义系列的系统⾏为，让它们联合起来实现⽤户需求，每⼀个系统⾏为即为⼀个系统需求
    • 该过程就是需求⼯程当中最为重要的需求分析活动，⼜称建模与分析活动

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

课堂练习

NBA数据分析应用

业务需求

媒体希望知道某支球队在未来某场比赛中的胜率
系统特征：获取球队相关信息、根据信息量化计算胜率

用户需求

  1. 系统应该允许用户选择对应的球队
  2. 系统应该允许用户选择对应的比赛场次
  3. 系统应该能够通过球队的过往战绩、近期球队舆论等信息，计算出球队的胜率
    需要补充的问题域知识：球队的教练、队员信息、过往战绩、该场比赛裁判信息、过往战术安排、球员近期社交媒体情况、社会舆论等等

系统级需求

  1. 系统提供一个选择系统，供用户选择对应球队
  2. 预测的比赛场次应当默认是该球队即将迎来的下一场比赛，用户也可自行选择该球队的后续比赛场次
  3. 用户确认后，系统获取数据库中信息，或对互联网信息进行爬取
  4. 对数据进行综合计算分析
  5. 将胜率以百分数形式返回给用户，并声明这只是理论预测，不一定与实际相符，呼吁用户不要参与非法赌球活动

需求分类

需求的图谱

需求的分类IEEE

功能需求（Functional Requirement）

和系统主要⼯作相关的需求，即在不考虑物理约束的情况下，⽤户希望系统所能够执⾏的活动，这些活动可以帮助⽤户完成任务。功能需求主要表现为系统和环境之间的⾏为交互

以下皆为非功能性需求

性能需求（Performance Requirement）

系统整体或系统组成部分应该拥有的性能特征，例如CPU使⽤率、内存使⽤率等

质量属性（Quality Attribute）

系统完成⼯作的质量，即系统需要在⼀个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等

对外接⼝（External Interface）

系统和环境中其他系统之间需要建⽴的接⼝，包括硬件接⼝、软件接⼝、数据库接⼝等等

约束

进⾏系统构造时需要遵守的约束，例如编程语⾔、硬件设施等

功能需求

  • 最常⻅、最主要和最重要的需求
  • 能够为⽤户带来业务价值的系统⾏为
  • 最需要按照三个抽象层次进⾏展开
  • 软件产品产⽣价值的基础

性能需求

  • 需要进⾏专⻔模拟和测试
    • 速度（Speed），系统完成任务的时间，例如PR1
      • PR1：所有的⽤户查询都必须在10秒内完成
    • 容量（Capacity），系统所能存储的数据量，例如PR2
      • PR2：系统应该能够存储⾄少100万个销售信息
    • 吞吐量（Throughput），系统在连续的时间内完成的事务数量，例如PR3
      • PR3：解释器每分钟应该⾄少解析5000条没有错误的语句
    • 负载（Load），系统可以承载的并发⼯作量，例如PR4
      • PR4：系统应该允许50个营业服务器同时从集中服务器上进⾏数据的上传或下载
    • 实时性（Time-Critical），严格的实时要求，例如PR5
      • PR5：监测到病⼈异常后，监控器必须在0.5秒内发出警报

需求的灵活性

  • PR6：98％的查询不能超过10秒
  • PR7：
    • （最低标准）在200个⽤户并发时，系统不能崩溃
    • （⼀般标准）在200个⽤户并发时，系统应该在80％的时间内能正常⼯作
    • （理想标准）在200个⽤户并发时，系统应该能保持正常的⼯作状态

质量属性

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

质量属性 - IOS/IEC 9126

常见质量属性

  • 可靠性（Reliability）：在规格时间间隔内和规定条件下，系统或部件执⾏所要求能⼒的能⼒
    • QA1：在进⾏数据的下载和上传中，如果⽹络故障，系统不能出现故障
  • 可⽤性（Availability）：软件系统在投⼊使⽤时可操作和可访问的程度或能实现其指定系统功能的概率
    • QA2：系统的可⽤性要达到98%
  • 安全性（Security）：软件阻⽌对其程序和数据进⾏未授权访问的能⼒，未授权的访问可能是有意，也可能是⽆意的
    • QA3：VIP顾客只能查看⾃⼰的个⼈信息和购买记录
    • 收银员只能查看，不能修改、删除VIP顾客的信息
  • 可维护性（Maintainability）：软件系统或部件能修改以排除故障、改进性能或其他属性或适应变更了的环境的容易程度，包括可修改性（Modifiability）和可扩展性（Extensibility）
    • QA4：如果系统要增加新的特价类型，要能够在2个⼈⽉内完成。
  • 可移植性（Portability）：系统或部件能从⼀种硬件或软件环境转换⾄另外⼀种环境的特性
    • QA5：集中服务器要能够在1⼈⽉内从Window 7操作系统更换到Solaris 10操作系统
  • 易⽤性（Usability）：与⽤户使⽤软件所花费的努⼒及其对使⽤的评价相关的特性
    • QA6：使⽤系统1个⽉的收银员进⾏销售处理的效率要达到10件商品/分钟

质量属性的开发

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

对外接口

  • 解系统和其他系统之间的软硬件接⼝
    • 接⼝的⽤途
    • 接⼝的输⼊输出
    • 数据格式
    • 命令格式
    • 异常处理要求
  • ⽤户界⾯

约束

  • 总体上限制了开发⼈员设计和构建系统时的选择范围
    • 系统开发及运⾏的环境
      • 包括⽬标机器、操作系统、⽹络环境、编程语⾔、数据库管理系统等
      • C1：系统要使⽤Java语⾔进⾏开发
    • 问题域内的相关标准
      • 包括法律法规、⾏业协定、企业规章等
    • 商业规则
      • ⽤户在任务执⾏中的⼀些潜在规则也会限制开发⼈员设计和构建系统的选择范围

数据需求

  • 功能需求的补充
    • 如果在功能需求部分明确定义了相关的数据结构，那么就不需要再⾏定义数据需求
  • 数据需求是需要在数据库、⽂件或者其他介质中存储的数据描述，通常包括下列内容：
    • 各个功能使⽤的数据信息
    • 使⽤频率
    • 可访问性要求
    • 数据实体及其关系
    • 完整性约束
    • 数据保持要求