系统需求说明书模板

产品名称密级

机密

产品版本

共21页

XX需求说明书

拟制日期yyyy-mm-dd

审核日期yyyy-mm-dd

批准日期yyyy-mm-dd

修订记录

日期修订版本修改描述作者

yyyy-mm-dd1.0初稿完成姓名（工号）

yyyy-mm-dd1.1

目录

1简介..............................................................................................................................................................6

1.1背景.....................................................................6

1.2用户特征.................................6

1.3假设和约束...............................6

1.4待确定问题...............................6

2系统概述.....................................................................................................................................................7

2.1WR版本描述..............................7

2.2系统上下文................................7

2.3产品组合形态（可选）......................7

2.4外部依赖............................................................7

3需求概述.....................................................................................................................................................7

3.1总体描述..................................7

3.2应用场景..................................8

3.3需求之间的依赖和联系（可选）..............8

4功能器求.....................................................................................................................................................8

4.1XX功能需求（含编写建议的模板）..........8

4.2YY功能需求（无编写建议的模板）..........12

4.3ZZ功能需求...............................13

5非功能需求..............................................................................................................................................13

5.1可采购性..................................13

5.2可供应性..................................13

5.3可靠性..................................................................13

5.4性能.....................................................................13

5.5可服务性............................................................14

5.6节能减排............................................................15

5.7安全性..................................................................15

5.8兼容性...................................................................15

5.8.1外部标准......................................................................15

5.8.2内部标准规范..................................................................15

5.9可测试性............................................................17

5.10可演进性............................................................17

5.11资料............19

5.12成本............20

5.13License...................20

5.14其它需求..................................20

5.14.1XX需求.....................................................................21

6备注和附录.............................................................21

表目录

表1样表：用户角色定义..............................................................6

表2样表：升级路线与升级策略......................................

图目录

图I样图：MA5600产品的系统上下文7

Keywords关键词：KeywordsarerequiredinbothChineseandEnglish,sothatforeignerscansearch

conveniently.为方便外籍人士检索,此处应提供中英文版

Abstract摘要：AbstractisrequiredinbothChineseandEnglish,sothatforeignerscansearch

conveniently.为方便夕卜籍人士检索,此处应提供中英文版

术语和缩略语清单:

术语/缩略语描述

MPLS(MultiprotocolLabelSwitching)MPLS（多协议标签交换）是提高电信网络性能的一种机制。

在MPLS网络中根据数据的标签确定下一跳的节点

1简介

1.1背景

写作说明:本文档默认使用的Word格式是“正文缩进”。作者在写作文档主体时,请在菜单

“样式和格式”中选择“正文缩进”样式。其它需要用到的表格、图、编号、列表等也己经预定义

了样式，请尽量使用己有样式,不要自定义样式。

一个系统通常有一篇或多篇系统需求说明书,对于多篇文档按如下方式组织:

I.对于功能的需求,每个功能域或者功能的需求写作为•篇功能需求文档,使用本模板,

可裁剪章节5“非功能需求”。

2.对于关键DFX的需求,每个关键DFX的需求写作为一篇需求文档,使用关键DFX需

求说明书模板。

3.对于其他没有必要独立交付的系统需求（包括全局性DFX需求、成本需求和没有必要

分类的需求），写作为一篇非功能需求文档,使用本模板,可裁剪章节4“功能需求”°

对于复杂系统,除了输出系统层面的需求文档外,还可能输出子系统层面的需求文档。

本章节简要描述待开发系统的背景、希望完成的任务/目标,范围。

1.2用户特征

表1样表：用户角色定义

用户角色

工作职责和目标工作场所技术程度语言备注

名称

COX代

Regional管理区域安装计划、进度高深，有资深

维办公熟练应用

Project监控、掌控各个区域的运的技术背景无

室、局点英语

Manager营和问题推到解决和管理背景

机房

实施项目的操作者，包括

安装督导、安装、软调、

高级或中级，能使用英

验证等。使月产品手册的

Engineer局点机房有一定技术语进行口无

人员，根据实际操作提出

背景头交流

问题，输出具体的与工程

场景匹配的MOP文档

