需求来自于用户，不论是用什么方法，首先应是找到我们需要访问的对象，然后对对象进行分类，再逐步对对象进行访问。具体访问过程中可以针对不同的访问对象采用不同的方法，根据访问的内容进行确定。本文要讨论的是，如何确定我们的访问对象，以及如何对确定用户对象进行调查。
讨论的前提条件是针对用户的需要进行的系统开发，或针对用户的需要进行的定置，而不是仅仅将我们已经成型的产品推销给用户。
这样就会面临两种情况，一种是我们可能对这个系统有一定的背景，有一定的开发经验，有不少相关的成功案例，但面对的用户实际上却是一个全新的用户，该用户的要求可能是全新，仅管从治理上讲，该系统的治理实质是一致的，但却许多细微的区别，让我们不能照搬以前的需求与设计，这就要求我们重新访问用户；第二种情况是我们根本对所需开发的系统的行业知识一点也不了解，需要从头熟悉与理解。无论是哪种情况，我们都要按照以下步骤来慢慢的完成我们的用户需求分析工作。
第一步是找出系统的未来推进者。通过与用户开发任务的提出者进行初步确认，由用户任务提出者指出我们所要开发的系统的最直接用户，或者说是系统的职能治理者，该用户也是未来的系统推进者。只有得到该用户的认可，未来的系统的推行，才能得到他的积极支持与推进。
第二步是把握系统的整体流程。通过对系统的推进者的访问，我们将能知道他的前面用户将向他提供什么信息，并完成哪些处理，信息到了他这里之后，他要做哪些处理，还要提交给另外哪些用户进行处理或访问，他所处理的这些内容，目的是什么，在治理中起什么作用，应该产生什么的治理绩效，有哪些量化的东西加以评价。通过这些问题的确认，我们会基本上形成系统的总体熟悉，整个系统经过了多少步骤，每个步骤都由谁来完成，应做哪些操作，形成哪些报表，通过整理，形成初步的系统模型。
第三步找出真正的用户。这里所讲的真正用户也要分开谈，一种是指系统的直接用户，另一种指系统的最终用户，即服务对象。我们这里首先要找直接用户，通过直接用户找到最终用户。需要注重的是，因为所站的角度不一样，可能最终的用户也不一样。如开发物资治理系统，直接用户是指参与物资治理系统使用的所有用户；但最终用户可能是财务人员，也可能是计划人员，甚至可能是公司经营老总。正因为如此，我们在确定需求分析的对象时，就要站在不同的角度对系统进行分析，以确定各种对象的需求。当然需求提出来以后，并不一定都要实现，可以根据用户的需要进行取舍，但这种全面的对系统进行熟悉与理解，有助于我们整体把握所要开发的系统在企业各项工作中的地位与相互之间的关系，从而为系统的接口与升级留有余地。
第四步把握一手资料。在经过与治理者的交流，建立初步印象以后，再与各个用户进行交流，我们所记录与整理的内容是否真实反映了用户所说的内容或意思，以及他们对系统实现过程中所期望能带来的改进，这一点很重要，因为只有他们最在意一些操作的可行性与实用性要求，而领导者与治理者更重视总体的功能需求。要尽可能的访问到每一个用户，假如不答应，也要保证所访问的用户具有权威性性与典型性。
第五步协助用户进行流程重组。收集好用户的各种需求与意见后，接下来，我们再与该项业务的主管人员进行交流，对我们在访问过程中，各级用户对系统提出的改进，或者说是感到不顺的地方加以澄清，并提出我们以往针对类似情况的处理案例以供决策。某种程度上讲，这是一个协助用户进行治理流程标准化或说是治理流程重组的过程（BPR）。这样的过程，看起来是增加了开发商的工作量，而且对开发商而言似乎未增加任何价值。但这个过程是值得的。用户希望利用信息系统的目的，有些用户是明确的，有些用户不明确，无论是什么情况，内心里都有这样一个想法，利用信息系统提高企业的治理效率，通过信息共享、提高效率等手段，来降低成本，实现企业竞争力提高的目的。因此，既然他们存在需要改进的地方，而且表达过了，假如此时不加以改进，未来也会进行改进，这种过程假如发生在我们系统开发的过程中，势必还会需要我们对系统的开发进行调整，以便能实现他们所提出来的新功能，也许我们可以说时间不答应加以推托，或通过价格来阻止这种情况的发生，但都会引起用户的不满足，这对开发者来说就是利益的损失。从这种意义上讲，尽可能的避免损失就是尽可能的创造效益。
第六步正确理解需求列表。通过需求分析，最终我们会形成需求文档，文档最重要的内容就是需求列表，这表示我们未来所开发的系统应该实现的功能。不过我们对此要有正确的理解，虽然在系统开发中不提倡开发人员自作主张对系统增加功能，但因为见识的面不同，可以用户一时未看到过的东西，在我们其他的项目早就实现过了，这一类情况我们要注重合理的取舍，以通过与用户交流即时的确定是否需要。另外，不能认为用户在需求文档上签过字了，以后有一点改动，都需要再行签字。要知道，有些企业的治理人员，当时熟悉上确实有不足的地方，后来发现了，假如你现在不让他改，对他要求这么严，他为了顾全面子，不作修改，将来使用以后，尽说你的系统的坏话，或专挑毛病，非搞死你不可。总之，在不影响到系统的根基的情况下，或者说对系统的开发成本没有太大的影响的情况下，应该尽可能的让用户在开发完成之前提出任何功能的变更需求，这是没办法的办法，这显然与开发的理论文章的说法不一致，但却是非常实在的一种做法。
需求分析是一门学问，不仅要把握需求分析的相关工具应用，还要把握人际交往的技巧，还要善于演讲，懂得治理的艺术，并且能综合运用这些知识。因此一个系统分析员，一个好的系统分析员真的很难做，至少比系分考试的东西要难得多。这里讲了一些实际工作中碰到的问题，以及我们的经验之谈，当然实际工作，可能因为面对的人不一样，所要处理的问题也不一样，但有一点没变，即需求面对的人，而不仅仅是事，只有明白这一点，才能成为用户的朋友，做好我们的需求分析工作。
