IPD术语基础手册大全.doc

保密级别：绝密 机密 控制 公开

IPD术语手册

编写人：XXX/YY.MM.DD
审核人：XXX/YY.MM.DD
/YY.MM.DD
/YY.MM.DD
批准人：XXX/YY.MM.DD

YYYY-MM-DD发布 YYYY-MM-DD实行
发布

目 录
1.0 IPD体系 8
1.1 集成产品开发IPD 8
1.2 异步开发 8
1.3 公用基本模块CBB 8
1.4 跨部门团队 8
1.5 构造化流程 8
1.6 项目管理 8
1.7 管道管理 9
1.8 客户需求分析 9
1.9 投资组合分析 9
2.0 PDT 9
2.1.1 IPMT 9
2.1.2 PDT 9
2.2 Charter 9
2.3 业务筹划 9
2.4 端到端项目筹划 9
2.5 工作分解构造WBS 9
2.6 WBS1/2/3/4级筹划 9
2.6.1 WBS1级筹划 9
2.6.2 WBS2级筹划 9
2.6.3 WBS3级筹划 10
2.6.4 WBS4级筹划 10
2.7 Charter 10
2.8 PDT角色 10
2.8.1 LPDT 10
2.8.2 FPDT 10
2.8.3 RDPDT 10
2.8.4 CSPDT 10
2.8.5 MNFPDT 11
2.8.6 PROPDT 11
2.8.7 MKTPDT 11
2.8.8 PQA 11
2.8.9 POP 11
2.8.10 SE 11
2.8.11 EE 11
2.8.12 SWE 11
2.8.13 ME 12
2.8.14 IDE 12
2.8.15 TE 12
2.8.16 CSS 12
2.8.17 PP 12
2.8.18 AME 12
2.8.19 PRO 12
2.8.20 MAKE 12
2.8.21 S 12
2.8.22 LLMT 12
2.8.23 引导者 13
3.0 IPMT业务领域术语 13
3.1 决策评审点 13
3.2 概念决策评审CDCP 13
3.3 筹划决策评审PDCP 13
3.4 可获得性评审ADCP 13
3.5 生命周期终结决策评审EOL DCP 13
4.0 财务业务领域术语 13
4.1 产品成本 13
4.2 产品毛利率 13
4.3 项目开发费用 13
4.4 投资回收期 14
4.5 净现值 14
4.6 现值指数 14
4.7 内含报酬率 14
4.8 投资报酬率 14
5.0 开发业务领域术语 14
5.1 SE 14
5.1.1 产品包 14
5.1.2 产品包概念 14
5.1.3 产品包需求 14
5.1.4 易用性需求 14
5.1.5 RAS需求 14
5.1.6 设计需求 14
5.1.7 需求分解 15
5.1.8 需求分派 15
5.1.9 Build 15
5.1.10 产品包需求跟踪矩阵 15
5.1.11 产品数据构造 15
5.1.12 基线化 15
5.2 硬件业务领域术语 15
5.2.1 基本逻辑 15
5.2.2 大规模逻辑 15
5.2.3 硬件概要设计 15
5.2.4 硬件详细设计 15
5.2.5 EMC 15
5.2.6 可测试性设计 16
5.2.7 可制造性设计 16
5.2.8 可靠性设计 16
5.3 软件业务领域术语 16
5.3.1 顾客（User） 16
5.3.2 需求 16
5.3.3 软件需求 16
5.3.4 业务需求 16
5.3.5 顾客需求 17
5.3.6 功能需求 17
5.3.7 非功能需求 17
5.3.8 需求分析 17
5.3.9 软件需求规格阐明 17
5.3.10 统一建模语言UML 17
5.3.11 用例图(use case) 17
5.3.12 IPO图 17
5.3.13 实体关系图（E - R图） 17
5.3.14 数据流图 18
5.3.15 状态转换图 18
5.3.16 序列图 18
5.3.17 数据字典 （data dictionary） 19
5.3.18 软件缺陷（bug） 19
5.4 构造业务领域术语 19
5.4.1 构造件 19
5.4.2 定制构造件 19
5.4.3 原则件 20
5.4.4 外部电缆 20
5.4.5 线组件 20
5.4.6 UCD（以顾客为中心设计） 20
5.4.7 工业设计 20
5.4.8 手板 20
5.4.9 塑料模具（简称塑模） 20
5.4.10 冷冲裁、冲压模具（简称冷冲模） 20
5.5 TE 20
5.5.1 可测试性需求 20
5.5.2 可测试性 20
5.5.3 测试筹划 20
5.5.4 测试报告 20
5.5.5 SDV 21
5.5.6 SIT 21
5.5.7 SVT&SVT2 21
5.5.8 Beta测试 21
5.5.9 实验局 21
5.5.10 回归测试 21
5.5.11 测试用例 21
5.5.12 测试方案 21
5.5.13 测试工具 21
5.5.14 测试环境 21
5.5.15 入网测试 21
5.5.16 检查报告 21
5.5.17 入网证 21
6.0 制造业务领域术语 22
6.1 可制造性/制造可测试性 22
6.2 制造方略 22
6.3 制造筹划 22
6.4 制造工艺 22
6.5 制造系统 22
6.6 装备 22
6.7 生产测试设备 22
6.8 初始产品 22
6.9 试产产品 22
6.10 量产产品 22
7.0 采购业务领域术语 22
7.1 Sourcing team 22
7.2 初始供应商&物料供应筹划 22
7.3 提前物料采购 23
7.4 核心器件 23
7.5 定制器件 23
7.6 代替器件 23
7.7 其他器件 23
7.8 长货期 23
7.9 构造件新供应商（供方） 23
7.10 备用供应商（供方） 23
8.0 市场业务领域术语 23
8.1 RFA 23
8.2 ESP 23
8.3 销售配备器 23
8.4 客户迁移筹划 23
8.5 市场需求 24
9.0 客服业务领域术语 24
9.1 可安装性 24
9.2 可服务性 24
9.3 客户迁移 24
9.4 初验 24
10.0 质量业务领域术语 24
10.1 TR1/TR2/TR3/TR4/TR5/TR6 24
10.2 同行评审 24
10.3 质量筹划 24
10.4 不合格品 24
10.5 缺陷 24
10.6 故障 24
11.0 产品维护业务领域术语 24
11.1 设计变更 25
11.2 CCB 变更控制委员会 25
11.3 设计变更评审 25
11.4 ECN 工程变更告知 25
11.5 A类设计变更 25
11.6 B类设计变更 25
11.7 C类设计变更 25
11.8 D类设计变更 25
12.0 产品规划术语 26
12.1 市场 26
12.1.1 需求 26
12.1.2 市场 26
12.1.3 市场细分 26
12.1.4 细分市场Segmenting 26
12.1.5 客户customer 27
12.1.6 顾客user 27
12.1.7 渠道 27
12.1.8 市场调研 27
12.1.9 市场营销管理 28
12.2 产品 28
12.2.1 产品 28
12.2.2 新产品 29
12.2.3 产品生命周期 29
12.2.4 产品平台和产品平台战略 30
12.2.5 产品线和产品线战略 30
12.3 缩略语 30
12.3.1 MM 31
12.3.2 SWOT 31
12.3.3 $APPEALS 31
12.3.4 SPAN 31
12.3.5 FAN 32
12.3.6 ANSOFF 32

