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　 状态转换图
实时系统和过程控制应用程序可以在任何给定的时间内以有限