《软件需求规格说明书》的目的?

1. 《软件需求规格说明书》的目的?

《软件需求规格说明书》的目的是作为用户和软件开发人员达成的技术协议书，作为着手进行设计工作的基础和依据，系统开发完成以后，为产品的验收提供了依据。由于用户要能看得懂，并且还能发现和指出其中的错误，这对于保证软件系统的质量有很大的作用。

扩展资料：
《软件需求规格说明书》必须用统一格式的文档进行描述，为了使需求分析描述具有统一的风格，可以采用已有的且能满足项目需要的模板，也可以根据项目特点和软件开发小组的特点对标准进行适当的改动，形成自己的模板。
软件需求说明主要包括引言、任务概述、需求规定、运行环境规定和附录等内容。软件需求说明书应该完整、一致、精确、无二义性，同时又要简明、易懂、易修改。

2. 《软件需求规格说明书》的目的?

《软件需求规格说明书》的目的是作为用户和软件开发人员达成的技术协议书，作为着手进行设计工作的基础和依据，系统开发完成以后，为产品的验收提供了依据。由于用户要能看得懂，并且还能发现和指出其中的错误，这对于保证软件系统的质量有很大的作用。

扩展资料：
《软件需求规格说明书》必须用统一格式的文档进行描述，为了使需求分析描述具有统一的风格，可以采用已有的且能满足项目需要的模板，也可以根据项目特点和软件开发小组的特点对标准进行适当的改动，形成自己的模板。
软件需求说明主要包括引言、任务概述、需求规定、运行环境规定和附录等内容。软件需求说明书应该完整、一致、精确、无二义性，同时又要简明、易懂、易修改。

3. 软件需求规格说明有哪些内容？

软件需求规格说明，也称为功能规格说明、需求协议以及系统规格说明。它精确的阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。软件需求规格说明不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。

它应该尽可能完整的描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或者工程管理的细节。

许多读者使用软件需求规格说明来达到不同的目的：
客户和营销部门依赖它了解他们所能提供的产品。
项目经理根据包含在软件需求规格说明中描述的产品来制定规划并预测进度安排、工作量和资源。
软件开发小组依赖它来理解他们将要开发的产品
测试小组使用软件需求规格说明中对产品行为的描述制定测试计划、测试用例和测试过程。

4. 什么是软件需求，什么是功能需求？

我们的软件产品或者项目，其需求都有三个层级和三个方面。一、我们首先看需求的三个层次软件需求包括3个不同的层次――业务需求、用户需求和功能需求。业务需求 （Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业 务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。用户需求 （user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。功能需求 （functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求 （behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什 么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标 得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用 户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。系统需求 （system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。业务规则 包 括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁 能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能 需求进行追溯时，会发现其来源正是一条特定的业务规则。功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库 或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试 、质量保证、项目管理和其他 相关的项目功能都要用到 SRS。除此之外，对于需求层次，我们还有其它的分法：组织级需求->业务需求->用户需求->功能需求（有时也叫行为需求）。组织级需求： 一 般代表着组织的愿景和目标。对于大的公司，一般是通过资深的咨询顾问和咨询公司得出的，呈现的方式是咨询报告。比如在ITSM或者企业信息化这方面。典型 的组织级的需求是：降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。业务需求： 是要完组织的使命，达成组织的愿景的各个业务流程和业务单元具有的需求。业务需求服从于组织需求。用户需求： 用户级的需求，是在业务级的需求下，各个岗位协作完成业务而具有的需求。我们在软件需求规格说明书中表述的需求其实主要是这一部分需求。功能需求： 同样，它代表着产品或者软件需求具备的能力。 一般是管理人员或者产品的市场部门人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。所有的用 户需求都必须符合业务需求。需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根据功能需求和非功能需求设计解决方案，在约束条 件的限制范围内实现必需的功能，并达到规定的质量和性能指标。当一项新的特性、用例或功能需求被提出时，需求分析员必须思考一个问题：“它在范围内 吗？”。如果答案是肯定的，则该需求属于需求规格说明，反之则不属于。但答案也许是“不在，但应该在”，这时必须由业务需求的负责人或投资管理人来决定： 是否扩大项目范围以容纳新的需求。这是一个可能影响项目进度和预算的商业决策。二、需求的三个方面 除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。质量属性 （quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或 开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。还有一项称为可用性（usability）的质量属性，它规 定了业务需求中“有效”（efficiently）一词的含义。约束（constraint）限制了开发人员设计和构建系统时的选择范围。约束，在产品的架构设计中，是需要被首先考虑的问题。如果说产品的功能代表了产品的能力，那么产品的质量属性代表了产品的品质，产品的约束代表了产品必须去满足的或者适应的条件！用人说“用户体验”是产品的 灵魂，对于个人级的软件这么说或许很恰当，当对于企业级甚至是行业级的产品，其灵魂有两个：一个是产品带个用户的价值，另一个是产品的品质，简单的说，就 是价值和品质。但其成为一个产品的前提应该是满足约束，否则就不应该设计、开发、进入市场而成为一个垃圾。用户需求 功能需求 区别简单的就是： 用户需求。用户需要在应用系统中实现什么东西，为实现这个目标，需要用户提供的全部的详细的业务说明，业务流程，表格样式等。 功能需求。将用户需求归类分解为计算机可以实现的子系统和功能模块，用设计语言描述和解释用户的需求，以达到可以指导程序设计的目的。

