5.1 SE
5.1.1 产品包
产品提供给用户时的全方位呈现，包括产品的外观、功能、性能、价格等
5.1.2 产品包概念
对一个产品包的高层次描述
5.1.3 产品包需求
产品包为满足的各方面要求所需要具有的特性
5.1.4 易用性需求
产品为使用户易于使用所需要具有的特性
5.1.5 RAS需求
产品为满足可靠性、可用性和可服务性要求所应具有的特性
5.1.6 设计需求
对产品包需求进行分解和整理，用以指导系统设计的需求描述
5.1.7 需求分解
将设计需求按照功能、层次逐步细化的过程。由SE与硬件工作师、软件工程师及结构工程师一起协作，分析产品包需求，将需求分解成硬件、软件或结构子系统；然后每一块（硬件、软件、结构）进一步将需求分配到更下一层子系统、部件或模块之中；需求分解要确定某些特殊需求如何由硬件、软件或结构或任何组合形式实现。
5.1.8 需求分配
将分解后的设计需求指配到具体设计模块，定义每个设计模块规格的过程。需求分配需要清晰地决定需求的哪些部门由硬件实现，哪些部分由软件实现，哪些部分由结构实现，它们之间的接口也要定义清楚。
5.1.9 Build
内部版本，满足特定的功能需求，由产品包的部分或全部设计模块构成，其中某些版本可以对外发布。所有Build必须进行SDV测试，对外发布的Build必须进行SIT测试。
5.1.10 产品包需求跟踪矩阵
使用跟踪矩阵将每条产品包需求对应到多个相关的模块，并根据每个模块的验证结果检验每条需求是否得到满足
5.1.11 产品数据结构
产品数据结构以文档树的形式汇总一个产品包所对应的所有数据，包括设计文档、代码、图纸、Bom清单等。
5.1.12 基线化
产品在其开发周期的不同时间点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。
5.2 硬件业务领域术语
5.2.1 基本逻辑
主要用于实现电路信号连接和切换控制的逻辑，规模较小，基本上不包括业务数据处理功能
5.2.2 大规模逻辑
包含较复杂的业务数据处理功能的逻辑
5.2.3 硬件概要设计
在计划阶段，基于概要的BOM结构树及系统的设计规格书，所开发的到板级的硬件设计。它用于指导硬件详细设计
5.2.4 硬件详细设计
基于硬件概要设计，使用标准的设计工具来进行详细设计，描绘出明确的板、卡、元器件要完成的功能和界面，对每一个板/卡/元器件，开发电路设计、原理图、零部件清单、网表等
5.2.5 EMC
EMC是电磁兼容性（Electromagnetic Compatibility），是指电子设备或网络系统具有一定的抵抗电磁干扰的能力，同时不能产生过量的电磁辐射。也就是说，要求该设备或网络系统能够在比较恶劣的电磁环境中正常工作，同时又不能辐射过量的电磁波干扰周围其它设备及网络的正常工作。
5.2.6 可测试性设计
产品能及时准确地确定其状态（可工作、不可工作、性能下降等），隔离其内部故障的设计特性称为可测试性。以提高可测试性为目的的设计称为可测试性设计，简称DFT（Design For Testability）。DFT可有效地降低测试的复杂性，缩短产品的开发时间，减少制造成本和维护成本。在设计初期就要将可测性考虑进去。
5.2.7 可制造性设计
可制造性设计（DFM,Design for Manufacturability）是并行工程中最重要的内容之一，其主要目标是：提高新产品开发全过程（包括设计、工艺、制造等）中的质量，降低新产品全生命周期中的成本（包括产品设计、工艺、制造、发送、支持、客户使用乃至产品报废等成本），缩短产品研制开发周期（包括减少设计反复，降低设计、生产准备、制造及投放市场的时间）。
5.2.8 可靠性设计
可靠性是产品在规定的条件下和规定的时间内,完成规定功能的能力，包括产品的故障（失效）、完好（正常）及可靠、不可靠等状态的随机性。可靠性设计是运用有机方法对这些随机性予以精确的描述，从而对产品进行概率设计。
5.3 软件业务领域术语
5.3.1 用户（User）
直接使用产品的人或组织。这是狭义的理解，等同于End User。在实践中，“用户”这个词的含义已被扩大，包括客户（Customer，负责接收产品、授权付费的个人或组织）、最终用户（End User，真正操作产品的人或组织）、其他人员（售前、售后人员、开发关联产品的人员或组织等）。在本模板中，如果没有特别强调，用户都是指广义的用户。用户可以存在于项目开发团队所在的组织外，也可存在于该组织之内，但一般应在项目开发团队之外。
5.3.2 需求
是指“被描述系统（SuD ，System Under Description）”“做什么”（功能需求）及“做什么”时的水平（非功能需求，如性能需求、质量属性需求、外部接口需求、其它需求）。这个通俗定义是针对技术需求的，而非技术需求（如进度的限制）一般不在本文档中给出（一般放在研制任务书/项目计划中）。
5.3.3 软件需求
软件需求(Software Requirement): 在对用户需求（纯软件项目）或系统方案中的分配需求（软硬件结合项目）进行进一步论证、分析的基础上得到的关于软件的需求，包括功能需求、性能需求、外部接口需求、质量属性需求、其它需求
5.3.4 业务需求
业务需求（business requirement），又称原始需求（raw requirement）用户提出的、未经过分析的需求。业务/原始需求的描述可能是不清晰、相互之间可能是矛盾的，需要经过进一步的论证、分析，以得到用户需求。很多情况下，业务/原始需求甚至包括了需求背景、解决方案的描述。
5.3.5 用户需求
用户提出的、经过论证、分析的需求。一般情况下，对原始需求进行分析，可得到用户需求。
5.3.6 功能需求
功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
5.3.7 非功能需求
非功能需求（non-functional requirement）是从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求。
5.3.8 需求分析
为“能够高质量地描述需求”而进行的活动。所谓“高质量地描述”是指：单条需求具备7大特性（完整性、正确性、必要性、可行性、划分优先级、无二义性、可验证性）、需求说明书具备4大特性（完整性、一致性、可修改性、可追踪性）。
5.3.9 软件需求规格说明
软件需求规格说明(software requirement specification，SRS)，对软件需求进行规格化的文档。该文档为后续的计划制订、设计、测试、用户文档编写等工作提供了基础与约束。一般由项目系统工程组完成产品需求的定义。
5.3.10 统一建模语言UML
统一建模语言（Unified Modeling Language，UML）是一种用来定义，形象表示，创建和文档记载软件系统的工业标准语言。它简化了软件设计的复杂程度，为整个软件的构架建立一个“蓝图”。
5.3.11 用例图(use case)
use case ：是对一组动作序列的描述，系统执行这些动作将产生一个对特定的参与者有价值而且可观察的结构。use case用来捕捉需求，描述参与者（用户）如何使用系统，用户使用系统看作是一系列动作；use case认为要完整描述需求，这些动作的结果应该可见，也就是说用户知道这些动作的结果是什么，而且这些结果是用户所希望得到的。用use case图有如下子项：前置条件，后置条件，触发条件，正常过程，正常过程步骤，可选过程，可选过程步骤，异常过程，异常过程步骤，特殊需求，输入，输出，处理。
5.3.12 IPO图
IPO图是输入加工输出(INPUT PROCESS OUTPUT)图的简称，它是由美国的IBM公司发起并完善起来的一种工具。用来说明每个需求或者模块的输入、输出数据和数据加工的重要工具。开发人员不仅可以利用IPO图进行模块设计，而且还可以利用它评价总体设计。用户和管理人员可利用IPO图编写、修改和维护程序。因而，IPO图是系统设计阶段的一种重要文档资料。
5.3.13 实体关系图（E - R图）
实体关系图描述数据对象及其关系。
实体：客观存在并可区分的事物。
属性：实体所具有的某种特性，一个实体可以有多个属性。
关系：实体之间的对应关系，可分为1：1联系、1：n联系、m：n联系
5.3.14 数据流图
数据流图(Data Flow Diagram，简称DFD)是结构化系统分析的基本工具。一个数据流图确定了系统的转化过程、系统所操纵的数据或物质的收集（存储），还有过程、存储、外部世界之间的数据流或物质流。数据流模型把层次分解方法运用到系统分析上，这种方法很适用于事务处理系统和其它功能密集型应用程序。
5.3.15 状态转换图
实时系统和过程控制应用程序可以在任何给定的时间内以有限的状态存在。当满足所定义的标准时，状态就会发生改变，例如在特定条件下，接收到一个特定的输入激励。这样的系统是有限状态机的例子。大多数软件系统需要一些状态建模或分析，就像大多数系统涉及到转换过程、数据实体和业务对象。
5.3.16 序列图
在整个设计过程中都会用到序列图，用于演示系统执行时参与者与对象之间的内部交互。序列图用于建立以下内容的模型：
5.3.17 数据字典 （data dictionary）
一个软件系统中使用的所有数据项名称，以及这些项相关属性的集合。
数据流、数据元素、文件、数据基础、和相关处理的一个集合。
5.3.18 软件缺陷（bug）
软件缺陷这一概念用来描述各种软件错误，是所有软件错误的统称。
把符合下列5种特征之一的软件错误认为是软件缺陷：
故障 fault：软件的内在缺陷，可在生存期各阶段引入；
错误 error：故障在一定环境下的暴露，导致系统的不正常运行；
失效 failure：对错误不做任何修正和改动，导致系统的错误输出。
5.4 结构业务领域术语
5.4.1 结构件
指自行设计或直接外购的机加工零件、模具、模具制品、包装纸箱、填充物、塑料袋、紧固件等。
5.4.2 定制结构件
指自行设计的，非直接外购的机加工零件、模具、模具制品、包装纸箱、填充物、塑料袋、定制紧固件等。
5.4.3 标准件
标准紧固件的简称，包括螺栓、螺柱、螺母、螺钉、垫圈、自攻螺钉、章销、铆钉、挡圈、焊钉、紧固件组合件及连接副等
5.4.4 外部电缆
设备机箱外部与其他设备连接的线缆，如：V35/D37线缆、光纤、电源线、网管线、同轴电缆等。外部线缆的特征是：位于设备外部、长度或者接口形式根据用户需求而定。
5.4.5 线组件
设备机箱内部，出口器件到PCB、以及PCB间连接的线缆，如：船形开关到PCB间的线组件等。线组件的特征是：位于设备外部、长度及接口形式根据设备自身而定。
5.4.6 UCD（以用户为中心的设计）
从结构设计的角度是指：关注于产品与客户接触的所有方面，如：人机用户接口、易用性、人机工程学、外观与造型等。是充分考虑用户体验的设计。
5.4.7 工业设计
工业设计就批量生产的产品而言，凭借训练，技术知识，经验及视觉感受而赋予材料，结构，构造，形态，色彩，表面加工以及装饰以新的品质和资格。
5.4.8 手板
在产品的设计过程中，完成了设计图纸以后，为验证设计的外观和自己的设计思想是否吻合、结构设计是否合理等因素而制作的样品。手板制作多采用CNC加工、激光快速成型、手工放样等方式实现。手板多指塑模制作的样品。
5.4.9 塑料模具（简称塑模）
在塑料成型工艺中，为成型塑料件而采用的模具。
5.4.10 冷冲裁、冲压模具（简称冷冲模）
在钣金成型工艺中，为分离工序（剪裁、冲裁）和成型工序（弯曲、拉伸、成型）而采用的模具。
5.5 TE
5.5.1 可测试性需求
为便于系统测试、便于发现、定位、隔离和解决异常问题而对系统设计提出的要求。
5.5.2 可测试性
系统和设备能够及时准确地确定其工作状态（如：可工作、不可工作、工作性能下降等），可有效的进行测试，发现问题后可有效的隔离其内部故障的一种设计特性。
5.5.3 测试计划
概要阐述测试过程。其中包括：各测试阶段的测试重点、测试环境、主要的测试工具、时间、人力安排等。
5.5.4 测试报告
分析测试结果，记录测试过程中关键信息的文档
5.5.5 SDV，功能样机测试
System Design Validate，SDV又称功能样机测试，是对系统功能展开较全面的测试。
5.5.6 SIT，性能样机测试
System Integration Test,SIT又称性能样机测试，在系统功能测试后，针对系统的稳定性和可靠性展开的测试。
5.5.7 SVT&SVT2
SVT（System Validate Test），对试产产品的抽查测试；SVT2针对BETA测试中发现的bug实行的回归测试。
5.5.8 Beta测试
β测试是由多个用户在多个用户的实际使用环境下进行的测试，一般以试验局体现。
5.5.9 实验局
即系统的Beta测试。对于在实验室不能进行的测试和验证工作，选择典型的应用场合，在用户的实际使用环境中进行的测试的活动，称为实验局。
5.5.10 回归测试
对曾经测试过的特征重新进行测试，以确保变更或bug的修复没有带来新的问题。
5.5.11 测试用例
测试用例是阐述如何对某项功能或功能组合进行测试的方法。（或者说：测试用例设计是将测试的行为活动，作一个科学的组织归纳。测试是又组织性、步骤性和计划性的行为；设计测试用例的目的，就是为了能将测试的行为转换为可管理的模式。）
5.5.12 测试方案
测试方案是产品测试的总设想，主要由测试用例组成。
5.5.13 测试工具
在测试过程中使用到的仪器、仪表、硬、软产品等
5.5.14 测试环境
测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备、测试用仪器仪表等辅助硬件设备所构成的环境 ；软件环境指被测软件运行时的操作系统、数据库以及其他应用软件构成的环境。在实际测试中，软件环境又可分为主测试环境和辅测试环境，主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境。配备测试环境是测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。
5.5.15 入网测试
为取得行内入网许可证的测试，入网测试需第三方测试。
5.5.16 检验报告
又称入网测试报告，在入网测试结束后由第三方测试机构出具的测试报告。
5.5.17 入网证
行内入网运行许可证书。