oooo

本系统主要应用于中东国家，其中有些国家的当地语言文字从右到左阅读。

本系统的计费部分由运营商的营业厅人员使用，他们是专家用户，具有友商或我司产品的应用

经验。

本系统的XX部分由我司技术支持人员使用，他们是专家用户，具有我司产品的应用经验，但本

系统XX部分XX功能的使用方法不同于我司已有产品，用户需要学习并习惯。

1.3假设和约束

本章节描述假设和约束。假设和约束就像系统的定义域,决定系统存在的根基,要加以重视。

1.4待确定问题

本章节描述待确定的问懑,包括问题影响范围、风险、责任人、计划解决口期、当前状态等。

2系统概述

2.1V/R版本描述

本章节描述同系列各WR版本的联系和区别、本版本的变化,包括新增修改删除需求对原有系

统的影响。

2.2系统上下文

本章节描述待开发系统的边界,包括所有的外部实体及相关接口。

图I样图：MA5600产品的系统上卜文

在图后辅以必要的文字说明

2.3产品组合形态（可选）

本章节描述产品运行时的组合形态,包括产品组合的差异和环境适应性。

例如:

公司第四代基站产品形态丰富，满足不同应用场景的网络部署，可以为运营商提供完美的全网

解决方案。公司第四代基站包括：室内宏基站BTS3900、室外宏基站BTS39OOA、分布式基站DBS3900

和微基站BTS3900C。BTS3900主要应用于高密度大话务量、机房租用成本高、空间受限的室内安装

场景；BTS3900A主要应用于需要大容量覆盖的城市/郊区/农村的室外安装场景；DBS3900主要应用

于需要广覆盖、站点建设困难的室外安装场景；BTS3900C主要用于室内覆盖和对热点地区的覆盖。

2.4外部依赖

本章节描述对外部条件的依赖,例如准备使用的第三方或商业组件,使用其他产品/平台/项目

的文档或交付件等。

3需求概述

3.1总体描述

本章节对本文档的需求进行总体描述,例如对本文档需求对应的功能域或功能的总体描述。

3.2应用场景

本章节描述需求的应用场景,解释说明用户在什么情况下使用这些需求。如果待开发系统对外

交互较多,建议分成多个场景描述,如正常运行场景、管理场景、维护场景、备份场景、升级场景

等。

3.3需求之间的依赖和联系（可选）

本章节描述需求之间的依赖和联系,包括本功能内多个需求之间的依赖/联系、本功能与其他功

能之间的依赖/联系。

4功能需求

大多数功能需求都具有较多步骤、而且这g步骤之间有逻辑顺序联系,建议使用下面的用例格

式描述这一类需求。而对于简单的的功能需求、没有明显的系统交互行为的功能需求、适合表格/

公式表达的功能需求,建议不使用用例格式进行描述,以非用例格式为模板写作。

4.1XX功能需求（含编写建议的模板）

本文不要求写作需求的编号、优先级、来源、实现的版本号,这些内容在需求管理工具中描述。

本章节描述单个功能镉求。本章节的格式是按照用例的格式编排的。

功能需求的名称就是用例的名字,同时也是用例的目标。为每个用例定义一个好名字幸常重要,

如果找不到合适的名字,则意味者此用例的目标不清晰。

使用动词+名词的方式命名每一个用例,这个动名词的近语必须能够清晰的表达出此用例的主

执行者的目标。完整并且清瞄的目标的特征如下:

1.它明显和一个主执行者密切相关,而且只和一个主执行者密切相关。

2.它对主执行者和其它相关人员是有价值的。

3.它与你当前正在写作的目标层次一致。如果不一致,则需要重新思考这个用例,或将它

移动到合适的层次中。

用例的这一个目标必须是主执行者的目标。执行者是与系统具有任何行为的事物。执行者可能

是一个人,一个公司或组织、一个程序或计算机系统、一个其他功能或本功能自身。主执行者是通

过用例达到了目标的执行者。

主执行者是通过用例达到了目标的执行者。

特别的,待开发系统和它的子系统也可以作为用例的一个执行者,但不能作为主执行者。只有

