需求分析中的用户识别与调查

《需求分析中的用户识别与调查》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、需求分析中的用户识别与调查

2、第1.lunwen1.需求来自于用户，不论是用什么方法，首先应是找到我们需要访问的对象，然后对对象进行分类，再逐步对对象进行访问。具体访问过程中可以针对不同的访问对象采用不同的方法，根据访问的内容进行确定。本文要讨论的是，如何确定我们的访问对象，以及如何对确定用户对象进行调查。讨论的前提条件是针对用户的需要进行的系统开发，或针对用户的需要进行的定置，而不是仅仅将我们已经成型的产品推销给用户。这样就会面临两种情况，一种是我们可能对这个系统有一定的背景，有一定的开发经验，有不少相关的成功案例，但面对的用户实际上却是一个全新的用户，该用户的要求可能是

3、全新，仅管从管理上讲，该系统的管理实质是一致的，但却许多细微的区别，让我们不能照搬以前的需求与设计，这就要求我们重新访问用户；第二种情况是我们根本对所需开发的系统的行业知识一点也不了解，需要从头认识与理解。无论是哪种情况，我们都要按照以下步骤来慢慢的完成我们的用户需求分析工作。第一步是找出系统的未来推进者。通过与用户开发任务的提出者进行初步确认，由用户任务提出者指出我们所要开发的系统的最直接用户，或者说是系统的职能管理者，该用户也是未来的系统推进者。只有得到该用户的认可，未来的系统的推行，才能得到他的积极支持与推进。第二步是把握系统的整体流程。通过对系统的推进者的访问，我

4、们将能知道他的前面用户将向他提供什么信息，并完成哪些处理，信息到了他这里之后，他要做哪些处理，还要提交给另外哪些用户进行处理或访问，他所处理的这些内容，目的是什么，在管理中起什么作用，应该产生什么的管理绩效，有哪些量化的东西加以评价。通过这些问题的确认，我们会基本上形成系统的总体认识，整个系统经过了多少步骤，每个步骤都由谁来完成，应做哪些操作，形成哪些报表，通过整理，形成初步的系统模型。第三步找出真正的用户。这里所讲的真正用户也要分开谈，一种是指系统的直接用户，另一种指系统的最终用户，即服务对象。我们这里首先要找直接用户，通过直接用户找到最终用户。需要注意的是，因为所站的

5、角度不一样，可能最终的用户也不一样。如开发物资管理系统，直接用户是指参与物资管理系统使用的所有用户；但最终用户可能是财务人员，也可能是计划人员，甚至可能是公司经营老总。正因为如此，我们在确定需求分析的对象时，就要站在不同的角度对系统进行分析，以确定各种对象的需求。当然需求提出来以后，并不一定都要实现，可以根据用户的需要进行取舍，但这种全面的对系统进行认识与理解，有助于我们整体把握所要开发的系统在企业各项工作中的地位与相互之间的关系，从而为系统的接口与升级留有余地。第四步掌握一手资料。在经过与管理者的交流，建立初步印象以后，再与各个用户进行交流，我们所记录与整理的内容是否真

6、实反映了用户所说的内容或意思，以及他们对系统实现过程中所期望能带来的改进，这一点很重要，因为只有他们最在意一些操作的可行性与实用性要求，而领导者与管理者更重视总体的功能需求。要尽可能的访问到每一个用户，如果不允许，也要保证所访问的用户具有权威性性与典型性。第五步协助用户进行流程重组。收集好用户的各种需求与意见后，接下来，我们再与该项业务的主管人员进行交流，对我们在访问过程中，各级用户对系统提出的改进，或者说是感到不顺的地方加以澄清，并提出我们以往针对类似情况的处理案例以供决策。某种程度上讲，这是一个协助用户进行管理流程标准化或说是管理流程重组的过程（BPR）。这样的过程，

7、看起来是增加了开发商的工作量，而且对开发商而言似乎未增加任何价值。但这个过程是值得的。用户希望利用信息系统的目的，有些用户是明确的，有些用户不明确，无论是什么情况，内心里都有这样一个想法，利用信息系统提高企业的管理效率，通过信息共享、提高效率等手段，来降低成本，实现企业竞争力提高的目的。因此，既然他们存在需要改进的地方，而且表达过了，如果此时不加以改进，未来也会进行改进，这种过程如果发生在我们系统开发的过程中，势必还会需要我们对系统的开发进行调整，以便能实现他们所提出来的新功能，也许我们可以说时间不允许加以推托，或通过价格来阻止这种情况的发生，但都会引起用户的不满意，这对

8、开发者来说就是利益的损失。从这种意义上讲，尽可能的避免损失就是尽可能的创造效益。第六步正确理解需求列表。通过需求分析，最终我们会形成需求文档，文档最重要的内容就是需求列表，这表示我们未来所开发的系统应该实现的功能。不过我们对此要有正确的理解，虽然在系统开发中不提倡开发人员自作主张对系统增加功能，但因为见识的面不同，可以用户一时未看到过的东西，在我们其他的项目早就实现过了，这一类情况我们要注意合理的取舍，以通过与用户交流即时的确定是否需要。另外，不能认为用户在需求文档上签过字了，以后有一点改动，都需要再行签字。要知道，有些企业的