5. 软件需求说明书内容都包括哪些

规范化软件开发过程中的《需求说明书》的编写，使之成为整个开发工作的基础。

2 适用范围

本规范适用于集团开发项目的（软件）《需求说明书》的编写。

3 编写内容提示

1 引言

3.1.1 背景说明

说明被开发软件的名称，任务提出者，用户及实现该软件的计算机网络。

3.1.2 参考资料

列出有关资料(名称，发表日期，出版单位，作者等)。

3.1.3 术语和缩写词

列出本文件中用到的专门术语的定义，及术语缩写词。

3.2 软件总体概述

3.2.1 目标

软件开发的意图、应用目标、作用范围以及需说明背景材料。

3.2.2 系统模型

图示说明该软件的所有功能及其相互关系和数据传递情况。

3.2.3 假设和约束

说明影响软件开发、运行环境和系统能力（如预告出错类型的能力）的某些假设和约束。3.3 详细需求

详细描述此软件系统的功能需求和性能需求。

3.3.1 功能需求

对系统中每一个功能，要详细描述（图示或文字）。

概述 叙述功能名称，目标和作用。 
输入 输入该功能的信息。 
处理 描述该功能做什么，如何对输入信息进行加工并转换成输出信息。 
输出 列出内部生成的文件。

3.3.2 性能需求

定量地描述此软件系统应满足的具体性能需求。可考虑以下方面：

3.3.2.1精度

说明系统的精度要求，如：

数据的精度要求。 
数字计算的精度要求。 
数据传送的误码率要求。

3.3.2.2 时间特性

说明系统的时间特性要求，如：

解题时间。 
询问和更新数据文件的响应时间。 
系统各项功能的顺序关系。

3.3.2.3 灵活性

说明当需求发生某些变化时系统的适应能力，指出为适应这些变化而需要设计的软件成分和过程。

3.3.2.4系统容量

包括系统的设计容量和理论（计算）容量。

3.3.3 输入和输出

解释各输入输出数据类型，并逐项说明某媒体、格式、数值范围等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

3.3.4 数据管理能力

说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作估算。

3.3.5 故障处理

列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

3.4 环境

描述所开发软件运行所需的环境。

3.4.1 设备环境

描述运行软件系统所需的设备能力，如：

处理器的型号和内存容量。 
存储媒体的数量。 
通信网络（包括说明网络结构，线路速度及通讯协议等）。

3.4.2 支持软件环境

列出与待开发的软件互相配合的支持软件（包括名称，版本号和文件资料），必要时还应列出测试软件，还要指出该软件用的编程语言，编译程序，操作系统和数据管理系统。

3.4.3 接口

说明本软件与其他软件之间的接口、数据通信协议等。

3.4.4其他

说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。

