今天新项目过来，还没有正式立项，只是大致做好了需求分析，只有一份材料《需求规格说明书》以及一位甲方的陪伴，以供对需求不懂时随时提问。

面对着并不详尽的《需求规格说明书》，怎么设计我们这个系统，我心中一片困惑。

一看到这个业务需求，我还是本能的思考具体的技术实现，当然我不介意我这么做，因为我觉得这是必须的，这对于掌控整体的技术架构是非常有好处的。

但是我担心的是，甲方以及项目经理需要一个过程，从业务需求一步步转化为设计、代码的过程，这个文档是这个项目立项、拍板的支持，也有可能是中标的保证，这个过程该怎么做。

项目很多，如何“扒”一个新项目，面对一个未知的项目领域如何全面、有效的分析，并得出结论是急需掌握的，我意识到这也是成长中很重要的一步，这方面的人才也是公司急切需要的。

（另一主线是某些技术领域的专业性，两手都要抓，两手都要硬）。

关键词：项目管理, 项目立项,业务分析, Enterprise Architect, EA

摘要：今天新项目过来，面对一个未知的项目领域，如何全面、有效的分析，如何从业务需求一步步转化为设计、代码，这个能力是急需掌握的，下面以一个简单的“数据管理和查询项目”为示例，来介绍一个项目的具体业务分析流程，其中所有的图如有引用，请标明来源。http://www.cnblogs.com/wgp13x/p/3824964.html

第一步：总结出业务目标。

从用户的角度来考虑这个项目，体会这个项目能为用户做到什么、带来什么，抛却是什么实现的，甚至都不需要用户知道有计算机帮助他完成这些业务。

这里要总结成书面的形式，一条一条的列在文档中。比如，“数据管理和查询项目”可以提炼出这么一条业务目标：

要实现多种类型数据的统一管理和查询，为用户提供方便快捷的数据查询界面，提高用户对人、事、物等数据的全面掌控能力；

第二步：划分业务边界。

根据业务目标，来划分业务边界，可以一条对一个边界，也可以不对应的来，后期也可以适当调整。

在这一步中，还需要进行涉众分析，从用户的角度来看，我要跟哪些部门打交道，记录下来。

第三步：进行业务分析。

进行业务分析，又分成三步，a、针对某一业务边界的业务主角的确定，b、针对某一业务边界的业务用例分析，c、针对某一业务边界的业务用例实现。

a、

针对某一业务边界的业务主角的确定，业务主角是某一业务的发起者，也是承受者，也可能是使用者，就是有哪些用户来使用这个项目。

b、

针对某一业务边界的业务用例分析，将上面那些步骤中划分出的涉众、业务主角，它们在某一业务执行过程中（可以在某一业务边界中细分业务），是如何进行交流的，分析出来，画出泳道图。

下面是各个细分业务。

下面是查询A系统的业务用例的泳道图，它讲述了具体的交互流程。

到这里还是没有涉及到计算机这类概念，仍然完全是从用户的角度来考虑这些问题。

c、

针对某一业务边界的业务用例实现，这里可以涉及计算机，计算机作为我们这个系统能为用户做什么事情，以及如何跟涉众、业务主角进行交互的，在这一步需要详细列出。

下面是查询A系统数据业务用例实现的泳道图。

以上步骤下来，就能够把所有的需求理解清楚了，我们这个项目能做什么，怎么跟外部交互的都能够解释的清清楚楚。

下面还有系统分析（系统用例实现）、概要设计、详细设计等各个阶段。

具体的扒项目的过程，请关注后续总结。

来自王安琪http://www.cnblogs.com/wgp13x/p/3824964.html

“扒项目”的历程一(业务分析)