IPD术语手册大全.docx

上传人:b****8 文档编号:9448292 上传时间:2023-05-19 格式:DOCX 页数:38 大小:120.61KB
下载 相关 举报
IPD术语手册大全.docx_第1页
第1页 / 共38页
IPD术语手册大全.docx_第2页
第2页 / 共38页
IPD术语手册大全.docx_第3页
第3页 / 共38页
IPD术语手册大全.docx_第4页
第4页 / 共38页
IPD术语手册大全.docx_第5页
第5页 / 共38页
IPD术语手册大全.docx_第6页
第6页 / 共38页
IPD术语手册大全.docx_第7页
第7页 / 共38页
IPD术语手册大全.docx_第8页
第8页 / 共38页
IPD术语手册大全.docx_第9页
第9页 / 共38页
IPD术语手册大全.docx_第10页
第10页 / 共38页
IPD术语手册大全.docx_第11页
第11页 / 共38页
IPD术语手册大全.docx_第12页
第12页 / 共38页
IPD术语手册大全.docx_第13页
第13页 / 共38页
IPD术语手册大全.docx_第14页
第14页 / 共38页
IPD术语手册大全.docx_第15页
第15页 / 共38页
IPD术语手册大全.docx_第16页
第16页 / 共38页
IPD术语手册大全.docx_第17页
第17页 / 共38页
IPD术语手册大全.docx_第18页
第18页 / 共38页
IPD术语手册大全.docx_第19页
第19页 / 共38页
IPD术语手册大全.docx_第20页
第20页 / 共38页
亲,该文档总共38页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

IPD术语手册大全.docx

《IPD术语手册大全.docx》由会员分享,可在线阅读,更多相关《IPD术语手册大全.docx(38页珍藏版)》请在冰点文库上搜索。

IPD术语手册大全.docx

IPD术语手册大全

 

保密等级:

绝密机密控制公开

 

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实施

发布

 

附件:

修订记录(本文档的任何变更应该在首次检视后在本附件进行跟踪)

版本

变更描述

修订人/日期

VX.XX

IPD术语手册

1.0IPD体系

集成产品开发IPD

IntegratedProductDevelopment,IPD是一种领先的、成熟的产品开发的管理思想和管理模式。

它是根据大量成功的产品开发管理实践总结出来的,并被大量实践证明的高效的产品开发模式。

通过IPD,可建立起基于市场和客户需求驱动的集成产品开发流程,将产品开发作为一项投资来管理,更有效地管理产品开发和新产品,达到加快市场反应速度,缩短开发周期,减少报废项目,减少开发成本,提高产品的稳定性、可生产性、可维护性的目的。

IPD是一个全公司范围的项目,不应该被局限地理解为是一个研发系统内部的项目,各部门不仅仅需要参与,而且需要投身其中。

IPD的核心是要形成由来自于市场行销、研发系统、生产、用户服务、财务、采购等方面人员组成的贯穿整个产品业务流程的管理模式,即从客户需求、概念形成、产品研究开发、产品发布等,一直到产品生命周期管理的完整过程。

通过IPD项目,事实上将对我们公司整个的价值创造核心过程进行重整,使产品开发更加关注市场竞争的需要,建立起规范的结构化开发过程,并且通过改善过程管理和采用合适的IT工具与系统,如PDM等,逐步建立完善的文档与产品数据管理模式,使得整个开发过程更加高效。

异步开发

异步开发模式是指将产品开发工作按技术领域纵向分层,如(软/硬件)技术层、子系统层、平台层、集成服务层,不同的技术专长的部门或团队并行地异步地开发和完成不同技术层次的工作,每一层都是技术专长相对集中的,达到技术和资源的共享化。

公用基础模块CBB

就是通用构建模块。

指那些可以在不同产品、系统之间共用的零部件、模块、技术及其他相关的设计成果。

跨部门团队

他们对最终的新产品开发共同承担责任,新产品的成功或失败就是整个团队的成功或失败。

跨职能部门团队是指由来自不同职能部门的人员,为了完成共同的目标集合在一起的一个整体组织。

结构化流程

为了管理好产品开发,产品开发必须成为结构合理、定义清楚的流程,结构合理:

自上而下的层次架构中,上层结构简单一些,越到下层越具体。

定义清楚:

每项工作都应清清楚楚地明确规定出来,所有与产品开发有关的人应该清楚他们所参与的是什么工作,用什么方法去完成。

