是否应以设计作为软件项目验收标准

很多软件项目都会有延期现象，比例相当高。延期的后果是相当严重的，其结果就是软件开发企业的利润急剧下降，甚至导致部分企业出现严重亏损。 

可以说，绝大多数的软件项目，都是以需求文档为合同的附件，这个附件是项目验收的标准。以需求为验收标准，按道理来说，开发商只要满足了需求描述的内容就可以了。但实际上是反过来，只要用户提出的修改意见没有超出需求的范围，在系统上线之前，开发商就得免费修改，无论修改多少次，因为用户提出的修改要求在需求范围之内。 

需求是一种笼统描述，它不具备精确含义。即使我们的需求写的很详细，仍然不可能规定软件的一切特征。需求描述了一个目的，但完成这个目的的方式有很多种。每一种实现，都需要付出劳动，老板都要为之付出成本。 
当我们辛辛苦苦的把软件按照需求开发完成，以为大功快要告成，而实际上那只是磨难的开始。用户在需求调研的时候敷衍了事，需求也提的很粗略。但是看到实际的软件之后，往往会提出一大堆的修改意见。他们会告诉你，这个功能，你没有正确理解我的意思。那个功能，实现是实现了，可是我觉得不好，能不能换个方式实现？ 

用户在提出需求的时候往往不会规定实现方式，可是等你实现好之后，他们会说你这个不好，那个不好，提出一大堆修改的理由，甚至全部推翻。对开发商来说，这是很冤枉的事情。 

如何避免冤枉事的发生呢？ 

如果我们要装修房子，我们不会把需求告诉装潢公司，由装潢公司整理一个装潢需求，让我们签个字，然后装修公司去装修。装潢公司肯定会根据我们的需求做一个设计图，然后给我们看设计图和效果图，如果我们认可这个设计，装潢公司才会开始装潢工作。以后如果有纠纷，就按照设计来裁定。 

同样的道理，软件项目，也不能仅仅依照需求书来做开发，我们应该把我们的设计反馈给用户，告诉用户我们打算这么设计，请用户确认这样的设计是否满足用户的需求。 

我们把用户说过的话复述一遍，或者换个角度描述一遍，是难以让用户来确认，我们所说的是否与用户所想的一致，只有把设计结果-功能设计文档（最好包含界面）提供给用户，让用户有感官的认识，才能做出正确的判断。 

我们的费用评估，应该基于功能设计文档，而不是基于需求文档。实现一个功能，有多种实现方式，每种实现方式的成本是不一样的。 

作为合同附件的文档，应该是功能设计文档而不是需求文档。当软件提交后，用户应该按照功能设计文档来验收，而不是按照需求来验收。因为功能设计文档不但规定了实现的功能，而且规定了实现的方式，用户要修改实现方式，也被认为是对合同标的的修改，需要追加费用。这样用户就不会随便提出修改意见，他们会提前深入项目，而不是在项目前期敷衍，项目后期进行无限期的修改，白白侵蚀开发商仅有的利润。 

如果你的供应商不挣钱，后果是什么？答案是你会得到劣质产品，最终损害自己的利益。