那边把需求收集过来，然后需要利用自己的语言来对问题进行描述。若在这个描述的过程中，CIO站在自己的角度去思考，则往往会引起一些不必要的歧义。笔者认为，CIO在整理需求的时候，最好能够站在用户的角度去思考问题。同时，需求整理好后，最好能够把自己整理的需求再让用户去确认一遍。让他们审核一下，看看书面需求分析与他们的想法是否有出入。
　　二是在需求描述中，最好能够配有实际案例。有时候，有些需求确实很难描述清楚。或者因为语言组织的不好，以及文化、工作背景的不同，不同的人看需求报告确实会产生不同的理解。为此，笔者认为，最好能够在需求中配上具体的案例。通过案例描述来把需求认识的歧义降至到最低。如当CIO描述“销售订单来对物料进行追踪”这个需求时，可以配上具体的案例。例如企业有一张销售订单，分别生成四张采购订单，需要购买A、B、C、D四个物料。其中，A物料因为仓库中有库存，所以采购没有下采购订单。而第二张采购订单因为采购人员操作不小心删除了，其后来手工补了一张采购订单。C物料一半用库存，一半采购。D物料后来利用其他物料来代替。把企业用户碰到的实际情况一一利用案例描述出来。如此的话，无论是谁，看到这个案例也就明白了需求中具体描述了什么内容。很明显，通过这个案例描述可以在很大程度上消除CIO与程序员或者外部实施顾问认识上的分歧。
　　所以，笔者建议，CIO在巴自己的需求报告拿给别人看的时候，先要扪心自问，看看这份需求报告会不会十个人看得出十个不同的结果。若不幸真的是如此的话，那么CIO就应该想出一些可行的措施，把这个歧义降低到最低。
　　问题三：是否详细定义了可靠性？
　　在考虑需求分析报告是否可以过关的时候，还需要考虑一个问题，就是要衡量一下这个需求的可靠性问题。如这个需求执行过程中会不会失败，以及失败会否给其他业务带来什么样的不利后果。同时，当失败时系统以何种形式来告知管理员这个失败的结果，等等。
　　如仍然是上面这个需求。现在在根据销售订单生成采购订单的时候，由于一些原因可能销售订单无法按物料清单展开而正确生成采购订单。如可能系统中某个物料有库存，所以某个物料就没有发生采购；又如可能某个原材料没有定义供应商，所以系统无法为这个供应商生成采购订单等等。
　　CIO在需求分析的时候，应该预见这些情况可能会发生。那么，CIO就需要从程序的可靠性出发，想出一些应对的措施。如因为有库存而没有下采购订单，这是属于正常的作业。但是，此时系统应该以某种形式来告知用户这种情况。如在生成采购单的时候通过日志信息记录等等都是可以的。而因为没有定义供应商而导致采购订单无法下达，此时，就需要系统通过非常明显的方式告知企业用户因为什么什么原因而导致采购订单无法下达。总之，当因为一些意外情况，导致某个流程被意外中断时，无论是合法的还是不合法的，系统都要能过以明文的形式告知用户。否则的话，根据这个需求开发的解决方案的可靠性就会受到质疑。
　　同时，这个提示信息业要尽量的让人看的明白。如笔者发现有些系统在设计上确实也考虑到了这个可靠性问题，但是他们没有更进一步，让用户头疼不已。如因为没有供应商而导致无法正常生成采购订单的时候，系统只提示“采购订单无法生成”。即没有告诉用户因为什么原因导致采购订单无法生成；同时也没有告诉用户哪些原材料无法生成采购订单。如此的话，用户就需要从头开始去查找错误的原因。其实，到底为什么无法生成采购订单的原因，在后台程序判断中都会有所体现。只需要用户把判断的参数，如某个编号的零件供应商ID为空等等信息反馈到前台。那么系统管理人员凭借这条信息就可以非常容易的定位错误信息。并在最短时间内把问题解决掉。
　　所以笔者认为，CIO在做需求分析的时候，除了要做好具体的需求描述之外，最好还要从这个可靠性出发，考虑发生意外事故时所需要传递的故障信息、错误检测以及恢复策略等等。并且，这些信息要能够帮助用户迅速定位并且解决问题。即要反映出问题发生的原因而不能够只是结果。

    项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~

    http://www.leadge.com/pmqhd/index.html