我们将从客户调研现场拿回来的需求，经过一番功能角色分析，整个系统的整体脉络与轮廓已经被勾画出来。在这个过程中，我们首先将系统划分成了几个功能模块（如果系统规模较大，还应先划分为几个子系统，然后再划分出各个功能模块）。然后，我们为每个功能模块绘制用例图。用例图是站在用户角度去观察的系统，即系统为用户提供了哪些功能，这是功能分析。同时，这些功能是为哪些用户服务的，这是角色分析。我们绘制的用例图应当能够为用户所理解，这也是UML其中的一项核心思想——与客户形成统一的、能够相互理解的语言，这对于需求分析过程中与客户的沟通是大有好处的。
　　但形成对系统的整体轮廓，对于软件的需求分析来说是远远不够的。许多软件终失败的非常重要的原因是对需求分析过于草率、浮于表面，而没有深入细致地去分析，往往到了项目后期才把需求搞懂，才发现真正的需求与起初的认识大相径庭，才恍然大悟需求原来是这样，而往往那时已经追悔莫及了。这样的经历相信你也有过吧。所以，我们一定要沉下气来认真仔细地做需求分析，一定要做到位。
　　同样，细化需求也需要一定的方法与思路。一般来说，我们可以有两个方向细化需求：业务流程分析与业务领域分析。这里，我们先谈谈业务流程分析吧。
　　如果我们现在做的需求分析是一个企业信息化管理系统，毫不疑问，我们的软件系统是在模拟企业已有的那些业务流程。在现实世界中，企业是按照怎样的流程来管理，我们的软件应当去模拟这样的流程。但是，我们的软件不可能也不必要完全去模拟这样的流程，在这个流程中的有些环节是应当由软件去模拟的，但有些环节则是应当在系统之外，由人工去完成的。我们进行流程分析，是要求分析哪些是系统之内的，哪些是系统之外的。
　　我曾经做过一个疑点信息库系统。该系统模拟的原有业务流程是这样的：高层纪检方面的领导通过信访、举报、数据查询分析等方式发现了一批问题，然后将这批问题制作成一套调查清册，亲自或者交由下级相关单位，下到基层去调查问题。直到调查工作完成以后，才从基层回到自己单位，填写调查工作底稿，详细描述调查情况，并结束调查工作。
　　首先，我们应当抛开软件实现，对这样一个流程进行梳理，形成这样一个步骤：
　　1. 高层领导通过信访、举报、数据查询分析等方式发现一批问题；
　　2. 将这批问题制作成一个调查清册；
　　3. 自查或将清册下派给下级去调查；
　　4. 下到基层执行调查；
　　5. 从基层回到自己的单位，填写调查工作底稿，详细描述调查情况，并结束调查工作。
　　然后，在对原始需求分析的基础上，分析我们的软件能做什么事：
　　第一步：信访和举报虽然有自己的操作流程，但那些都在这个系统之外，在这个系统中仅仅只需录入后的结果。数据查询分析过去只是业务人员在相关业务系统中根据自己的经验执行各种查询，现在则可以上一套数据采集和分析系统，提高数据分析的质量。
　　第二步：形成调查清册，可以在系统中设计一个功能实现。
　　第三步：自查或下派，可以在系统中设计一个流程实现。
　　第四步：下到基层执行调查，由于网络条件等因素的限制，业务人员不可能也不必要在系统中去完成调查，只需要执行一个标志调查工作开始的操作，并打印或导出调查清册，然后去基层调查。终，这部分被设计成一个“开始实地核查”的操作，并提供打印导出功能。
　　第五步：调查人员从基层回到自己的单位都是系统外的事情，而填写调查工作底稿，详细描述调查情况，并结束调查工作，则是系统内的功能。终，这部分被设计成一个“调查完结”功能，标志调查工作结束，并提供工作底稿的填写功能。
　　计算机信息化管理并不是的，它并不能代替现实世界中的所有工作。因此，我们进行业务流程分析，是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。信息化管理过细，无疑会加重基层业务人员的负担（这也正是为什么许多基层业务人员会排斥信息化系统的原因），而适当的信息化管理则可以提高工作效率。试想一下，如果你工作中的每一个步骤都必须在计算机中操作一下，怎么不让人烦呢？而如果在工作中一旦需要先查一个什么信息，或者需要计算一下，系统立即可以替你完成这些工作，或者那些过去基本靠吼的操作，现在立马通过信息化传递过去了，怎么不让人舒心呢？我们做信息化管理，不是要加重人的负担，而应是降低人的负担。以这样的思路去进行流程分析才能设计出的、人见人爱的管理系统出来。因此，我做需求分析，喜欢下到基层去了解基层业务人员的需求，去分析怎样设计流程才能提高他们的工作效率，而避免加重他们的负担。“水能载舟，也能覆舟。”一套系统是否能顺利推行下去，基层人员是否支持往往起到十分重要的作用。