需求文档可以不签字吗? 之一

在软件开发中,需求分析和需求管理一直被认为是软件开发成功与否的关键。
在CMMI中,需求管理是CMMI2级的过程域,需求开发是CMMI3级的过程域。
在瀑布型生命周期当中,安排了需求分析阶段,一般也安排需求分析里程碑评审。
瀑布型生命周期存在了很多年,曾经几度写入到软件开发的国际标准、国家标准当中。

由于瀑布型生命周期如瀑布般顺流而下,在设计阶段开始后,根据需求文档的结果来开
展工作,要求需求文档的结果比较清晰、稳定。所以对于需求确认,往往地采用签字的
方式,希望各方慎重、全面、充分的确定需求。

签字确认需求文档这个做法几乎成为一个标准过程,在大大小小的软件开发中出现。
那么软件工程发展了这么多年之后,发现经签字确认的需求仍然有大量的变更,不禁要
问:需求文档需要签字确认吗?
在软件没有开发的时候,分析需求需要各类想象,对于目前一般规模的商业软件(全部
12人月工作量以上)而言,而无论做得如何仔细,就算访问所有的干系人,也不能把所
有环节全部考虑到。而在软件开发的过程中,时间在推移,随着时间的推移,用户的需
求会不断的发掘、修正;开发人员对软件需求的认知也是随时间推移而渐渐的清晰。而
随着软件的开发部署,经过初步的使用,变更的要求、升级的要求就自然的产生了。

所以需求在变化,或者说需求在演化,这是客观规律。

在需求的演化之中,签字确认有用吗? 当然有用,用处是在这个签字的一瞬间保留了需
求的一张快照,这张快照对于履行合同是有用的,在短期内指导后续的工作,但是除此
之外并没有太大的用处。因为这演化中的需求会渐渐地与这张快照不一样。

传统的瀑布型生命周期中就需要设计需求变更管理流程,每一次的变更都需要多方的签
字确认。为了维护一致性,还需要追溯需求文档、设计文档、代码、测试用例的一致性
。需求变更成为不少项目风险的最大来源,成为大量项目不成功的最大原因。

签字的另一个问题是签字很麻烦,对于甲方而言,签字意味着责任,往往要拖到最后,
认为各方面都没有问题后才能签字。而需求分析或变更都是后续工作的前提,签字的拖
期也将推迟后续工作的开展。

因此签字确认需求文档的弊端有:
1,  签字不能真正的确认需求。
2,  签字过程慢。

所以,值得回过头来反思:签字确认的需求有用吗?有没有更好的方式?
如果需求文档写在软件运行之后,那么以软件运行的截屏为主体的需求文档肯定比软件
运行之前想象之中的需求文档更加精准,而且书写文档所费工作量大大减少,而且这个
需求文档经过简单的转换,就可以成为用户文档。

你可能感兴趣的:(需求文档可以不签字吗? 之一)