外部的执行者才能作为主执行者并通过用例实现自身的目标。例如“记录日志”用例,在此用例隐

含的主语是“系统”，但不能据此认为此用例完成了“系统”的目标。虽然没有出现“管理员”这

几个字,但此动作确实完成了“管理员”这个主执行者的目标。即在用例中,系统可以有动作,但

不能有目标,所有的目标必须是外部主执行者的。即用例只能100%从系统外部的角度考虑,描述

系统或系统内部行为的目的只能是为了实现某个外部主执行者的目标。

与用例的目标类似,用例中的每个场景、场景中的每个动作都必须具有目标,而且必须是某个

外部主执行者的目标。凡是没有外部主执行者认领的场景或动作,都不应该在用例中出现。不过,

我们必须为每个用例的目标命名,即为每个功能需求取名,但没有必要为用例中的每个场景、场景

中的每个动作命名。

用例必须全部达到下面的判定标准:

I.所有的主执行者和目标都已经被识别并写出;

2.客户或其代表认为没有遗漏用例,并旦每个用例都是正确并H可读的;

3.系统设计人员认为能够演现这些用例。

4.系统测试人员认为能够验证这些用例。

1.简要说明

本章节描述此用例的概要。

2.Actor

本章节描述此用例涉及的所有Actor（执行考）。

3.前置条件：

在没有“前置条件”的情况下,应该写“前置条件:无”。

用例的前置条件声明了启动该用例之前系统必须满足的条件。

一个常见的例子是“用户已经通过了身份验证”。通常,前置条件是其他用例的执行结果，“用

户已经通过了身份验证”这个前提条件是“验证用户身份”用例执行成功后的结果。

4.最小保证：

在没有“最小保证”的憎况下,应该写“最小保证:无”。

最小保证是在主执行者的目标不能被满足的情况下,对系统的最低要求,例如系统数据不能丢

失,业务不能中断等。

每一个失败条件和处理方案都会在用例的某个扩展场景中进行描述。此处需要描述的是所有场

景都必须做到的要求。

5.成功保证（后置条件）：

在没有“成功保证”的情况下,应该写“成功保证:无”。

成功保证是在主执行者地目标被满足的情况下,系统的输出和达到的状态。

6.触发事件：

在项目组约定将“触发事件”写作为用例主成功场景第一步的情况"此章节可以被蒯除。

用例的“触发事件”不能为“空”，也不能为“无”。

触发事件是启动用例的事件，紧接着就发生用例的第一步。

触发事件必须能够被系统检测到,“客户决定使用系统”不是一个恰当的触发事件。

7.主成功场景（基本事件流）

本章节的内容不能为“空”。

一系列的成功动作最终实现了主执行者的目标，并保护了项目相关人员的利益,它们构成了用

例的主成功场景。主成功场景应该简短明了,它指明了系统提供的服务。

主成功场景能够完成此用例的目标,并且故事直线发展。主成功场景不一定是达到用例目标的

最短路径,但它必须是最常发生或用户最喜欢发生的路径。其他的成功场景和所有错误的处理,都

在下一章节的扩展场景中进行描述。

用例中的每个场景、场景中的每个动作都必须具有外部主执行者的目标。主成功场景的目标是

实现主执行者的意图（并且与用例目标相同），扩展场景的目标是在异常情况下实现主执行者的某

个意图（其他的成功路径）,或者在不能实现主执行者意图的情况下,保证系统其他相关人员的利

益（失败路径）。

主成功场景使用带编号的步骤进行描述。场景中每一个步骤的粒度相近,而且每一步的目标层

次稍低于整个场景的目标层次。

对其中的每一个步骤,在任何情况下,都不能省略句子的主语,不能使用被动语态。建议不使

用复杂的句子结构。

.1.步骤1。

.2.步骤2。

.3......

.4.步骤No

.5.主成功场景的最后一个步骤。此步骤完成后，必须达到了主执行者的目标。

场景的一次交互包含卜面的4个部分:

1.主执行者向系统发送请求和数据。

2.系统验证收到的请求和数据。

3.系统更改内部状态。

4.系统向执行者返回结果。

