小时工资率是什么?我们国内企业发工资一般会是基于工作天数的月薪，而许多外企则是基于工作小时数的月薪，所以这里有一个区别：一天可以是8个小时也可以是18个小时，难怪我们国内企业加班是家常便饭：没有请你周六周日来啊，不就是每天多那么几个小时嘛!而外企加班相对少许多：额外的工作时间要付加班费的(或许是工商局对它们看得比较严，而对我们国内的企业则网开一面的缘故吧)。说远了，小时工资率的设定与计算可依据组织的特点设定，自己搞不定请财务部门帮你出个数吧。
人时乘以小时工资率不就是人员工作量对应的成本嘛!其他的有时候可能涉及到材料费用、软硬件的采购费用、差旅费用等，我们统一将它归结为非人力成本好了。这样我们将这两部分相加就得到需求变更对应的成本增加情况。第四步也是这么一目了然，没有问题吧。
第五步
要说第五步还真不太容易给一个统一的建议，这得取决于项目组的情况。如果项目组没有量化的历史数据参考，只能以定性的方式去描述需求变更对于项目不同阶段的影响。例如我们在测试阶段的后期实施一项大的变更，那么它对测试阶段的质量影响是可以想见的：因为引入新功能或更改功能，一定导致更多的缺陷，而在回归过程中如发现新的问题需要修改的话又可能带来更多的问题。所以对于测试阶段的质量是负面的。对于产品运行阶段的质量影响也是显然的：系统的稳定性、可靠性、安全性可能都会受到波及。
当然，如果项目所在的组织有些历史数据作参考，那判断起来就容易多了。如果变更的需求是30个功能点,又假定测试阶段缺陷密度是0.4/FP到0.8/FP之间,我们容易推测变更将导致增加的缺陷个数介于12到18个之间;而如果残余缺陷密度是0.02/FP到0.05/FP之间，则上线后暴露给客户的问题数目为0.6个到1.5个之间，也即一到两个。
我们将对质量的影响是不是也可做相应的分析?当然喽!
第六步
这个小节关注的是风险，变更往往意味着更多的功能，更多的功能意味着更多的工作要做，因而面临更多的变数，也即我们就常所说的风险。比如说变更往往伴随着工期的延长，而对于在外地开发的项目此种情形尤其有可能导致项目组成员普遍的厌倦情绪，对应的风险表述就是项目组士气低下，导致工作效率下降，甚至会引起人员的流失，对于项目组来说不得不预见这种类型的风险，所以变更分析应该做出对应的风险分析。
第七步
这一步就很简单了，主要是根据前面的给定的各方面信息权衡以后做出是否变更的决定。有人又说了：才不是呢，如果是需求变更，那一定得客户签字，客户如果不签字，我们一点招数都没有!我们再一次退而求其次：能不能把客户的名字写上，表明他(她)知晓这件事情?应该是可以的吧。至于表头信息，我想应该没什么问题，所提供的相关信息主要是供以后做统计分析之用。
文章来源于领测软件测试网 https://www.ltesting.net/
