在软件开发中，需求分析和需求管理一直被认为是软件开发成功与否的关键。
在CMMI中，需求管理是CMMI2级的过程域，需求开发是CMMI3级的过程域。
在瀑布型生命周期当中，安排了需求分析阶段，一般也安排需求分析里程碑评审。
瀑布型生命周期存在了很多年，曾经几度写入到软件开发的国际标准、国家标准当中。
由于瀑布型生命周期如瀑布般顺流而下，在设计阶段开始后，根据需求文档的结果来开
展工作，要求需求文档的结果比较清晰、稳定。所以对于需求确认，往往地采用签字的
方式，希望各方慎重、全面、充分的确定需求。
签字确认需求文档这个做法几乎成为一个标准过程，在大大小小的软件开发中出现。
那么软件工程发展了这么多年之后，发现经签字确认的需求仍然有大量的变更，不禁要
问：需求文档需要签字确认吗？
在软件没有开发的时候，分析需求需要各类想象，对于目前一般规模的商业软件（全部
12人月工作量以上）而言，而无论做得如何仔细，就算访问所有的干系人，也不能把所
有环节全部考虑到。而在软件开发的过程中，时间在推移，随着时间的推移，用户的需
求会不断的发掘、修正；开发人员对软件需求的认知也是随时间推移而渐渐的清晰。而
随着软件的开发部署，经过初步的使用，变更的要求、升级的要求就自然的产生了。
所以需求在变化，或者说需求在演化，这是客观规律。
在需求的演化之中，签字确认有用吗？ 当然有用，用处是在这个签字的一瞬间保留了需
求的一张快照，这张快照对于履行合同是有用的，在短期内指导后续的工作，但是除此
之外并没有太大的用处。因为这演化中的需求会渐渐地与这张快照不一样。
传统的瀑布型生命周期中就需要设计需求变更管理流程，每一次的变更都需要多方的签
字确认。为了维护一致性，还需要追溯需求文档、设计文档、代码、测试用例的一致性
。需求变更成为不少项目风险的最大来源，成为大量项目不成功的最大原因。
签字的另一个问题是签字很麻烦，对于甲方而言，签字意味着责任，往往要拖到最后，
认为各方面都没有问题后才能签字。而需求分析或变更都是后续工作的前提，签字的拖
期也将推迟后续工作的开展。
因此签字确认需求文档的弊端有：
1， 签字不能真正的确认需求。
2， 签字过程慢。
所以，值得回过头来反思：签字确认的需求有用吗？有没有更好的方式？
如果需求文档写在软件运行之后，那么以软件运行的截屏为主体的需求文档肯定比软件
运行之前想象之中的需求文档更加精准，而且书写文档所费工作量大大减少，而且这个
需求文档经过简单的转换，就可以成为用户文档。