在经过与管理者的交流，建立初步印象以后，再与各个用户进行交流，我们所记录与整理的内容是否真实反映了用户所说的内容或意思，以及他们对系统实现过程中所期望能带来的改进，这一点很重要，因为只有他们最在意一些操作的可行性与实用性要求，而领导者与管理者更重视总体的功能需求。要尽可能的访问到每一个用户，如果不允许，也要保证所访问的用户具有权威性性与典型性。

    第五步协助用户进行流程重组。

    收集好用户的各种需求与意见后，接下来，我们再与该项业务的主管人员进行交流，对我们在访问过程中，各级用户对系统提出的改进，或者说是感到不顺的地方加以澄清，并提出我们以往针对类似情况的处理案例以供决策。某种程度上讲，这是一个协助用户进行管理流程标准化或说是管理流程重组的过程（BPR）。这样的过程，看起来是增加了开发商的工作量，而且对开发商而言似乎未增加任何价值。但这个过程是值得的。用户希望利用信息系统的目的，有些用户是明确的，有些用户不明确，无论是什么情况，内心里都有这样一个想法，利用信息系统提高企业的管理效率，通过信息共享、提高效率等手段，来降低成本，实现企业竞争力提高的目的。因此，既然他们存在需要改进的地方，而且表达过了，如果此时不加以改进，未来也会进行改进，这种过程如果发生在我们系统开发的过程中，势必还会需要我们对系统的开发进行调整，以便能实现他们所提出来的新功能，也许我们可以说时间不允许加以推托，或通过价格来阻止这种情况的发生，但都会引起用户的不满意，这对开发者来说就是利益的损失。从这种意义上讲，尽可能的避免损失就是尽可能的创造效益。

    第六步正确理解需求列表。

    通过需求分析，最终我们会形成需求文档，文档最重要的内容就是需求列表，这表示我们未来所开发的系统应该实现的功能。不过我们对此要有正确的理解，虽然在系统开发中不提倡开发人员自作主张对系统增加功能，但因为见识的面不同，可以用户一时未看到过的东西，在我们其他的项目早就实现过了，这一类情况我们要注意合理的取舍，以通过与用户交流即时的确定是否需要。另外，不能认为用户在需求文档上签过字了，以后有一点改动，都需要再行签字。要知道，有些企业的管理人员，当时认识上确实有不足的地方，后来发现了，如果你现在不让他改，对他要求这么严，他为了顾全面子，不作修改，将来使用以后，尽说你的系统的坏话，或专挑毛病，非搞死你不可。总之，在不影响到系统的根基的情况下，或者说对系统的开发成本没有太大的影响的情况下，应该尽可能的让用户在开发完成之前提出任何功能的变更需求，这是没办法的办法，这显然与开发的理论文章的说法不一致，但却是非常实在的一种做法。

    需求分析是一门学问，不仅要掌握需求分析的相关工具应用，还要掌握人际交往的技巧，还要善于演讲，懂得管理的艺术，并且能综合运用这些知识。因此一个系统分析员，一个好的系统分析员真的很难做，至少比系分考试的东西要难得多。

    这里讲了一些实际工作中碰到的问题，以及我们的经验之谈，当然实际工作，可能因为面对的人不一样，所要处理的问题也不一样，但有一点没变，即需求面对的人，而不仅仅是事，只有明白这一点，才能成为用户的朋友，做好我们的需求分析工作。

【责编:Luzi】