<软件工程>1 需求规约

SE0 软件工程

软件工程概念的提出，目的是倡导以工程的原理、原则和方法进行软件开发，以期解决出现的 “软件危机”

软件危机的典型表现：

• 对软件开发成本和进度估算不准确
• 用户常常对软件系统不满意
• 软件产品质量靠不住
• 软件常常是不可维护的
• 软件通常没有适当的文档资料
• 软件成本在计算机系统的总成本占比上升
• 软件开发生产提高的速度跟不上计算机应用普及的速度

软件危机中，人们提出的很多问题至今仍在困扰着人们。包括：如何缩短开发周期、如何控制开发成本、如何保证产品质量、如何提供产品维护

消除软件危机的方法：

• 对计算机软件有正确认识
• 借鉴各种工程项目积累的原理、概念、技术和方法
• 开发和使用计算机辅助开发工具
• 探索更高效的管理措施对开发过程进行控制和管理

软件工程：是指导计算机软件开发和维护的工程学科。用工程管理的原则、方法，结合应用计算机科学理论、技术，按预算和进度开发高质量可维护的软件。

软件工程的基本原理

• 用分阶段的生命周期计划严格管理
• 坚持进行阶段评审
• 实行严格的产品控制
• 采用现代程序设计技术
• 结果应能够清楚地审查
• 开发小组的人员少而精
• 承认不断改进软件工程实践的必要性

# 软件开发的本质

计算机软件是计算机系统中的 程序、数据 和 文档。程序是计算机完成预定功能和性能的可执行指令序列；数据是使程序能适当处理信息的数据结构；文档是为了理解程序所需的阐述性资料。

运行平台是指可以直接支持软件执行的系统软件、支撑软件、硬件等的集合体。

软件开发就是要弥补问题域和运行平台间的 “距离”。

从问题域向运行平台直接映射存在困难。为了控制复杂性，需要定义多个抽象层，如需求层、设计层、实现层、部署层等。

graph LR
A(问题域) --映射--> B(抽象层) --映射--> C(抽象层)--映射--> D(抽象层)--映射--> E(运行平台)

软件开发的本质 是不同抽象层术语间的映射，以及不同抽象层处理逻辑间的映射。

# 过程途径

求解软件的开发手段。

基本手段是问题建模：运用掌握的知识，给出该问题的一个结构。

主要的建模手段包括：结构化方法、面向对象方法及诸多面向数据结构方法等。

建模后形成的结果称为该问题的模型，即 系统/产品模型。系统模型大体上可以分为两类：

• 概念模型：对客观事物系统的抽象，即标识要解决的问题，或称问题定义
• 软件模型：给出需求层上概念模型的软件解决方案。依据所在的抽象层，可分为 设计模型、实现模型、部署模型 等

o

SE1 需求规约

软件需求以一种技术形式，描述了一个产品/系统应具有的功能、性能及其他性质。

软件需求是产品设计、实现及验证的基本信息源之一，是软件工程的基础。

SE1.1 需求与需求获取

一个需求是一个有关 “要予构造” 的陈述。其描述了待开发产品功能上的能力、性能参数或其他性质。

对于单一需求，必须具有如下性质：

• 必要性：该功能是用户所要求的
• 无歧义性：该需求只能用一种方式解释
• 可测性：该需求是可以进行测试的
• 可跟踪性：该需求可以从一个开发阶段跟踪到另一阶段
• 可测量性：该需求是可被测量的

# 需求分类

可以把需求分为两大类：功能需求、非功能需求

功能需求

功能需求是整个需求的主体。其规约了系统必须执行的功能。没有功能需求，就没有派生的其他功能需求，也没有非功能需求。

非功能需求

非功能需求可能作用于一个或多个功能需求。非功能需求又可分为：性能需求、外部接口需求、设计约束、质量属性需求

• 性能需求

  性能需求规约了一个系统在性能方面必须具有的一些特性

• 外部接口需求

  规约了系统必须与之交互的用户、硬件、软件或数据库元素

  接口需求可以分为以下几类

  • 系统接口：一个应用如何与系统其他应用进行交互
  • 用户接口：描述软件系统与用户间交互的逻辑特性。即，给用户显示的数据，用户如何控制该用户接口。
  • 硬件接口：描述软件系统和硬件设备间的交互
  • 软件接口：描述与其他软件产品进行的交互
  • 通信接口：描述与通信设施（如局域网）间的交互
  • 内存约束：描述易失性存储和永久性存储的特性和限制
  • 运行：描述用户如何使系统进入正常和异常的运行，及如何与系统交互
  • 地点需求：描述系统安装及如何调整一个地点，以适应新的物理环境

• 设计约束

  限制了软件系统的设计方案范围

  为确定设计约束，应考虑如下问题

  • 法规政策
  • 硬件限制：技术上和经济上的限制
  • 与其他应用的接口
  • 并发操作
  • 审计功能：考虑数据记录或事务记录的需要
  • 控制功能：考虑对系统进行远程控制、对其他软件及内部过程进行控制的需要
  • 高级语言需求
  • 握手协议
  • 应用的关键程度：考虑是否存在潜在的人员、财政损失
  • 安全和保密

• 质量属性

  规约了产品具有的一个性质必须达到期望水平

# 需求发现技术

包括 自悟、交谈、观察、小组会、提炼