6. 软件需求说明书的正文

1Introduction简介1.1Purpose目的1.2Scope范围2General description总体概2.1Software perspective软件概述2.1.1About the Project项目介绍2.1.2Environment ofProduct产品环境介绍2.2Software function软件功能2.3User characteristics用户特征2.4Assumptions & Dependencies假设和依赖关系3Requirements Modeling需求建模3.1Modeling tool 1建模工具4Specific Requirements具体需求4.1Functional Requirements功能需求4.1.1Functional Requirements1功能需求4.2Performance Requirements性能需求4.2.1Performance Requirements1性能需求4.3External Interface Requirements外部接口需求4.3.1User Interface用户接口4.3.2Software Interface软件接口4.3.3Hardware Interface硬件接口4.3.4Communication Interface通讯接口5Overall Design Constraints总体设计约束5.1Standards compliance标准符合性5.2Hardware Limitations硬件约束5.3Technology Limitations技术限制6Software Quality Attributes软件质量特性7Dependencies依赖关系8Other Requirements其他需求8.1Database数据库8.2Operations操作8.3Localization本地化9Requirements Classification需求分级10Issues To Be Determined待确定问题11Appendix附录11.1Appendix A附录AFeasibility Analysis Results可行性分析结果

7. 在软件开发中，需求规格说明书和系统设计说明书有什么区别？

1、内容有区别
需求规格说明书主要是描述软件系统应该完成的功能，包含硬件、功能、性能、输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规的要求等等。
设计说明书是说明如何实现这些功能、性能的。设计书中会对功能进行重新的分解，并需要描述这些功能如何实现，甚至包括如何用代码实现。

2、目的不同
需求规格说明书的作用在于便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件开发工作的基础和依据，并作为确认测试和验收的依据。
系统设计说明书编制的目的是说明对程序系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计、运行设计、安全设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。
3、阅读对象不同
需求规格说明书主要从用户角度（需求或市场人员根据用户要求编写）描述软件需要实现的功能。
系统设计说明书主要从软件开发（程序员）角度描述软件需要实现功能。
参考资料：百度百科-软件需求说明书
参考资料：百度百科-概要设计说明书

8. 软件需求说明怎么写

如何写需求分析报告（软件需求说明书GB856T-88）
近来学校的一些科研项目又在申报了，一些学弟开始Q我一些软件工程上书面的问题。大概的总结了下，写到这里。本文涉及到的是需求分析部分的书写，主要是根据国家标准文档中的要求来的。
在互联网公司或者一些敏捷开发的公司里，其实大家都是秉承着重开发，重讨论，而轻文档的态度。这个轻文档并不是指没有文档或者几乎不做文档，而是在严格的文档流程中解脱出来，只把最最实际的部分写出来。这个特征是有互联网本身迭代周期短，版本发布快等特点决定的。而在实际的兼职项目的时候，同学们就要注意了，最重要的应该就是在签合同的时候一定要附上最清楚的一份需求分析，虽然这份需求说明可能不是按照某些标准文档而来的，描述清楚每个功能达到的效果，而这个效果一定要让客户点头确认，而不能出现“应该是”、“可能是”、“也许是”这样的模糊回答。否则在项目后期就会比较难过了。在学校申请的项目和大型公司项目开发中，是重视文档流程的，一部一部来。所以还是看情况来对待文档的深度和标准。

一、目录： 目录要用word的 “引用”—>”目录”，自动生成目录，一般都是要三级目录。通常这部分基本都不需要改结构，直接更新页码即可。
二、内容部分。 国家标准软件需求说明书G856T-88下载
1引言
1.1编写目的
说明编写这份软件需求说明书的目的，指出预期的读者。
（这部分说明需求分析报告的概况，例如：本X需求分析报告是为S系统而编写的。+S系统的两句话概述。+本X报告旨在使U1（需求者）明确S系统的要求和细节，给U2(开发人员)了解需求实现的难度和困难，最终提供给U3（审核人、管理者）讨论和审核，达到沟通效果）

