软件开发及培训

(仅供内部使用) 

深圳市华为技术有限公司 

版权所有 侵权必究 

1 软件开发过程介绍

华为公司的软件开发过程基本上由以下几个开发过程组成: 

∙系统需求分析过程 

∙系统设计过程 

∙软件需求分析过程 

∙软件概要设计过程 

∙软件详细设计过程 

∙软件编码和单元测试过程 

∙软件集成与集成测试过程 

∙系统集成和系统集成测试过程 

∙系统验收测试过程 

∙软件维护过程 

各软件开发过程中应该输出的文档如下 

2. 软件开发过程详细要求

系统需求分析

开发者应该根据以下要求参与系统需求分析。 

注：如果一个系统分成多个版本开发，可能直到最后一个版本需求才能完全定义。开发者的计划中应该定义在每个版本中确定的需求子集，每个版本中实现的需求子集。某个版本的需求分析应该理解为定义那个版本的系统需求。 

2.1.1 分析用户的输入

开发者应该通过分析用户的输入来理解用户的需求。这个输入的形式可能是需求报告单、调查、问题/修改报告，原型的反馈，访谈或其他用户或反馈。 

2.1.2 操作概念

开发者应该参与定义和记录系统的操作概念。结果应该包括在《操作概念描述（OCD）》文档模板中的所有条目。 

2.1.3 系统需求

开发者应该参与定义和记录系统应该满足的需求以及验证每个需求已经被满足的方法。结果应在包括《系统/子系统规格说明书（SSS）》中的所有可能的条目。根据实际情况，有关系统接口的需求可以在SSS中规定或者在《接口需求规格说明书（IRSs）》中规定。 

注：如果一个系统由子系统组成，系统需求分析）中的活动应该同系统设计中的活动叠代进行。定义系统的需求，设计系统并定义它的子系统，定义这些子系统的需求，设计子系统并定义他们的部件，如此下去。 

系统的设计

开发者应该按照下列要求参与系统的设计。 

注：如果系统分成多个版本开发，系统的设计可能要等到最后一个版本才完成。开发者的计划中应该定义每个版本中所要完成的设计。一个特定版本的设计应理解为那个版本中应完成的设计内容。 

2.2.1 系统范围的设计决定（System-wide design decisions)

开发者应该参与定义和记录系统范围的设计决定（这就是，有关系统运行设计和其它影响到系统部件选择、设计的决定）。结果应该包括《系统/子系统设计说明书（SSDD）》模板中有关系统范围设计决定的所有内容。根据实际情况，有关接口的设计可以包括在SSDD中或者《接口设计说明书》中，有关数据库的设计可以包括在SSDD或者《数据库设计说明书（DBDDs）》中。 

注：除非在需求中有明确的规定，设计一般由开发者负责。开发要满足所有的需求并通过系统集成测试来证明需求得到了满足。 

2.1.2系统结构设计(System architectural design)

开发者应该参与定义和记录系统的结构设计（定义系统的部件，它们的接口，以及它们之间的运行概念）以及系统部件同系统需求之间的跟踪关系。结果应该包括《系统/子系统设计说明书（SSDD）》中有关结构设计及跟踪性的部分的所有条目。根据需要，有关接口的设计可以包括在SSDDs或《接口设计说明书》中。 

 软件需求分析（Software requirements analysis) 

开发者应该定义和记录每个CSCI应该满足的软件需求，验证每个需求是否完成的方法，以及CSCI需求同系统需求之间的跟踪关系。结果应该包括《软件需求规格说明书（SRS）》中所有的条目。根据需要，CSCIs接口的需求可以包括在SRS中或《接口需求规格说明书（IRSs）》中。 

注：如果一个CSCI分成多个版本开发，需求可能要到最后一个版本才能完全定义。开发者的计划中应该说明每个版本中每个CSCI需求的子集。 

 软件设计

开发者应该根据以下要求进行软件的设计。 

注意：如果一个CSCI分成多个版本开发，可能需要等到最后一个版本才能完全设计完毕。每个版本的软件设计应该理解为为了实现这个版本的需求而进行的设计。 

2.4.1 CSCI范围的设计决定（CSCI-wide design decision).

开发者应该定义和记录CSCI范围的设计决定（这就是，有关CSCI的运行设计和其它影响到构成CSCI的软件单元选择和设计的设计决定）。结果应该包括《软件设计说明书（SDD）》中有关CSCI范围设计决定的所有项目。根据需要，有关接口的设计内容可以包括在SDD中，也可以安排在《接口设计说明书》中。有关数据库的设计可以安排在《数据库设计说明书》中。 

