变更及案例(精选6篇)
变更及案例 篇1
堵截假证件办理账户年检及法人变更案例
XX科技有限公司财务至柜台办理账户年检手续,提供的资料中组织机构代码证为复印件,柜台人员要求出示原件,财务要求先为其办理账户年检手续,过两天再将原件送至柜台。柜台人员拒绝其要求并解释必须先核原件方可受理。
二天后,财务提交代码证原件,柜台人员接过代码证时发现该代码证颜色偏黄,字体异常,无防伪线。柜台人员立即将疑点向营业经理汇报并再次审核,确认代码证从字体、颜色、编号等方面均存在疑点,用验印系统对代码证上“国家质量监督检验检疫总局”印章进行核印时,发现轮廓及印模基本吻合,但天安门城楼上的五角星存在偏差,平台核印结果分别显示为“X”及“?”,支行初步断定该证为伪证。
变更及案例 篇2
1 工程案例
某工程公司承揽一座综合办公建筑, 双方依照河北省建设工程施工合同制式文本签订了施工合同。原设计室内地面采用600*600m m地砖, 施工过程中建设方认为不上档次, 要求改为800*800m m地砖, 让施工单位填写了“工程变更单”, 变更单内容为“应建设单位要求, 地砖规格改为800*800m m ”, 各方均签字确认, 其后施工单位未履行任何费用索赔手续就进行了施工。双方竣工结算时, 施工单位提出结算价格应该加上变更费用12 万元, 建设方认为提出价格过高, 只给增加费用8 万元, 双方无法达成一致。建设方提出按照合同要求执行, 双方查阅合同发现, 专用条款中关于价款的调整方法填写“执行通用条款”。通用条款中“提交价款调整报告及其限制”中规定:“承包人应在价款调整事件发生后的14 天内向造价工程师提出价款调整报告;如承包人未在价款调整事件发生后的14 天内提出价款调整报告, 则造价工程师可以在报经发包人批准后, 根据掌握的实际资料决定是否调整合同价款以及调整的金额”。建设方以此为由, 提出建设方有权定价, 符合合同规定, 施工方因未按合同及时提出变更工程价款报告, 失去了争取权益的机会。
2 产生分歧的原因分析
施工单位项目管理人员经营管理经验不足, 施工不看合同, 也未及时核算工程变更产生的费用增加, 盲目赶进度, 这是粗放型管理的典型特征, 也是现阶段施工单位现场管理中存在的普遍情况。同时, 在施工阶段变更发生后, 变更手续使用表格也不正确, 由于是业主提出的设计变更, 所以, 应该出具“设计变更通知单”而不是“工程变更单”, 业主在不具备设计资质、非设计主体的情况下是无权擅自进行设计变更的。施工单位应在变更发出后14 天内填写“工程变更费用报审表”或“费用索赔申请表”报监理及业主审批, 施工单位未能及时按程序申报, 可能会让业主产生不增加费用的错觉, 也给业主压价提供了机会, 最终施工方要承担差价损失。
3 工程变更程序要求及避免产生分歧的要点
根据河北省 《建筑工程资料管理规程》, 现阶段施工现场工程变更应使用“设计变更通知单”、“工程洽商记录”。
“设计变更通知单”是在施工过程中, 设计单位对施工图需要变更的部位下发的书面变更文件。“工程洽商记录”是施工过程中, 由于设计图纸本身差错、设计图纸与实际情况不符、施工条件变化及职工提出施工合理化建议等原因, 对设计文件部分内容进行修改而办理的洽商记载, 工程洽商变更内容不能影响结构安全和使用功能, 降低节能效果。施工单位、监理单位和建设单位均可提出洽商要求, 施工单位负责洽商的记载, 工程洽商记录应按专业分别填写, 由设计、施工、建设和监理等单位的代表签认, 并加盖单位技术部门印章。设计单位如委托建设 (监理) 单位办理签认, 应办理委托手续, 分包工程的有关工程洽商记录, 应通过工程总包单位办理。
“工程洽商记录”大多体现出承发包双方的合意, 产生分歧的较少。但在施工过程中, 有些业主善于要求设计单位出具“设计变更通知单”, 对工程局部按照业主的意愿进行变更, 设计往往不考虑费用问题, 施工方也不重视, 习惯于秋后算账, 最终产生分歧。所以, 施工过程中, 把握好因“设计变更通知单”产生的费用问题, 是避免产生分歧的要点。
4 施工单位工程变更应履行程序的要求
施工单位接到“设计变更通知单”或“工程洽商记录”已形成, 均应计算费用的增减, 及时提报“工程变更费用报审表”, 承包人应在价款调整事件发生后的14 天内向造价工程师提出价款调整报告, 造价工程师、建设单位代表在合同约定期限内对施工单位所报的工程变更引起的工程量、费用和工期进行审核和协商, 协商一致后签署审查意见和暂定价款数额。工程竣工结算应包括合同工程价款、工程变更价款、费用索赔合计金额。
5 施工单位索赔程序
建设工程索赔通常是指在工程合同履行过程中, 合同当事人一方因对方不履行或未能正确履行合同或者由于其他非自身因素而受到经济损失或权利损害, 通过合同规定的程序向对方提出经济或时间补偿要求的行为。索赔不限于工程变更, 应根据合法生效的合同条款提出。
河北省 《建筑工程资料管理规程》 有“索赔意向通知书”、“费用索赔的申请用表”、“费用索赔审批表”三个相关表格, “索赔意向通知书”是提出单位在施工合同约定的期限内向项目监理机构提交的对责任单位的费用索赔意向通知。表中“根据合同__ 条款”是指施工合同中有关索赔内容的合同条款, “附件”是发生索赔时的相关资料以及造成损失的初步评估额度。“费用索赔申请表”是施工单位向项目监理机构提出的对建设单位费用索赔的申请用表, 应在合同约定的时间内提出。其中应有:1) 索赔的详细理由和经过, 具体包括:索赔事件造成施工单位的直接经济损失、索赔事件是由于非施工单位责任发生的详细理由和事件经过;2) 索赔金额的计算, 应根据合同的约定编制索赔计算过程;3) 附件, 主要是证明材料, 应包括索赔事件发生和费用计算依据的凭证。“费用索赔审批表”是项目监理机构对施工单位提出的费用索赔申请的审查、确认和批复用表, 总监理工程师应在施工合同约定的期限内签发费用索赔审批表, 或发出要求施工单位提交有关费用索赔的进一步详细资料的通知。
参考文献
[1]DB13 (J) T 145-2012河北省工程建设标准.建筑工程资料管理规程[S].北京:中国建材工业出版社, 2013.
变更及案例 篇3
中图分类号:U41 文献标识码:B文章编号:1008-925X(2012)11-0104-02
摘 要 本文通过几个实际案例,简要讲述道路工程变更索赔过程中经常使用的方法与技巧,并列举了容易发生变更索赔的问题
关键词 案例; 变更; 索赔; 技巧; 方法; 利润
1引言
FIDIC合同条件中,工程变更一般指“工程范围的变更”和“工程量的变更”,工程范围的变更属于施工索赔的范围,因为它超出了原合同的工程范围,属于额外工程;工程量的变更是指原合同工程范围内的工程内容,只是在工程数量上有所变化。因此,在FIDIC合同条件中,“工程量的变更”与“工程范围的变更”有质的区别。
但是,在实际操作过程中,工程师为了保护业主的利益,往往不会轻易同意承包商根据合同条件所提出的正常变价要求。因此,承包人如何巧妙利用合同变更来维护自己的利益,也是建设工程合同实践中的一个操作问题。
建设工程索赔通常指在工程合同实施过程中,合同一方因非自身因素、对方没有履行或没有正确履行合同规定的义务等方面的原因,导致其利益受到损失时,按照合同约定或者律法规定,在规定的时间内依据利益损失事实向对方提出的权利主张。索赔不以对方违约为必要前提,在行为性质上更接近于寻求经济补偿行为,是当事人保护自己、避免损失、增加利润、提高效益的一种重要手段。
建设工程索赔的权利是双向的:不仅承包人可以向发包人索赔,发包人同样也可以向承包人索赔。但在建设工程实践中,索赔大多以承包方向发包方索赔的方式出现。本文阐述的索赔也是此类。
2案例
某非洲项目业主在发标时,对合同的部分工程进行了变更。为避免承包商根据合同条款进行索赔,以便在最大程度上控制项目造价,业主要求承包商做出两个书面承诺,并作为合同的附件:①在合同工期内完成全部工程,包括所有的变更工程②投标的单价适用于变更工程。
其中一项变更为边沟断面:原设计边沟的边坡根据所处的填挖段和土质条件为1:3或1:2,边沟底宽3m;变更后的边坡根据所处的填挖段和土质条件为1:2或1:1,土边沟底宽1m。
技术规范规定:道路(包括边沟)开挖的土方,如果实验证明可利用时,应将该土方用于3km以内的道路填方,并在普通填方项下支付,没有单独的边沟开挖支付项。
工程现状:取样实验结果表明本项目的挖方均可用于路基填方。这就意味着:①边沟开挖不单独计价②边沟开挖出来的土方要用于填方③填方按普通填方支付,而普通填方的报价仅为1.6美元/m3。综合以上:边沟开挖与土方回填的支付款一共就只有1.6美元/m3。
那么,承包商如何才能利用合同变更和索赔来维护自己的利益呢?
分析:这里涉及两个问题:①如何才能将边沟开挖作为变更处理?②如何计算边沟开挖的单价。
第一个问题:将边沟开挖作为变更处理
合同条款:单纯的施工量的变化或者施工难度的增加,按照合同的约定不属于变更。但如果涉及施工顺序或时间安排进行的任何变化,承包人有权提出作为合同变更来考虑。
对策:原设计边沟在实施中可采用推土机和平地机与路基挖方同步施工,而设计变更后的边沟只能采用挖掘机开挖且只能在路基施工完成后开始开挖,因而边沟开挖的施工方法和时间安排改变了,所以应该按照合同变更来处理,这点得到了对方的认可。
第二个问题:计算边沟开挖的单价
合同条款:承包商承诺“投标的费率适用于变更工程”。这就意味着如果重新申请单价就必须套用投标时清单的费率,这样根本就没什么实际意义。
对策:边沟开挖是排水工程的一部分,应套用排水工程项下的开挖土方单价2.53美元/m3。边沟开挖单价变更后,边沟开挖的土方将不再考虑用于路基填方,那么道路填方的单价就该使用借土填方的单价3.03美元/m3。那么边沟开挖与土方回填的支付款一共2.53+3.03=5.56美元/m3。
综上所述:边沟每立方米增加收入:5.56-1.6=3.96美元/m3,工程量超过30万m3,仅此一项的索赔就超过120万美元。
通过上述案例,我们得到这样一个结论:只要有目的、有目标的认真研究思考,变更索赔总是会有突破点的。
3变更索赔的技巧及道路工程若干案例
第一、工程量的权衡与合同单价的斟酌
道路工程施工中,很多工程量是含混不清的,这就要求施工方在施工之前,先要对合同的清单单价进行分析比较,然后再有针对性有选择的进行施工。例如:
①斟酌报价进行清表的量与清淤泥的量的权衡:一般清表量少报、清淤量多报
②斟酌报价进行清淤泥的量与清淤后回填料的量的权衡:哪个报价高哪個量多报
③斟酌报价进行挖土、利用土与借土填方的工程量的权衡:挖土量会影响回填利用土的量;利用土的量又会影响借土填方的量;这三个量相互影响,一定要先算后报,做到利润最大化。
④斟酌报价进行回填料的选择
第二、工程量的计算。例如:路面工程量的计算因为有曲线段、不规则图形,所以手动计算和AutoCAD计算的结果会有一定的差距,比较哪种方法更有利。
第三、方案优化。例如:清单中的施工内容为筑坝排水清淤,但由于筑坝报价很低,申请优化方案,省去筑坝。
第四、寻求利润最大化是每个项目的终极目标,不应只体现在施工过程中,更应该提早到投标之前。施工方提前介入,认真进行标前核量,根据图纸工程量与清单所给工程量的差别,来确定中标后施工时变更的方向,借此进行不平衡报价,这样会起到事半功倍的效果。例如:
某项目有个池塘需要处理。清单中需要填筑7万多m3混渣,核量后发现实际工程量为3万多m3,在工程量必然减少的趋势下进行低报价,亏损7元/m3;但实际施工时经与业主协商,此项工程量不大,可将混渣变更为8%灰土,而灰土的单价在投标报价时单价很高,盈利30元/m3;这样一盈一亏,仅此一项扭亏为盈111万元。
第五、其他。变更索赔有很多技巧,例如:将一个大变更大索赔分解到多个小变更小索赔,这样就更容易签认通过;上报的时间也是要好好把握的,不能太早也不能太晚,最好选在签字人记得有这件事发生但可能记不清细节的时候,等等。
4结语
违规变更单位结算账户引发的案例 篇4
一、案例简介
分行运行督导员对网点进行专项检查,检查该网点变更单位结算账户业务时发现:一单位账户户名由“XX汽车贸易责任公司” 变更为“XXX汽车销售有限公司”,单位法定代表人由“黄X” 变更为“陈X”,而且,单位填写的变更申请表上营业场所地址、联系电话等均发生变动,但客户提供变更资料只有变更申请书、税务登记证,没有变更单位提供相关部门的证明文件,如工商行政管理部门的《变更登记表》及工商营业执照,也无对单位的尽职调查记录,网点却直接为其办理了变更手续。
二、案例分析
根据《关于加强人民币单位银行结算账户管理的通知》要求:对客户账户名称、法定代表人发生变化的账户变更业务,银行要严格按照新开户的审核标准及相关规定办理。而《人民币单位结算账户管理办法》也明确规定:对单位客户账户名称、法人代表人发生变化的账户变更,但不改变开户行及账号的业务,单位客户的法定代表人或主要负责人、住址以及其他开户资料发生变更时,单位应于5个工作日内向开户行提交正式公函通知,并出具有关部门的证明文件,开户行对单位客户的变更通知和证明文件审核无误后,才能为单位客户办理变更手续。
本案例中,该网点柜员明显违反规定未要求单位客户提供完整的相关重要资料,就直接为其办理了账户变更手续,而现场管理人员也没有按规定对相关证明文件真实性、合规性、完整性进行现场审核,尽职调查不到位,是导致业务风险发生的主要原因,极易给不法分子提供可乘之机,引发经济案件。
三、案例启示
(一)要以《业务操作指南》为指南,加强对一线柜员对人民币单位结算账户业务处理规程的培训,促使其熟练掌握账户变更操作流程、关键风险点和重要环节,有效提升自身风险意识和风险防范能力,自觉规范其操作行为,从源头上减少风险事件的发生。
(二)要认真贯彻“了解你的客户”原则,落实尽职调查责任。“了解你的客户” 是保护银行合法权益和资金安全的基础工作,因此,不论是开户资料、还是变更资料,都应对单位客户的账户名称、法人,营业地址、联系电话等进行认真核实,对其真实性、完整性、合规性进行认真审查,从而将账户的开立、变更、撤销等各个风险环节规章制度的执行真正落到实处,确保客户身份资料的真实性、有效性和完整性。
变更及案例 篇5
公司股权变更的程序及变更步骤是什么?股权和法人财产权和合伙组织财产权,均来源于投资财产的所有权。投资人向被投资人投资的目的是营利,是将财产交给被投资人经营和承担民事责任,而不是将财产拱手送给了被投资人。
公司股权变更流程:
一、公司股权变更的具体流程:
1、领取《公司变更登记申请表》(工商局办证大厅窗口领取)
2、变更营业执照(填写公司变更表格,加盖公章,整理公司章程修正案、股东会决议、股权转让协议、公司营业执照正副本原件到工商局办证大厅办理)
3、变更组织机构代码证(填写企业代码证变更表格,加盖公章,整理公司变更通知书、营业执照副本复印件、企业法人身份证复印件、老的代码证原件到质量技术监督局办理)
4、变更税务登记证(拿着税务变更通知单到税务局办理)
5、变更银行信息(拿着银行变更通知单基本户开户银行办理)
二、公司股权变更所需资料:
1、《公司变更登记申请表》
2、公司章程修正案(全体股东签字、盖公章)
3、股东会决议(全体股东签字、盖公章)
6、公司执照正副本(原件)
7、全体股东身份证复印件(原件核对)
8、股权转让协议原件(注明股权由谁转让给谁,股权、债权债务并转让,转让人与被转让人签字)
公司股权变更步骤:
一、《企业变更(改制)登记(备案)申请书》(内含《企业变更(改制)登记申请表》、《变更后单位投资者(单位股东、发起人)名录》、《变更后自然人股东(发起人)、个人独资企业投资人、合伙企业合伙人名录》、《变更后投资者注册资本(注册资金、出资额)缴付情况》、《法定代表人登记表》、《董事会成员、经理、监事任职证明》、《企业住所证明》等表格。请根据不同变更事项填妥相应内容);
二、依照《公司法》作出的变更决议或决定;股份有限公司股东大会决议应按照《公司法》的有关规定由到会法人股东盖章、自然人股东签字或提交授权委托书。
三、《企业法人营业执照》正、副本;
四、《指定(委托)书》;
变更下列具体事项的,还需要提交以下文件、证件:
(一)变更名称:
(1)《企业名称变更预先核准通知书》及《预核准名称投资人名录表》(办理名称变更预先核准登记请您参看《一次性告知单①--如何办理名称预先登记》的相关内容)。
(二)增加注册资本:
(1)股东大会决议;
(2)提交依法设立的验资机构出具的验资证明;以非货币方式增资的,还应提交评估报告(涉及国有资产评估的,应提交国有资产管理部门的核准或备案文件)及法定验资机构对评估结果和办理财产转移手续进行验证的报告;
(3)非上市股份公司以未分配利润、股本溢价计入的资本公积金、红利转增注册资本的,还应提交审计报告,并提交会计师事务所出具的《验资报告》。(公司法定公积金转增为注册资本的,验资证明应当载明留存的该项公积金不少于转增前公司注册资本的25%);
(4)上市股份有限公司增加注册资本的(公开发行新股),还应提交国务院证券管理部门的批准文件;
(5)上市股份公司以公积金转增注册资本的还应提交中国证券登记结算有限责任公司深圳(上海)分公司确认的《协助查询确认函》
(6)上市股份公司涉及国有股权变更的应提交国有资产监管部门的批准文件及中国证券登记结算有限责任公司深圳(上海)分公司过户确认书。
(7)公司境外上市发行增加注册资本还应提交中国证监会的批准文件,同时请企业咨询外商务部是否必须变更为中外合资股份公司。
(三)减少注册资本:
软件项目的需求变更及对策 篇6
什么是需求分析?
要知道需求变更是什么, 首先要知道什么是需求分析。
需求分析是指理解客户需求, 就软件功能与客户达成一致, 估计软件风险和评估项目成本代价, 最终形成开发计划的一个复杂过程。需求分析的成果形成需求说明书。
什么是需求变更?
根据软件工程思想定义, 需求说明书一般要经过论证, 如果在需求说明书经过论证以后, 需要在原有需求基础上追加和补充新的需求, 或对原有需求进行修改和削减, 均属于需求变更。
二、需求变更的原因及影响
1. 需求变更原因
一方面是用户:他们是项目需求的提出者。一个十分常见的现象是用户提出需求以后, 在软件开发过程中用户改变了需求, 这只能迫使开发工作返工, 丢弃一些无法修正的部分。无疑这会造成一定的损失, 但又无法完全避免。要求用户一次性把需求讲清楚, 并且不允许此后需求有任何变更, 这是不现实的。只能尽量减少需求变更, 降低它所造成的影响。
二是系统因素:在系统内部, 如计算机硬件、系统软件或数据的变更要求与其相适应。
三是外部环境因素:与软件运行相关的工作制度或法规、政策的变更, 或是业务要求变更导致的需求变更。
四是需求分析阶段工作缺陷:需求调研、分析、定义和评审工作不够充分, 致使需求规格说明中隐含着问题, 在开发过程中才有所发现。或者需求开发中开发人员与用户沟通不够充分, 如未能如实获得用户的潜在需求等。
软件需求一旦出现变更, 它可能要涉及到一些相关的代码和文档的修改, 为此要把这一变更通知到所有相关人员。提出需求变更有可能在开发的任何阶段, 并且随着项目的进展, 越晚的需求变更引起的损失越大。
2. 需求变更给软件的开发工作带来的影响
需求变更对软件开发的影响是多方面的, 概括的看, 包括以下三个方面:
(1) 增加项目的人员、费用开支, 影响开发进度。需求变意味着原先的需求调研、分析的结果与预期的软件实现存在偏差, 需要进行需求变更。这无疑要增加项目的人员、费用的开支, 并对开发进度造成影响。更有甚者, 如果变更频繁, 可能对项目造成较大影响, 严重时可能直接导致项目的失败。
(2) 影响软件质量。在一个复杂的软件系统中, 需求之间具有一定的联系, 相关需求可构成需求链。如果由于需求变更导致需求链的某些环节脱节, 就可能引起一些难以察觉的错误。当需求变更没能及时修改项目的设计、开发文档时, 这些错误一般难以被测试人员发现, 将直接影响系统质量, 严重时可导致系统崩溃。
(3) 影响开发者与用户之间的合作关系。需求变更的实施是用户和开发者相互协作的过程。开发者和用户在是否采用变更问题上常常产生分歧, 如果没有恰当处理, 影响双方的互信, 从而影响项目开发进程。同时需求变更也会在项目开发人员之间产生分歧, 影响合作关系。
三、采取的对策
1. 首先是预防
尽量做好需求分析工作, 以期减少需求变更的频次, 为此在需求分析阶段着重处理好以下问题, 力图使需求分析的结果更接近目标。
(1) 培养正确的需求意识。优秀软件产品建立在优秀的需求基础之上, 而高质量的需求又来源于客户与开发人员之间有效的交流与合作。因此, 双方的参与者都需要认识到:要想获得成功, 自己需要什么, 合作方又需要什么。只有这样, 才能建立融洽的合作关系。因此, 培养正确的需求意识是双方都需要努力的, 而开发人员在这个阶段应该发挥更加积极主动的作用。
首先, 需求分析人员应该接受一定的正规培训, 以提高与人沟通的能力、缓解矛盾的能力、善于倾听和询问的技巧, 以及收集整理资料的能力等。在参与具体项目时, 分析人员也应主动学习一些项目所涉及的具体应用领域的基本知识, 以更好地理解用户的需求。
其次, 开发单位应该对那些不想花时间在需求分析上的用户明确指出:如果用户不能充分地支持并参与, 项目很可能会失败;开发单位还可以通过学习一些前车之鉴的真实案例警告用户:低质量的需求分析可能导致严重的后果。通过对用户代表和管理人员的培训, 使他们真正理解需求分析的重要性和忽略需求带来的风险, 并对计算机系统有一个大体的了解, 这样用户才能够主动地参与需求分析。
同时, 正因为不可能一次就完全了解用户的需求, 而且在系统开发过程中还需要不断地请用户参与, 因此与用户的沟通是需要贯穿始终的。需求分析中所采取的一些策略可能会让用户觉得意外和难以接受。因此, 需求分析人员需要对用户解释一些做法的必要性和合理性, 以得到用户最大的支持与合作。
(2) 从业务需求入手。用户认识到了需求分析的重要性, 但可能仍然不知道从何处入手表达自己的需求。这时可以从业务需求入手, 任何企业对自己的经营运作目标应该是比较清楚的, 这样的经营背景让用户不仅有话说, 也让开发者有章可循。需求分析不可以完全与它所处的背景相脱离, 只有当系统真正置身于它的社会和组织环境中, 它的需求才能清晰地反映出来。
(3) 充分利用需求来源。有了以上需求背景, 就比较容易做到有的放矢了。需求分析人员可以直接与系统未来的操作者探讨他们希望有什么样的软件;观察系统的潜在用户当前的日常工作以获取有价值的信息;系统的使用者可能有很多, 可以将他们分类以简化需求;最后一定要与真正的决定者达成协议:对于有冲突的需求如何权衡, 对于直接用户的众多需求如何取舍等。
同时, 用户往往对计算机期望过高, 认为计算机可以解决当前存在的所有问题, 因此会提出很多的功能需求, 并且希望在很短的时间内看到成效。但是, 由于技术、人力等资源的限制, 并不一定能够在设定的时间期限内满足用户所有的期望, 这时就应该尽早确定出交付的产品应具备的最重要功能, 即设定需求的优先级。
在这个阶段, 可以采用UML中的用例图帮助用户和需求分析人员之间的交流。一个用例图描述用户可以用软件产品执行的一个任务。它不是从软件的性能和系统的行为方面出发, 而是从用户到底能够用这个软件产品干什么入手。这样的方式用户比较熟悉, 容易沟通;而且不会在需求分析的一开始就陷入过于细节化的设计, 也有助于避免分析人员添加一些与所需任务无关的自认为很好的功能。
(4) 提供选择方案。由于用户对软件系统缺乏经验, 或者由于用户的运作机制还未完善, 或者由于其他种种原因, 用户可能仍然不能对一些需求做出明确的说明, 收集整理的需求中可能仍然存在一些不确定因素。这时可提出几份比较详细的方案。附带不同做法的优点, 供用户选择或者启发用户确定需求。
如果需求分析做得好, 文档清晰且又有客户签字, 那么后期客户提出的变更就超出了合同范围, 需要另外收费。这个时候, 开发方一定要据理力争, 此时这并非要刻意赚取客户的钱财, 而是不能让客户养成经常变更的习惯, 否则后患无穷。
2. 分级管理客户需求
软件开发项目中, “客户永远是对的”和“客户是上帝”并不完全的正确, 因为在已经签定的项目合同中, 任何新需求的变更和增加除了影响项目的正常进行以外, 还影响到了客户的投入收益, 所以有的时候项目经理反倒应该为客户着想。
对于项目中的需求变更, 可以实行分级管理, 以达到对需求变更的控制。
一级需求变更是关键性的需求, 这种需求如果不满足, 意味着整个项目不能正常交付使用, 前期工作也会被全部否定。这个级别的需求是必须满足的, 否则就意味着否定自已的项目成员和成员的所有努力, 所以定为“Urgent”。
二级需求变更是后续关键性需求, 它不影响前面工作内容的交付, 但不加以满足, 新的项目内容无法提交或继续, 所以是“Necessary”。一般新模块关键性的基础组件, 属于这个级别。
三级需求是后续重要的需求, 如果不被满足会令整体项目工作的价值下降, 为了体现项目价值, 也是开发人员自已的技术价值的证明, 所以定为“Needed”。一般性的重大的有价值的全新模块开发, 属于这个级别。
以上三个等级是应该实施的, 但时间性上可以作优先级的排列。
四级需求是改良性需求, 没有满足这类需求并不影响已有功能的使用, 但如果实现了则会更好, 定级为“Better”。界面和使用方式的需求, 一般在这个档次。
五级需求是可选性需求, 更多的是一种设想, 以及一种可能, 通常只是客户的的一种个人喜好而已, 定级为“Maybe”。
对于四级需求, 如果时间和资源条件都允许的话, 不妨做下去。对于五级需求, 正如对它的描述一样做与不做是“Maybe”。
3. 加强需求变更的控制
在需求分析阶段工作完成后, 需求变更仍可以会发生, 因此就要加强对需求变更的控制, 主要有以下原则:
(1) 建立需求基线。需求基线是需求变更的依据。在开发过程中, 需求确定并经过评审后 (用户参与评审) , 可以建立第一个需求基线。此后每次变更并经过评审后, 都要重新确定新的需求基线。
(2) 制订简单、有效的变更控制流程, 并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时, 这个流程具有一定的普遍性, 对以后的项目开发和其他项目都有借鉴作用。
(3) 成立项目变更控制委员会 (CCB) 或相关职能的类似组织, 负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成, 应该包括用户方和开发方的决策人员在内。
(4) 需求变更一定要先申请然后再评估, 最后经过与变更大小相当级别的评审确认。
(5) 需求变更后, 受影响的软件计划、产品、活动都要进行相应的变更, 以保持和更新的需求一致。
(6) 妥善保存变更产生的相关文档。
这六大原则看起来简单, 但真正实施起来有难度, 还需要依据理论知识配合开发项目组的实际工作情况, 在实践中不断摸索总结。
四、总结
软件项目的需求变更是对软件产品的质量、成本、工期带来巨大的影响。通过预防性措施和加强需求变更的控制与管理, 将需求变更的频次大幅度降低, 从而为软件项目的顺利实施打下坚实基础。
参考文献
[1]王莉吴洁明:软件项目中的需求变更管理的研究[J].计算机技术与发展, 2007, 17 (1) :120~121
[2]王强:软件开发项目中的需求变更管理[J].电脑知识与技术 (学术交流) , 2007, (11)
[3]李师贤张珞玲:需求分析的常见问题及其对策分析[J].计算机工程, 2002, 28 (1) :7~8
【变更及案例】推荐阅读:
变更策划及实施07-31
变更及应用论文09-13
上海变更公司法人,股东流程及费用07-11
监理工程师变更注册程序及申请表10-02
造价变更05-12
变更测量05-17
变更方案05-25
变更原则06-24
制度变更06-27
变更方式07-03