产品模块划分设计实现方法
设计需求分解过程指南
1 主题内容与适用范围
本指南为产品开发的初始阶段的模块划分、设计实现、需求分解规定了统一的、最基本的要求，它规定了产品设计需求分解阶段的工作内容、方法、结果和评审。描述了产品设计初始阶段设计需求分解、模块划分、系统设计与实现方法的工作要求与指南。
产品模块划分设计需求分解的结果是产品设计、实现、测试验收和维护的依据。本文件指出了该过程的任务、原则、依据、要求、工作程序和主要内容。适用于新型和改型装备进行的产品模块划分设计需求分解工作和系统的设计与实现。
本指南适用于产品开发的初始阶段。本指南可以根据具体产品要求剪裁使用。
2 引用标准
GJB 190 特性分类
GJB 437 军用软件开发规范
GJB 438 军用软件文档编制规范
GJB 439 军用软件质量保证规范
GJB 450 装备研制与生产的可靠性通用大纲
GJB 726 军工产品质量标志和可追溯性要求
GJB 900 系统安全性通用大纲
GJB 906 成套技术资料质量管理要求
GJB 907 产品质量评审
GJB 939 外购器材的质量管理
GJB 1310 设计评审
3 产品初始设计阶段的工作的任务、原则、依据和要求
3.1 任务
本阶段对产品产品的需求（如功能和性能、可靠性等方面的能力）进行分析和定义，并编制出相应文件。要求编写《功能需求分解表》《接口需求分解表》《接口需求文件》《采购要求说明》《系统模块划分和编码表》。开始编写《用户手册》和《测试计划》。在本阶段的可靠性工作是继续改进和确定产品可靠性和可维修性的目标；制定产品《可靠性、维修性计划》。 产品设计需求分解的任务主要是确定系统或子系统的产品功能需求说明、接口需求说明和数据要求、采购要求说朗。在产品设计初始阶段，承办单位必须根据交办单位提出的战术技术要求，产品开发任务书或合同以及其他有关资料，在对用户进行调查研究的基础上，确定产品的功能、性能、接口、数据、采购、环境需求、产品的安全、保密要求以及假设和约束. 在此基础上编写《初步设计说明书》。明确指出将被开发的产品产品满足系统或子系统的功能和性能的要求。
3.2 设计需求分解的原则
3.2.1 必要性
为了保证满足用户的需求，需要帮助用户对提出的功能要求和需求进行系统化的分析。因为用户提出的需求一般都为隐含的，不明确的，不完全的，经常变化的，有时是错误的。设计者对于工作的划分、组织、管理和人员的使用没有依据。在设计工作最初阶段，必须认真确定和明确用户的功能需求。其目的是为设计工作提供明确的工作任务和工作分工依据；防止错误的理解造成错误和失败的设计；为研制工作模块化分解提供依据；为设计研制工作提供协调和支持；为产品的验收提供依据。
3.2.2 可行性原则
充分考虑已有的技术储备或近期可能获得的预研成果，确保分析的结果可实现。分析的结果与装备研制与生产能力以及其他方面的承受能力相适应。满足研制周期要求。
3.2.3 先进性原则
技术性能先进，满足用户使用要求。合理利用关键性高新技术。产品设计需求分解结果应当使系统、分系统或设备的构成简洁、科学、合理。
3.2.4 经济性原则
在投资强度（寿命周期费用）相同条件下可能获得的使用效果最佳，或用尽可能少的投资获得尽可能高的使用效果。在促进产品技术和武器装备发展方面带来的其他效益尽量多。充分利用和继承同类或其他产品的成熟技术
3.2.5 系统性原则
综合配套；协调发展；整体优化；有利于工程下一步的研制和管理功能兼容。
3.2.6 标准化原则
符合国家军用标准的要求。与已有同类装备标准化程度比较具有较高的总体水平。系列化、通用化、组合化程度高。
3.2.7 对比选优原则
采用系统工程方法，从效能、经费（或寿命周期费用）、进度及其他效果等方面，对所提出的几种需求进行全面的分析和综合比较，提出优选方案，。
3.3 设计需求分解的依据
产品设计需求分解是在系统分析和产品定义的基础上，在完成了可行性研究报告和项目开发计划之后进行的。系统分析提供的有关信息主要有：
a. 系统总体设计要求；
b. 系统性能要求；
c. 设备要求；
d. 接口设计要求；
e. 操作使用要求；
f. 系统设计标准；
g. 系统备份和维护要求。
3.4 要求
承办单位必须编制《功能需求分解表》《接口需求分解表》《接口需求文件》《采购要求说明》《系统模块划分和编码表》及其他有关文档，并进行需求逐步审查。这些文档必须经交办单位审查同意，并通过产品需求评审。在使用本指南时，可根据不同装备系统的层次和项目特点进行剪裁。
4 设计需求分解的工作程序
设计需求分解工作，一般分为4个阶段：任务下达阶段、设计需求分解研究阶段、审查与报批阶段、归档阶段。每一阶段都有其特定任务和目标，一般情况下只有完成前一阶段的任务后方可转入下一阶段工作，特殊情况下，可根据具体项目的特点和要求，将各阶段工作互相交叉进行，但最后都应达到本规范规定的要求。
4.1 任务下达阶段
产品设计需求分解是在系统分析和产品定义的基础上，在完成了可行性研究报告和项目开发计划之后进行的，至正式下达任务书为止。
4.1.1 确定项目产品设计需求分解承担单位
项目承担单位应具备下列条件：
a. 产品专业对口；
b. 有较强的产品研究力量；
c. 有必要的产品科研手段、设备和物资保障条件。
4.1.2 成立产品设计需求分解课题组
课题组一般由项目承担单位负责组建并指分析工作负责人。
4.1.3 下达产品设计需求分解任务书
4.1.3.1 任务书内容一般包括，产品项目名称、内容、经费、进度及文档编制要求。
4.1.3.2 任务书由产品项目提出单位与产品项目承担单位协商后按程序下达，并按规定报送有关部门（单位）。
4.2 设计需求分解研究阶段
该阶段自接到任务书开始，至完成各类文件编写为止。
4.2.1 制定产品设计需求分解实施计划
课题组应根据任务书的要求，制定产品设计需求分解实施计划，实施计划的制定与呈报按本部门的规定执行。
4.2.2 调查研究
调查研究的任务是继续了解有关方面对产品的详细要求，收集和分析国内外有关的资料，并根据实际情况进行必要的研讨和试验。为设计需求分解提供依据。
4.2.3 综合分析和编写
根据第3章规定的原则和要求，按任务书的要求和《军用产品文档编制规范》要求编写《功能需求分解表》《接口需求分解表》《接口需求文件》《采购要求说明》《系统模块划分和编码表》《软件需求说明》《数据要求说明》。制定产品《可靠性、维修性大纲计划》。开始编写《用户手册》和《测试计划》。初稿和其他文件。
在此基础上征求有关专家和用户的意见，并进行综合分析和合理权衡，进一步修改和完善各种方案及相应的文件，形成送审稿。
4.3 审查与报批阶段
该阶段自审查、上报设计需求分解文件开始，至上级正式批复为止。设计需求分解文件上报前应逐级进行审查，并根据需要组织有关专家进行评审。
4.3.1 产品需求评审
在产品设计需求分解阶段末期. 必须进行产品需求评审。评审工作由承办单位负责组织，交办单位参加，评审人员由交办单位和承办单位共同确定，以保证双方对产品需求理解的一致性和准确性。
4.3.2 评审目的
评审的目的是审定承办单位是否明确系统的要求产品需求是否合理，可行，审查产品功能是否覆盖了系统的要求；产品功能与系统要求之间是否一致；并着重审查产品需求说明的准确性、完整性和可理解性。
4.3.3 评审内容
评审的内容应针对产品需求说明、数据要求说明、产品质量保证计划和产品配置管理计划，进行下列项目的分析并得出结论。
任务和需求；根据战术技术要求、任务书和合同要求，对产品需求说明、数据要求说明进行评审。其内容包括功能、性能、接口、数据、环境需求等。
可行性；其内容包括技术、经费、人员要求，系统的投资效益分析、风险分析等。
质量保证；根据产品质量保证计划，检查是否已把质量保证列为产品设计需求分解阶段的一项重要内容。
标准化；检查本阶段工作及产生的文档是否符合有关的产品标准。
可维护性；检查产品需求说明是否规定了产品可维护性的要求。
安全和保密性；检查拔件需求说明是否包括所开发产品的安全和保密措施，以防止对产品的破坏和失泄密事件的发生。
4.3.4 评审结论
评审最终要作出评审结论。如通过，产品开发可进入产品设计阶段。如有条件地通过，则承办单位必须根据评审的意见，对产品设计需求分解阶段工作进行补充或修改，并对补充或修改部分进行评审，直至全部通过评审为止。如未通过，承办单位必须重做产品设计需求分解阶段的工作。
4.3.2 审查后对设计需求分解文件送审稿和其他有关文件做出必要的整理和修改，按科研规定履行报批手续。
4.4 归档阶段
该阶段自论证文件报批后开始，至归档工作全部结束为止。
4.4.1 归档文件主要包括：
任务书；
产品分析实施计划；
功能需求分解表；
接口需求分解表与接口需求文件；
采购要求说明；
系统模块划分编码表；
软件需求说明；
数据要求说明
可靠性、维修性实施计划；
各类报告、来往公文、会议纪要、调研报告；
其他有关资料，如声像、图片、表格及评审资料等。
4.4.2 归档具体要求按科研部的规定执行。
4.5 产品需求说明文件的更改
为了预防产品编制过程的随意性和与用户发生重大冲突，产品需求说明文件经评审通过后，进入技术冻结状态。一般不允许修改。如因特殊情况必须修改时；应遵守下列几条规定； a. 必须取得交办单位和承办单位双方认可，并完整、准确地说明修改内容和原因； b. 必须建立一个正式的修改规程，以标识、控制，追踪和报告产品需求说明的修改； c. 提供准确和完整的审查记录；并同时保存修改前和修改后的条款；
d. 若产品需求说明有重大修改，经承办与交办单位双方同意，可对修改部分重新进行评审。
5 设计需求分解工作指南
本文件改造自GJB2255-94计算机产品，设计的方法和原则可以适用于硬件或嵌入式控制系统。
承办单位根据交办单位提供的战术技术要求、软件开发任务书或合同以及其它有关资料，详细分析所开发产品的功能、性能、接口、数据、环境的需求、产品的安全、保密要求以及假设和约束、确定系统对硬件、软件和其它资源的需求。根据这些需求，可能导出系统的补充要求或修订原来的有关文档。
5.1功能需求
必须给出产品的每一项功能及其目的，确定主要功能和次要功能，并用文字、图形、逻辑或数学方法描述其特性。
5.1.1 输入
必须确定与功能有关的所有输入信息，包括其来源、意义、表现形式、数据格式、接收方法、数量、输入范围及换算方法，必须说明时间要求、优先顺序（常规作业，紧急情况），操作控制要求和所用的输入媒体。
5.1.2 处理
必须确定输入到中间物理量、信号、数据直到获得预期输出结果的全部过程，操作的准确顺序，非正常情况的响应。对每种处理功能以及算法及其实现作文字描述，必要时给出图形、逻辑描述或相应的数学描述。
5.1.3 输出
必须确定与功能有关的所有输出信息，包括信息的传送方法、意义、格式、数量、输出范围及换算方法。必须说明时间要求、优先顺序和输出形式（运动、仪表指示、显示、打印等）。
5.1.4 特殊要求
必须确定系统是否有特殊要求或应急措施。
5.2 性能需求
定量描述产品系统应满足的具体性能需求。如输出物理量、信号、数据能力，处理数据的最大容量、相应要求、从输入到响应所允许的最长时间以及适应用户需求变化的能力等。
5.2.1 能力和容量要求
确定系统的能力容量要求，如负载能力、检测能力、处理的记录数和处理数据的最大容量等。
5.2.2 精度要求
确定系统的精度要求。如控制的精度、测量的精度、数据或数值计算的精度要求、数据传输的精度要求等。
5.2.3 时间特性要求
确定系统的时间特性要求。如检测、处理时间、响应时间及其峰值负载期间允许偏离范围，系统各项功能的顺序关系，由于输入类型的不同和操作方式的变化而引起的优先顺序的变化等。
5.2.4 适应性要求
必须指明反映系统环境变化和系统适应能力的各种参数. 说明当需求发生某些变化时系统的适应能力，指出为适应这些变化而需要设计的软件成分和过程。
5.2.5 通用要求
对任何产品的通用要求。来自产品的研制总要求。一般参考GJBZ 20221-6《武器装备论证通用规范战术技术指标论证》要求进行分析。
5.3 接口需求
必须确定产品与外部其他装备的各种接口关系，指明每个接口的特性。
5.3.1与外部设备的接口
必须指明产品与各种外部设备的接口关系，特别是与输入输出设备和专用设各的接口。必须说明每种设备对产品的要求、设备的型号、功能、控制方法、物理量、信号、数据流向以及在系统中指定的设备号。
5.3.2与其他系统的接口
必须指明产品与其他产品、系统和设备的接口及其性能要求。
5.3.3人机接口
必须指明产品的人机界面，明确操作及使用要求。
5.3.4 产品内部的接口
必须按产品的模块划分结果和产品结构，逐个、逐模块的指明产品内部各种模块的接口关系，特别是各模块的输入输出的接口。必须说明每个模块功能、控制方法、物理量、信号、数据流向以及在系统中指定的模块号。
5.4 数据需求和采购需求
必须定义系统使用的各种数据，并说明数据采集的要求。必须规定静态数据、动态输入输出数据和内部生成数据的逻辑结构，列出这些数据的清单，说明对数据元素的约束。同时，必须规定数据采集的要求。说明被采集数据的特性、要求和范围。数据要求说明的内容和格式见GJB438。产品开发过程中，应有一个书面形式的采购要求说明，明确指出对关键数据、设备和物资采购的要求情况，包括产品使用的各种数据，设备物资以及对采购的要求。
5.4.1 采购要求说明的技术内容
5.4.1.1 采购描述
采购要求说明应对待开发产品所涉及到的数据、设备和物资予以描述，对可预料的采购约束也应加以说明。
5.4.1.2 数据、设备、物资的采购
采购要求说明必须描述用户必要的采购活动，说明采购的要求和范围、数据设备物资的来源、采购与运输等问题，以便采购到适宜的数据和物资。
5.4.2 采购要求说明的编制规定
采购要求说明应完整地说明在产品的开发过程中必须处理的所有采购需求，并向用户说明采购要求。
5.5 环境需求
环境需求包括硬件环境与支持软件环境的需求。
5.5.1硬件环境
必须说明和确定运行软件系统所需的硬件设备。说明当前可用的设备和要求的新设备，必要时可给出设备的余量要求。例如：
电源的要求;
配套的运输设备;
供水设备;
锅炉设备;
起吊设备;
地基;
输入输出设备的种类、数量和要求；
通信、网络设备的要求。
5.2.2支持软件环境
必须指明与软件开发和运行有关的全部支持软件，包括操作系统. 高级语言处理程序、数据库管理系统和软件开发工具等。
5.6 安全和保密要求
承办单位必须与交办单位共同确定整个系统及子系统的使用范围，确定软件安全措施和保密要求。
5.7 可修改性要求
确定哪些产品功能可能发生变动以及功能变动后修改硬件和软件所需的时间和范围。
5.8 假设和约束
必须说明影响产品开发和运行环境的一些假设、约束及影响系统能力的某些限制。
5.9 设计需求分析阶段的产品与其他要求
5.9.1 文档
在设计需求分析阶段，必须完成产品需求说明和数据要求说明的编写工作，并开始起草用户手册和测试计划. 其内容与格式见GJB 438。如果承办单位要补充或修改系统分析与软件定义阶段的文档，应取得交办单位的同意，并完整、准确地做好修改记录。
5.9.2 产品质量保证计划
产品质量保证计划是保证与提高产品质量的重要手段、在需求分析阶段，应修订或制订质量保证计划，其内容与格式见GJB 439。
5.9.3 产品模块划分和配置管理计划
在需求分析阶段，根据产品模块划分和配署管理的要求，应编制模块划分和配置管理计划。该计划用于对产品模块和配置项的标识、控制、修改和状态记录。其主要内容如下： a. 模块划分和配置标识规程；
b. 模块划分和配置控制规程；
c. 模块划分和配置状态记录；
d. 模块划分检查和评审规程。
5.9.4 产品开发标准和规程
在设计需求分析阶段，还应确定开发软件的标准和规程，其内客包括：
a. 开发过程所用的技术、方法、设计标准和设计约束及有关工具；
b. 程序编制的标准和约定；
c. 在特殊情况下，允许不采用自顶向下方法的准则；
d. 所有非正式文档的内容和格式。
5.9.5 研制总要求中提出的战术技术指标中的通用要求
具体要求和分析参考《科研论证工作要求与指南战术技术指标论证》内的要求进行研究分解。
5.9.6 衡量需求说明的标准
需求说明应是；
a. 无歧义的，即每个需求只有一种解释
b. 完整的，即每个需求在内容、格式和输入数据的定义方面是完整的；
c. 可验证的，即每个需求都是可验证的；
d. 一致的，即每个需求之间互相不矛盾；
e. 一可修改的，即需求的修改是易实现的，并保证修改后的需求是完整的、一致的； f. 可追踪的，即每个需求的来源是清晰的、并易于追溯其来源；
g. 易使用的，即在运行和维护阶段易于使用。
6 产品设计与实现方法
6.1 分析和设计原则
6.1.1 分析和设计应是((个决策过程。首先需确定需求的概念模型，然后选定把模型转换为满足产品系统需求的设计方法。最后，利用所选择的最佳设计方法，开发系统的功能。
6.1.2 开发任务承办单位应使用白顶向下的方法设计系统。从高层系统功能开始，通过向低层的功能分配、评价和比较来实现后续的低层设计。
6.1.3 为支持自顶向下的分析和设计，推荐的方法是结构化分析和结构化设计方法；推荐的设计描述方法为系统结构图、结构图、N2图。
6.1.4 设计应遵循以下步骤：
a. 从建立功能设计层次结构开始，以顶层表示整个系统执行的全部任务；
b. 通过逐渐分析把系统划分成为更细化的功能块，从而得出系统的设计层次； c. 将所有的需求逐一分配和映射到这些设计层次；
d. 明确定义设计层次结构的最低层，使所开发系统成为实现所有需求的全部输入到输出路径所必须的常规工程制造方法、算法和数据处理功能的有序集合。
6.2 系统的分析与设汁方法
6.3.1.2.1 结构化分析
本条提供一种可用于分析、定义和记录系统功能和接口需求的有效方法。这也是一种将高层需求分解为更详细需求的图形表达方法。它主要包括：系统结构图、处理逻辑和数据字典。
6.2.1.1 系统结构图
系统结构图用规定的各种符号来表示物理量、信号、数据的流向、处理及装置等，以描述求解某问题的物理量、信号、数据流的模拟和逻辑通道。
系统结构图应有下列四种基本元素：
a. 物理量、信号、数据流向
用箭头表示。物理量、信号、数据流可以由一个或((组数据元素组成。物理量、信号、数据元序列可以根据数据流的法定结构所规定的语法规则排列。
必须注意，物理量、信号、数据流仅用来表示数据的流向，而不表示控制的流向。 b. 处理
用矩形符号表示各种处理功能。处理应是一种数据转换的发生点。
应注意，转换可能是简单的，如存储物理量、信号、数据；也可能很复杂，如将模拟物理量、信号、数据转换为一系列物理量、信号、数字信息分配给其他外部系统。
c. 物理量、信号、数据存储
用符号仁工表示以一种适合于处理的形式表达的物理量、信号、数据存储，但未规定媒体。物理量、信号、数据存储指明某数据从一处理点到准备接收此物理量、信号、数据的下一处理点之间有延迟物理量、信号、数据存储的地方。
d. 外部实体
用(、(、(等符号表示显示器、文件、人工操作等。也可以用正方形表示与系统相连接的其他数据源或数据用户。
应注意，外部实体可以是其它系统或与系统相互作用的人。有关系统结构图的详细规定参见GB 1526.
6.2.1.2 物理量、信号、处理方法
物理量、信号、处理方法应是描述每一层处理将输入物理量、信号、数据转换为正确的输出物理量、信号、数据所必需发生的处理方法序列。
6.2.1.2.1 系统结构图中的处理必须用处理方法说明来描述
大系统的系统结构图中，处理往往包括许多隐含的重要的物理量、信号、数据转换。进行分
析和设计时，应将每一高层的处理逐一分解为更详细、更低层的系统结构图，直到所有功能均可用简单的、严格定义过的处理来表达出来为止。在这一系列系统结构图中，所有处理均须用处理方法、逻辑的说明来描述。
6.2.7.2.2 描述处理方法可用下述方法：
a. 结构化语言
把结构化程序设计中描述结构(操作顺序、操作的循环、操作的选择等) 的语法与该语言的语法相结合；
b. 判定表(树)
适合于描述小的、复杂的处理；
c. 其他
任何有效地描述完成处理功能的步骤序列的方法，甚至自然语言均可使用。
6.2.1.3 物理量、信号、数据检索表
物理量、信号、数据检索表应记录系统中所有物理量、信号、数据，包括物理量信号数据结构、物理量信号数据存储和独立的数据元素。物理量信号数据检索表应与系统的系统结构图同时建立。
6.2.2 结构化设计
结构化设计方法包括产生最佳设计的策略、方案以及设计文档的图形描述模式。这里所述的图形描述应是系统结构图和结构图。结构图是一种用于记录设计决策的模块化层次图。它表述产品的各个功能如何分配到程序单元中去，并描述最终的单元接口。
结构化设计用于建立和描述系统的结构设计。并可用于标识和记录所必须建立的处理功能和程序单元。在设计已用结构化分析方法定义的功能需求时，结构化设计方法尤其适用。 结构化设计不仅为硬件和产品设计提供重要的开发方法，而且为评价系统设计提供重要的指南。
6.2.2.1 方法
a. 画系统结构图
结构化设计方法要求设计人员必须将所有穿过系统的数据流标识和记录于系统结构图中，作为系统设计的基础。
系统结构图中的矩形等表示数据的处理(转换) 点可能有一次或多次中间转换，但最终必须是正确形式的输出。
b. 构造结构图
一旦确定好所有数据处理(转换) 点后，即可构造结构图，用结构图描述所有数据转换所必需的功能集合。
设计人员可以按系统设计要求将系统全部功能进行逐层分解，以确定结构图的功能模块项和层次结构。分解的原则应是按功能将硬件、产品分解为对其他部分影响最小的简单且相对独立的功能模块或程序处理单元。一般要求每个模块仅含一个入口和一个出口。
除指明功能模块和程序单元所执行的功能外，在进行系统结构设计，构造结构图时，还必须标识那些在各功能模块之间进行控制信号处理的模块，它们向下层模块传递信号、控制下层模块运行井接收其输出。
应当注意，最低层的模块应当是实现具体功能处理或计算而不是操纵或控制其他模块的模块。设计人员在系统初步设计阶段中，描述待开发系统的硬件和产品结构时尤其应选用结构图。
6.2.2.2 设计评价
从系统结构图出发构造结构图，通常不可能一次就把模块或程序单元组织好。往往需要反复调整、修改。因而，结构化设计方法为硬件和产品设计提供了评价设计的指南。最基本最主要的是下述三条：
a. 耦合
度量模块之间的关系；
b. 内聚
度量单个模块中元素的关联程度；
c. 模块的控制范围和判定的影响范围。
6.2.2.2.1 耦合
结构化设计方法用耦合概念来度量模块间的关系。一个模块越是相对独立就越易于理解；它传递变化和错误的路径数目越少，则该模块化设计越好。
越是简单的模块接口，越可以提高可靠性，并降低硬件和产品对修改的敏感性。 结构化设计方法规定耦合的五个级别，优先采纳的顺序如下：
a. 物理量、电、数据耦合
输入的数据元素应以可以测量的显式参数的形式传给另一模块的接口，使用模块功能无须知道物理量、电、数据如何被使用。
b. 控制耦合
形成控制的接口方式，例如：使用指定要求处理类型的物理量、电、变量。这时，要求发送模块输出一个控制信号，接收模块测试此信号。
c. 外部耦合
模块通过检查和使用已在另一模块中驻留的物理量、电、数据变量来接收其输入的接口方式，例如：模块间相互共用信号。
d. 公共数据耦合
所需物理量、电、数据是更大的物理量、电、数据集合中一部分的接口方式，例如：公共物理量、电、数据结构的使用。采用公共物理量、电、数据耦合设计的系统中，物理量、电、数据流是无法跟踪的，容易造成干扰。
c. 内容耦合
设计一个模块时，必须了解其他模块的技术细节的接口层。例如：必须知道其他设备内部的工作情况才能进行设计。内容耦合的模块往往可共用设备。
6.2.2.2.2 内聚
结构化设计方法用内聚性来度量模块中元素的相互关联程度。
结构化设计方法要求将硬件、产品按功能尽可能地分解为较小的、功能相对独立的功能模块。衡量内聚性，促使设计者区分功能内聚和非功能内聚的模块。结构化设计的目标应尽可能将程序细分为功能内聚模块。
结构化设计方法的观点认为，内聚性从最好到最差的顺序应排列如下：
a. 功能内聚
功能内聚的模块应是全部成分均为执行单一的、相对独立的处理功能的模块。例如：电机、指示灯、车轮等。
b. 顺序内聚
顺序内聚的模块应是一种其中某处理成分的输出用于下一成分输入的模块。这种模块是 基于控制结构而组织的。例如：放大器、减速器。
c. 通信内聚
通信内聚的模块应是一种全部元素在同一类型输入物理量、电、数据集上操作并(或) 产生同样类型的输出物理量、电、数据的模块。这是一种将输入和输出组合在相同模块中的模块化。例如：通讯网络；并联供电系统；液压助力器。
d. 时间内聚
为处理面向时间的活动而建立的模块。这是一种其成分仅在时间上相关的内聚方式。例如：
某飞机的启动系统；机械、电子定时器。
e. 逻辑内聚
以逻辑分组形式组合的模块。例如继电器连锁保护装置；
f. 偶然内聚
其中的元素没有关系或几乎没有关系的模块。例如：为了整齐将各系统的导线绑扎在一起； 上述六个级别的内聚性也可能并非唯一地出现在同一模块中。
上述的耦合和内聚性是相关的。结构化设计观点认为，力求高内聚、低耦合，二者之中内聚性更为重要。
6 2.2.2.3 模块的控制范围与判定的影响范围
模块的控制范围与判定的影响范围应作如下定义：
a. 模块的控制范围
模块本身以及设备模块组织中该模块下属的全部子模块的集合。
b. 判定的影响范围
包括根据判定结果而运行的模块在内的全部模块的集合。
为使系统工作和运行路径的复杂性最小，并能降低耦合。模块判定的影响范围应在该模块的控制范围之内。
6.2. 2.2.4 模块的规模和合理的控制范围
a. 模块的规模应当尽可能小，小到易于理解。
b. 合理的控制范围
直接从属于某给定模块的子模块数量不应多于9个；尽可能不多于7个。
6.2.3 N2图
N2图突出系统各组成部分以及其功能之间的接口和内部联系，提供一种系统开发过程中用图形描述接口的好方法。
6.2.3.1 构造N2图应遵守下列基本规则：
a. 所有功能均在对角线上的方框中表述；
b. 所有输出均为横向(左或右) 表示；
c. 所有输入均为纵向(上或下) 表示；
d. 所有非功能的方块用来定义一种单向的有关功能间的接口关系。对接口的说明可以在交叉的方块中给出。如果复杂，也可以在交叉的方块中给出带数字的圆圈，并附上每个接口相应数字的说明表来描述。空白的交叉点则表示没有接口关系。
6.2.3.2 N2图可以用来描述任意层次的接口。无论系统之间、子系统之间、程序之间、子程序之间、模块之间还是程序单元之间均可用N ‘图来描述其接口关系。
6.2.3.3 在模块需求定义、初步设计和详细过程中，本标准推荐使用N2图分析定义并设计接口关系。
N2图突出接口存在与否，为设计人员指明特别复杂、难以处理或容易遗漏的接口。当数据流和接口复杂时，N2图对于结构化设计方法是十分有用的补充。其他方法无法处理的许多接口，N2图往往能有效地提供可追踪性。
接口关系描述图
功能1
F1
F1-》F2
1
F1-》F3
2
F1-》F4
3
F1-》F5
4
F2-》F1
5
功能2
F2
F2-》F3
6
F2-》F4
7
F2-》F5
8
F3-》F1
9
F3-》F2
10
功能3
F3
F3-》F4
11
F3-》F5
12
F4-》F1
13
F4-》F2
14
F4-》F3
15
功能4
F4
F4-》F5
16
F5-》F1
17
F5-》F2
18
F5-》F3
19
F5-》F4
20
功能5
F5
8 科研项目功能设计需求分解工作指南
8.1 系统功能设计需求分解的目的
为了保证满足用户的需求，需要帮助用户对提出的功能要求和需求进行系统化的分析。因为用户提出的需求一般都为隐含的，不明确的，不完全的，经常变化的，有时是错误的。在设计工作最初阶段，必须认真确定和明确用户的功能需求。其目的是为设计工作提供明确的工作任务和工作分工依据；为研制工作模块化分解提供依据；为设计研制工作提供协调和支持；为产品的验收提供依据。功能需求分配表是分析的重要手段，该表是研制方案的功能设计需求分解和系统验收标准重要的附件。
8.2 功能设计需求分解的内容；
8.2.1 产品、硬件的每个系统、每个分系统、每个模块、功能的设计需求分解
该分析的目的是根据用户的实际需求，产生所要进行设计工作的系统的具体组成。将设计工作与用户实际需求进行结合，最后将所有工作任务落实到具体的人。
各系统应当将《研制总要求》中内容分类作为各系统验收的标准，同时进一步分解为对子系统验收标准，并且参照标准制定系统和子系统相应的、可测量的验收检验方法和指标。最后落实到具体研制人员，去实现每个功能需求（要求）。该需求的分析直接影响设计开发的最终质量。
参加分解的人员应当在认真研究《研制总要求》的基础上，对国家标准和《研制总要求》进行详细讨论与分解。编写功能设计需求分解文件，《功能设计需求分解表》可以系统的对研制对象的功能需求进行逐条分解，作为各系统研制的依据和验收的标准。在分析表的后面，逐条对接口功能需求按《研制总要求》条款内容进行填写。在对《研制总要求》条款内容分析后，简要描述本系统完成要求需要进行研制内容以及建立的产品、硬件配置模块，描述功能实现的技术要求以及验证的方式，描述完成功能需要的支持。最后形成完备的接口设计需求分解文件
功能应当是产品和硬件制造和实现的的目的，一般都是产品或模块划分的依据，产品功能划分一般与产品模块划分直接关联。
8.2.2 每个层次、每个系统、每个分系统、每个模块、每个工作任务、每个工作项目之间的接口的功能和需求的分析
接口功能设计需求分解产生的描述文件的作用是：
a. 为初步设计提供设计需求分解与完整性支持；
b. 为各系统接口协调提供依据与完整性支持；
c. 为研制工作模块化分解提供依据；
d. 为各系统验收提供完整性支持；
对于硬件设计，也建议在方案设计和初步设计时参考采用产品设计的方法和文件系统。这样可以同时保证产品与硬件的接口设计控制在同一种文件系统或同一个文件中。特别是对于比较小的系统，既有产品又有硬件。可以使设计人员使用更少种类的文件。
8.3 功能设计需求分解表
本表作为工作任务划分和接口技术协调的依据，是保证设计的可追述性和可控制性的重要文件。他可以保证设计工作责任落实到人。
本表将《研制总要求》中的功能和需求分解落实到相应的负责人，最后由负责人负责完成设计和加工任务。
设计过程的分解等级根据参加设计的人员和设计程序确定。
对于大的设计需求，可以由负责人编写该需求（要求）的分析表，将需求分配到下一级设计过程。并注明向下分解。
对于相关到多个人员的设计需求，由参加本条目的负责人协调进行需求分解，将需求（功能需求和接口需求）分配到本人负责的下一级设计过程，
XX 系统设计功能设计需求分解表
方案提出的要求条目
简要说明和代码
条目落实负责人
人名1
人名2
人名3
人名4
人名5
4 XX 系统接口设计需求分解表
功能与需求编码：（按设计功能设计需求分解表编号填写）
工作任务编码:（按工作单元代码填写）
分析负责人： 分析时间：
接口关系描述图
模块1
F1
F1-》F2
1
F1-》F3
2
F1-》F4
3
F1-》F5
4
F2-》F1
5
模块2
F2
F2-》F3
6
F2-》F4
7
F2-》F5
8
F3-》F1
9
F3-》F2
10
模块3
F3
F3-》F4
11
F3-》F5
12
F4-》F1
13
F4-》F2
14
F4-》F3
15
模块4
F4
F4-》F5
16
F5-》F1
17
F5-》F2
18
F5-》F3
19
F5-》F4
20
模块5
F5
接口设计需求分解描述文件
本表为接口设计需求分解提供帮助。需求（包括接口需求）是功能实现的输入和支持条件。产品或硬件模块将需求转换为功能。上面的5个模块需求表格，需要分别编写20个接口分
析需求文件。按照接口需求每个分析文件编写条目的要求如下：
（模块名称）接口设计需求分解
a. 提供方名称及工作代码；
b. 接口信息描述；包括数据、信息、知识要求，功能、性能指标、时间序列、 c. 提供方式描述；载体、接口、协调方法、参加协调方数量及工作代码名称等。 d. 提供时间描述；满足需求方接口需求的时间、进度等。
e. 提供仿真描述；用于无法按时或直接提供接口服务时, 为保证研制工作顺利进行，而采用仿真方法替代的描述。
产品模块划分设计实现方法
设计需求分解过程指南
1 主题内容与适用范围
本指南为产品开发的初始阶段的模块划分、设计实现、需求分解规定了统一的、最基本的要求，它规定了产品设计需求分解阶段的工作内容、方法、结果和评审。描述了产品设计初始阶段设计需求分解、模块划分、系统设计与实现方法的工作要求与指南。
产品模块划分设计需求分解的结果是产品设计、实现、测试验收和维护的依据。本文件指出了该过程的任务、原则、依据、要求、工作程序和主要内容。适用于新型和改型装备进行的产品模块划分设计需求分解工作和系统的设计与实现。
本指南适用于产品开发的初始阶段。本指南可以根据具体产品要求剪裁使用。
2 引用标准
GJB 190 特性分类
GJB 437 军用软件开发规范
GJB 438 军用软件文档编制规范
GJB 439 军用软件质量保证规范
GJB 450 装备研制与生产的可靠性通用大纲
GJB 726 军工产品质量标志和可追溯性要求
GJB 900 系统安全性通用大纲
GJB 906 成套技术资料质量管理要求
GJB 907 产品质量评审
GJB 939 外购器材的质量管理
GJB 1310 设计评审
3 产品初始设计阶段的工作的任务、原则、依据和要求
3.1 任务
本阶段对产品产品的需求（如功能和性能、可靠性等方面的能力）进行分析和定义，并编制出相应文件。要求编写《功能需求分解表》《接口需求分解表》《接口需求文件》《采购要求说明》《系统模块划分和编码表》。开始编写《用户手册》和《测试计划》。在本阶段的可靠性工作是继续改进和确定产品可靠性和可维修性的目标；制定产品《可靠性、维修性计划》。 产品设计需求分解的任务主要是确定系统或子系统的产品功能需求说明、接口需求说明和数据要求、采购要求说朗。在产品设计初始阶段，承办单位必须根据交办单位提出的战术技术要求，产品开发任务书或合同以及其他有关资料，在对用户进行调查研究的基础上，确定产品的功能、性能、接口、数据、采购、环境需求、产品的安全、保密要求以及假设和约束. 在此基础上编写《初步设计说明书》。明确指出将被开发的产品产品满足系统或子系统的功能和性能的要求。
3.2 设计需求分解的原则
3.2.1 必要性
为了保证满足用户的需求，需要帮助用户对提出的功能要求和需求进行系统化的分析。因为用户提出的需求一般都为隐含的，不明确的，不完全的，经常变化的，有时是错误的。设计者对于工作的划分、组织、管理和人员的使用没有依据。在设计工作最初阶段，必须认真确定和明确用户的功能需求。其目的是为设计工作提供明确的工作任务和工作分工依据；防止错误的理解造成错误和失败的设计；为研制工作模块化分解提供依据；为设计研制工作提供协调和支持；为产品的验收提供依据。
3.2.2 可行性原则
充分考虑已有的技术储备或近期可能获得的预研成果，确保分析的结果可实现。分析的结果与装备研制与生产能力以及其他方面的承受能力相适应。满足研制周期要求。
3.2.3 先进性原则
技术性能先进，满足用户使用要求。合理利用关键性高新技术。产品设计需求分解结果应当使系统、分系统或设备的构成简洁、科学、合理。
3.2.4 经济性原则
在投资强度（寿命周期费用）相同条件下可能获得的使用效果最佳，或用尽可能少的投资获得尽可能高的使用效果。在促进产品技术和武器装备发展方面带来的其他效益尽量多。充分利用和继承同类或其他产品的成熟技术
3.2.5 系统性原则
综合配套；协调发展；整体优化；有利于工程下一步的研制和管理功能兼容。
3.2.6 标准化原则
符合国家军用标准的要求。与已有同类装备标准化程度比较具有较高的总体水平。系列化、通用化、组合化程度高。
3.2.7 对比选优原则
采用系统工程方法，从效能、经费（或寿命周期费用）、进度及其他效果等方面，对所提出的几种需求进行全面的分析和综合比较，提出优选方案，。
3.3 设计需求分解的依据
产品设计需求分解是在系统分析和产品定义的基础上，在完成了可行性研究报告和项目开发计划之后进行的。系统分析提供的有关信息主要有：
a. 系统总体设计要求；
b. 系统性能要求；
c. 设备要求；
d. 接口设计要求；
e. 操作使用要求；
f. 系统设计标准；
g. 系统备份和维护要求。
3.4 要求
承办单位必须编制《功能需求分解表》《接口需求分解表》《接口需求文件》《采购要求说明》《系统模块划分和编码表》及其他有关文档，并进行需求逐步审查。这些文档必须经交办单位审查同意，并通过产品需求评审。在使用本指南时，可根据不同装备系统的层次和项目特点进行剪裁。
4 设计需求分解的工作程序
设计需求分解工作，一般分为4个阶段：任务下达阶段、设计需求分解研究阶段、审查与报批阶段、归档阶段。每一阶段都有其特定任务和目标，一般情况下只有完成前一阶段的任务后方可转入下一阶段工作，特殊情况下，可根据具体项目的特点和要求，将各阶段工作互相交叉进行，但最后都应达到本规范规定的要求。
4.1 任务下达阶段
产品设计需求分解是在系统分析和产品定义的基础上，在完成了可行性研究报告和项目开发计划之后进行的，至正式下达任务书为止。
4.1.1 确定项目产品设计需求分解承担单位
项目承担单位应具备下列条件：
a. 产品专业对口；
b. 有较强的产品研究力量；
c. 有必要的产品科研手段、设备和物资保障条件。
4.1.2 成立产品设计需求分解课题组
课题组一般由项目承担单位负责组建并指分析工作负责人。
4.1.3 下达产品设计需求分解任务书
4.1.3.1 任务书内容一般包括，产品项目名称、内容、经费、进度及文档编制要求。
4.1.3.2 任务书由产品项目提出单位与产品项目承担单位协商后按程序下达，并按规定报送有关部门（单位）。
4.2 设计需求分解研究阶段
该阶段自接到任务书开始，至完成各类文件编写为止。
4.2.1 制定产品设计需求分解实施计划
课题组应根据任务书的要求，制定产品设计需求分解实施计划，实施计划的制定与呈报按本部门的规定执行。
4.2.2 调查研究
调查研究的任务是继续了解有关方面对产品的详细要求，收集和分析国内外有关的资料，并根据实际情况进行必要的研讨和试验。为设计需求分解提供依据。
4.2.3 综合分析和编写
根据第3章规定的原则和要求，按任务书的要求和《军用产品文档编制规范》要求编写《功能需求分解表》《接口需求分解表》《接口需求文件》《采购要求说明》《系统模块划分和编码表》《软件需求说明》《数据要求说明》。制定产品《可靠性、维修性大纲计划》。开始编写《用户手册》和《测试计划》。初稿和其他文件。
在此基础上征求有关专家和用户的意见，并进行综合分析和合理权衡，进一步修改和完善各种方案及相应的文件，形成送审稿。
4.3 审查与报批阶段
该阶段自审查、上报设计需求分解文件开始，至上级正式批复为止。设计需求分解文件上报前应逐级进行审查，并根据需要组织有关专家进行评审。
4.3.1 产品需求评审
在产品设计需求分解阶段末期. 必须进行产品需求评审。评审工作由承办单位负责组织，交办单位参加，评审人员由交办单位和承办单位共同确定，以保证双方对产品需求理解的一致性和准确性。
4.3.2 评审目的
评审的目的是审定承办单位是否明确系统的要求产品需求是否合理，可行，审查产品功能是否覆盖了系统的要求；产品功能与系统要求之间是否一致；并着重审查产品需求说明的准确性、完整性和可理解性。
4.3.3 评审内容
评审的内容应针对产品需求说明、数据要求说明、产品质量保证计划和产品配置管理计划，进行下列项目的分析并得出结论。
任务和需求；根据战术技术要求、任务书和合同要求，对产品需求说明、数据要求说明进行评审。其内容包括功能、性能、接口、数据、环境需求等。
可行性；其内容包括技术、经费、人员要求，系统的投资效益分析、风险分析等。
质量保证；根据产品质量保证计划，检查是否已把质量保证列为产品设计需求分解阶段的一项重要内容。
标准化；检查本阶段工作及产生的文档是否符合有关的产品标准。
可维护性；检查产品需求说明是否规定了产品可维护性的要求。
安全和保密性；检查拔件需求说明是否包括所开发产品的安全和保密措施，以防止对产品的破坏和失泄密事件的发生。
4.3.4 评审结论
评审最终要作出评审结论。如通过，产品开发可进入产品设计阶段。如有条件地通过，则承办单位必须根据评审的意见，对产品设计需求分解阶段工作进行补充或修改，并对补充或修改部分进行评审，直至全部通过评审为止。如未通过，承办单位必须重做产品设计需求分解阶段的工作。
4.3.2 审查后对设计需求分解文件送审稿和其他有关文件做出必要的整理和修改，按科研规定履行报批手续。
4.4 归档阶段
该阶段自论证文件报批后开始，至归档工作全部结束为止。
4.4.1 归档文件主要包括：
任务书；
产品分析实施计划；
功能需求分解表；
接口需求分解表与接口需求文件；
采购要求说明；
系统模块划分编码表；
软件需求说明；
数据要求说明
可靠性、维修性实施计划；
各类报告、来往公文、会议纪要、调研报告；
其他有关资料，如声像、图片、表格及评审资料等。
4.4.2 归档具体要求按科研部的规定执行。
4.5 产品需求说明文件的更改
为了预防产品编制过程的随意性和与用户发生重大冲突，产品需求说明文件经评审通过后，进入技术冻结状态。一般不允许修改。如因特殊情况必须修改时；应遵守下列几条规定； a. 必须取得交办单位和承办单位双方认可，并完整、准确地说明修改内容和原因； b. 必须建立一个正式的修改规程，以标识、控制，追踪和报告产品需求说明的修改； c. 提供准确和完整的审查记录；并同时保存修改前和修改后的条款；
d. 若产品需求说明有重大修改，经承办与交办单位双方同意，可对修改部分重新进行评审。
5 设计需求分解工作指南
本文件改造自GJB2255-94计算机产品，设计的方法和原则可以适用于硬件或嵌入式控制系统。
承办单位根据交办单位提供的战术技术要求、软件开发任务书或合同以及其它有关资料，详细分析所开发产品的功能、性能、接口、数据、环境的需求、产品的安全、保密要求以及假设和约束、确定系统对硬件、软件和其它资源的需求。根据这些需求，可能导出系统的补充要求或修订原来的有关文档。
5.1功能需求
必须给出产品的每一项功能及其目的，确定主要功能和次要功能，并用文字、图形、逻辑或数学方法描述其特性。
5.1.1 输入
必须确定与功能有关的所有输入信息，包括其来源、意义、表现形式、数据格式、接收方法、数量、输入范围及换算方法，必须说明时间要求、优先顺序（常规作业，紧急情况），操作控制要求和所用的输入媒体。
5.1.2 处理
必须确定输入到中间物理量、信号、数据直到获得预期输出结果的全部过程，操作的准确顺序，非正常情况的响应。对每种处理功能以及算法及其实现作文字描述，必要时给出图形、逻辑描述或相应的数学描述。
5.1.3 输出
必须确定与功能有关的所有输出信息，包括信息的传送方法、意义、格式、数量、输出范围及换算方法。必须说明时间要求、优先顺序和输出形式（运动、仪表指示、显示、打印等）。
5.1.4 特殊要求
必须确定系统是否有特殊要求或应急措施。
5.2 性能需求
定量描述产品系统应满足的具体性能需求。如输出物理量、信号、数据能力，处理数据的最大容量、相应要求、从输入到响应所允许的最长时间以及适应用户需求变化的能力等。
5.2.1 能力和容量要求
确定系统的能力容量要求，如负载能力、检测能力、处理的记录数和处理数据的最大容量等。
5.2.2 精度要求
确定系统的精度要求。如控制的精度、测量的精度、数据或数值计算的精度要求、数据传输的精度要求等。
5.2.3 时间特性要求
确定系统的时间特性要求。如检测、处理时间、响应时间及其峰值负载期间允许偏离范围，系统各项功能的顺序关系，由于输入类型的不同和操作方式的变化而引起的优先顺序的变化等。
5.2.4 适应性要求
必须指明反映系统环境变化和系统适应能力的各种参数. 说明当需求发生某些变化时系统的适应能力，指出为适应这些变化而需要设计的软件成分和过程。
5.2.5 通用要求
对任何产品的通用要求。来自产品的研制总要求。一般参考GJBZ 20221-6《武器装备论证通用规范战术技术指标论证》要求进行分析。
5.3 接口需求
必须确定产品与外部其他装备的各种接口关系，指明每个接口的特性。
5.3.1与外部设备的接口
必须指明产品与各种外部设备的接口关系，特别是与输入输出设备和专用设各的接口。必须说明每种设备对产品的要求、设备的型号、功能、控制方法、物理量、信号、数据流向以及在系统中指定的设备号。
5.3.2与其他系统的接口
必须指明产品与其他产品、系统和设备的接口及其性能要求。
5.3.3人机接口
必须指明产品的人机界面，明确操作及使用要求。
5.3.4 产品内部的接口
必须按产品的模块划分结果和产品结构，逐个、逐模块的指明产品内部各种模块的接口关系，特别是各模块的输入输出的接口。必须说明每个模块功能、控制方法、物理量、信号、数据流向以及在系统中指定的模块号。
5.4 数据需求和采购需求
必须定义系统使用的各种数据，并说明数据采集的要求。必须规定静态数据、动态输入输出数据和内部生成数据的逻辑结构，列出这些数据的清单，说明对数据元素的约束。同时，必须规定数据采集的要求。说明被采集数据的特性、要求和范围。数据要求说明的内容和格式见GJB438。产品开发过程中，应有一个书面形式的采购要求说明，明确指出对关键数据、设备和物资采购的要求情况，包括产品使用的各种数据，设备物资以及对采购的要求。
5.4.1 采购要求说明的技术内容
5.4.1.1 采购描述
采购要求说明应对待开发产品所涉及到的数据、设备和物资予以描述，对可预料的采购约束也应加以说明。
5.4.1.2 数据、设备、物资的采购
采购要求说明必须描述用户必要的采购活动，说明采购的要求和范围、数据设备物资的来源、采购与运输等问题，以便采购到适宜的数据和物资。
5.4.2 采购要求说明的编制规定
采购要求说明应完整地说明在产品的开发过程中必须处理的所有采购需求，并向用户说明采购要求。
5.5 环境需求
环境需求包括硬件环境与支持软件环境的需求。
5.5.1硬件环境
必须说明和确定运行软件系统所需的硬件设备。说明当前可用的设备和要求的新设备，必要时可给出设备的余量要求。例如：
电源的要求;
配套的运输设备;
供水设备;
锅炉设备;
起吊设备;
地基;
输入输出设备的种类、数量和要求；
通信、网络设备的要求。
5.2.2支持软件环境
必须指明与软件开发和运行有关的全部支持软件，包括操作系统. 高级语言处理程序、数据库管理系统和软件开发工具等。
5.6 安全和保密要求
承办单位必须与交办单位共同确定整个系统及子系统的使用范围，确定软件安全措施和保密要求。
5.7 可修改性要求
确定哪些产品功能可能发生变动以及功能变动后修改硬件和软件所需的时间和范围。
5.8 假设和约束
必须说明影响产品开发和运行环境的一些假设、约束及影响系统能力的某些限制。
5.9 设计需求分析阶段的产品与其他要求
5.9.1 文档
在设计需求分析阶段，必须完成产品需求说明和数据要求说明的编写工作，并开始起草用户手册和测试计划. 其内容与格式见GJB 438。如果承办单位要补充或修改系统分析与软件定义阶段的文档，应取得交办单位的同意，并完整、准确地做好修改记录。
5.9.2 产品质量保证计划
产品质量保证计划是保证与提高产品质量的重要手段、在需求分析阶段，应修订或制订质量保证计划，其内容与格式见GJB 439。
5.9.3 产品模块划分和配置管理计划
在需求分析阶段，根据产品模块划分和配署管理的要求，应编制模块划分和配置管理计划。该计划用于对产品模块和配置项的标识、控制、修改和状态记录。其主要内容如下： a. 模块划分和配置标识规程；
b. 模块划分和配置控制规程；
c. 模块划分和配置状态记录；
d. 模块划分检查和评审规程。
5.9.4 产品开发标准和规程
在设计需求分析阶段，还应确定开发软件的标准和规程，其内客包括：
a. 开发过程所用的技术、方法、设计标准和设计约束及有关工具；
b. 程序编制的标准和约定；
c. 在特殊情况下，允许不采用自顶向下方法的准则；
d. 所有非正式文档的内容和格式。
5.9.5 研制总要求中提出的战术技术指标中的通用要求
具体要求和分析参考《科研论证工作要求与指南战术技术指标论证》内的要求进行研究分解。
5.9.6 衡量需求说明的标准
需求说明应是；
a. 无歧义的，即每个需求只有一种解释
b. 完整的，即每个需求在内容、格式和输入数据的定义方面是完整的；
c. 可验证的，即每个需求都是可验证的；
d. 一致的，即每个需求之间互相不矛盾；
e. 一可修改的，即需求的修改是易实现的，并保证修改后的需求是完整的、一致的； f. 可追踪的，即每个需求的来源是清晰的、并易于追溯其来源；
g. 易使用的，即在运行和维护阶段易于使用。
6 产品设计与实现方法
6.1 分析和设计原则
6.1.1 分析和设计应是((个决策过程。首先需确定需求的概念模型，然后选定把模型转换为满足产品系统需求的设计方法。最后，利用所选择的最佳设计方法，开发系统的功能。
6.1.2 开发任务承办单位应使用白顶向下的方法设计系统。从高层系统功能开始，通过向低层的功能分配、评价和比较来实现后续的低层设计。
6.1.3 为支持自顶向下的分析和设计，推荐的方法是结构化分析和结构化设计方法；推荐的设计描述方法为系统结构图、结构图、N2图。
6.1.4 设计应遵循以下步骤：
a. 从建立功能设计层次结构开始，以顶层表示整个系统执行的全部任务；
b. 通过逐渐分析把系统划分成为更细化的功能块，从而得出系统的设计层次； c. 将所有的需求逐一分配和映射到这些设计层次；
d. 明确定义设计层次结构的最低层，使所开发系统成为实现所有需求的全部输入到输出路径所必须的常规工程制造方法、算法和数据处理功能的有序集合。
6.2 系统的分析与设汁方法
6.3.1.2.1 结构化分析
本条提供一种可用于分析、定义和记录系统功能和接口需求的有效方法。这也是一种将高层需求分解为更详细需求的图形表达方法。它主要包括：系统结构图、处理逻辑和数据字典。
6.2.1.1 系统结构图
系统结构图用规定的各种符号来表示物理量、信号、数据的流向、处理及装置等，以描述求解某问题的物理量、信号、数据流的模拟和逻辑通道。
系统结构图应有下列四种基本元素：
a. 物理量、信号、数据流向
用箭头表示。物理量、信号、数据流可以由一个或((组数据元素组成。物理量、信号、数据元序列可以根据数据流的法定结构所规定的语法规则排列。
必须注意，物理量、信号、数据流仅用来表示数据的流向，而不表示控制的流向。 b. 处理
用矩形符号表示各种处理功能。处理应是一种数据转换的发生点。
应注意，转换可能是简单的，如存储物理量、信号、数据；也可能很复杂，如将模拟物理量、信号、数据转换为一系列物理量、信号、数字信息分配给其他外部系统。
c. 物理量、信号、数据存储
用符号仁工表示以一种适合于处理的形式表达的物理量、信号、数据存储，但未规定媒体。物理量、信号、数据存储指明某数据从一处理点到准备接收此物理量、信号、数据的下一处理点之间有延迟物理量、信号、数据存储的地方。
d. 外部实体
用(、(、(等符号表示显示器、文件、人工操作等。也可以用正方形表示与系统相连接的其他数据源或数据用户。
应注意，外部实体可以是其它系统或与系统相互作用的人。有关系统结构图的详细规定参见GB 1526.
6.2.1.2 物理量、信号、处理方法
物理量、信号、处理方法应是描述每一层处理将输入物理量、信号、数据转换为正确的输出物理量、信号、数据所必需发生的处理方法序列。
6.2.1.2.1 系统结构图中的处理必须用处理方法说明来描述
大系统的系统结构图中，处理往往包括许多隐含的重要的物理量、信号、数据转换。进行分
析和设计时，应将每一高层的处理逐一分解为更详细、更低层的系统结构图，直到所有功能均可用简单的、严格定义过的处理来表达出来为止。在这一系列系统结构图中，所有处理均须用处理方法、逻辑的说明来描述。
6.2.7.2.2 描述处理方法可用下述方法：
a. 结构化语言
把结构化程序设计中描述结构(操作顺序、操作的循环、操作的选择等) 的语法与该语言的语法相结合；
b. 判定表(树)
适合于描述小的、复杂的处理；
c. 其他
任何有效地描述完成处理功能的步骤序列的方法，甚至自然语言均可使用。
6.2.1.3 物理量、信号、数据检索表
物理量、信号、数据检索表应记录系统中所有物理量、信号、数据，包括物理量信号数据结构、物理量信号数据存储和独立的数据元素。物理量信号数据检索表应与系统的系统结构图同时建立。
6.2.2 结构化设计
结构化设计方法包括产生最佳设计的策略、方案以及设计文档的图形描述模式。这里所述的图形描述应是系统结构图和结构图。结构图是一种用于记录设计决策的模块化层次图。它表述产品的各个功能如何分配到程序单元中去，并描述最终的单元接口。
结构化设计用于建立和描述系统的结构设计。并可用于标识和记录所必须建立的处理功能和程序单元。在设计已用结构化分析方法定义的功能需求时，结构化设计方法尤其适用。 结构化设计不仅为硬件和产品设计提供重要的开发方法，而且为评价系统设计提供重要的指南。
6.2.2.1 方法
a. 画系统结构图
结构化设计方法要求设计人员必须将所有穿过系统的数据流标识和记录于系统结构图中，作为系统设计的基础。
系统结构图中的矩形等表示数据的处理(转换) 点可能有一次或多次中间转换，但最终必须是正确形式的输出。
b. 构造结构图
一旦确定好所有数据处理(转换) 点后，即可构造结构图，用结构图描述所有数据转换所必需的功能集合。
设计人员可以按系统设计要求将系统全部功能进行逐层分解，以确定结构图的功能模块项和层次结构。分解的原则应是按功能将硬件、产品分解为对其他部分影响最小的简单且相对独立的功能模块或程序处理单元。一般要求每个模块仅含一个入口和一个出口。
除指明功能模块和程序单元所执行的功能外，在进行系统结构设计，构造结构图时，还必须标识那些在各功能模块之间进行控制信号处理的模块，它们向下层模块传递信号、控制下层模块运行井接收其输出。
应当注意，最低层的模块应当是实现具体功能处理或计算而不是操纵或控制其他模块的模块。设计人员在系统初步设计阶段中，描述待开发系统的硬件和产品结构时尤其应选用结构图。
6.2.2.2 设计评价
从系统结构图出发构造结构图，通常不可能一次就把模块或程序单元组织好。往往需要反复调整、修改。因而，结构化设计方法为硬件和产品设计提供了评价设计的指南。最基本最主要的是下述三条：
a. 耦合
度量模块之间的关系；
b. 内聚
度量单个模块中元素的关联程度；
c. 模块的控制范围和判定的影响范围。
6.2.2.2.1 耦合
结构化设计方法用耦合概念来度量模块间的关系。一个模块越是相对独立就越易于理解；它传递变化和错误的路径数目越少，则该模块化设计越好。
越是简单的模块接口，越可以提高可靠性，并降低硬件和产品对修改的敏感性。 结构化设计方法规定耦合的五个级别，优先采纳的顺序如下：
a. 物理量、电、数据耦合
输入的数据元素应以可以测量的显式参数的形式传给另一模块的接口，使用模块功能无须知道物理量、电、数据如何被使用。
b. 控制耦合
形成控制的接口方式，例如：使用指定要求处理类型的物理量、电、变量。这时，要求发送模块输出一个控制信号，接收模块测试此信号。
c. 外部耦合
模块通过检查和使用已在另一模块中驻留的物理量、电、数据变量来接收其输入的接口方式，例如：模块间相互共用信号。
d. 公共数据耦合
所需物理量、电、数据是更大的物理量、电、数据集合中一部分的接口方式，例如：公共物理量、电、数据结构的使用。采用公共物理量、电、数据耦合设计的系统中，物理量、电、数据流是无法跟踪的，容易造成干扰。
c. 内容耦合
设计一个模块时，必须了解其他模块的技术细节的接口层。例如：必须知道其他设备内部的工作情况才能进行设计。内容耦合的模块往往可共用设备。
6.2.2.2.2 内聚
结构化设计方法用内聚性来度量模块中元素的相互关联程度。
结构化设计方法要求将硬件、产品按功能尽可能地分解为较小的、功能相对独立的功能模块。衡量内聚性，促使设计者区分功能内聚和非功能内聚的模块。结构化设计的目标应尽可能将程序细分为功能内聚模块。
结构化设计方法的观点认为，内聚性从最好到最差的顺序应排列如下：
a. 功能内聚
功能内聚的模块应是全部成分均为执行单一的、相对独立的处理功能的模块。例如：电机、指示灯、车轮等。
b. 顺序内聚
顺序内聚的模块应是一种其中某处理成分的输出用于下一成分输入的模块。这种模块是 基于控制结构而组织的。例如：放大器、减速器。
c. 通信内聚
通信内聚的模块应是一种全部元素在同一类型输入物理量、电、数据集上操作并(或) 产生同样类型的输出物理量、电、数据的模块。这是一种将输入和输出组合在相同模块中的模块化。例如：通讯网络；并联供电系统；液压助力器。
d. 时间内聚
为处理面向时间的活动而建立的模块。这是一种其成分仅在时间上相关的内聚方式。例如：
某飞机的启动系统；机械、电子定时器。
e. 逻辑内聚
以逻辑分组形式组合的模块。例如继电器连锁保护装置；
f. 偶然内聚
其中的元素没有关系或几乎没有关系的模块。例如：为了整齐将各系统的导线绑扎在一起； 上述六个级别的内聚性也可能并非唯一地出现在同一模块中。
上述的耦合和内聚性是相关的。结构化设计观点认为，力求高内聚、低耦合，二者之中内聚性更为重要。
6 2.2.2.3 模块的控制范围与判定的影响范围
模块的控制范围与判定的影响范围应作如下定义：
a. 模块的控制范围
模块本身以及设备模块组织中该模块下属的全部子模块的集合。
b. 判定的影响范围
包括根据判定结果而运行的模块在内的全部模块的集合。
为使系统工作和运行路径的复杂性最小，并能降低耦合。模块判定的影响范围应在该模块的控制范围之内。
6.2. 2.2.4 模块的规模和合理的控制范围
a. 模块的规模应当尽可能小，小到易于理解。
b. 合理的控制范围
直接从属于某给定模块的子模块数量不应多于9个；尽可能不多于7个。
6.2.3 N2图
N2图突出系统各组成部分以及其功能之间的接口和内部联系，提供一种系统开发过程中用图形描述接口的好方法。
6.2.3.1 构造N2图应遵守下列基本规则：
a. 所有功能均在对角线上的方框中表述；
b. 所有输出均为横向(左或右) 表示；
c. 所有输入均为纵向(上或下) 表示；
d. 所有非功能的方块用来定义一种单向的有关功能间的接口关系。对接口的说明可以在交叉的方块中给出。如果复杂，也可以在交叉的方块中给出带数字的圆圈，并附上每个接口相应数字的说明表来描述。空白的交叉点则表示没有接口关系。
6.2.3.2 N2图可以用来描述任意层次的接口。无论系统之间、子系统之间、程序之间、子程序之间、模块之间还是程序单元之间均可用N ‘图来描述其接口关系。
6.2.3.3 在模块需求定义、初步设计和详细过程中，本标准推荐使用N2图分析定义并设计接口关系。
N2图突出接口存在与否，为设计人员指明特别复杂、难以处理或容易遗漏的接口。当数据流和接口复杂时，N2图对于结构化设计方法是十分有用的补充。其他方法无法处理的许多接口，N2图往往能有效地提供可追踪性。
接口关系描述图
功能1
F1
F1-》F2
1
F1-》F3
2
F1-》F4
3
F1-》F5
4
F2-》F1
5
功能2
F2
F2-》F3
6
F2-》F4
7
F2-》F5
8
F3-》F1
9
F3-》F2
10
功能3
F3
F3-》F4
11
F3-》F5
12
F4-》F1
13
F4-》F2
14
F4-》F3
15
功能4
F4
F4-》F5
16
F5-》F1
17
F5-》F2
18
F5-》F3
19
F5-》F4
20
功能5
F5
8 科研项目功能设计需求分解工作指南
8.1 系统功能设计需求分解的目的
为了保证满足用户的需求，需要帮助用户对提出的功能要求和需求进行系统化的分析。因为用户提出的需求一般都为隐含的，不明确的，不完全的，经常变化的，有时是错误的。在设计工作最初阶段，必须认真确定和明确用户的功能需求。其目的是为设计工作提供明确的工作任务和工作分工依据；为研制工作模块化分解提供依据；为设计研制工作提供协调和支持；为产品的验收提供依据。功能需求分配表是分析的重要手段，该表是研制方案的功能设计需求分解和系统验收标准重要的附件。
8.2 功能设计需求分解的内容；
8.2.1 产品、硬件的每个系统、每个分系统、每个模块、功能的设计需求分解
该分析的目的是根据用户的实际需求，产生所要进行设计工作的系统的具体组成。将设计工作与用户实际需求进行结合，最后将所有工作任务落实到具体的人。
各系统应当将《研制总要求》中内容分类作为各系统验收的标准，同时进一步分解为对子系统验收标准，并且参照标准制定系统和子系统相应的、可测量的验收检验方法和指标。最后落实到具体研制人员，去实现每个功能需求（要求）。该需求的分析直接影响设计开发的最终质量。
参加分解的人员应当在认真研究《研制总要求》的基础上，对国家标准和《研制总要求》进行详细讨论与分解。编写功能设计需求分解文件，《功能设计需求分解表》可以系统的对研制对象的功能需求进行逐条分解，作为各系统研制的依据和验收的标准。在分析表的后面，逐条对接口功能需求按《研制总要求》条款内容进行填写。在对《研制总要求》条款内容分析后，简要描述本系统完成要求需要进行研制内容以及建立的产品、硬件配置模块，描述功能实现的技术要求以及验证的方式，描述完成功能需要的支持。最后形成完备的接口设计需求分解文件
功能应当是产品和硬件制造和实现的的目的，一般都是产品或模块划分的依据，产品功能划分一般与产品模块划分直接关联。
8.2.2 每个层次、每个系统、每个分系统、每个模块、每个工作任务、每个工作项目之间的接口的功能和需求的分析
接口功能设计需求分解产生的描述文件的作用是：
a. 为初步设计提供设计需求分解与完整性支持；
b. 为各系统接口协调提供依据与完整性支持；
c. 为研制工作模块化分解提供依据；
d. 为各系统验收提供完整性支持；
对于硬件设计，也建议在方案设计和初步设计时参考采用产品设计的方法和文件系统。这样可以同时保证产品与硬件的接口设计控制在同一种文件系统或同一个文件中。特别是对于比较小的系统，既有产品又有硬件。可以使设计人员使用更少种类的文件。
8.3 功能设计需求分解表
本表作为工作任务划分和接口技术协调的依据，是保证设计的可追述性和可控制性的重要文件。他可以保证设计工作责任落实到人。
本表将《研制总要求》中的功能和需求分解落实到相应的负责人，最后由负责人负责完成设计和加工任务。
设计过程的分解等级根据参加设计的人员和设计程序确定。
对于大的设计需求，可以由负责人编写该需求（要求）的分析表，将需求分配到下一级设计过程。并注明向下分解。
对于相关到多个人员的设计需求，由参加本条目的负责人协调进行需求分解，将需求（功能需求和接口需求）分配到本人负责的下一级设计过程，
XX 系统设计功能设计需求分解表
方案提出的要求条目
简要说明和代码
条目落实负责人
人名1
人名2
人名3
人名4
人名5
4 XX 系统接口设计需求分解表
功能与需求编码：（按设计功能设计需求分解表编号填写）
工作任务编码:（按工作单元代码填写）
分析负责人： 分析时间：
接口关系描述图
模块1
F1
F1-》F2
1
F1-》F3
2
F1-》F4
3
F1-》F5
4
F2-》F1
5
模块2
F2
F2-》F3
6
F2-》F4
7
F2-》F5
8
F3-》F1
9
F3-》F2
10
模块3
F3
F3-》F4
11
F3-》F5
12
F4-》F1
13
F4-》F2
14
F4-》F3
15
模块4
F4
F4-》F5
16
F5-》F1
17
F5-》F2
18
F5-》F3
19
F5-》F4
20
模块5
F5
接口设计需求分解描述文件
本表为接口设计需求分解提供帮助。需求（包括接口需求）是功能实现的输入和支持条件。产品或硬件模块将需求转换为功能。上面的5个模块需求表格，需要分别编写20个接口分
析需求文件。按照接口需求每个分析文件编写条目的要求如下：
（模块名称）接口设计需求分解
a. 提供方名称及工作代码；
b. 接口信息描述；包括数据、信息、知识要求，功能、性能指标、时间序列、 c. 提供方式描述；载体、接口、协调方法、参加协调方数量及工作代码名称等。 d. 提供时间描述；满足需求方接口需求的时间、进度等。
e. 提供仿真描述；用于无法按时或直接提供接口服务时, 为保证研制工作顺利进行，而采用仿真方法替代的描述。