2.4.2 CSCI结构设计（CSCI architectural design)。

开发者应该定义和记录每个CSCI的结构设计（定义构成CSCI的软件单元，它们的接口，它们之间的运行概念）以及软件单元CSCI需求的跟踪关系。结果应该包括《软件设计说明书》中有关结构设计及跟踪性的所有项目.根据实际需要，有关接口的设计内容可以包括在《接口设计说明书》中。 

注意：如果软件单元又有其它软件单元组成，则CSCI的结构可以根据需要组成多个层次。例如。一个CSCI可以被分成三个软件单元，上述每个软件单元又可以分成其他的软件单元，如此下去。 

2.4.2 CSCI的详细设计（CSCI detailed design)

开发者应该开发和记录每个软件单元的设计描述。结果应该包括《软件设计说明书》模板的所有项目。根据需要，接口的内容可以在《接口设计说明书》中，有关数据库访问和操作的软件单元可以安排在《数据库设计说明书》中。 

 软件编码与单元测试

开发者应根据以下要求进行软件单元实现和测试。 

注意：“软件”的含义即包括计算机程序也包括计算机数据库。“实现"的含义为将软件实现转换为计算机程序和计算机数据库。如果一个CSCI的开发分成多个版本，软件实现、和单元测试可能要到最后一个版本才能完成。每个版本的软件实现和单元测试指在那个版本中需要实现的软件单元或部分软件单元。 

2.5.1 软件实现

开发者应该开发和记录CSCI设计中的每个软件单元。这些活动应该包括，编码、数据定义、构造数据库，给数据库或其他数据文件赋值以及其他实现设计所需要的活动。 

注意：设计中的软件单元不一定与实现它们的代码和数据实体有一一对应的关系。 

2.5.2 单元测试准备

开发者应该建立测试用例（按照输入、预期输出和评价标准）、测试过程和测试数据来测试每个软件单元。测试用例应该覆盖单元详细设计的所有方面。开发者应该将这些信息记录在相应的软件开发文件中。 

2.5.3 进行单元测试

开发者应该测试每个软件单元对应的软件。这些测试应该按照单元测试用例和测试过程进行。 

2.5.4 修正和回归测试

开发者应该根据单元测试的结果进行所需的修正并进行回归测试，更新相关的软件开发文件。 

2.5.5 分析和记录单元测试的结果

开发者应该分析单元测试的结果并将测试和分析结果记录在相应的软件开发文件中。 

 单元集成和测试

开发者应该根据以下要求进行单元集成和测试。 

注意1：单元集成和测试指将两个或多个软件单元集成起来，通过测试保证它们在一起工作正常，继续这个过程直到每个CSCI中的软件单元都集成和测试过。因为一个软件单元可能由其它单元组成，一些集成测试在单元测试过程中就可以完成，这里不要求重复这些测试活动。 

如果一个CSCI分成多个版本开发，CSCI的单元集成和测试可能要等到最后一个版本才能完成。 

2.6.1 单元集成和测试的准备

开发者应该建立单元集成和测试的测试用例、测试过程和测试数据（按照输入、预期结果和评价标准）。测试用例应该覆盖CSCI范围和CSCI结构设计的所有方面。开发者应该将这些信息记录在相应的软件开发文件中。 

2.6.2 进行单元集成和测试

开发者应该进行单元集成和测试，测试应该按照单元集成测试用例和过程进行。 

2.6.3 修正和回归测试

开发者应该根据单元集成和测试的结果修正软件并进行回归测试，更新软件开发文件及其他所需的软件产品。 

2.6.4 分析、记录单元集成和测试的结果

开发者应该分析单元集成和测试的结果并记录在相应的软件开发文件中。 

 CSCI/HWCI的集成和测试

开发者应该根据以下要求参加CSCI/HWCI（软件配置项/硬件配置项）的集成和测试活动。 

注意1：CSCI/HWCI集成和测试的含义是将CSCI和与之有接口的HWCI、CSCI结合，通过测试来验证它们在一起工作是否正常。连续进行这个过程，直到系统中所有CSCI和HWCI都已经集成并进行测试过。这个集成测试的最后阶段是开发者内部的系统测试。 