作者可以把上面的每个部分写成一个单独的执行步骤,也可以用不同的方式合并其中的几个部

分,或者将4个部分合并成一个执行步骤。

合并的原则取决于每个部分的复杂程度和执行过程中在什么地方会发生扩展场景来决定,不存

在对所有用例通用的写作方式。

使用下面的2种方式之一表达重复的步骤:

1.在单个步骤中直接表达,例如:“主执行者执行XX动作，直到满足r条件时停止”。

或“此步骤操作可能会重更多次”

2.在余复的步骤前面表达,例如:“步骤3—5可以重复执行”这句话放在步骤2之后,

步骤3之前,没有编号。

8.扩展场景

通常,本章节需要描述多个扩展场景。

本章节的内容不能为“空”。在确实没有扩展场景的情况下，说明此功能需求十分简单,不需

要使用用例的格式进行描述,直接使用一段话描述此功能需求即可。

在主成功场景下，对于因为特别条件而出现行为分支的每个地方,写出分支的条件以及处理分

支的步骤,这就是扩展。每一个扩展场景最后必须能够回到主成功场景中,或者由于失败直接结束。

扩展由一系列的扩展场景组成。每一个扩展场景都开始于一个与它相关的前提条件,然后是一

个步骤的序列,该序列描述了在这个条件下发生了什么;每个场景以完成或放弃本场景的目标作为

结束。

由于每个扩展场景实质上是一个从主用例中拆分出来的小型用例,所以每个扩展场景也拥有自

己的目标、目标级别、前提条件、主干（完成了扩展目标的主成功场景）和分支（完成了扩展目标

的其他路径或保证其他相关人利益的其他失败路径），并且按照用例的写作方式进行写作。

任何一个扩展场景,都只能并且必须以下面的4种方式之一结束:

1.修改或替换主成功场景的当前步骤，然后重新开始主成功场景的当前步骤、或者执行主

成功场景的下一步。在这种情况下,不需要说明扩展场景执行后怎么办。

2.系统给执行者其它的选择,执行完毕后回到主成功场景的某个步骤。在这种情况下,扩

展场景的最后一个步骤必须是“转到步骤N〃。

3.与主成功场景不同的成功路径。在这种情况下,犷展场景的最后一个步骤必须是“用例

结束".

4.没有达到主执行者目标的异常结束。在这种情况下,扩展场景的最后一个步骤必须是“用

例结束”。

每个扩展场景开始于一个编号和前提条件。此编号由3部分组成:

阿拉伯数字:表示此前提条件出现在主成功场景的第N个步骤。此处不能使用自动编号,

建议由作者手工编号。

英文字母:表示在主成功场景的第N个步骤中，出现了多个扩展场景,这些扩展场景按照

“a”到“z”的顺序编号。同一个步骤下出现的扩展场景不多,建议由作者手工编号。

（点、）：分隔此编号和前提条件。

例如:“〃.〃表示主成功场景的步骤1发生的第1个扩展场景,“1b.”表示主成功场景的步

骤1发生的第2个扩展场景,以此类推。

特别的，有些扩展场景可能发生在任意一个步骤中,例如2表示此扩展场景发生在主成功

场景的任意，个步骤中。有些扩展场景可能发生在多个步骤中,例如“2-5a.”表示此扩展场景发生

在主成功场景的步骤2-5中。

针对复杂的扩展场景,可能需要进一步写作此扩展场景下面的犷展场景,这种情况下,建议在

此扩展场景出现分支处理的步骤中,直接写作下层扩展场景。例如,编号“"2a.”表示在扩展场景

“1b.”的步骤2中发生的第i个更下层扩展场景,此扩展场景应写作在“1b.”的步骤2下面。比

“"2a.”更下层的扩展场景,建议不编号直接写作（使用缩进）,或者独立为1个单独的子功能用

例。

用一个描述系统检测到了什么的短语或句子描述扩展场景的前提条件,并且在扩展场景的前提

条件后面加一个冒号（:主用单元或备用单元发生故障、链路故障或切换、对端设备拒绝或拆线、

用户中途取消操作、被叫忙、酿置数据不完整、低压或掉电等都是扩展场景常见的前提条件。