项目管理

项目管理是指对项目进行计划、监督、控制等。

项目管理是使跨部门团队集合起来更好地行动的关键。

首先要有一个目标即项目所要达到的效果,一旦我们将客户的需求转换为对产品的需求时,就可以制定详细计划,该计划中的各部分将具体划分为每个职能部门的工作,即这个计划不单是研发部门的计划,还是公司各个部门共同的计划。

一个产品从概念设计到上市期间会涉及到许多不同的相互紧密联系的活动,就好象不同职能部门彼此之间是有关系的,同样在一个项目中他们彼此之间的活动是有关系的,所有的活动加起来就是整个产品开发的周期了。

下一步就是安排活动的时间,然后对每个活动进行预算和资源的调配,打个军事上的比喻来说,从目标到计划阶段就相当于战前的准备,接着就是去打仗。

在打仗即实施的时候还应不断地与计划对照,因为没有任何一个计划是完善的,所以可以在细的层面上对计划进行一定的调整,但是做出的承诺不能变。

管道管理

管道管理主要包括在开发管道中项目的动态分布(不同项目应处于不同阶段)和不同项目所需资源的动态平衡的2个方面,目的是使项目经过喇叭口的过滤后,快速、平稳的流过整个产品开发过程,缩短产品上市时间。

客户需求分析

将客户需求进行筛选、分类,判断可实现行,对相关需求信息进行整理、汇总与合并、对模糊的、描述不清楚甚至有问题的需求进行进一步的确认,最后输出需求描述。

投资组合分析

对企业外部环境和内部条件进行调查研究、分析企业面临的发展机会和挑战的前提下,明确企业当前和未来的经营方向,提出希望达到的目标,在需要与可能的基础上,研究制订可行的经营方案。

可行方案应该有多个不同的组合,以便比较和进行全面评价,并从中选择一个满意方案。

2.0PDT

IPMT

IntegratedProductManagementTeam,IPMT是集成产品组合管理团队,决定公司的产品投资。

PDT

ProductDevelopmentTeam,产品开发团队,执行产品开发项目。

Charter

Charter,项目任务书,描述IPMT交给PDT任务。

业务计划

是PDT产品开发过程中的关键文档之一,其中包括产品的市场定位、市场策略、开发计划、生产制造策略以及财务分析等内容。

在开发的各个阶段需要不断进行修正、丰富。

是CDCP、PDCP的关键交付物。

端到端的项目计划

就是从产品概念的产生到发布上市的整个过程的计划。

工作分解结构WBS

工作分解结构(WBS)实际上就是将一个复杂的开发系统分层逐步细化为一个个工作任务单元。

WBS1/2/3/4级计划

WBS1级计划

是关键的DCP点的计划,是IPMT控制项目的依据。

WBS2级计划

是IPD袖珍卡中流程要求的活动的计划,是LPDT控制项目的依据。

WBS3级计划

是IPD流程活动的细化,是PDT核心代表控制各自领域工作的依据。

WBS4级计划

是IPD流程活动的进一步细化,是指导PDT团队活动的依据。

PDT角色

LPDT

PDT经理,PDT经理类似于一个新成立公司的首席执行官,他将业务计划提交给IPMT,并争取获得项目开发所需的资金。

PDT经理全面负责新产品的成功开发。

通常PDT经理在一个或多个功能领域有管理层和操作层经验,并有管理过开发项目的经历。

PDT经理可以来自财务、R&D、市场、制造、客户服务或采购等任何功能部门。

PDT经理组织项目开发团队,对团队的结果负责并代表整个团队在产品开发合同上签字。

PDT经理富有项目管理经验很重要,理想情况下,PDT经理应有项目经理的任职资格证书。

PDT经理管理项目计划进度、预算、人员配置、资源并向有关方面汇报。

他/她负责创建和维护项目综合文档,评估并管理项目风险,整合决策点材料和建议书并提交给IPMT以做出投资决策和评审。

FPDT

PDT财务代表,财务人员负责研发产品的专项核算,涉及到产品的研发阶段,材料采购阶段,试产阶段,正式投产阶段及销售阶段的实际投入及收益的财务核算。

并据相应的财务数据分析研发产品的实际获利及贡献情况。

RDPDT

