在进行软件开发需求分析时，第一个工作就是让软件公司整理现有的跟软件开发有关的流程。通常情况下，有条件上软件开发项目的软件公司，在管理上往往有了一定的水准。在软件公司内部，一般都已经有一套比较完善的软件公司管理制度。这其中就包括操作流程。而软件开发系统其本质就是流程驱动的。为此软件公司现有的软件开发管理流程对于我们需求的整理就显得尤其的重要。所以第一件工作就是查看软件公司现有的管理流程。在这个环节中，主要要注意如下内容。

一是流程要细化。有些软件公司虽然已经有了比较书面化的管理流程，但是线条太粗。如笔者以前碰到过一家软件公司，他们已经实施了ISO。通过ISO项目帮助软件公司建立了相关的流程。可惜的是，这些流程的线条很粗。如销售接单就一个流程。实际情况是，销售订单会分为赊销订单、预付款订单等等。根据产品的性质不同，还可以分为新订单和返工订单等等。根据订单性质的不同，后续相关的操作也不同。在软件开发系统中的操作也有所差异。为此在收集客户现有的流程时，要注意对流程的细化。如果客户的流程比较粗，还要求客户根据实际情况，对流程进行细化。这有利于后续系统的配置与调整。

二是流程要与软件公司的实际操作一致。软件公司的实际操作可能不规范，需要在后续工作中进行调整。但是在软件开发需求分析阶段，一定要注意，项目管理员收集起来的流程，要能够反映软件公司用户的实际操作。简单的说，在软件开发需求分析阶段我们并不太过于关心用户的实际操作是否符合规范。我们关心的是用户现在到底是怎么操作的。即使管理很完善的软件公司，用户也不会百分之百的去按照流程来办事。为此在流程收集时，需要向用户多问一句：实际操作跟这个流程有差异吗?如果有差异的话，那么差异在哪里?在这个环节中，不要去一味的责怪用户没有按流程来办事。否则的话，用户很可能不会畅所欲言。

三是流程应该有关键用户过目过。有时候流程是软件公司的稽核部门或者管理部门提供的。虽然他们能够提供比较完整的流程，但是为了后续项目能够顺利开展，项目管理员在这里不能够偷懒。应该拿着这些书面流程，给关键用户进行确认：这是最新的版本呢?这能够反映他们的实际操作吗?这一步确认的动作，其目的也主要是分析软件公司所规定的流程与用户的实际操作之间的差异。因为在软件开发流程重组过程中，可能需要对软件公司现有的流程进行优化与重组。要做这项工作的话，其前提就是要知道软件公司现有的书面流程与实际操作之间的差异以及原因。

在软件开发需求分析时，除了要关注软件公司现有的实际操作之外，笔者认为还应该适度的超前。如果上了软件开发系统之后，软件公司所做的客户关系管理还只是停留在原有的范围，那么即使软件开发项目上线了，也不能够给软件公司带来多大的价值。为此一个负责任的项目管理员，会提醒软件公司，在需求整理时要考虑到未来两三年之内的需求。这对于系统的配置、基础数据的整理等等都有很大的帮助。具体的来说，可以从如下几个方面展开。

一是可以从系统的角度出发，来分析软件公司未来的需求。有过软件开发经验的用户，都会有这方面的感受。有些软件开发管理模型，很难通过手工管理来实现。而需要通过系统的帮助，再加上恰当的管理，才可以发挥效益。对于这些需要依赖于信息化系统才能够实现的需求，在项目过程中需要特别关注。因为以前由于技术方面的限制，用户基本上不会涉及这方面的内容。而以后上了软件开发系统之后，这方面的需求就是顺理成章的事情。这些需求就很可能是软件公司未来所需要的需求。故无论是项目管理员，还是实施顾问，在软件开发需求分析时要同时去关注系统的功能。以判断未来发展的需求。

二是听听关键用户的声音。关键用户往往在软件开发这个领域内具有比较丰富的经验。有些甚至在学校里受过专门的软件开发相关的培训。可能由于种种方面的限制，他们所希望实现的需求难以完成(有些是上面第一点所说的技术上的限制，另外有可能是平时没有决策的权利)。此时这些关键用户正可以凭借软件开发这个项目平台来展示自己的才华。他们会把自己的理论知识转化为实践。他们提出来的需求，就有可能是软件公司未来可能需要实现的内容。不过这里需要注意的是，不要纸上谈兵。虽然这些关键用户受过正规的教育，也了解软件公司的运作，但是有时候仍然会犯教条主义的错误。此时实施顾问就要与这些关键用户进行沟通，以判断这个需求实现的可能性与必要性。

在软件开发需求分析的时候，笔者向来强调书面报告的重要性。其实我们在日常工作中，都会有这方面的经验。当我们提建议时，口头的内容很可能是大脑的第一反应，而没有经过深思熟虑。相反，在会后将口头的内容进行书面化的过程中，会对这个第一反应再次进行消化分析。在这个消化