• 自悟：将自己作为系统的最终用户，审视并提出问题
• 交谈：提供提问/回答的方式，直接询问用户需要什么样的系统
• 观察：通过观察用户执行其任务的过程，了解系统运行的环境
• 小组会：举行客户和开发人员的联席会议，共同交流开发需求
• 提炼：复审技术文档，提取相关信息

SE1.2 需求规约

**软件需求规约（SRS）**是一个产品所有需求陈述的正式文档，表达了一个软件产品的概念模型。

需求规约要满足以下性质：

• 重要性和稳定性程度：按照需求的重要性和稳定性，对需求进行分级
• 可修改性：在不过多影响其他需求的前提下，可以容易地修改一个单一需求
• 完整性：没有遗漏的需求
• 一致性：不存在互斥的需求

此外，功能规约还要考虑以下问题：

• 功能源
• 功能共享的数据
• 功能与外部界面的交互
• 功能所使用的计算资源

# 需求规约（草案）格式

引言    1.1 目的    1.2 范围    1.3 定义、缩略语    1.4 参考文献    1.5 概述 总体描述    2.1 产品描述    2.2 产品功能    2.3 用户特性    2.4 约束    2.5 假设和依赖 特定需求 附录 索引

其中，第三部分 “特定需求” 是文档的技术核心。一般应该根据不同类型的系统来构造这一部分

• 根据用户类划分小节。每类用户执行的功能包含在该类用户的描述中
• 按对象划分小节。每小节给出对象关联的功能
• 根据系统层特征划分小节。对任意给定需求可以有若干特征
• 根据激发划分小节。给出响应每一激发的执行功能的规约
• 按功能层次划分小节。依照信息流的活动、执行的处理、通过的数据 进行功能规约
• 依据系统运行模式划分小节。在小节中对系统性能进行规约
• 通过可选的模式划分小节。规约涵盖每种模式的性能
• 根据用户类、功能和特征划分小节。

# 需求规约（规格说明书）的表达

需求规约的表达有 3 种风格

• 非形式化需求规约

  以一种自然语言表达规约。通常要为特定语境中使用的术语进行定义。

  非形式化需求规约困难产生歧义、矛盾和不可测等问题。因此，只适用于规模较小、复杂度低的小型软件项目。

• 半形式化需求规约

  以半形式化符号体系表达需求规约。其遵循一个标准表示模板：

  • 数据表：明确标识了一些词，可以基于一种自然语言
  • 标准化表达格式：标识了一些元信息，支持以更清晰地方式系统化编制文档

• 形式化需求规约

  以一种基于良构数学概念的符号体系来编制需求规约。一般伴有解释性注释的支持：

  • 以数学概念来定义该符号体系的语法和语义
  • 定义了一组支持逻辑推理的证明规则，并支持该符号体系的定义和引用

  由于表达能力问题，在实际工程中注意针对质量要求较高的产品或其中某一部分，采用形式化语言表达需求。目的是为了程序的正确性验证

# 需求规约的作用

可以概括为以下几点

• 需求规约是软件开发组织和用户间一份事实上的技术合同书，是产品功能及其环境的体现

• 对于项目的其余大多数工作，需求规约是一个管理控制点

• 对于产品设计，需求规约是一个正式的、受控的起始点

• 需求规约是创建产品验收测试计划和用户指南的基础。

  也就是说，基于需求规约，还会产生 初始测试计划 和 用户系统操作描述 这两个文档

  • 初始测试计划

    包括对未来系统中哪些功能和性能指标进行测试，以及达到何种要求。在后续阶段中，对该计划要不断修正和完善，并成为相应阶段文档的一部分

  • 用户系统操作描述

    一份初步的用户手册。内容包括对系统功能和性能的简要描述，使用系统的方法，系统用户的责任等

需求规约不是一个设计文档。它是一个 “为了” 设计的文档。

需求规约也不是进度或规划文档，不应给出：项目成本、交付进度、报告规程、软件开发方法、质量保证规程、配置管理规程、验证和确认规程、验收规程、安装规程等。

# 需求验证

有关软件需求规约，应该对以下方面进行验证

• 正确性：SRS 中每个需求都表达了将构造系统的某个要求

• 无二义性：SRS 中每个需求都只有一种解释

• 完整性：一个 SRS 应该具有以下特性：

  • 未来系统所做的任何事情都包含在软件需求规约的陈述中
  • 未来系统响应所有可能的输入（有效和无效输入）
  • SRS 中没有被标识为待定的内容

• 可验证性：SRS 中每个需求都是可验证的

  存在一个有限代价的过程（人工或机器）可以检查构造的软件产品是否符合用户需求

  这要求 SRS 中不能出现任何二义性，不能包括任何不可度量的量（大量、时常之类的词语），也不能有任何等同于停机问题的需求（以其不可验证）

• 一致性：避免需求与以前的文档发生冲突，也要避免需求间的冲突

• 可理解性

对于 SRS 的格式与风格方面：

• 可修改性：SRS 的结构和风格使对需求的修改易于完整、一致地执行

• 可被跟踪性：每个需求的出处都是清楚的。这意味着 SRS 包含对前期支持文档的引用表

• 可跟踪性：SRS 的书写方式要有助于其他文档对其进行引用

• 设计无关性：不暗示特定的软件结构或算法

• 注释：向开发机构提供了每个需求是否重要的指导意见

  如：E（Essential）、D（Desirable）、O（Optional）