在扩展场景可以通过一句话或者一段话说清楚的情况下,将步骤与分支条件写在一行,例如:

2a.系统检测到XX条件：系统提示失败，退出YY操作，执行ZZ操作，……，用例结束。

在扩展场景必须通过多段话才能说清楚的情况下,将分支条件写成独立的一行,例如:

2a.系统检测到XX条件：

.1.系统提示用户，要求输入新的XX参数。

.2.用户输入XX参数。

包含更F层扩展场景的例子:

2a.系统检测到XX条件：

.1.系统提示用户，要求输入新的XX参数。

.2.用户输入XX参数。

2a2a:系统检测到XX」条件：

..1.系统提示用户，要求先执行XX操作后才能输入此参数

♦•2•・・・・・・

..3.用例结束

.3.转到步骤6。

在多个扩展场景中,如果处理行为一致,则应该合并这些场景。例如:

2b.系统检测到YY条件或检测到ZZ条件：系统提示失败，……，用例结束。

9.质量属性

本章节描述此功能需求的DFX质最属性,例如各个操作导致的业务中断时间、单板/模块最长

启动时间、性能等。

10.数据字典和附加描述

在没有“数据字典和附加描述”的情况下，本章节应该被删除。

数据字典是数据元素的有组织的列表、以及精确的严格定义,目的是达成用户和系统设计人员

共同的理解。数据字典使用“数幽•”+“详细解释”的格式进行描述,其中的“数据”应该己经

出现在用例中,可以是名词、动作、或者一个短语。

附加描述是需要解释或者备注说明的任何内容。有可能附加描述中的内容在其他用例中有详细

的执行步骤,但在本用例中并不关心这些细节,说明参加XX章节即可。

4.2YY功能需求（无编写建议的模板）

1.简要说明

2.Actor

3.前置条件：

4.最小保证：

5.成功保证：

6.触发事件：

7.主成功场景

8.扩展场景

9.质量属性

10.数据字典和附加描述

4.3ZZ功能需求

有些功能需求不合适以完整用例的方式描述，建议以下面的模板写作。

1.正常场景

本章节描述系统在各种正常场景的处理情况。场景应该简明,完整,不含糊,可验证，必要的。

至少包括:前置条件,触发事件、关键步骤、成功保证（后置条件）四部分的内容.即说明清楚在

什么条件下,发生什么事件后,系统加何处理,最后系统输出什么等内容

2.异常场景

本章节描述系统在各种异常场景中的处理情况。场景应该简明,完整,不含糊,可验证，必要

的。至少包括:前置条件,触发事件、关键步骤、后置条件四部分的内容,即说明清楚在什么条件

下,发生什么事件后,系统如何处理,最后系统输出什么等内容。

3.质量属性

本章节描述此功能需求的DFX质量属性,例如各个操作间的时间间隔要求、整个功能完成的时

间要求、单板/模块最长启动时间、完成此功能消耗的系统资源、需遵循的标准规范等。

5非功能需求

5.1可采购性

分析友商相对应产品物料选型方案,分析物料行业趋势,分析公司内同类标杆产品或者继承性

产品物料选型设计,为本产品物料选型、重用设计、演进设计需求提供参考。

例如:

物料优选率：从公司优选库/路标库中选取物料，遵循公司物料选型规范。

关键物料种类：产品同一版本中的物料种类/数量最优最小化，保证产品内的重用率。

替代设计：物料都要有2-3个主流厂家，并进行容限容差设计；如电源模块、光模块、flash、

DRAM、钟振等器件实现可替代性设计（参数兼容、功能兼容、跨代兼容）。

物料生命周期匹配设计：与产品/单板生命周期匹配选型，短生命周期物料能在产品生命周期内

持续演进。

物料差异化优势构建：通过供应商早期介入项目（ESI）,产品关键新物料与供应商签署的排他协

议、或者技术断裂点、或者申请专利。

物料供应成套周期匹配设计：根据产品供应方案，对生产需要的原材料齐套时间进行分析，使

之符合产品供货及弹性需求。

5.2可供应性

