跟着《软件需求分析和设计实践指南》成长

软件需求分析和设计实践指南从软件开发和软件测试的多年实践出发，系统介绍了系统需求分析、系统设计、软件需求分析、软件设计的方法和逻辑关系，提供了宝贵的案例。

作者：韩雪燕、李楠、孙亚东、陈尘

丛书名：高等学校软件工程专业系列教材

定价：49.8元

印次：1-4

ISBN：9787302570950

出版日期：2021.04.01

印刷日期：2024.01.17

术语和定义

GB/T 11457 和 GJB 2786A - 2009 确立的术语和定义适用于本标准。

GJB 438B-2009缩略语

COM---computer operation manual 计算机操作手册；

CPM---computer programming manual 计算机编程手册；

CSCI---computer software configuration item 计算机软件配置项；

DBDD---database design description 数据库设计说明；

FSM---firmware support manual 固件保障手册；

HWCI---hardware configuration item 硬件配置项；

IDD---interface design description 接口设计说明；

IRS---interface requirement specification 接口需求规格说明；

IV&V---independent verification and validation 独立验证和确认；

OCD---operational concept description 运行方案说明；

SCMP---software configuration management plan 软件配置管理计划；

SCMR---software configuration management report 软件配置管理报告；

SCOM---software center operator manual 软件中心操作员手册；

SDD---software design description 软件设计说明；

SDP---software development plan 软件开发计划；

SDSR---software development summary report 软件研制总结报告；

SDTD---software development task description 软件研制任务书；

SIOM---software input/output manual 软件输入/输出手册；

SIP---software installation plan 软件安装计划；

SPS---software product specification 软件产品规格说明；

SQAP---software quality assurance plan 软件质量保证计划；

SQAR---software quality assurance report 软件质量保证报告；

SRS---software requirement specification 软件需求规格说明；

SSDD---system/subsystem design description 系统/子系统设计说明；

SSS---system/subsystem specification 系统/子系统规格说明；

STD---software test description 软件测试说明；

STP---software test plan 软件测试计划；

STR---software test report 软件测试报告；

STrP---software transition plan 软件移交计划；

SUM---software user manual 软件用户手册；

SVD---software version description 软件版本说明。

文档种类

根据 GJB 2786A－2009 的要求，在软件开发过程中可产生下列文档:

a) 运行方案说明 (OCD)；

b) 系统/子系统规格说明 (SSS)；

c) 接口需求规格说明 (IRS)；

d) 系统/子系统设计说明 (SSDD)；

e) 接口设计说明 (IDD)；

f) 软件研制任务书 (SDTD)；

g) 软件开发计划 (SDP)；

h) 软件配置管理计划 (SCMP)；

i) 软件质量保证计划 (SQAP)；

j) 软件安装计划 (SIP)；

k) 软件移交计划 (STRP)；

l) 软件测试计划 (STP)；

m) 软件需求规格说明 (SRS)；

n) 软件设计说明 (SDD)；

o) 数据库设计说明 (DBDD)；

p) 软件测试说明 (STD)；

q) 软件测试报告 (STR)；

r) 软件产品规格说明 (SPS)；

s) 软件版本说明 (SVD)；

t) 软件用户手册 (SUM)；

u) 软件输入/输出手册 (SIOM)；

v) 软件中心操作员手册 (SCOM)；

w) 计算机编程手册 (CPM)；

x) 计算机操作手册 (COM)；

y) 固件保障手册 (FSM)；

z) 软件研制总结报告 (SDSR)；

aa) 软件配置管理报告 (SCMR)；

bb) 软件质量保证报告 (SQAR)。

一、逻辑篇：厘清开发活动的本质关系

逻辑混乱是文档"无价值"的根源。必须首先理清各开发活动之间的输入输出关系与思维边界。

1.1 系统需求分析与系统设计的关系

这是最常混淆的环节。系统需求分析 的对象是"系统"作为黑盒，目标是定义系统必须做什么 以及做到什么程度，其输出是《系统/子系统规格说明》

。这份文档描述的是系统对外展现的能力 （功能）、质量 （性能、安全性等）和必须遵守的约束 。而系统设计 的对象是"系统"作为白盒，目标是提出系统如何做 的解决方案，其输出是《系统/子系统设计说明》。设计说明的核心是阐述设计决策 （为何如此设计）和体系结构（静态组成与动态交互）。

关键逻辑：需求分析回答"做什么"（What），产生"规格"；设计回答"怎么做"（How），产生"方案"。将设计内容（如CSCI划分、功能分配）写入系统规格说明，是严重的逻辑错位。

1.2 系统设计与软件需求分析的关系