1.2背景
说明：
a．  待开发的软件系统的名称；
b．  本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
c．  该软件系统同其他系统或其他机构的基本的相互来往关系。
（这部分可以将a,b,c分为2部分，例子如下：
1.2.1项目概况
本需求分析报告所预期开发的软件系统是:S。S是（不是则无）SS系统的某一个功能子模块，S和S1、S2等系统之间的联系，以及概述其他系统的状态等等。
1.2.2任务分配
a.       任务提出者：xxx
b.       软件开发者：xx
c.       产品使用者：xx
d.       文档编写者：xx
e.       预期产品使用者：xx
）

1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
（这部分很简单，就是描述专业词汇，比如
1. XML(Extensible Markup Language)即可扩展标记语言,它与HTML一样,都是SGML(Standard Generalized Markup Language,标准通用标记语言)。
2. Word2, 解释。。。
）
1.4参考资料
列出用得着的参考资料，如：
a．  本项目的经核准的计划任务书或合同、上级机关的批文；
b．  属于本项目的其他已发表的文件；
c．  本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2任务概述
2.1目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
（
本模块开发主要是为SS的整体服务，完成SS工作中的XX部分以及相关的工作。其涉及的范围就是，从下达A、B命令后，到给出C结果的过程。具体描述：B1，来完成B11功能；B2，来完成B22功能； 等等。本部分是（否）耦合在分词工具包其他部分中的，主要为嵌入方式和先后方式相互交互。
图

图1. 该系统的组成同其他各部分的联系和接口
）
2.2用户的特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束
（例如：二次开发和系统调用人员：具有很高的专业知识水平，理解XX的运行机制。可以对开放代码进行阅读和分析，以完成其系统独特的需求，提供给这部分用户开放API手册和Debug版本的源代码即可；预期这部分用户会占本系统总用户量的多大部分。
xx使用者：具有一定的计算机操作能力和知识，了解xx领域的相关概念和用途。提供给这部分用户操作手册即可。预期这部分使用者主要是来简单的xx操作。
维护人员：具有较高的计算机专业水平，可以对常见的系统Bug进行追踪和分析，具有一定的测试能力。 这部分用户主要是采用了本系统之后的后期工作维护者。
等等
）
2.3假定和约束
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
（这部分重要是对你有的技术力量、资金状况、人力资源等情况的假设，以使得你可以在什么样的情况和时间范围内完成工作。工期约束，经费约束，人员约束，地理约束，设备约束等几个方面列举说明。）
3需求规定
3.1对功能的规定
用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
（例如：

INPUT输入

PROCESS处理

OUTPUT输出

LOAD负载量



A

预处理,做怎样的动作，

AA

CC



B

BBBB

Bb

v



C

CCCC

cc

v


表一、xx模块IPO表
对IPO表的简单文字描述。
）
3.2对性能的规定
3.2.1精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
（例如：
Xx目标处理：1Byt–10M，包括左右边界值。
yy精度范围：….
ZZ的精度：由于xx的特殊性，本系统均采用xx型来进行字符统计运算，概率部分以及其他比率部分精度精确到0.0x%。
）
3.2.2时间特性要求
说明对于该软件的时间特性要求，如对：
a．  响应时间；
b．  更新处理时间；
c．  数据的转换和传送时间；
d．  解题时间；等的要求。
(这部分只要一一列举就可以：
由于xxx过程中，需要大量xxxx操作或怎样，故xx解题时间占总时间的最大部分。其次就是xx转换和存储的开销。其具体时间特性要求，如下：
a．  xx响应时间：xxms左右；
b．  yy更新处理时间：yy；
c．  zz数据的转换和传送时间：zz；
d．  vv解题时间：vv。
等等
)
3.2.3灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
a．  操作方式上的变化；
b．  运行环境的变化；
c．  同其他软件的接口的变化；
d．  精度和有效时限的变化；
e．  计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
（这部分按列举来即可， 由于本模块第一目的是用于xxx，其次则是xxxx。故本模块的灵活性在于实际应用者的不同。当需求发生某些变化时，该软件对这些变化的适应能力。具体情况如下：
f．   操作方式上的变化：采用集成运行制和独立运行制两种模式，集成运行制是把本模块嵌入到分词工具包的主框架中，提供给用户具有一定UI的可操作软件；独立运行制是可以独立运行于后台，并提供给各种程序调用的模式的工作方式，以增强其生命力。
g．  运行环境的变化：主采用Windows平台的编译版本运行和调试，在时间允许的情况下，同步开发支持SUSE Linux的服务器版本。；
h．  同其他软件的接口的变化：在尽量保证接口不出现变动的情况下，允许接口的重载和再定义。但接口的命名规则是统一的；
i．   精度和有效时限的变化：精度在必须调整的条件下，可以上下浮动10个百分点；有效时限则依据现实的测试情况允许稍大范围的变化。
j．   计划的变化或改进：工作时间安排会存在必然的浮动，这部分要协同分词工具包课题设计组其他成员一同来进行商定，前期的计划可以稍微有些变动，后期的安排尽量按照计划执行。
等等
）
3.3输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
（这部分可以把输入输出分为 3.3.1输入要求和3.3.2输出要求，如下给出一个单元的例子。
XXX输出
数据名称：XXX输出数据
实际含义：用于XX,表示XXXX
数据类型：Character(字符串)
数据格式：XX
数据约束：由于xxx,，大小在xx以内
）
3.4数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
（
根据实际系统要求列举即可

