软件需求文档的产生在于产品经理/系统分析师（以下统一称“产品经理”）对系统进行分析，导出用户的真实需求并文档化供需求方（甲方）及项目组成员阅读理解。从分析、导出-文档化-阅读理解这么几个过程，涉及到不同的角色，需求文档作为各位理解需求的桥梁，常容易出现各种各样的问题。

首先，导出需求就是一个非常困难的过程。主要原因有4点：

1、需求方往往难以陈述清楚他们的需求，也可能陈述的要求并不符合他们真正需要的产品解决方案；

2、需求方特别是跨几个部门的软件需求，需求方提出的相互矛盾的要求，甚至有个别项目，需求来源于需方的某一个人也存在相互矛盾的需求；

3、产品经理很难设想出新的工作方法或流程以符合他们未来理想的要求；

4、有些项目周期比较长，需求方对产品的要求可能会随时间而改变。这些问题导致软件需求的导致非常困难。

其次，在软件需求的文档化也并不是一件容易的事情。在项目中，产品经理常说到隐形需求，将一些没有在文档中描述的要求，都归类为隐形需求。认为这类需求都是常识，不用写成文档程序员（应不仅仅是程序员，还包括用户）也应该要知道。由于每个人的背景、经历都不尽相同，对隐形需求的理解在项目中就各不相同，在实际开发过程中，所谓的隐形需求就成了项目的问题所在。是不是产品经理将隐形需求都显性化就能解决这个问题了呢？软件项目都有时间约束，需求编写同样也有时间约束，显示不可能将所有的隐形需求都显性化。在实际项目执行过程中，一些项目因为产品经理将一些业务逻辑没有描述透彻而当做隐形需求进行处理导致项目延期的现象时有发生。

再次，产品经理对行业的理解偏差及未来发展方向把握不准，导致设计的产品在系统还没有上线前就发生改变。有些业务的调整甚至涉及到系统大范围的调整，形成一个致命的问题。我曾经历的一个项目因对行业的理解不够深入，前期收集到的客户合同管理只需要简单的处理，后来随着开发的深入，系统进行修修补补，最后导致项目模板有100多个，仅合同管理模块的测试工作就达到了40人日以上的工作量。

最后，阅读需求文档的群体由于经验及理解带来的偏差，会导致对同样一段文字存在不一致的理解。这只能说我过的文字博大精深，一句话不同的人解读不尽相同。

由于上述几方面原因导致软件需求文档化存在各种各样的困境，在一些项目中产品经理和程序员是矛盾最尖锐的2个群体。如果解决这个问题？在明天的话题中我们一起来探讨如果编制好一份优质的需求文档。