注意2：如果一个系统CSCI分成多个版本开发，CSCI/HWCI集成和测试可能要到最后一个版本才完成。某个版本的CSCI/HWCI的含义为此版本中的CSCI和此版本中HWCI进行测试以保证这个版本的系统需求得到了实现。 

2.7.1 准备CSCI/HWCI的集成和测试

开发者应该参与开发和记录CSCI/HWCI集成和测试的测试用例（根据输入、预期输出和评价标准）、测试过程。测试用例应该覆盖系统范围设计和系统结构设计的所有方面。开发者应该将软件相关信息记录在软件开发文件中。 

2.7.2 进行CSCI/HWCI集成和测试

开发者应该参加CSCI/HWCI的集成和测试。测试应该按照CSCI/HWCI集成测试用例和测试过程进行。 

2.7.3 修正和重新测试

根据CSCI/HWCI集成和测试的结果，开发者应该做所需要的修正，参加所有需要的重新测试，更新相应的软件开发文件和其他软件产品。 

2.7.4 分析和记录CSCI/HWCI集成和测试的结果

开发者应该参加分析CSCI/HWCI集成测试的结果。软件相关的分析和测试结果应该记录在相应的软件开发文件中。 

 系统测试

开发者应该根据以下要求参加系统测试。 

注意1：系统测试用来给用户演示系统需求已经得到满足。它覆盖《系统/子系统规格说明书（SSS）》中的系统需求和相关的接口需求。这个测试和集成测试的最后阶段在开发者内部进行的系统测试不同。 

注意2：如果系统分成多个版本开发，完整的系统测试可能在最后一个版本才遇到。每个版本的质量测试应该理解为为了验证此版本的需求已经得到满足而进行的测试。 

2.8.1 系统测试中的性

负责系统测试的人不应该是进行详细设计或软件实现的人。这并不排除负责详细设计或实现的人对这个过程作出贡献，例如：提供需要了解系统内部实现的测试用例。 

2.8.2 在目标计算机上的测试

开发者的系统测试应该包括在目标计算机（或其它用户同意的系统）上的测试。 

2.8.3 系统测试的准备

开发者应该参加参加开发和记录测试的准备、测试用例、测试过程以及测试用例和系统需求之间的跟踪性。对于软件系统，结果应该包括《软件测试说明书（STD）》中的所有项目。开发者应该参加准备系统测试需要的测试数据以及通知用户测试的时间和地点。 

2.8.4 运行（自己动手）系统测试

如果系统测试需要用户见证，开发者应该参加（自己动手）运行系统测试用例和过程以保证其完整性和正确性。开发者应该将这些测试活动的结果记录在相应的软件开发文件中并根据需要对测试用例和过程进行更新。 

2.8.5 进行系统测试

开发者应该参加系统测试。测试应该根据测试用例和过程进行。 

2.8.6 修正和重新测试

根据系统测试的结果，开发者应该对软件做必要的修正，给用户提供重新测试的建议，参加所有需要的重新测试并更新软件开发文件和其他软件产品。 

2.8.7 分析和记录系统测试结果

开发者应该参加分析和记录系统测试结果。对于软件小，这些结果应该包括《软件测试报告（STR）》中的所有项目。 

深圳市华为技术有限公司 

(仅供内部使用) 

深圳市华为技术有限公司 

版权所有 侵权必究 

修订记录 

软件需求规格说明书（SRS）规定一个计算机软件配置项（CSCI）的需求，以及验证每个需求是否得到满足的方法。CSCI的外部接口需求可以在SRS中进行规定，也可以在一个或多个接口需求规格说明书（IRS）中进行规定，在软件需求规格说明书（SRS）对这些文档进行引用。 

软件需求规格说明书（SRS）（可能需要IRS的补充）是CSCI设计和测试的基础。 

1.范围

这部分将被分为以下几段。 

1.标识

这一部分应包含系统、接口实体、被说明接口的完整标识，尽可能包括：标识号码、标题、缩写、版本号、发布号。 

1.系统概论

这一部分将简要的阐述文档所说明的系统和软件的目的。它将大概描述系统、软件的本质；总结系统的发展、操作和维护的历史；确定这个方案的发起人、受益人、使用人、开发者和维护机构；确定当前的状况并计划操作地点；最后列出其它相关联的文档。 

1.文档概述

这一部分总结了这个文档的目的和内容，并且描述了与文档用处有关的任何安全性及保密性的事项。 

