本书按照GJB2786A要求的软件开发活动，分别阐述了开展系统需求分析、系统设计、软件需求分析、软件设计活动的方法，以及运用这些方法得到的分析结果和设计结果如何按照GJB438B要求文档化。本书共分为十一章。简要说明了本书适用涉众，能够解决的问题。重点阐述了常见的软件开发过程，分别对系统需求分析、系统设计、软件需求分析和软件设计的方法进行了详细阐述。并将这些活动中应该记录的内容与GJB438B的要求进行了相关说明。

第1章 概念与定义
1.1 初衷
1.2 系统/软件需求
1.2.1 需求的分类
1.2.2 需求的分层
1.3 涉众
1.4 组织
1.4.1 业务用例
1.4.2 业务流程
1.4.3 业务执行者
1.4.4 业务工人
1.4.5 业务实体
1.5 系统
1.5.1 系统用例
1.5.2 系统工作流程
1.5.3 系统执行者
1.5.4 系统部件
1.6 软件配置项
1.6.1 CSCI用例
1.6.2 软件处理流程
1.6.3 执行者
1.6.4 软件单元
1.7 UML模型
1.7.1 概述
1.7.2 用例图
1.7.3 类图
1.7.4 活动图
1.7.5 序列图
1.7.6 状态图
1.7.7 包图
1.7.8 构件图
1.7.9 部署图
1.8 质量因素
1.8.1 功能性
1.8.2 可靠性
1.8.3 易用性
1.8.4 效率
1.8.5 维护性
1.8.6 可移植性
1.9 设计约束
1.10 架构设计
1.11 需求与设计的关系
思考题
第2章 软件开发过程
2.1 基本活动
2.2 瀑布式开发
2.3 增量式开发
2.4 演进式开发
2.5 敏捷开发
2.6 需求分析/设计活动
2.6.1 系统需求分析
2.6.2 系统设计
2.6.3 软件需求分析
2.6.4 软件设计
思考题
第3章 系统需求分析方法
3.1 系统需求的来源
3.2 系统是组织的部件
3.3 分析方法综述
3.4 分析之第一步——系统能力需求分析
3.4.1 确定组织
3.4.2 发现组织的业务用例
3.4.3 确定系统用例
3.4.4 描述系统用例规格
3.5 分析之第二步——系统外部接口分析
3.6 分析之第三步——系统内部接口分析
3.7 分析之第四步——系统内部数据需求
3.8 分析之第五步——系统质量因素分析
3.8.1 质量因素分析方法
3.8.2 质量因素表达方法
3.9 分析的第六步——设计和构造约束分析
3.10 系统需求分析案例
3.10.1 对组织建模
3.10.2 对组织业务流程现状建模
3.10.3 对组织业务流程改进建模
3.10.4 得到系统用例，确定系统规约
3.10.5 系统质量因素分析
3.10.6 系统设计约束分析
3.11 系统规格说明文档模板解析
3.11.1 范围
3.11.2 需求
3.11.3 合格性规定
3.11.4 需求可追踪性
思考题
第4章 系统设计方法
4.1 系统架构设计方法
4.1.1 第一阶段——与需求对接阶段
4.1.2 第二阶段——概念架构设计阶段
4.1.3 第三阶段——具体架构设计阶段
4.2 系统级设计决策
4.2.1 系统行为设计决策
4.2.2 对系统部件产生影响的决策
4.3 系统体系结构设计
4.3.1 系统部件
4.3.2 执行方案
4.3.3 接口设计
4.4 系统设计案例
4.4.1 确定系统级设计决策
4.4.2 确定系统架构
4.5 系统设计说明模板解析
4.5.1 范围
4.5.2 系统级设计决策
4.5.3 系统体系结构设计
4.5.4 需求可追踪性
思考题
第5章 软件需求分析方法
5.1 软件需求的来源
5.2 软件是系统的部件
5.3 分析方法综述
5.4 分析之第一步——CSCI能力需求分析
5.5 分析之第二步——CSCI外部接口需求分析
5.6 分析之第三步——CSCI内部接口需求分析
5.7 分析之第四步——CSCI内部数据需求分析
5.8 分析之第五步——软件质量因素分析
5.9 分析之第六步——设计和实现约束分析
5.10 软件需求规格说明模板解析
5.10.1 范围
5.10.2 需求
5.10.3 合格性规定
5.10.4 需求可追踪性
思考题
第6章 软件设计方法
6.1 CSCI级设计决策
6.2 CSCI体系结构设计
6.2.1 CSCI部件
6.2.2 执行方案
6.3 CSCI详细设计
6.4 软件设计说明模板解析
6.4.1 范围
6.4.2 CSCI级设计决策
6.4.3 CSCI体系结构设计
6.4.4 CSCI详细设计
6.4.5 需求可追踪性
思考题
第7章 软件开发活动质量评价
7.1 系统需求分析活动评价
7.1.1 功能需求
7.1.2 系统质量因素
7.1.3 设计和构造约束
7.1.4 系统环境需求
7.1.5 其他
7.2 系统设计活动评价
7.2.1 系统级设计决策
7.2.2 系统体系结构设计
7.2.3 其他
7.3 软件需求分析活动评价
7.3.1 功能需求
7.3.2 软件质量因素
7.3.3 设计和实现约束
7.3.4 CSCI环境需求
7.3.5 其他
7.4 软件设计活动评价
7.4.1 CSCI级设计决策
7.4.2 CSCI体系结构设计
7.4.3 CSCI详细设计
附录A网络数据采集系统案例
附录A1网络数据采集系统规格说明
附录A2网络数据采集系统设计说明
附录A3数据采集软件需求规格说明
附录A4数据采集软件设计说明
参考文献