系统设计将系统分解为硬件配置项（HWCI）和计算机软件配置项（CSCI）。软件需求分析 的对象是某个具体的CSCI，目标是定义该软件配置项必须做什么 。因此，软件需求（即CSCI能力需求）应严格来源于系统设计中对该CSCI的功能分配。系统设计定义了CSCI的职责和接口，软件需求分析则对这些职责进行细化、量化，形成软件级的详细规格。

关键逻辑 ：系统设计是软件需求的直接来源和约束框架。软件需求不能凭空产生，必须与系统设计中的分配结果严格追溯。

1.3（每层对象）功能的来源

这是理解功能分解链的核心。功能的来源具有严格的层次性：

1. 系统功能 ：来源于系统所属组织的业务用例和价值。系统是为了改进组织的业务流程（如将人工点钞变为点钞机自动化）而引入的。因此，系统需求分析的第一步是研究组织，发现待改进的业务用例。
2. CSCI功能 ：来源于系统设计阶段的功能分配。系统设计决策确定了哪些功能由软件（CSCI）实现，哪些由硬件（HWCI）实现，以及它们如何协作。
3. 软件模块/单元功能 ：来源于软件设计阶段对CSCI功能的进一步分解和分配。

关键逻辑：功能是"价值"的载体，自顶向下逐级派生和分配，每一层的功能都服务于上一层的目标。识别出"串口通信功能"、"数据采集功能"这类错误，正是因为混淆了"技术手段"与"业务功能"的界限。

二、概念篇：统一语言，消除歧义

概念错误是导致实践偏差的直接原因。必须对关键术语达成共识。

2.1 计算机软件配置项（CSCI）

CSCI是系统设计的结果 ，是出于设计、开发、测试、配置管理的目的而标识的软件项。它不是需求分析阶段识别出来的，而是在系统设计阶段，根据技术解决方案、复用、采购等因素划定的软件单元。在系统需求规格中描述CSCI及其功能分配，是完全错误的。

2.2 物理实体和逻辑实体

• 物理实体：指系统中真实存在的硬件部件、设备、线缆等。
• 逻辑实体 ：指在分析、设计、代码中定义的构件，如软件模块、数据流、对象、接口协议等。
  UML图用错地方，常表现为用描述逻辑结构的类图去表达物理部署，或用物理部署图去表达软件模块间的依赖关系。

2.3 功能、性能、接口

• 功能：对象（系统、CSCI）能够完成的任务或动作，体现其"能力"。应使用动词短语描述（如"计算弹道"、"存储目标数据"），而非名词或技术手段（如"通信功能"）。
• 性能 ：对象完成功能时，在时间、精度、容量、资源消耗等方面应达到的量化指标。如"响应时间不大于2秒"、"支持并发用户数100个"。性能必须与特定功能关联，泛泛而谈的"通信周期"是无效的。
• 接口 ：对象与外部（其他系统、硬件、用户）进行交互的契约 。包括数据格式、协议、时序等。CSCI内部模块间的交互属于内部设计，不应作为"CSCI内部接口需求"提出。

2.4 模块、部件、单元

这些是设计层面的概念。

• 部件/模块：指系统或CSCI内部的一个组成部分，具有相对独立的功能和接口。
• 单元 ：通常指软件的最小可测试单元，如函数、类、过程。
  在需求文档中过早定义模块或单元，属于设计越界。

2.5 架构/结构、组成

• 架构/结构：指系统或软件的高层设计，体现了部件之间的关系以及设计决策。
• 组成 ：指系统由哪些部件（CSCI/HWCI）构成。这是系统设计说明中"系统部件"章节的内容。
  在需求规格中描述"组成"，是错误的。

2.6 功能分解/分配

• 功能分解：将一个复杂功能拆解为若干子功能的过程，是设计活动的一部分。
• 功能分配 ：将已识别的功能，决定由哪个部件（CSCI或HWCI）来实现，是系统设计的核心活动之一。
  两者都是设计行为，不应出现在需求规格中。

2.7 设计决策

设计决策是《系统/子系统设计说明》第3章的核心，它解释为什么选择这样的设计方案，例如：为何划分这些CSCI？为何选择此数据库？为何将关键性能指标分配给软件而非硬件？

它绝不是对需求的复述，而是对需求（尤其是关键需求和约束）的技术响应和理由阐述。在其中描述输入输出等需求，是根本性的概念错误。

三、方法篇：掌握GJB438B框架下的正确实践

3.1 需求分析的方法