可供应性的系统需求，请参考本产品版本的“可供应性需求说明书”，本文档不做具体描述。

5.3可靠性

可靠性的系统需求，请参考本产品版本的“可靠性需求说明书”，本文档不做具体描述。

5.4性能

例如:

业务性能：产品提供的业务性能要求

设备性能：产品的配置、容量、处理能力等性能指标

网络类性能：网络能力指标，如接口吞吐量、网络连接能力

5.5可服务性

例如:

生产预女装：指将能够在公司完成的女装提前在生产发货前完成，包括但不限于单板/模块、内

部线缆、版本定制、License文件生产预安装，以及软件类的操作系统、数据库、双机软件等。使一

线安装的工作简单再简单，提升交付效率，降低对安装人员的技能要求

硬件安装基础工时：指某典型配置的产品在各种条件具备的前提下，由符合既定技能要求的工

程师按既定的资料和质量要求，一次性的完成从开箱验货到机柜上电之间标准工序所花的所有工

时；不包括路途和管理工时。降低硬件安装工时，提升硬件安装效率，降低服务成本，支撑GTS降

低合作外包价格。牵引研发人员从设计方案上提升产品的可安装性能力。

远程集中调测：指软调人员不用去现场，可以远程集中完成基础数据配置、业务调测、软件质

量检查（包括版本补丁的确认）工作。节省软调进站的路途工时和费用，提高工程交付效率，支撑

GTS降低合作外包价格

远程集中升级/打补丁效率：指在客户允许的时间维护窗口内，可完成升级/打补「操信的网元

数量。提升升级效率，降低服务成本

--键式升级/打补丁：指进行完必要的参数设置后，仅执行一个操作就完成整个软件的升级，在

后续的执行升级/打补丁过程中，用户只需要监控度，不需要进行任何干预（过程中不需要用户进行

任何操作，包括确认操作）；在失败的情况下，无需任何参数配置，仅执行一个操作就可完成整个

软件的回退，在整个回退过程只需要监控进度，不需要进行任何干预。降低升级对操作人员的技能

要求

License安装及维护效率：实现License文件的远程批量安装、失效License文件，并能够远程查询

网元License状态、License授权及使用情况，例如：通过网管或工具实现远程安装及维护，以提升

License操作效率，降低服务成本。

License可验收：安装License文件后，能呈现出客户购买特性及License授权状态，以支持软件及

License在客户界面的验收。

单故障告警数符合率：指对系统注入故障后，产生的告警数小于规定值的故障数量占整个注入

故障数量的比值。用于减少设备产生的无效告警，降低用户无效的派单数，提高监控效率，

告警帮助有效性：指通过告警资料或联机帮助中提供的STEP-BY-STEP处理步骤，能准确将告

警消除的告警数量与所有告警数量的比值。方便用户自行解决告警，减少GTS工作量

远程数据配置：数据配置的手段上，可以远程配置。在数据配置过程上，简单、高效、少错。

具体方式包括GUI配置、批最配置、场景化标准配置、完善配置校验、检查等能力。提升配置效率、

降低对人员技能的要求、防止配置人因差错并降低配置错误对网络的影响。

远程巡检：可远程完成设备巡检；提高巡检项目自动化比例：巡检设备批量化：自动分析提示

隐患、问题原因和解决建议；跨版本巡检。提升巡检效率、降低巡检人力需求、快速准确发现设备

隐患并形成解决办法。

电子标签能力具备：指可更换单元（FRU,不限于主控板、业务板、机框/背板、机柜、电源（含

外购/监控）、风扇（含外购/监控）、光模块（含外购）、辅助类板（环境监控/告警监控/时钟/AUX等）等部

件）能将拉手条上标签信息电子化，并能够远程采集。能通过各产品线网管进行管理的IT外购设备（小

型机/存储/服务器等），同样要能实现标签电子化，并能远程采集。不需要到现场去手抄FRU或IT

外购设备的条码，节省进站成本，提升采集效率

全球化设计：是否需要支持全球应用

区域市场：需要在哪些特定市场应用

界面类全球化需求：界面语言、格式、文化习惯方面的要求