1.参考文献

这一部分列出了一些文档中引用的所有文档的号码、名称、修订本和数据。 

1.需求

本部分应该分成以下段落来描述CSCI的需求，它们是CSCI为了被接受而必须具有的特性。CSCI的需求是为了满足分配到本CSCI的系统需求而产生的软件需求。需要给每个需求分配一个项目唯一的标识符以支持需求的测试和跟踪，对需求的描述必须能够达到可以设计针对性测试的程度。如果在以后的4、5节没有说明，在这里每个需求都要注明相应的测试方法（见4节）及与系统需求间的追溯关系（见5节）。需求描述的详细程度应该依照以下原则：包括CSCI达到可接受的标准所必须具有的特征，避免进行设计描述，这些是开发者的工作。如果在某一段中没有需求，只需要写“无”即可。如果一个需求在多个段落中出现，它只需描述一次即可，在其它地方进行引用。 

1.所需的状态和模式

如果CSCI工作在不同的状态和模式中，并且在不同的工作状态和模式有不同的需求，本段应定义每一个状态和模式。状态和模式的例子如下：等待、待命、行动、事后分析、训练、降级、紧急、备份、战时、和平时期。状态和模式间的区别时灵活的。一个CSCI可以只按照状态描述，只按照模式描述，按照模式中的状态描述，按照状态中的模式描述或按照任何其他有用的顺序描述。如果系统没有任何状态和模式的特别要求，按照实际情况描述即可，没有必要“人工创造”不同。如果需要按照模式或状态描述，那么每个需求或者需求集合都要和状态或模式相关。这些相关性可以通过段落或附录中的一个表格进行说明，也可以对需求进行注释。 

1.CSCI能力需求

本段应该分成以下子段落以逐条说明CSCI的每个能力需求。一个“能力”定义成一组相关的需求。名词“能力”可以用“功能”、“题目”、“目标”等有助于表达需求的名词替代。 

1.（CSCI 能力）

本段定义CSCI的一个能力并罗列有关此能力的需求。如果此能力分成几个组成部分描述更清楚些，这些子能力应在各子段落中描述。需求规定CSCI的动态行为并包括可能的参数，例如：反映时间、吞吐时间、其他时间约束、顺序、准确度，能力（多少）、优先级、连续操作的需求，不同操作条件下允许的偏差。需求应尽可能包括：在异常情况下、越界情况下所需的动态行为，错误处理的需求，紧急情况下提供连续操作能力的需求。段规定了描述CSCI有关输入输出需求时需要考虑的一系列题目。 

1.CSCI 外部接口需求

本段应该分成以下几个子段落来规定CSCI的外部接口需求，本段可能引用一个或多个接口需求规格说明书或其它相关文档。 

1.接口标识符和示意图

本段应该定义CSCI所需的外部接口（它们是和其他外部实体之间涉及共享、提供或交换数据的关系）。每个接口的标识包括一个项目内部唯一的标识符以及接口实体（系统、配置项、用户、等），对接口实体的说明尽量包括以下内容：名称、编号、版本、参考文档。定义应该说明那个接口实体具有固定的接口特性（因此对相应的接口实体提出接口要求），那些正在被开发或修改（因此被赋予接口需求）。应该提供一个或多个示意图以对接口进行说明。 

1.（接口的标识符）

本段（从3.3.2开始〕应该给CSCI的一个外部接口定义一个项目唯一的标识符，简要描述接口实体。为了描述一个或者多个接口实体的需求，可以划分为子段落。如果一个接口实体未被本文档覆盖（例如一个外部系统），但是描述接口需要提到它时，应该以假定的方式说明，或者以“当[未被覆盖的实体]这样作，[系统中说明的实体]将........" 样的方式说明。本段可能会引用其他文档（例如：数据字典、标准协议、用户接口标准）。设计描述应该尽可能包括以下信息，可以用任何适合需求的顺序提供，应该注明这些特征从接口实体角度看的任何区别（例如：对数据元素的大小、频率或其他特征的不同理解）： 

∙接口实体必须赋予接口的优先级。 

∙接口类型的需求（例如：实时数据传送，存储－检索，等等）。 

∙接口实体提供、存储、发送、访问、接收的每个数据元素的特征。例如： 

1.名称/标记 

1.项目唯一的标记 

2.自然语言的名称 

3.国防部标准数据元素名称 