附件：修订记录（本文档任何变更应当在初次检视后在本附件进行跟踪）
版本
变更描述
修订人/日期
VX.XX

IPD术语手册
1.0 IPD体系
1.1　 集成产品开发IPD
Integrated Product Development,IPD是一种领先、成熟产品开发管理思想和管理模式。它是依照大量成功产品开发管理实践总结出来，并被大量实践证明高效产品开发模式。 通过IPD，可建立起基于市场和客户需求驱动集成产品开发流程，将产品开发作为一项投资来管理，更有效地管理产品开发和新产品，达到加快市场反映速度，缩短开发周期，减少报废项目，减少开发成本，提高产品稳定性、可生产性、可维护性目。IPD是一种全公司范畴项目，不应当被局限地理解为是一种研发系统内部项目，各部门不但仅需要参加，并且需要投身其中。IPD核心是要形成由来自于市场行销、研发系统、生产、顾客服务、财务、采购等方面人员构成贯穿整个产品业务流程管理模式，即从客户需求、概念形成、产品研究开发、产品发布等，始终到产品生命周期管理完整过程。通过IPD项目，事实上将对咱们公司整个价值创造核心过程进行重整，使产品开发更加关注市场竞争需要，建立起规范构造化开发过程，并且通过改进过程管理和采用适当IT工具与系统，如PDM等，逐渐建立完善文档与产品数据管理模式，使得整个开发过程更加高效。
1.2　 异步开发
异步开发模式是指将产品开发工作按技术领域纵向分层，如（软/硬件）技术层、子系统层、平台层、集成服务层，不同技术特长部门或团队并行地异步地开发和完毕不同技术层次工作，每一层都是技术特长相对集中，达到技术和资源共享化。
1.3　 公用基本模块CBB
就是通用构建模块。指那些可以在不同产品、系统之间共用零部件、模块、技术及其她有关设计成果。
1.4　 跨部门团队
她们对最后新产品开发共同承担责任，新产品成功或失败就是整个团队成功或失败。跨职能部门团队是指由来自不同职能部门人员，为了完毕共同目的集合在一起一种整体组织。
1.5　 构造化流程
为了管理好产品开发，产品开发必要成为构造合理、定义清晰流程，构造合理：自上而下层次架构中，上层构造简朴某些，越到下层越详细。定义清晰：每项工作都应清清晰楚地明确规定出来，所有与产品开发关于人应当清晰她们所参加是什么工作，用什么办法去完毕。
1.6　 项目管理
项目管理是指对项目进行筹划、监督、控制等。项目管理是使跨部门团队集合起来更好地行动核心。一方面要有一种目的即项目所要达到效果，一旦咱们将客户需求转换为对产品需求时，就可以制定详细筹划，该筹划中各某些将详细划分为每个职能部门工作，即这个筹划不单是研发部门筹划，还是公司各个部门共同筹划。一种产品从概念设计到上市期间会涉及到许多不同互相紧密联系活动，就好象不同职能部门彼此之间是关于系，同样在一种项目中她们彼此之间活动是关于系，所有活动加起来就是整个产品开发周期了。下一步就是安排活动时间，然后对每个活动进行预算和资源调配，打个军事上比喻来说，从目的到筹划阶段就相称于战前准备，接着就是去打仗。在打仗即实行时候还应不断地与筹划对照，由于没有任何一种筹划是完善，因此可以在细层面上对筹划进行一定调节，但是做出承诺不能变。
1.7　 管道管理
管道管理重要涉及在开发管道中项目动态分布（不同项目应处在不同阶段）和不同项目所需资源动态平衡2个方面，目是使项目通过喇叭口过滤后，迅速、平稳流过整个产品开发过程，缩短产品上市时间。
1.8　 客户需求分析
将客户需求进行筛选、分类，判断可实现行，对有关需求信息进行整顿、汇总与合并、对模糊、描述不清晰甚至有问题需求进行进一步确认，最后输出需求描述。
1.9　 投资组合分析
对公司外部环境和内部条件进行调查研究、分析公司面临发展机会和挑战前提下，明确公司当前和将来经营方向，提出但愿达到目的，在需要与也许基本上，研究制定可行经营方案。可行方案应当有各种不同组合，以便比较和进行全面评价，并从中选取一种满意方案。
2.0 PDT
2.1.1　 IPMT
Integrated Product Management Team，IPMT是集成产品组合管理团队，决定公司产品投资。
2.1.2　 PDT
Product Development Team，产品开发团队，执行产品开发项目。
2.2　 Charter
Charter，项目任务书，描述IPMT交给PDT任务。
2.3　 业务筹划
是PDT产品开发过程中核心文档之一，其中涉及产品市场定位、市场方略、开发筹划、生产制造方略以及财务分析等内容。在开发各个阶段需要不断进行修正、丰富。是CDCP、PDCP核心交付物。
2.4　 端到端项目筹划
就是从产品概念产生到发布上市整个过程筹划。
2.5　 工作分解构造WBS
工作分解构造（WBS）事实上就是将一种复杂开发系统分层逐渐细化为一种个工作任务单元。
2.6　 WBS1/2/3/4级筹划
2.6.1　 WBS1级筹划
是核心DCP点筹划，是IPMT控制项目根据。
2.6.2　 WBS2级筹划
是IPD袖珍卡中流程规定活动筹划，是LPDT控制项目根据。
2.6.3　 WBS3级筹划
是IPD流程活动细化，是PDT核心代表控制各自领域工作根据。
2.6.4　 WBS4级筹划
是IPD流程活动进一步细化，是指引PDT团队活动根据。
2.7　 PDT角色
2.7.1　 LPDT
PDT经理，PDT经理类似于一种新成立公司首席执行官，她将业务筹划提交给IPMT，并争取获得项目开发所需资金。PDT经理全面负责新产品成功开发。普通PDT经理在一种或各种功能领域有管理层和操作层经验，并有管理过开发项目经历。PDT经理可以来自财务、R&D、市场、制造、客户服务或采购等任何功能部门。PDT经理组织项目开发团队，对团队成果负责并代表整个团队在产品开发合同上签字。PDT经理富有项目管理经验很重要，抱负状况下，PDT经理应有项目经理任职资格证书。 PDT经理管理项目筹划进度、预算、人员配备、资源并向关于方面报告。她/她负责创立和维护项目综合文档，评估并管理项目风险，整合决策点材料和建议书并提交给IPMT以做出投资决策和评审。
2.7.2　 FPDT
PDT财务代表，财务人员负责研发产品专项核算，涉及到产品研发阶段，材料采购阶段，试产阶段，正式投产阶段及销售阶段实际投入及收益财务核算。并据相应财务数据分析研发产品实际获利及贡献状况。
2.7.3　 RDPDT
PDT开发代表，RDPDT 开发代表关注和管理产品包中所包括硬件、软件和构造详细开发工作。普通由于项目内容和复杂度不同，一种项目依照复杂限度也许会有一种或各种硬件、软件、构造人员作为RDPDT代表，她们和系统工程师一起共同代表开发部门对产品开发作出详细规划和承诺。
在项目初期，各RDPDT开发代表会和系统工程师一起工作，将各方面提出对产品需求转化为开发目的，其后对产品包内容进行详细定义和筹划，并最后开发出合格产品包，RDPDT负责开发某些内容。
在详细开发过程中，RDPDT代表负责创立和维护产品包信息筹划、安全筹划、质量筹划、生命周期结束筹划、升级筹划、硬件测试筹划、软件测试筹划、全球化支持（NLS－National Language Support）和翻译验证筹划。
RDPDT是项目组内软件、硬件、构造开发人员、测试人员、筹划人员、知识产权分析人员等所有成员代表和项目工作管理者，她们通过制定项目筹划来管理研发构成员活动。
2.7.4　 CSPDT
客户服务代表，PDT客户服务代表是涉及硬件或软件在内产品所需要所有支持服务接口人，代表所有服务部门做出承诺。客户服务PDT代表制定和执行筹划，保证依照时间进度表规定，完毕该产品包所需要支持服务。她/她负责产品服务，通过支持那些产品包在顾客环境中运作，协助顾客从这些硬件和软件中得到更多价值。普通地，这些服务涉及协助客户安装、客户化、调节/调试产品、备份和恢复硬件、软件、系统和网络。PDT客户服务代表可以是客户服务组织里专家，或是市场部、开发部以及业务伙伴组织里，依照PDT需要和上市途径对服务需求而定。PDT客户服务代表为客户提供产品安装使用和问题解决方面客户服务，和PDT开发代表紧密合伙以完毕产品维护工作。
2.7.5　 MNFPDT
制造代表，PDT制造代表关注所要提供产品包需要硬件和软件生产工艺，代表生产部门做出承诺。PDT制造代表为有效和高效地生产产品和开发工艺，这涉及给设计提供输入来改进产品可制造性、制造工艺设计和开发、对工人进行培训，以保证所需数量能被生产出来并如期交付，满足预期规定。这也涉及硬件重用、再使用和回收。该PDT代表负责制定和维护制造方略和筹划。制造PDT代表也代表需求和供应筹划、高档制造工程、硬件制造操作、测试装备工程、发布管理、资产管理、硬件重用、再运用和收回、软件制造。
2.7.6　 PROPDT
采购代表，PDT采购代表关注产品包交付所需所有采购流程，代表采购功能部门做出承诺。她/她制定筹划，当需要（时间和地点）时提供所有硬件、软件，和/或服务部件/资源，这涉及认证、洽谈和监控所有供应商。采购PDT代表代表生产采购、非生产采购、供应商管理、业务伙伴等。
2.7.7　 MKTPDT
市场代表，PDT市场代表代表营销部门做出承诺，PDT市场代表进行市场竞争状况分析、市场需求定义。
2.7.8　 PQA
PQA是PDT核心构成员之一，保证产品开发按照公司既定IPD流程进行，全流程统筹协调各功能领域质量保证活动。
2.7.9　 POP
项目操作员，项目操作员(POP)协助建立项目基本设施和设备，按照PDT核心组、经理和/或IPMT批示，负责项目寻常运作。
2.7.10　 SE
系统工程师，系统工程师面对预测需求和产品整个生命周期中挑战，及指引产品开发满足这些需求和挑战方面扮演重要角色。系统工程师与PDT 开发代表和其她代表一起将市场需求翻译成产品包需求，更进一步以技术规格表达出来。她/她监视/检查整个产品开发过程以保证开发过程始终满足预先规定产品需求和规格。系统工程师开发产品总体架构，并推动产品集成和测试方略和筹划实行。 系统工程师要保证产品数据精确性、可制造性、可维护性和及时齐套性。
2.7.11　 EE
Electronics Engineer，电子工程师，即硬件工程师。硬件工程师负责电子硬件技术开发。硬件工程师是若干专业类型工程师之一（涉及硬件、软件、机械、工业设计），向系统工程师和 PDT开发代表报告。
2.7.12　 SWE
软件工程师 ，软件工程师负责任何与新产品有关软件技术开发。 软件工程师是若干专业类型工程师之一（涉及硬件、软件、机械、工业设计），向系统工程师和PDT核心组开发代表报告。
2.7.13　 ME
构造工程师 ，构造工程师负责构造件技术开发。 构造工程师是若干专业类型工程师之一（涉及电气、软件、机械、工业设计），向系统工程师和PDT核心组开发代表报告。
2.7.14　 IDE
工业设计师 ，工业设计师 负责把美学及人性因素设计事项考虑到产品功能需求及规格中，这涉及保持品牌形象产品外观。工业设计师依照下列准则评审项目： 产品外观及美学方面和产品人机工程方面
2.7.15　 TE
测试工程师 ，测试工程师负责新产品测试技术、测试系统开发并检查其与否满足行业原则、国标或国际原则，同步负责产品国际、国内型号认证工作。测试工程师是几类专业工程师之一（涉及：硬件、软件、机械和工业设计），向系统工程师和PDT开发代表报告。
2.7.16　 CSS
客户服务专人 ，客户服务专人向PDT客户服务代表报告，负责协助客户解决她们也许遇到任何问题。她经常是客户和公司工程部之间联系纽带。
2.7.17　 PP
试制工程师，制造-试制工程师是几类向PDT制造代表报告另一类制造人员，专门关注用生产线试生产，该生产线就是用来生产新产品生产线，以便评估生产线。
2.7.18　 AME
高档制造工程师，制造--高档制造工程师是几位向PDT制造代表报告另一类制造人员，关注于评估一种新产品如何被放到生产线上、如何批量生产。 她需要评估当前及新技术、工艺， 并测试和开发制造新产品最佳办法。 制造--高档制造工程师同步也负责产品版本切换控制过程；负责与制造工程师加工接口；参加清单管理、发货管理、库存管理等。
2.7.19　 PRO
采购人员，采购员向PDT采购代表报告，关注于和供应商谈判以保证新产品开发、制造和测试所需要部件能持续供应。
2.7.20　 MAKE
营销工程师，市场行销筹划人员是负责新产品上市有关阐明书、培训资料编写并对分公司销售人员进行培训专人。（手机营销部人员）市场操作人员是配合其她部门进行新品上市推广工作并进行新品详细市场销售活动直至产品生命周期结束专人。（销售部手机销售中心人员）
2.7.21　 S
销售专人 ，销售专人是制定并执行产品销售方略,并保持和顾客(代理商)紧密联系,增进公司销售目的实现工作人员。
2.7.22　 LLMT
LMT经理，LMT经理是各LMT团队管理者，当项目通过技术评审3准备进入PP1阶段时，LMT经理必要为该项目专门组织一种LMT团队，LMT团队普通由产品部、制造部、质管部、售后等部门工程师构成，LMT团队在后续各个阶段试产、首批量产中与项目构成员共同工作，在产品进入稳定生产后LMT团队全面接手产品维护工作，这种维护工作将持续到产品最后退出市场才停止。
LMT经理对各个LMT团队工作进行管理，在产品即将停产退出市场时，需要启动产品生命终结程序，提出产品生命终结祈求，并准备材料与IPMT充分沟通，在产品生命终结流程中要跟踪详细贯彻和组织对项目经验进行总结。
2.7.23　 引导者（PQA兼任）
引导者是中立于IPMT、PDT之间一种独特角色，她更关注流程、目的和问题。通过与团队一起工作，指引团队走产品开发流程，最后使她们获得有效独立运作技能。
3.0 IPMT业务领域术语
3.1　 决策评审点
在产品开发过程中，分阶段对交付物进行评审，在每一次投入更多资源迈进行，重要关注产品市场体现层面，以决定与否继续对项目进行投资评审
3.2　 概念决策评审CDCP
在概念阶段结束时要召开一种概念决策评审会，在这个会议上，PDT正式向IPMT报告初始业务筹划，由IPMT来决定项目是继续还是终结。若初始业务筹划得到批准，分委会将做出下一阶段开始前所需承诺，项目进入筹划阶段。
3.3　 筹划决策评审PDCP
在筹划阶段结束时要召开一种筹划决策评审会。在这个会议上，PDT向IPMT展示最后业务筹划以及决策合同，由IPMT来做出继续/终结决策。最后业务筹划以初始业务筹划为基本，提供了更多细节内容及对筹划承诺。若业务筹划获得批准，则PDT与IPMT订立合同，合同中列出容许偏差。项目进入开发阶段。合同代表了IPMT做出坚实承诺，即每个重要部门都将支持项目以及给PDT必要资源。 另一方面，PDT将承诺按合同规定完毕项目交付目的。
3.4　 可获得性评审ADCP
这是产品正式公开发布及推向市场前最后决策评审，需要IPMT明确做出继续/终结决策。可获得性决策评审应在任何重要发布耗费投入之迈进行。 这一决策评审目是证明在筹划阶段制定业务筹划中预计和假设，并评估产品发布前公司准备状况。
3.5　 生命周期终结决策评审EOL DCP
在产品生命周期结束时，生命周期管理团队（LMT）要向IPMT给出停止销售、停止生产、停止服务等方面日期建议，由IPMT做出继续/终结决策。IPMT必要要审核产品生命终结发布与否与新产品战略保持一致以及与否已较好地考虑了潜在客户满意度方面问题。
4.0 财务业务领域术语
4.1　 产品成本
产品成本涉及：直接材料、直接人工费、其她直接费用、间接制造费用。
4.2　 产品毛利率
产品销售收入减去产品销售成本后与产品销售收入比率。 
4.3　 项目开发费用
项目投资总额是指用于项目内产品开发所有费用，涉及人力成本、材料、加工、测试、实验局、差旅、以及管理分摊。
4.4　 投资回收期
投资回收期是评价投资项目经济价值一种比较简朴和惯用原则。投资回收期是，从一种项目收入钞票流入偿清初期投资钞票流出所需时间。
投资回收期自身作为一种独立选取原则并不十分可靠，它没有考虑货币时间价值。
4.5　 净现值
净现值（Net Present Value，NPV）等于投资项目将来净钞票流量按照资本成本折算成现值，减去初始投资后余额。净现值法是运用投资项目净现值进行投资评估基本办法。
应当选取净现值>0项目。
4.6　 现值指数
现值指数（Profitability Index，PI）是用项目将来现值与初始投资额之比来衡量项目经济效益一种办法，又称获利能力指数，是钞票流量折现分析法又一表达形式。
应当选取现值指数>1项目
4.7　 内含报酬率，内部收益率
内含报酬率（Internal Return Rate，IRR），也被称为内部收益率，是使项目净现值等于零贴现率。这个贴现率反映了一种投资项目内部收益率。
当计算出来内部报酬率不不大于公司资本成本或所规定最低投资报酬率时，表达该投资项目可行；反之不可行。
4.8　 投资报酬率
项目投资业绩评价指标之一。投资报酬率指标有二种：投资利润率和投资利税率。
投资利润率是项目年平均利润总额除以项目投资总额；
投资利税率是项目年平均利税总额除以项目投资总额。
5.0 开发业务领域术语
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　 序列图
在整个设计过程中都会用到序列图，用于演示系统执行时参加者与对象之间内部交互。序列图用于建立如下内容模型：
l 用例方案
l 框架中合同
l 子系统
l 类
l 办法逻辑

5.3.17　 数据字典 （data dictionary）
l 一种软件系统中使用所有数据项名称，以及这些项有关属性集合。
l 数据流、数据元素、文献、数据基本、和有关解决一种集合。

5.3.18　 软件缺陷（bug）
软件缺陷这一概念用来描述各种软件错误，是所有软件错误统称。   
把符合下列5种特性