软件类全球化需求：软件语言、格式、文化习惯方面的要求

资料类全球化需求：资料语言、格式、文化习惯方面的要求

翻译类全球化需求：为了保证翻译的一致性和快速，在全球化设计方面提前构架

外购件类全球化需求：外购件语言、格式、文化习惯方面的要求

法律法规全球化需求：在软件的本地化过程中应支持当地标准，且确保不违背当地法规

硬件类全球化需求：工业外观设计要求

资料类全球化需求：资料语言、格式、文化习惯方面的要求

解决方案配套：为实现业务功能需要的多网元配套

整机功耗、电源参数、重量、尺寸等技术参数

5.6节能减排

节能减排的系统需求，请参考本产品版本的“节能减排需求说明书”，本文档不做具体描述。

5.7安全性

安全性的系统需求，请参考本产品版本的“安全性风险分析及需求说明书”，本文档不做具体

描述。

5.8兼容性

5.8.1外部标准

描述产品需要遵循的外部标准,例如:

接口兼容性：说明本版本相对于本产品以前的版本，接口在兼容性方面的变化。

行业管理类准入：行业管理类准入测试

国际认证类准入：国际认证类准入测试

业界行业认证：业界某一行业的认证

区域市场准入：目标市场及国家的市场准入原则、测试机构和测试流程

外部标准不遵从说明：本产品的设计不遵从或不完全遵从哪些企业内部标准规范。需详细说明

不遵从的情况和原因以及可能造成的影响。

5.8.2内部标准规范

描述产品需要遵循的企业内部标准和技术规范,下面罗列了需聿点关注的部分内部标准规范,

详细可查阅公司标准规范库和业界标准:

I.系统设计规范

(1)软硬件解耦规范

(2)...

2.硬件设计规范

(1)印制板(业务单板)外形尺寸规范

(2)单板电压规范

(3)...

3.软件设计规范

(1)License文件规范

(2)编程规范

(3)...

4.整机设计规范

(1)整机结构作选型规范

(2)整机电缆组件选型规范

(3)机电部件与上位机通信协议规范

(4)工程安装结构件设计规范

(5)包装设计规范

(6)...

5.原理图、PCB工艺设计规范

(1)电路图绘制规范

(2)PCB工艺设计规范

(3)...

6.可靠性设计规范

(1)器件降额规范

(2)内存管理可靠性规范

(3)...

7.可服务性设计规范

(1)公司电子标签规范

(2)公司告警定义规范

(3)...

8.可测试性设计规范

(1)单板可测试性设计规范

(2)单板硬件电源可测性设计规范

(3)...

9.网络安全设计规范

(1)*EB应用安全开发规范

(2)Mb安全测试规范

(3)...

内部标准规范不遵从说明：本产品的设计不遵从或不完全遵从哪些企业内部标准规范，需详细

说明不遵从的情况和原因以及可能造成的影响。

5.9可测试性

一、可测试性需求包含以下方面:

/、客户标书中的故障定位&隔离需求

2、客户标书中的测试验证需求

3、网上&研发历史问题可定位和快速定位需求（适用于继承产品）：内置自诊断,问题重现

需求等。

4、研发测试需求：可观可控设计提升测试质量和覆盖,可控和可跟踪设计提升自动化质量和

效率

5、生产测试需求（适用于硬件）：内置自测试支撑免仪器，测试接口标准化支撑测试装备归

一化和简化,压力测试拦截物料批量一致性问题等

6、运维测试需求:产品在安装、升级、搬迁、割接、扩容等场景下能够快速、方便的进行现

场测试验证

7、故障定位信息一键式采集需求:按照故障现象或产品特定可一键式采集信息

8、故障定位信息远程采集需求:提供远程访问的硬件物理通道,提供远程接入的协议设计,

故障信息（告警、日志、跟踪信息、性能、配置信息等）远程获取。

9、提供远程调测方式:提供远程调测的硬件物理通道,以及调测的安全设计,调测H志、可

读写地址可访问等

二、可测试性需求分析方法可采用:交叉矩阵、用户场景方法、分层分段分面方法、规格FDA、

故障树、FMEA分析等。