4.技术名称（例如，代码或数据库中的变量名和域名） 

5.缩写词或同义词 

2.数据类型（字符型、整型等） 

3.大小和格式（例如字符串的长度和分隔符号〕 

4.测量单位（例如米、美元、微秒） 

5.可能的数值范围（例如：0－99） 

6.准确度（正确的程度）和精确度（有效数字的位数） 

7.优先级、时序、频率、数量、顺序和其他约束，例如：是否更新数据成员，是否应用行业标准。 

8.安全和隐蔽性的约束 

9.源头（设置/发送实体）和接受（使用/接收实体） 

∙数据元素集（纪录，消息，文件，数组，显示，报告）的特性。 

10.名称/标记 

1.项目唯一的标记 

2.自然语言的名称 

3.技术名称（例如，代码或数据库中的变量名和域名） 

4.缩写词或同义词 

11.装配中的数据元素及其类型 （编号，顺序，分组） 

12.媒介（如磁盘）和在媒介上的元素/装配的结构 

13.输出的视觉和听觉特性，其他输出（颜色，字体，布局，图标，亮度， 蜂鸣等） 

14.数据集合之间的关系，如排序/存取特性 

15.优先级、时序、频率、数量、顺序和其他约束，例如：是否更新数据成员，是否应用行业标准。 

16.安全和隐蔽性的约束 

17.源头（设置/发送实体）和接受（使用/接收实体） 

∙接口使用的通讯方法 

∙项目唯一的标识符 

∙通讯链接、波段、频率、媒质和特性。 

∙消息格式 

∙流控（例如：顺序号和分配缓冲）。 

∙数据传输数率，是周期性还是突发性，传送的间隔。 

∙路由、地址、和命名约定。 

∙传送服务，包括：优先和分级 

∙安全和隐蔽性的考虑，例如：加密、用户验证、隔离和审计。 

∙接口中使用的协议特性需求 

∙项目唯一的标志符 

∙协议的优先级和层次 

∙包操作，包括拆分、组装、路由和寻址 

∙合法性检查，出错控制，恢复过程。 

∙同步过程，包括：建立连接，保持，结束。 

∙状态、标志、任何其他的报告特性。 

∙其他特性，例如：接口实体的物理兼容性（体积、公差、负荷、电压、插头兼容性等） 

18.CSCI内部接口需求

本段定义CSCI内部接口需求。如果内部接口情况由开发者决定，这里说明即可。如果需要定义内部接口需求，请参照的题目进行说明。 

1.CSCI内部数据需求

本段定义CSCI内部数据的需求，内部数据库和数据文件的需求。如果所有的设计由开发者决定，这里只要说明即可。如果具有这方面的需求，本段的 和提供了需要考虑的条目。 

1.适应性需求

本段规定CSCI和安装数据有关的需求（例如：和安装地点有关的经纬度，或和安装有关的州税务码）以及不同操作下可能不同的操作参数需求（例如：指示和操作有关的目标变量或数据记录的参数）。 

1.安全性需求

本段应该描述CSCI有关避免或减少对人员、财产、环境的意外伤害的需求。例如：必须提供一些保证措施来避免一些无意中的行为（例如：无意中发出一个关闭自动驾驶仪的命令）和“不行为”（例如：没有按要求发出“关掉自动驾驶”命令）。 

1.安全和隐蔽性需求

本段规定有关保持系统安全和隐蔽性的需求。这些需求包括，CSCI操作必须的安全和隐蔽环境，需要满足的安全和隐蔽性级别。CSCI需要面对的安全/隐蔽性风险，减少这些风险所需的安全性措施，必须满足的安全/隐蔽性策略，CSCI必须提供的安全/隐蔽性责任，通过安全/隐蔽性检验所必须满足的标准。 

1.CSCI的环境需求

本段规定CSCI有关操作环境的需求。例如：CSCI所必须运行的操作环境、计算机硬件。（有关计算机资源的详细需求在下段描述）。 

1.计算机资源需求

1.计算机硬件需求

本段规定CSCI必须使用的计算机硬件资源的需求。需求包括：每种设备的数量，体积，能力，其它对处理器、存储器、输入输出设备、辅助存储器、通讯网络设备和其它所需设备的需求。 

1.计算机硬件资源利用程度需求

本段说明有关CSCI的计算机硬件资源使用方面的需求，例如：允许最大限度占用的处理器、存储器、输入输出设备、通讯网络设备能力。需求（例如以每种资源所允许的占用百分比说明）应说明测量条件和环境。 