PDT开发代表,RDPDT开发代表关注和管理产品包中所包含的硬件、软件和结构的具体开发工作。

通常由于项目的内容和复杂度不同,一个项目根据复杂程度可能会有一个或多个硬件、软件、结构人员作为RDPDT代表,他们和系统工程师一起共同代表开发部门对产品的开发作出具体的规划和承诺。

在项目初期,各RDPDT开发代表会和系统工程师一起工作,将各方面提出的对产品需求转化为开发目标,其后对产品包内容进行详细的定义和计划,并最终开发出合格的产品包,RDPDT负责开发部分的内容。

在具体的开发过程中,RDPDT代表负责创建和维护产品包的信息计划、安全计划、质量计划、生命周期结束计划、升级计划、硬件测试计划、软件测试计划、全球化支持(NLS-NationalLanguageSupport)和翻译验证计划。

RDPDT是项目组内的软件、硬件、结构开发人员、测试人员、计划人员、知识产权分析人员等所有成员的代表和项目工作管理者,他们通过制定项目计划来管理研发组成员的活动。

CSPDT

客户服务代表,PDT客户服务代表是包括硬件或软件在内的产品所需要的所有支持服务的接口人,代表所有服务部门做出承诺。

客户服务PDT代表制定和执行计划,确保根据时间进度表的要求,完成该产品包所需要的支持服务。

他/她负责产品服务,通过支持那些产品包在用户环境中的运作,帮助用户从这些硬件和软件中得到更多的价值。

一般地,这些服务包括帮助客户安装、客户化、调整/调试产品、备份和恢复硬件、软件、系统和网络。

PDT客户服务代表可以是客户服务组织里的专家,或是市场部的、开发部的以及业务伙伴组织里的,根据PDT需要和上市途径对服务的需求而定。

PDT客户服务代表为客户提供产品安装使用和问题处理方面的客户服务,和PDT开发代表紧密合作以完成产品维护工作。

MNFPDT

制造代表,PDT制造代表关注所要提供的产品包需要的硬件和软件生产工艺,代表生产部门做出承诺。

PDT制造代表为有效和高效地生产产品和开发工艺,这包括给设计提供输入来改进产品的可制造性、制造工艺设计和开发、对工人进行培训,以确保所需的数量能被生产出来并如期交付,满足预期的要求。

这也包括硬件的重用、再使用和回收。

该PDT代表负责制定和维护制造策略和计划。

制造PDT代表也代表需求和供应计划、高级制造工程、硬件制造操作、测试装备工程、发布管理、资产管理、硬件重用、再利用和收回、软件制造。

PROPDT

采购代表,PDT采购代表关注产品包交付所需的所有采购流程,代表采购功能部门做出承诺。

他/她制定计划,当需要(时间和地点)时提供所有硬件、软件,和/或服务部件/资源,这包括认证、洽谈和监控所有的供应商。

采购PDT代表代表生产采购、非生产采购、供应商管理、业务伙伴等。

MKTPDT

市场代表,PDT市场代表代表营销部门做出承诺,PDT市场代表进行市场竞争状况分析、市场需求定义。

PQA

PQA是PDT核心组的成员之一,确保产品开发按照公司既定的IPD流程进行,全流程统筹协调各功能领域的质量保证活动。

POP

项目操作员,项目操作员(POP)协助建立项目的基础设施和设备,按照PDT核心组、经理和/或IPMT的指示,负责项目的日常运作。

SE

系统工程师,系统工程师面对预测需求和产品整个生命周期中的挑战,及指导产品开发满足这些需求和挑战方面扮演重要的角色。

系统工程师与PDT开发代表和其他代表一起将市场需求翻译成产品包需求,更进一步以技术规格表示出来。

他/她监视/检查整个产品的开发过程以确保开发过程一直满足预先规定的产品需求和规格。

系统工程师开发产品的总体架构,并推动产品集成和测试策略和计划的实施。

系统工程师要保证产品数据的准确性、可制造性、可维护性和及时齐套性。

EE

ElectronicsEngineer,电子工程师,即硬件工程师。

硬件工程师负责电子硬件的技术开发。

硬件工程师是若干专业类型的工程师之一(包括硬件、软件、机械、工业设计),向系统工程师和PDT开发代表报告。

SWE

软件工程师,软件工程师负责任何与新产品相关的软件技术开发。