前言
在作者十余年的软件开发工作中，虽然也写
过一些软件需求、设计文档，但是因为没有经过
这方面的学习与训练，毫无章法，只能将做的工
作如实记录下来，那个年代没有严格的软件工程
化的标准规范，只要记录下来、逻辑清晰、内容
完整即可顺利交差。后来在从事软件测评工作初
期，发现做文档审查时，根本无从判断文档内容
的正确性，这才醒悟到缺乏软件需求分析、设计
的技能是不能胜任软件测评工作的。于是，拜读
了徐锋老师的《软件需求最佳实践》，开启了软
件需求分析的启蒙阶段。由于资质愚钝，没有真
正理解书中方法，在混沌状态中，有幸两次参加
UMLChina首席专家潘加宇老师的培训课，并反
复阅读领悟潘加宇老师的《软件方法》（上册）
，方才有所顿悟。本书也大量引用了上述两本书
的精华内容，在此，向两位老师表示衷心的感谢
！本书共7章，主要内容有： 概念与定义； 软
件开发过程； 系统需求分析方法； 系统设计方
法； 软件需求分析方法； 软件设计方法； 软
件开发活动质量评价。本书的组织结构如下。（
1） 第1章重点阐述系统需求分析和设计活动中
涉及的相关概念，这些概念非常重要，是后续章
节描述的方法的基础。（2） 第2章重点阐述软
件开发团队中常见的软件开发过程，以及对开发
过程中的系统/软件需求分析和设计活动进行了
综合性概要说明，目的是建立整体性概念。（3
） 第3~6章是本文的重点内容，分别对系统需求
分析、系统设计、软件需求分析和软件设计的方
法进行了详细阐述。并将这些活动中应该记录的
内容与GJB 438B的要求进行了相关说明。对GJB
438B要求的四个文档模板内容进行了解析，详细
说明了按照本文所阐述的需求分析和设计方法开
展各项软件开发活动后，落实在GJB 438B的相
关章节的具体内容，这些内容基本上都以表格或
图（含UML图）的形式体现。
在第3章和第4章中，贯穿了一个案例，案
例中选取的组织对象是某个第三方软件测评机构
，系统对象是测评机构的测试项目管理系统。案
例具体说明了如何从组织的业务用例分析得到系
统的用例，如何针对关键需求确定系统设计决策
，如何得到系统的概念架构，如何分配系统职责
给相应的部件等； 详见3.10节和4.4节。在第3
章的3.4.4节，用一个ATM设备的系统用例和一
个自动饮料售卖机的系统用例说明系统用例规约
的写法，供读者参考。在第5章的5.4节，用自动
饮料售卖机控制软件的用例规约作为例子，读者
可以与3.4.4节的系统用例进行比较。（4） 第
7章是基于上述章节描述的需求分析、设计方法
，归纳总结了系统需求分析、系统设计、软件需
求分析和软件设计活动产出的软件工作产品需要
考核评价的内容，并对这些内容的定量评价提供
了方便、可操作的方法。
（5） 附录A是一个实例，以网络数据采集
系统为例，给出系统规格说明、系统设计说明，
以及系统中的一个软件配置项的软件需求规格说
明和软件设计说明的主要内容。这个实例的特点
是系统由两个软件配置项和一个硬件设备组成，
但是硬件设备属于货架产品，无须专门研制，所
以在系统设计说明的执行方案章节中可以发现，
系统的职责都被分配给了这两个软件配置项。
本书第1~6章由韩雪燕编写； 第7章由孙亚
东编写，附录A1、A2和A3由李楠编写，
附录A4由陈尘编写。除附录A4中的UML图外
，书中其他UML图均由李楠提供。
本书可作为软件工程技术人员的培训、参考
用书，适用于系统能力需求论证人员、系统研制
总体单位的系统需求分析人员、系统架构设计人
员、软件开发组织的软件需求分析人员、软件设
计人员、软件编码人员和软件测试人员以及第三
方软件测试机构的测试需求分析人员； 也可作
为高等学校计算机软件工程专业的本科生教材。
由于编者水平有限，书中不当之处在所难免，欢
迎广大同行和读者批评指正。韩雪燕2020年8月