1.计算机软件需求

本段规定CSCI运行使用到或者需要合作的计算机软件。例如：操作系统、数据库管理软件、通讯网络软件，设备软件，输入和设备模拟器，测试软件，制造软件等等。应该说明每种软件的正确名称、版本、参考文档。 

1.计算机通讯需求

本段规定CSCI必须使用的计算机通讯需求。例如：需要相互连接的地理位置；配置和网络拓扑； 

传送技术；数据传送速率；网关；需要的系统使用次数；传送和接收数据的类型和容量；传送/接收/反馈的时间界限；数据量的峰值；诊断特点； 

1.软件质量因素

本段应该规定CSCI的软件质量需求。例如：有关CSCI功能性（完成所有的所需功能的能力），可靠性（提供正确、连续操作结果的能力），可维护性（能够很容易修正的能力），可用性（在需要时候能够很容易访问和操作），灵活性（适应变化环境的能力），可测试性（容易和全面测试的能力），重用性（应用在多个应用中的能力），易用性（容易学习和使用的能力），以及其它属性。 

1.设计和实现约束

本段应说明CSCI设计和实现的约束。这些需求可能需要对民用和军用标准进行引用。例如： 

1.使用专门的CSCI结构或对结构的需求，例如：数据库或其他软件单元；标准、现有部件的使用。 

2.特别设计和实现标准的使用；特别数据标准的使用；特别编程语言的使用 

3.为了支持预期增长的技术、威胁和目标所必须提供的灵活性和可扩展性。 

1.人员相关的需求

本段应该规定对使用或支持本CSCI所需的人员需求，包括：数量、熟练程度、责任链、培训需求或者其他信息。例如对同时进行操作者数量的要求，内部帮助和培训特征。同时也应包括工程需求的人的因素。这些需求应该包括：对人的能力及的考虑；在一般情况下和极端环境中可预见的人的错误；人为错误将造成特别严重后果的区域。例如：错误信息显示的颜色和时段，关键指示器和开关的物理位置，声音信号的使用。 

1.培训有关的需求

本段应该包括CSCI有关培训的需求。例如：CSCI中应该包括的训练软件。 

1.后勤相关的需求

本段应该规定CSCI与后勤相关的需求，例如：系统维护、系统支持、系统运输、支持系统的需求，对原有设施的影响，对现有设备的影响。 

1.其它需求

本段应该包括在上述段落中没有包括的其它需求。 

1.包装的需求

本部分应该说明CSCI包装、标签、发行的需求。 

1.需求的优先和关键顺序

本段应该通过优先顺序、关键程度、权重来说明规格中需求的相对重要程度。例如：要注名那些需求对安全性、保密性或隐蔽性上非常关键，以便进行特殊处理。如果所有需求具有相同的权重，本段这样据实描述即可。 

1.质量保证措施

本段应说明一系列的质量保证措施，并说明对3节中每个需求所采用的质量保证方法。可以用表格的形式提供这方面的信息，或者在3节中对需求进行说明时加上相关的注释。 

1.演示： 该接口实体的运作依赖于明显的功能性操作，并且不需要使用仪器、特殊测试装备、或是事后的分析。 

2.测试：接口实体的运作需要使用仪器、测试装备，来收集数据，用于事后的分析。 

3.分析：处理使用其它的判定方法获取的数据，例如简约、译码、或是推断。 

4.检视： 对接口实体、文档的正规检视。 

5.特殊合格性判定方法： 所有的特殊合格性判定方法，如专用的工具、技术、过程、设备和容忍极限。 

1.需求跟踪

1.本文档中的需求到系统（或子系统）需求的跟踪。（这种跟踪也可以由第三节中的需求的注释表明。） 

注释：每一层次的系统求精可能会导致需求无法直接跟踪到高层的需求。例如，有一项系统构结构设计产生了多个软件配置项（CSCIs），这有可能产生了如何划分接口的需求，然而这些需求并没有包括在系统需求之中。这种需求可能会跟踪到一般性的需求，象“系统实现”，或是跟踪到导致他们产生的系统设计决定上。 

2. 从每个系统（子系统）需求到CSCI需求间的跟踪。与CSCI有关的所有需求都应该被说明。如果有些跟踪涉及到的CSCI需求在接口需求说明书中（IRS），应该对这些文档进行引用。 