软件工程师是若干专业类型的工程师之一(包括硬件、软件、机械、工业设计),向系统工程师和PDT核心组开发代表报告。

ME

结构工程师,结构工程师负责结构件的技术开发。

结构工程师是若干专业类型的工程师之一(包括电气、软件、机械、工业设计),向系统工程师和PDT核心组开发代表报告。

IDE

工业设计师,工业设计师负责把美学及人性因素的设计事项考虑到产品的功能需求及规格中,这包括保持品牌形象的产品外观。

工业设计师依照下列准则评审项目:

产品外观及美学方面和产品人机工程方面

TE

测试工程师,测试工程师负责新产品的测试技术、测试系统开发并检验其是否满足行业标准、国家标准或国际标准,同时负责产品的国际、国内型号认证工作。

测试工程师是几类专业工程师之一(包括:

硬件、软件、机械和工业设计),向系统工程师和PDT开发代表报告。

CSS

客户服务专员,客户服务专员向PDT客户服务代表汇报,负责帮助客户解决他们可能遇到的任何问题。

他经常是客户和公司的工程部之间的联系纽带。

PP

试制工程师,制造-试制工程师是几类向PDT制造代表汇报的另一类制造人员,专门关注用生产线试生产,该生产线就是用来生产新产品的生产线,以便评估生产线。

AME

高级制造工程师,制造--高级制造工程师是几位向PDT制造代表汇报的另一类制造人员,关注于评估一个新产品如何被放到生产线上、如何批量生产。

他需要评估当前及新的技术、工艺,并测试和开发制造新产品的最佳方法。

制造--高级制造工程师同时也负责产品版本切换的控制过程;负责与制造工程师加工接口;参与清单管理、发货管理、库存管理等。

PRO

采购人员,采购员向PDT采购代表汇报,关注于和供应商谈判以确保新产品开发、制造和测试所需要的部件能持续供应。

MAKE

营销工程师,市场行销计划人员是负责新产品上市的相关说明书、培训资料的编写并对分公司销售人员进行培训的专员。

(手机营销部人员)市场操作人员是配合其他部门进行新品上市推广工作并进行新品的具体市场销售活动直至产品生命周期结束的专员。

(销售部手机销售中心人员)

S

销售专员,销售专员是制定并执行产品销售策略,并保持和顾客(代理商)紧密联系,促进公司销售目标实现的工作人员。

LLMT

LMT经理,LMT经理是各LMT团队的管理者,当项目通过技术评审3准备进入PP1阶段时,LMT经理必须为该项目专门组织一个LMT团队,LMT团队通常由产品部、制造部、质管部、售后等部门的工程师组成,LMT团队在后续的各个阶段的试产、首批量产中与项目组的成员共同工作,在产品进入稳定生产后LMT团队全面接手产品的维护工作,这种维护工作将持续到产品最终退出市场才停止。

LMT经理对各个LMT团队的工作进行管理,在产品即将停产退出市场时,需要启动产品的生命终止程序,提出产品生命终止请求,并准备材料与IPMT充分沟通,在产品生命终止流程中要跟踪具体的落实和组织对项目的经验进行总结。

引导者(PQA兼任)

引导者是中立于IPMT、PDT之间的一个独特角色,他更关注流程、目标和问题。

通过与团队一起工作,指导团队走产品开发流程,最终使他们获得有效的独立运作的技能。

3.0IPMT业务领域术语

决策评审点

在产品开发过程中,分阶段对交付物进行评审,在每一次投入更多资源前进行,主要关注产品的市场表现层面,以决定是否继续对项目进行投资的评审

概念决策评审CDCP

在概念阶段结束时要召开一个概念决策评审会,在这个会议上,PDT正式向IPMT报告初始的业务计划,由IPMT来决定项目是继续还是终止。

若初始的业务计划得到批准,分委会将做出下一阶段开始前所需的承诺,项目进入计划阶段。

计划决策评审PDCP

在计划阶段结束时要召开一个计划决策评审会。

在这个会议上,PDT向IPMT展示最终的业务计划以及决策合同,由IPMT来做出继续/终止的决策。

最终的业务计划以初始的业务计划为基础,提供了更多的细节内容及对计划的承诺。

若业务计划获得批准,则PDT与IPMT签订合同,合同中列出允许的偏差。

项目进入开发阶段。

合同代表了IPMT做出的坚实承诺,即每个主要部门都将支持项目以及给PDT必要的资源。