参考资料清单:

参考1：DFT质最属性标准V2.0分解分配要求

参考2：可测试性需求分析指导书YLO

参考3：可测试性需求分析模板

参^4：各产品线可测试性需求基线

5.10可演进性

例如:

性能伸缩性需求：指系统通过增加资源（CPU、内存、业务板卡、设备单元等），提升系统的

性能的能力。

如:

支持通过增加单元，以集群、分布式、或负载均衡等方式提升能力。

增加资源时，系统能力线性增长。

增配资源不影响现有业务运行

增配资源时可以进行资源配置修改，但不需要修改应用软件

支持总线扩容，背板在产品当前规格基础上还具有的无缝提速能力。

支持通过现有端口提速或者端口密度扩展实现的系统扩容能力。

支撑业务板k容量和能力提升。

支持通过提升CPU、增加内存等提升系统能力。

系统功耗扩展能力（含供电和散热能力）。

功能扩展性需求：指将在系统中添加、修改及裁减功能的能力

如：

支持系统裁减，对不需要的特性进行剪裁时不需要修改代码，不影响系统的功能

支持运行期剪裁，系统运行期进行特性裁剪不影响其他特性的运行。

增加新特性不影响现有特性的用户感知

软件扩展时不需要调整架构（如：不增加新的接口；不修改现有接口；不修改模块间依赖关系;

不修改现有模块代码；不增加新的模块等）。

支持按License销售

支持运行期的可扩展（动态可变性），系统运行期进行特性的扩展不影响其他特性的运行

软硬件解耦、主机软件与单板软件解耦、子卡与业务处理板解耦等。

扩容与升级/补丁：远程、集中、批量升级/打补丁；在线扩容，升级补丁。

组件可替代性需求：指组成架构的各组件，可以随技术进步而演进和更换，而不影响其他组件

和架构一致性。

单板即插即用，新单板能够即插即用，能够通过网络完成自动部署和启动，不引起主机软件及

网管联动升级。

切换硬件平台应不需要更改业务代码或修改受控；问类型CPU单板的外设硬件升级，土机软件

不需要升级。

切换操作系统不影响业务，不需要更改业务代码；同类CPU架构卜切换Linux的不同发行版，应

用软件不需要升级。

数据库升级不引起产品的联动升级。数据库切换，自研软件不需修改代码或代码修改受控。

更新换代较频繁的xx器件，支持独立升级，无需重新开发单板，且除驱动外无需修改软件。

某个整机模块的修改无需其他模块同步修改。

业务模块升级不引发其它业务升级。

业务相关模块与业务无关模块隔离，业务无关的软件升级不影响业务。

外购软件、开源软件版本升级不对自研软件产生影响。

系统升级路线与升级策略：根据版本立项时的版本收编和升级路径规划，标识本版本和其他版

本间的继承关系和收编关系以及所有升级路线，识别出需要点到点开发的升级路线（即升级场景）。

对于每个升级场景，从特性/需求兼容性、配置（包括数据表、软参、定时器、公共参数、模块参数

及license）和外部接口（包括MML、话统、北向、告警、话单、监听、网关及其他周边网元的接口）

变更等方面分析升级产生的影响。

表2样表：升级路线与升级策略

升级路线升级影响升级策略

R2c05-*R3coi系统查询位置区小区表时会增1、系统增加保护性处理，当判

加对•小区对应的BSC个数的判断BSC个数为0时，继续原有的

断，如果BSC个数为0,则该小处理，判断是否存在有效的信令

区下的用户无法发起和接收呼点，如果存在则呼叫流程仍然可

叫。以正常接续。

2、提供升级脚本保证小区对应

的BSC个数的正确性。

注：一般情况下是不允许升级脚

本修改数据的，如果采用这样的

策略，需要知会版本SE。

升级前对于NCSIDP3数据，系通过升级工具检查升级前的

统会对SCP寻址表的CAP版本NSCIDP3表，如果某条记录在

进行判断，不等于CAP3就抑制SCP寻址表中的CAP版本不为

触发DP3。升级后改变了处理流CAP3则升级后丢弃该记录的数

程