1. GJB438B需求文档各章节的关系

   以《软件需求规格说明》为例，其核心章节构成一个有机整体：

   • 3.1 要求的状态和方式：描述软件在各种运行模式下的行为场景，是理解功能的背景。
   • 3.2 CSCI能力需求（核心） ：逐条描述功能需求，并应整合性能指标（而非单独设立"性能需求"章节）。每条功能需求应包含触发条件、处理过程、输出结果等规格要素。
   • 3.3 & 3.4 接口需求：明确外部和内部接口（指CSCI与外部HWCI或其他CSCI的接口），需覆盖研制任务书中的相关内容。
   • 3.5 内部数据需求 ：指软件内部需要维护的核心数据实体及其关系（如数据库表、关键全局变量），绝非软件的输入输出数据流。
   • 适应性、安全性、保密性等质量因素：作为独立章节，描述非功能性的要求。

2. 功能的各规格要素的内涵与编写方法

   每条功能需求应结构化描述，要素包括：

   • 标识符与名称：唯一标识和功能名称。
   • 描述：功能的目的和概要。
   • 输入：触发该功能的数据、事件或信号。
   • 处理：对输入数据/事件进行转换或响应的主要步骤和逻辑（可用结构化语言、活动图或伪代码）。
   • 输出：处理完成后产生的数据、事件、状态变化或对外部的影响。
   • 性能：与该功能直接相关的量化指标（如处理时间、精度）。
   • 前提与约束：执行该功能必须满足的条件或受到的约束。
   • 后置条件：功能执行后系统必须达到的状态。

3. 需求分析涉及的UML图的正确使用方法

   • 用例图 ：适用于系统或CSCI顶层，识别外部参与者和系统提供的服务（用例），不宜用于描述系统内部组成或功能分解。
   • 活动图/流程图：非常适合描述功能需求的处理过程（3.2章节）和运行场景（3.1章节）。
   • 序列图：可用于描述特定场景下，系统与外部参与者或CSCI与外部实体的交互时序，是澄清接口行为的有效工具。
   • 类图/数据模型图：可用于描述内部数据需求（3.5章节），定义关键数据实体及其关系。
   • 状态图：适用于描述具有明确状态变迁的CSCI或子系统。
   • 

4. 质量因素与设计约束的编写示例

   • 质量因素（如安全性）：不应写"系统应安全"。应写："当检测到非法访问尝试时，系统应在1秒内记录安全事件（包括时间、IP地址、操作类型），并中断该会话。对于连续5次认证失败的用户账户，系统应自动锁定30分钟。"
   • 设计约束：不应写"软件应模块化设计"。应写："软件必须使用C++语言进行开发，编译器版本不低于GCC 7.3.0。所有与外设'XX雷达'的通信必须遵循其提供的《XX通信协议V2.1》。"

3.2 设计的方法

1. GJB438B设计文档各章节的关系

   《系统/子系统设计说明》的核心逻辑是：

   • 第3章 系统级设计决策：解释"为什么"这样设计，是方案的灵魂和理由。
   • 第4章 系统体系结构设计 ：展示"是什么"设计。
     • 4.1 系统部件：展示系统的静态组成，即由哪些CSCI和HWCI构成。
     • 4.2 执行方案：展示系统的动态协作，即每个系统功能如何通过这些部件协同完成（功能分配与实现流程）。

2. 设计决策应该考虑的内容

   设计决策应围绕如何满足《系统/子系统规格说明》中的关键需求展开，包括：

   • 架构风格选择理由（如微服务 vs 单体）。
   • 关键部件划分与选型理由（如为何使用Redis作缓存，为何将XX算法独立为专用CSCI）。
   • 关键技术路线选择理由（如通信协议选型、数据存储方案）。
   • 关键质量属性（性能、可靠性、安全性）的实现策略。
   • 对设计约束的符合性方案。

3. 部件的静态关系的表达方法

   使用框图 （如系统组成框图）清晰展示所有CSCI和HWCI，并标注它们之间的物理连接或逻辑关联。可以配合接口表详细定义每个接口的物理特性、协议和数据类型。

4. 部件的动态关系的表达方法

   使用序列图 、活动图 或带泳道的流程图是最佳选择。针对《系统规格说明》中定义的每一项重要系统功能，绘制一幅图，展示从触发到完成的过程中，各个CSCI和HWCI之间消息的传递、函数的调用、数据的流转。这直观地体现了"执行方案"，也明确了每个部件的职责。

写出合格有用的文档，必须进行思维上的根本转变：需求阶段，坚守"黑盒"视角，定义契约；设计阶段，转为"白盒"视角，构思方案。 严格遵循GJB2786A的活动划分和GJB438B的文档定位，使用准确的概念，并辅以正确的建模方法，才能让文档从"合规的废纸"变为"指导开发的蓝图"和"沟通共识的桥梁"。您从逻辑、概念、方法三管齐下的普及工作，对于提升整个行业的基础能力至关重要。

参见：

https://www.tup.tsinghua.edu.cn/booksCenter/book_08878001.html

https://www.doc88.com/p-4532958902972.html