1.注释

本段包括对理解文档有帮助的其他一般信息（例如：背景、词汇表、原理）。本部分应该包括所有专有名词、缩写词、术语、定义及其含义。 

1.附录

附录用来提供为了文档维护方便而进行发行的信息（例如，图表，分类数据）。如果可能，在文档主体中需要相关数据的地方提供对文档的索引。为了便于处理，附录装订成文档。附录应按字母顺序标记（A，B，等..）。 

深圳市华为技术有限公司 

(仅供内部使用) 

深圳市华为技术有限公司 

版权所有 侵权必究 

修订记录 

接口需求描述文档（IRS）详细描述接口需求，它涉及一个或多个系统，子系统，硬件配置项（HWCIs），软件配置项（CSCIs），手动操作或是其他系统组件，一篇接口描述文档可包括任意数目的接口。 

接口需求描述文档可以补充说明系统/子系统规格说明书(SSS) (DI-IPSC-81431)和软件需求规格说明书，作为系统和软件配置项的设计与测试的基础。 

1.1 范围：

本部分应该分为以下几个段落。 

1. 标志

本段应该包括文档所应用系统和软件的完全标志，可能包括，序列号、名称、简称、版本号、发行号。 

1. 系统概述

本段应简短的说明文档叙述的系统和软件的目的。描述软件和系统的本质；总结系统或软件的发展、操作、维护的历史。 

1. 文档的概述

本段应该总结本文档的目的和内容并描述所有的安全和隐蔽性的考虑。 

1.2 参考文献

本段应该列出本说明中提到的所有文档的序号，名称，修订和日期。本段也要说明一般途径不能获得的文档的来源。 

1.3 需求

本部分应该分为以下几个段落，用来描述一个或多个系统，子系统，硬件配置项（HWCIs），软件配置项（CSCIs），手动操作或是其他系统组件所涉及到的接口需求。应该给每个需求赋予一个项目内部唯一的标识符，用来支持测试和跟踪，需求的描述方式应能够用来定义针对性测试。如果在以后的部分没有提供，需求就要加以注释，表明相关的合格性判定方法（见 4部分）及与系统/子系统需求（见节）可追溯性。详细程度应该遵循以下规则：包括接口实体达到可接受水平所必须具有的特性，避免描述具体设计，这些是开发者的工作。如果一项需求安排在几个段落中，应该说明一次，而在其他的段落中引用。如果一个接口实体在不同的工作模式下的接口需求不同，那么所有的需求都要基于一定的模式进行说明。通过一张表或者其他方式说明对应关系。 

1. 接口定义和图示

本段应该给每个接口定义一个项目唯一的标识符并说明接口的实体（软件单元、系统、配置项、用户等), 可能的话使用名称、编号、版本、参考文献进行说明。定义应说明那些实体具有固定的接口特性（因此有接口需求），那些正在被开发或修改。有可能的话，提供一个或多个图型对接口进行描述。 

1.（项目内部唯一的接口标识符）

本段（从开始〕应该给接口一个项目唯一的标识符，简要描述接口实体。为了描述一个或者多个接口实体的需求，可以划分为子段落。如果一个接口实体未被本文档覆盖（例如一个外部系统），但是描述接口需要提到它时，应该以假定的方式说明，或者以“当[未被覆盖的实体]这样作，[系统中说明的实体]将........" 样的方式说明。本段可能会引用其他文档（例如：数据字典、标准协议、用户接口标准）。设计描述应该尽可能包括以下信息，可以以任何合适的顺序提供，应该注明这些特征从接口实体角度看的任何区别（例如：对数据元素的大小、频率或其他特征的不同理解）： 

∙接口实体必须赋予接口的优先级。 

∙接口类型的需求（例如：实时数据传送，存储－检索，等等）。 

∙接口实体提供、存储、发送、访问、接收的每个数据元素的特征。例如： 

1.名称/标记 

1.项目唯一的标记 

2.自然语言的名称 

3.国防部标准数据元素名称 

4.技术名称（例如，代码或数据库中的变量名和域名） 

5.缩写词或同义词 

2.数据类型（字符型、整型等） 

3.大小和格式（例如字符串的长度和分隔符号〕 

4.测量单位（例如米、美元、微秒） 

5.可能的数值范围（例如：0－99） 

6.准确度（正确的程度）和精确度（有效数字的位数） 