Name名称

Number数量

Size大小

Increase增长



词典xx

xx

xxxx

并行执行，其大小依据实际xx大文本而增长



）
3.5故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
（包括软件压力，内存不足，硬件损坏等，这部分可以根据百度到其常见故障。）
3.6其他专门要求
如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
（例如安全保密性：密钥更换等； 预期扩展：扩展兼容等；OS更换：Slackware转SUSE等
）
4运行环境规定
4.1设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a．  处理器型号及内存容量；
b．  外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
c．  输入及输出设备的型号和数量，联机或脱机；
d．  数据通信设备的型号和数量；
e．  功能键及其他专用硬件
（列举说明即可）
4.2支持软件
列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
（操作系统和版本：xxxx
支撑环境和版本：xxxx
备用IDE环境和版本：xxxx
与该软件有关的软件组件：xxxx
后续可能扩展环境：xxxx

）
4.3接口
说明该软件同其他软件之间的接口、数据通信协议等。
(例如：
a．用户和主程序调用接口(图中接口1)。这个接口采用封装API形式和函数调用形式，分别以外部调用和内部调用的方式为不同用户提供使用本机械分词工具的入口。例如以xxxx方式调用DLL文件，以xxxx方式调用函数。如下图2所示。

图2.软件接口调用图

b.xx接口(图中接口2)。这里是一个xxx的接口调用过程。xxxx
)
4.4控制
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
(例如：
下面通过图表的形式，将本模块以及涉及到本模块的软件模块的运行方法、控制信号，以及这些控制信号的来源，其中箭头所指方向对应的模块的控制信号来自箭头另一方向的模块，具体情况如下：

图3 .控制流程图
图3的具体说明情况如下表所示：

Name模块名称

Method运行方式

Signal控制信号

Forward控制去向



主程序模块

运行框架

用户调用或运行

1.       调用xx模块
2.       调用xx方法
3.       调用标准输出模块



xxx模块

xxx

xxx调用

Xxx模块



)
附录： 软件设计文档国家标准(GB8567–88)软件设计文档国家标准(GB8567–88)GB8567——88操作手册（GB8567——88）.doc 数据库设计说明书（GB8567——88）.doc测试分析报告（GB8567——88）.doc 数据要求说明书（GB856T——88）.doc测试计划（GB8567——88）.doc 图1.doc概要设计说明书（GB8567——88）.doc 文件给制实施规定的实例（GB8567-88）.doc开发进度月报（GB8567——88）.doc 详细设计说明书（GB8567——88）.doc可行性研究报告（GB8567——88）.doc 项目开发计划（GB856T——88）.doc模块开发卷宗（GB8567——88）.doc 项目开发总结报告（GB8567——88）.doc软件需求说明书（GB856T——88）.doc 用户手册（GB8567——88）.doc