另一方面,PDT将承诺按合同要求完成项目的交付目标。

可获得性评审ADCP

这是产品正式公开发布及推向市场前的最终决策评审,需要IPMT明确做出继续/终止的决策。

可获得性决策评审应在任何主要的发布花费投入之前进行。

这一决策评审的目的是证实在计划阶段制定的业务计划中的估计和假设,并评估产品发布前公司的准备情况。

生命周期终止决策评审EOLDCP

在产品生命周期结束时,生命周期管理团队(LMT)要向IPMT给出停止销售、停止生产、停止服务等方面日期的建议,由IPMT做出继续/终止的决策。

IPMT必须要审核产品生命终止的发布是否与新产品战略保持一致以及是否已很好地考虑了潜在的客户满意度方面的问题。

4.0财务业务领域术语

产品成本

产品成本包括:

直接材料、直接人工费、其他直接费用、间接制造费用。

产品毛利率

产品销售收入减去产品销售成本后与产品销售收入的比率。

 

项目开发费用

项目投资总额是指用于项目内产品开发的所有费用,包括人力成本、材料、加工、测试、实验局、差旅、以及管理分摊。

投资回收期

投资回收期是评价投资项目经济价值的一种比较简单和常用的标准。

投资回收期是,从一个项目收入的现金流入偿清初期投资的现金流出所需的时间。

投资回收期本身作为一种独立的选择标准并不十分可靠,它没有考虑货币的时间价值。

净现值

净现值(NetPresentValue,NPV)等于投资项目未来净现金流量按照资本成本折算成现值,减去初始投资后的余额。

净现值法是运用投资项目的净现值进行投资评估的基本方法。

应该选择净现值>0的项目。

现值指数

现值指数(ProfitabilityIndex,PI)是用项目未来现值与初始投资额之比来衡量项目经济效益的一种方法,又称获利能力指数,是现金流量折现分析法的又一表达形式。

应该选择现值指数>1的项目

内含报酬率,内部收益率

内含报酬率(InternalReturnRate,IRR),也被称为内部收益率,是使项目的净现值等于零的贴现率。

这个贴现率反映了一个投资项目的内部收益率。

当计算出来的内部报酬率大于公司的资本成本或所要求的最低投资报酬率时,表示该投资项目可行;反之不可行。

投资报酬率

项目的投资业绩评价指标之一。

投资报酬率指标有二种:

投资利润率和投资利税率。

投资利润率是项目的年平均利润总额除以项目投资总额;

投资利税率是项目的年平均利税总额除以项目投资总额。

5.0开发业务领域术语

SE

产品包

产品提供给用户时的全方位呈现,包括产品的外观、功能、性能、价格等

产品包概念

对一个产品包的高层次描述

产品包需求

产品包为满足的各方面要求所需要具有的特性

易用性需求

产品为使用户易于使用所需要具有的特性

RAS需求

产品为满足可靠性、可用性和可服务性要求所应具有的特性

设计需求

对产品包需求进行分解和整理,用以指导系统设计的需求描述

需求分解

将设计需求按照功能、层次逐步细化的过程。

由SE与硬件工作师、软件工程师及结构工程师一起协作,分析产品包需求,将需求分解成硬件、软件或结构子系统;然后每一块(硬件、软件、结构)进一步将需求分配到更下一层子系统、部件或模块之中;需求分解要确定某些特殊需求如何由硬件、软件或结构或任何组合形式实现。

需求分配

将分解后的设计需求指配到具体设计模块,定义每个设计模块规格的过程。

需求分配需要清晰地决定需求的哪些部门由硬件实现,哪些部分由软件实现,哪些部分由结构实现,它们之间的接口也要定义清楚。

Build

内部版本,满足特定的功能需求,由产品包的部分或全部设计模块构成,其中某些版本可以对外发布。

所有Build必须进行SDV测试,对外发布的Build必须进行SIT测试。

产品包需求跟踪矩阵

使用跟踪矩阵将每条产品包需求对应到多个相关的模块,并根据每个模块的验证结果检验每条需求是否得到满足

产品数据结构

产品数据结构以文档树的形式汇总一个产品包所对应的所有数据,包括设计文档、代码、图纸、Bom清单等。

基线化

产品在其开发周期的不同时间点上通过正式评审而进入正式受控的一种状态,而这个过程被称为“基线化”。