第3章
系统需求分析方法
3.1系统需求的来源
系统需求应该从所属组织的业务用例中进行获取。
业务用例是组织存在的价值，不是经常发生变化的，经常改变的是业务用例在组织内部实现的流程，也就是说，组织引入系统后，改善了业务流程。
例如，银行的业务用例包括存款、取款、转账等，这些业务用例自银行出现就存在了，多少年都没有改变，改变的只是这些业务用例的实现流程，从这些业务用例的序列图的变化就会发现业务流程从纯人工变为自动化实现，即组织使用某些系统替换了原来的业务工人。如银行使用点钞机替换了点钞技能强的员工，使用自动取款机、手机银行替换了更多的柜员和柜员系统。因此，对于银行的存款和转账业务用例来说，银行对每个用例都提供多种实现，例如，柜台方式取款见图31、ATM设备取款见图32，柜台方式转账见图33、手机银行方式转账见图34。
可见，组织中引入系统，改变了相关业务用例的实现流程，而流程的改变为银行降低了用人成本，提高了准确率，扩大了顾客群体。
组织中引入系统，系统通常在以下三方面发挥作用，改善相关业务用例的实现流程［1］。
图31存款用例的序列图——使用柜员系统/点钞机
图32存款用例的序列图——使用ATM设备
图33转账用例的序列图——使用柜员系统
图34转账用例的序列图——使用手机银行
(1) 系统将原物流改为信息流。例如，某组织以前的办事流程主要靠纸质在办事人员之间进行流转，引入某业务系统后，在不同办事人员之间流转的是系统中的信息。
软件需求分析和设计实践指南
第
3
章系统需求分析方法
(2) 系统改善了信息流转。例如，医院原来的看病流程是： ①患者在挂号窗口挂号，等待挂号系统叫号； ②医生开具处方后，患者去收费窗口，划价人员将药品信息录入财务系统，划价收费； ③之后患者去取药窗口，药品管理系统记录取药品种和数量。医院引进新的系统后，看病流程变为： ①患者在挂号窗口挂号，系统录入医保卡或银行卡信息，等待系统叫号； ②医生使用系统开具处方后，系统直接扣除药费，并记录取药品种和数量； ③患者去取药窗口直接取药。可见，原来医院的看病流程中至少有三个独立系统，信息不能在三个系统中直接流转，引进新的系统后，信息流在一个系统内部流转，为患者看病节约了等待时间。
(3) 系统封装了领域逻辑。例如，银行引进点钞机，将人工点钞技能变为系统实现，无须再花费人力物力培养柜员的点钞技能； 出现手机银行后，手机银行封装了转账的业务逻辑，替代了柜员和柜员系统。如果作战部队引入智能指挥信息系统，封装优秀指挥人员的指挥决策技能，就能减少指挥决策失误的概率。
可见，要获取系统需求，就要从研究(系统所属)组织的业务用例开始。系统用例来自组织的业务用例。
3.2系统是组织的部件
系统作为组织中的业务实体，和业务工人一样，属于组织内部的部件。在一个组织中，通过对业务工人和业务实体(系统)之间的协作关系进行良好设计，从而对外部涉众提供有价值的服务。服务的优劣受到业务工人素质的影响，同样也受到系统能力的影响。
系统和业务工人一样都属于组织的部件，系统可以被业务工人使用，也可以直接被外部涉众使用。也就是说，系统用例的主执行者可以是业务工人，也可以是组织的外部涉众。例如某车载侦察系统，其主执行者有业务工人(侦察员)，也有外部涉众(上级指挥人员)。
3.3分析方法综述
系统作为所属组织的部件，是为提升组织的业务价值而存在的，系统是为组织更好地实现业务用例而研制，所以系统的能力需求来自组织的业务用例(即组织的业务价值)。
系统需求分析的第一步首先要找对组织，将组织作为研究对象，发现组织的业务用例，并确定现行状态下，组织的这些业务用例是如何在组织内部(各部门和系统)分工协作完成的。之后，将待采购的新系统或待改进的系统放在组织内部，确定系统能够在哪些方面改进哪些业务用例的实现过程。
上述工作完成后，按照GJB 2786A的要求，可以将工作内容记录在《运行方案说明》中。
之后，将系统作为研究对象，对得到的系统用例(能力需求)进行详细分析，描述每个用例的规格。相应的工作内容记录在《系统/子系统规格说明》中的第3章的3.2系统能力需求中。
系统需求分析的第二步工作是基于得到的系统用例，进行外部接口分析，确定系统的外部接口的物理形式、传输速率，以及与软件相关的数据协议。相应的工作内容记录在《系统/子系统数据较多，可以在附录中或使用GJB 438B的《接口设计说明》模板详细说明
接口通信特征
通信链路如网络的带宽、串口速率等
数据传输非周期性/周期性、单向或双向传输
接口协议特征说明接口是否有同步机制，详细说明同步机制是如何设计的
接口上的每类数据的传输层协议等
3.6分析之第三步——系统内部接