软件需求分析和设计实践指南

"本书介绍： 如何从系统所属组织着手开始系统需求分析； 如何基于系统需求分析的结果开展系统设计； 如何基于系统设计的结果开展软件需求分析； 如何基于软件需求分析结果开展软件设计； 如何在系列软件开发活动中落实国家军用标准相关要求。"

本书在全面系统地介绍系统需求分析和设计领域涉及的相关概念，以及概念之间关系的基础上，着重介绍了如何从系统所属组织着手系统需求分析，如何基于系统需求分析的结果开展系统设计，如何基于系统设计的结果开展软件需求分析，以及如何基于软件需求分析结果开展软件设计，并在这一系列软件开发活动中，如何落实国家军用标准相关要求。最后，通过一个网络数据采集系统的系统需求分析、设计和软件需求分析、设计过程，举例说明文中描述方法的具体应用。本书适合作为军工企业的软件开发人员和软件测试人员的培训教材，同时可作为高等学校计算机、软件工程专业髙年级本科生的教材。

韩雪燕，高级工程师。硕士研究生，毕业于国防科技大学。曾任空军某软件测评中心主任、全军军用软件测评实验室评审员，现任航天中认软件测评测评科技（北京）有限责任公司行业总监。在软件开发领域耕耘二十年，聚焦于卫星测控和指控系统行业，积累了一定的编程经验和军用软件开发经验，获得多项军队科技成果奖。后从事软件测评工作，专注于研究软件需求分析和设计的方法，致力于在军用软件开发领域普及需求分析和设计方法。

第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数据采集软件设计说明
参考文献

     第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分析之第三步——系统内部接