需求分析的重要性，笔者相信已经深入人心。如何做好需求调研，大家说起来也已经一套一套了。笔者这里从另一个层面来谈谈需求分析，即如何来判断你需求是否可以过关。笔者试图通过三个问题，来检验你需求分析的质量是否可以站得住脚。
问题一：需求是否已经考虑到了所有的应用场景？
CIO在需求调研时，务必要根据企业的实际情况来进行需求的描述。也就是说，在需求报告中，不要只简单的描述用户所需要达到的结果，而是还要定义清楚实际的应用场景，而且要全面。因为往往不同的应用场景会导致不同的解决方案。
如CIO通过调查发现，员工需要根据销售订单来对物料进行追踪。也就是说，员工希望能够在系统中看到，某帐销售订单是否已经下了采购订单；采购订单上的预计交期是多少；现在到料的情况如何，等等。
这个需求描述是否够详细了呢？笔者以前认为，这已经非常的详细。因为我把我们需要什么样的结果都一一列举出来。但是，随着几年CIO工作下来，现在再回头看看，才发现这个需求描述很难过关。因为其虽然描述了我们所需要达到的目标，但是，他没有反应出企业的实际应用场景。笔者认为，在这个需求描述中，我们至少还需要说明如下问题。
一是当企业正常下采购订单，即从销售订单生成采购订单，然后再从采购订单生成收货单。在这种应用场景下，那么该如何来收集统计这一连串的信息。因为他们彼此之间是前后有关联的，实现起来比较方便。
二是若企业存在手工下订单的情况，该如何来显示这个关联特性。如企业在维护采购订单的时候，因为不小心把某张采购订单删除了；后来又手工补了一张采购订单。此时，手工补的采购订单与销售订单就会失去联系。根据销售订单就无法追踪到这种采购订单的信息。CIO在收集需求的时候，也要把这种情况反馈给软件实施顾问或者程序员，让其能够预先找到措施来应对这个问题。其实，只需要在采购订单单头设立一个字段。当用户手工开立采购订单的时候，去关联销售订单即可。实现起来很发现。但是，若CIO不把这个企业会实际碰到的情况告诉给他人的话，则他们就不会寻找可行的解决方案。那么当企业实际遇到这个问题时，企业就束手无策了。
三是是否会存在不下采购订单的情况。如可能某个物料有库存，所以系统在考虑物料需求计划的时候，就没有考虑到这个物料。所以，在生成采购订单的时候，当然也不会把这个物料考虑进去。此时，就会引发另外一个问题。因为根据上面的需求描述，这个需求是按照销售订单、采购订单、物料收货单这个链条下去的。若没有采购订单的话，这个中间的链条就断裂了。那么当用户去查询的时候，就会有这个疑问：为什么没有这个物料呢？是否是采购忘记下采购订单了呢？不少企业出于安全生产的需要，往往会备有安全库存。当安全库存没有降低到采购点的话，则就不会发采购订单。CIO在需求分析的时候，若没有把这个应用情景描述出来，则这个需求分析仍然是不健全的。到时候程序开发人员设计的解决方案，仍然不能够涵盖企业所有的应用场景。
所以，除非CIO能够拍拍胸脯自信的说，所有已知的应用场景都已经在需求描述中一一列举出来。否则的话，笔者劝各位CIO，还是暂时不要把这份需求报告拿出来丢人现眼为好。
问题二：需求描述会给其它人带来歧义吗？
若CIO收集的需求描述，给不同的人看会有不同的结论，那么这个需求描述就不会有多大的实用价值。或者说，这些需求分析还是不要做的好。因为此时别人若按照你的需求描述去编写解决方案，那么反而是在做无用功。
那该如何减少这个需求描述所带来的歧义呢？笔者认为，各位CIO，可以借鉴以下的做法。
一是尽量从用户的角度来考虑问题。当我们从用户
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
