From c66c8c1e3e3f0c4d4c16fd28bc194f8d69c3b2c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=BE=90=E6=B6=9B?= <midnite@outlook.com>
Date: Wed, 30 Jun 2021 17:30:09 +0800
Subject: [PATCH] =?UTF-8?q?post:=E5=9F=BA=E6=9C=AC=E5=AE=8C=E6=88=90?=
 =?UTF-8?q?=E8=BD=AF=E4=BB=B6=E8=A7=84=E6=A0=BC=E8=AF=B4=E6=98=8E=E4=B9=A6?=
 =?UTF-8?q?=E6=A8=A1=E7=89=88=E6=96=87=E6=A1=A3=E3=80=82?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 source/_posts/software-specification.md | 210 ++++++++++++++++++++++++
 1 file changed, 210 insertions(+)
 create mode 100644 source/_posts/software-specification.md

diff --git a/source/_posts/software-specification.md b/source/_posts/software-specification.md
new file mode 100644
index 0000000..55200b2
--- /dev/null
+++ b/source/_posts/software-specification.md
@@ -0,0 +1,210 @@
+---
+title: 软件规格说明书模版
+tags:
+  - 架构知识
+  - 软件设计理论
+  - 软件设计文档
+  - 需求文档
+  - 详细设计文档
+categories:
+  - - 架构知识
+    - 软件设计理论
+keywords: '架构师,软件,规格说明书,方案,编写,模版'
+date: 2021-06-30 17:29:43
+---
+
+
+软件规格说明书（Software Specification），又称软件需求规格说明书，是软件架构设计时详细设计过程的输出，是对于前一阶段软件概要设计的进一步细化和响应。软件规格说明书作为一部详细设计方案，其中包括了对软件整体架构、架构运行运营方式、软件功能体系、运行环境与依赖、软件功能分解设计等可以直接用于指导后续软件开发、测试以及验收工作的具体内容，是软件开发中的技术性纲领文件。<!-- more -->
+
+软件规格说明书是系统架构师日常的主要输出文档，不仅对架构师意义重大，更是架构师组织和管理团队的重要文档。但是这个文档的编写一般没有太多可以参考的范例。所以在这里根据网络上一些零碎的资料，自行拼装组合了一套自认为可以在日常应用的模版，在此记录了下来，以供后续的使用和改进。
+
+!!! note ""
+    模版中的章节并不是全部都要具备的，可以按照软件功能需求和设计需要进行增减。
+
+## 模板大纲
+
+{% oss_image software-specification/software-specification.svg 软件规格说明书大纲 700 %}
+
+## 大纲部分章节的编写说明
+
+这个模版中的大部分章节都是比较容易理解的，而且基本上只需要看章节的名称就能明确其中需要编写什么内容。但是还有一大部分章节是属于比较难以下笔的，这里专门针对这种章节做以鞥引导式说明。
+
+### 产品范围
+
+提供对指定产品机器目的的简短描述，解释产品的功能目标，要做什么事情，不做什么事情，以及产品的适用领域和不适用领域，需要包含和不包含的内容。更进一步的还可以提出产品被使用的途径、方式等，还可以包括产品相关利益群体的获利和目标。
+
+### 产品背景
+
+描述产品的背景和起源，说明产品是否是产品系列中的成员，是否是成熟产品的改进版等。如果规格说明书只是定义了一个大系统中的子系统，那么还需要说明子系统与大系统之间的关联和交互方式。
+
+### 产品功能简述
+
+仅概述产品所具备的主要功能，重点在系统层次上描述产品的功能需求和功能分类，还需要包括产品与外部组件连接的需求。可以使用数据流程图的顶层图或者类图来辅助描述。
+
+### 应用模型
+
+主要是绘制产品的结构图示、与系统交互的外部对象之间的关系，展现应用整体结构和与外部交互的位置。
+
+### 业务模型
+
+主要是通过绘制业务结构、步骤组成，清晰描述业务功能的流转和实现期望。
+
+### 假设与依赖
+
+需要列出所有会影响需求实现的假设因素，包括但不限于诸如打算要使用的商业组件或开发、运行环境的问题。如果假设不正确或者发生了改变，那么就一定会影响产品的开发。所以对于项目管理来说，假设也是一种风险。
+
+依赖则是产品对外部因素存在的依赖，例如软件包、组件库、政策支持等。
+
+### 设计与实现约束
+
+确定影响开发人员自由选择的问题，并需要说明这些问题为什么会成为一种限制。常见的限制有以下这些，在编写文档的时候可以从以下这些问题的角度展开分析。
+
+- 必须使用或者避免使用的特定技术、工具、语言、数据库等。
+- 来自费用、进度、资源等方面的限制。
+- 被要求遵循的开发规范或者标准。
+- 企业策略、政府法规或者工业标准。
+- 硬件限制。
+- 数据转换格式标准。
+
+### 指导方针
+
+描述任何用于统治软件设计的目标、指南、原则和条件。对于每一个目标或指南，除非其目的非常明显，否则都应该描述其作为目标的原因。
+
+例如比较常用的几个方针是：
+
+- KISS原则。
+- 重点关注速度。
+- 关注内存使用比。
+
+### 开发方法
+
+简单描述软件设计的方法或者方式。如果其中采用了多个方法，就需要提供针对这些方法的更详细参考。
+
+### 需求关系模型
+
+需求关系模型中主要从产品的各个需求出发，详细的描述需求的特性。一般对于需求的描述可以从以下几点展开。
+
+1. 需求的编号和名称。
+1. 需求的输入。要包括需要访问的信息等。
+1. 需求的过程。主要描述功能需求要执行什么。
+1. 需求的输出。要包括需要访问的信息等。
+1. 候选可重用组件。
+1. 验收准则。要具体描述用于验证满足需求的具体条件。
+
+### 包结构模型与模块关系模型
+
+这两个模型都是使用UML模型来描述需求分析结果，但所采用的角度不同。包结构模型主要是表示用户机构与系统各个包之间的关系和系统各包部分之间的关系。而摘用基于模块的需求分析方法时，则用图绘制用户机构与系统模块之间的关系和系统各模块之间的关系。
+
+### 包用例
+
+包用例主要采用UML模型描述需求分析结果。
+
+其中用例模型是描述包内所有用例之间的关系。而用例描述则可采用类似下表的模版。
+
+{% oss_image software-specification/用例表格.svg 用例描述模版表 650 %}
+
+### 性能需求描述
+
+性能需求描述需要说明产品所需要满足的量化性能需求，用以体现不同的应用领域对产品性能的需求。这些需求包括但不限于以下这些：
+
+- 支持的终端数量。
+- 并行操作的用户数量。
+- 相互合作的用户数量。
+- 支持的操作、处理的信息数量、类型、响应时间等。
+- 相同负载条件下持续处理时间等。
+- 系统容量需求。
+
+所有的需求必须量化或者以可度量的方式详细描述，要详细描述其度量原理以及需求原因。每个需求都要分别陈述，尽量避免集中统一说明。
+
+!!! caution ""
+    所有的非功能性需求都需要量化，且明确定义验收准则。
+
+### 安全设施需求
+
+描述产品在使用过程中可能发生的损失、破坏等相关的需求。定义必须采取的安全保护动作，并且还需要包含对于潜在危险动作的预防。明确确定产品所需要遵循的安全标准、策略和规则。
+
+### 安全性需求
+
+描述产品与系统安全性、完整性或私人问题相关的需求。定义产品防止由于意外或恶意访问、不正确的使用或修改等动作带来的需要产品采取的保护性应对动作。这些内容可能包括密码系统、身份认证、数据加密、备份机制等。
+
+### 质量属性
+
+描述产品与客户或开发人员相关的质量特性，指明产品在可靠性、可移植性、实用性、可维护性等方面的指标。至少要指明不同属性的相对侧重点。
+
+### 其他需求
+
+主要用于列举没有在大纲中列出的需求，例如国际化需求、法律需求等。
+
+### 用户接口
+
+描述产品的各个UI的逻辑特征，包括但不限于：
+
+- 将要采用的GUI标准或者全部产品的系列风格。
+- 屏幕尺寸及布局。
+- 每个UI中的标准按钮、功能或者导航链接。
+- 键盘快捷键。
+- 错误信息显示标准。
+
+### 硬件接口
+
+描述系统中软件所支持的设备类型，软硬件之间交流的数据、控制信息的格式、通讯协议等。
+
+### 软件接口
+
+描述产品与产品组件间的接口需求，包括本产品与外部组件，例如数据库、OS、工具库、运行库、商业中间件等，之间的连接。明确组件之间数据交换的目的，确定组件之间共享数据的机制、格式以及协议等。
+
+### 通信接口
+
+主要描述产品所使用的通信功能相关的需求，例如HTTP、WebSocket等。需要明确定义相关的信息格式，指明需要遵循的通讯标准，说明通讯过程中的安全和加密、数据传输速率、同步机制等。
+
+### 架构策略
+
+描述任何可以影响到整个系统或者高层结构的设计决定或者策略，这些策略应该包含对于整个系统结构的主要抽象与机制。需要详细描述每一个决定或策略的原因。
+
+常见的策略方面主要有以下这些：
+
+- 使用特定的产品，例如语言、数据库、第三方库等。
+- 对已有软件组件的重用。
+- 未来对软件的扩展或增强的计划。
+- 用户接口规范。
+- 硬件或软件接口的规范。
+- 故障检测与恢复。
+- 内存管理策略。
+- 外部数据库与数据存储持久化策略。
+- 分布式数据策略。
+- 基于网络的控制策略。
+- 一般控制方法。
+- 并行与同步的机制。
+- 通信机制。
+- 其他资源管理。
+
+### 方针与应对
+
+描述针对以下问题的应对策略或方案。
+
+- 特定产品的选择，例如编译器、解析器、数据库、第三方库等。
+- 工程权衡。
+- 编码指南与规范。
+- 一个或者多个子系统、模块、子流程的协议。
+- 特定算法或设计模式的选择。
+- 保证需求可跟踪性的计划。
+- 软件测试计划。
+- 软件维护计划。
+- 终端用户、软件、硬件和通信的接口。
+- 源代码的组织、保存、维护。
+- 系统的部署与发布。
+
+### 详细设计
+
+在系统架构中对组件或更低层次的子组件进行的更加详细的讨论，其中主要讨论的方面包括但不限于以下这些：
+
+- 组件的种类，例如子系统、模块、类、包、函数等。
+- 组件的具体目的和语义。
+- 组件的主要职责和主要行为。
+- 任何相关的假设、限制和约束。
+- 子组件的使用和意义描述。
+- 与其他组件协作、相互作用的描述。
+- 任何实体管理、影响或需要的资源。
+- 组件如何履行其职责的描述，包括所使用的算法、状态变化机制、时间或控件复杂性、并发性、创建方法、初始化和清理、异常条件的处理等。
+- 组件提供的服务，包括资源、数据、类型、子程序、异常等。
+