7.优先级、时序、频率、数量、顺序和其他约束，例如：是否更新数据成员，是否应用行业标准。 

8.安全和隐蔽性的约束 

9.源头（设置/发送实体）和接受（使用/接收实体） 

∙数据元素集合（纪录，消息，文件，数组，显示，报告）的特性。 

10.名称/标记 

1.项目唯一的标记 

2.自然语言的名称 

3.技术名称（例如，代码或数据库中的变量名和域名） 

4.缩写词或同义词 

11.集合中的数据元素及其类型 （编号，顺序，分组） 

12.媒介（如磁盘）和在媒介上的元素/装配的结构 

13.输出的视觉和听觉特性，其他输出（颜色，字体，布局，图标，亮度， 蜂鸣等） 

14.数据集合之间的关系，如排序/存取特性 

15.优先级、时序、频率、数量、顺序和其他约束，例如：是否更新数据成员，是否应用行业标准。 

16.安全和隐蔽性的约束 

17.源头（设置/发送实体）和接受（使用/接收实体） 

∙接口使用的通讯方法 

∙项目唯一的标识符 

∙通讯链接、波段、频率、媒质和特性。 

∙消息格式 

∙流控（例如：顺序号和分配缓冲）。 

∙数据传输数率，是周期性还是突发性，传送的间隔。 

∙路由、地址、和命名约定。 

∙传送服务，包括：优先和分级 

∙安全和隐蔽性的考虑，例如：加密、用户验证、隔离和审计。 

∙接口中使用的协议特性需求 

∙项目唯一的标志符 

∙协议的优先级和层次 

∙包操作，包括拆分、组装、路由和寻址 

∙合法性检查，出错控制，恢复过程。 

∙同步过程，包括：建立连接，保持，结束。 

∙状态、标志、任何其他的报告特性。 

∙其他特性，例如：接口实体的物理兼容性（体积、公差、负荷、电压、插头兼容性等） 

18. 需求的优先级和紧急程度

本段应是第三节的最后一段，应该包括需求的优先级，紧急程度，需求的权重，用来表明在这篇说明中的需求的重要程度。例如应该这样描述：对于先安全性和隐蔽性这种关键的需求，要把它单独列出来特别说明。如果本段中的需求重要性平均，只要一般描述即可。 

1.4 合格性规定(qulification provisions)

这一节应该定义一系列的合格性判定方法。对于第三节中的每一项需求，说明验证是否满足需求的合格性判定方法。可以使用表来说明这一信息，否则要对第三节中的每一项需求加以注释，说明合格性判定方法。合格性判定方法包括： 

1.演示： 该接口实体的运作依赖于明显的功能性操作，并且不需要使用仪器、特殊测试装备、或是事后的分析。 

2.测试：接口实体的运作需要使用仪器、测试装备，来收集数据，用于事后的分析。 

3.分析：处理使用其它的判定方法获取的数据，例如简约、译码、或是推断。 

4.检视： 对接口实体、文档的正规检视。 

5.特殊合格性判定方法： 所有的特殊合格性判定方法，如专用的工具、技术、过程、设备和容忍极限。 

1.5 需求跟踪

本段落不适用于系统级别的接口实体。对本文档包括的子系统或更低级别的接口实体来说，本段落应该包括： 

1.本文档中的需求到系统（或子系统）需求的跟踪。（这种跟踪也可以由第三节中的需求的注释表明。） 

注释：每一层次的系统求精可能会导致需求无法直接跟踪到高层的需求。例如，有一项系统构结构设计产生了多个软件配置项（CSCIs），这有可能产生了如何划分接口的需求，然而这些需求并没有包括在系统需求之中。这种需求可能会跟踪到一般性的需求，象“系统实现”，或是跟踪到导致他们产生的系统设计决定上。 

2. 有的系统/子系统需求分配到了接口实体，并且影响到了本文档中包括的某个接口，应该有从这样的需求到本文档中相关需求的跟踪。 

1.6 注释

本段包括对理解文档有帮助的其他一般信息（例如：背景、词汇表、原理）。本部分应该包括所有专有名词、缩写词、术语、定义及其含义。 

1.7 附录

附录用来提供为了文档维护方便而进行发行的信息（例如，图表，分类数据）。如果可能，在文档主体中需要相关数据的地方提供对文档的索引。为了便于处理，附录可以装订成文档。附录应按字母顺序标记（A，B，等..）。