每一个基线都是其下一步开发的出发点和参考点。

15.1 硬件业务领域术语

基本逻辑

主要用于实现电路信号连接和切换控制的逻辑,规模较小,基本上不包括业务数据处理功能

大规模逻辑

包含较复杂的业务数据处理功能的逻辑

硬件概要设计

在计划阶段,基于概要的BOM结构树及系统的设计规格书,所开发的到板级的硬件设计。

它用于指导硬件详细设计

硬件详细设计

基于硬件概要设计,使用标准的设计工具来进行详细设计,描绘出明确的板、卡、元器件要完成的功能和界面,对每一个板/卡/元器件,开发电路设计、原理图、零部件清单、网表等

EMC

EMC是电磁兼容性(ElectromagneticCompatibility),是指电子设备或网络系统具有一定的抵抗电磁干扰的能力,同时不能产生过量的电磁辐射。

也就是说,要求该设备或网络系统能够在比较恶劣的电磁环境中正常工作,同时又不能辐射过量的电磁波干扰周围其它设备及网络的正常工作。

可测试性设计

产品能及时准确地确定其状态(可工作、不可工作、性能下降等),隔离其内部故障的设计特性称为可测试性。

以提高可测试性为目的的设计称为可测试性设计,简称DFT(DesignForTestability)。

DFT可有效地降低测试的复杂性,缩短产品的开发时间,减少制造成本和维护成本。

在设计初期就要将可测性考虑进去。

可制造性设计

可制造性设计(DFM,DesignforManufacturability)是并行工程中最重要的内容之一,其主要目标是:

提高新产品开发全过程(包括设计、工艺、制造等)中的质量,降低新产品全生命周期中的成本(包括产品设计、工艺、制造、发送、支持、客户使用乃至产品报废等成本),缩短产品研制开发周期(包括减少设计反复,降低设计、生产准备、制造及投放市场的时间)。

可靠性设计

可靠性是产品在规定的条件下和规定的时间内,完成规定功能的能力,包括产品的故障(失效)、完好(正常)及可靠、不可靠等状态的随机性。

可靠性设计是运用有机方法对这些随机性予以精确的描述,从而对产品进行概率设计。

15.2 软件业务领域术语

用户(User)

直接使用产品的人或组织。

这是狭义的理解,等同于EndUser。

在实践中,“用户”这个词的含义已被扩大,包括客户(Customer,负责接收产品、授权付费的个人或组织)、最终用户(EndUser,真正操作产品的人或组织)、其他人员(售前、售后人员、开发关联产品的人员或组织等)。

在本模板中,如果没有特别强调,用户都是指广义的用户。

用户可以存在于项目开发团队所在的组织外,也可存在于该组织之内,但一般应在项目开发团队之外。

需求

是指“被描述系统(SuD,SystemUnderDescription)”“做什么”(功能需求)及“做什么”时的水平(非功能需求,如性能需求、质量属性需求、外部接口需求、其它需求)。

这个通俗定义是针对技术需求的,而非技术需求(如进度的限制)一般不在本文档中给出(一般放在研制任务书/项目计划中)。

软件需求

软件需求(SoftwareRequirement):

在对用户需求(纯软件项目)或系统方案中的分配需求(软硬件结合项目)进行进一步论证、分析的基础上得到的关于软件的需求,包括功能需求、性能需求、外部接口需求、质量属性需求、其它需求

业务需求

业务需求(businessrequirement),又称原始需求(rawrequirement)用户提出的、未经过分析的需求。

业务/原始需求的描述可能是不清晰、相互之间可能是矛盾的,需要经过进一步的论证、分析,以得到用户需求。

很多情况下,业务/原始需求甚至包括了需求背景、解决方案的描述。

用户需求

用户提出的、经过论证、分析的需求。

一般情况下,对原始需求进行分析,可得到用户需求。

功能需求

功能需求(functionalrequirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。

非功能需求

非功能需求(non-functionalrequirement)是从各个角度对系统的约束和限制,反映了应用对软件系统质量和特性的额外要求。

需求分析

为“能够高质量地描述需求”而进行的活动。

所谓“高质量地描述”是指:

单条需求具备7大特性(完整性、正确性、必要性、可行性、划分优先级、无二义性、可验证性)、需求说明书具备4大

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 解决方案 > 学习计划

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2