今天新项目过来，还没有正式立项，只是大致做好了需求分析，只有一份材料《需求规格说明书》以及一位甲方的陪伴，以供对需求不懂时随时提问。
面对着并不详尽的《需求规格说明书》，怎么设计我们这个系统，我心中一片困惑。
一看到这个业务需求，我还是本能的思考具体的技术实现，当然我不介意我这么做，因为我觉得这是必须的，这对于掌控整体的技术架构是非常有好处的。
但是我担心的是，甲方以及项目经理需要一个过程，从业务需求一步步转化为设计、代码的过程，这个文档是这个项目立项、拍板的支持，也有可能是中标的保证，这个过程该怎么做。
项目很多，如何“扒”一个新项目，面对一个未知的项目领域如何全面、有效的分析，并得出结论是急需掌握的，我意识到这也是成长中很重要的一步，这方面的人才也是公司急切需要的。
（另一主线是某些技术领域的专业性，两手都要抓，两手都要硬）。
关键词：项目管理, 项目立项,业务分析, Enterprise Architect, EA
第一步：总结出业务目标。
从用户的角度来考虑这个项目，体会这个项目能为用户做到什么、带来什么，抛却是什么实现的，甚至都不需要用户知道有计算机帮助他完成这些业务。
这里要总结成书面的形式，一条一条的列在文档中。比如，“数据管理和查询项目”可以提炼出这么一条业务目标：
要实现多种类型数据的统一管理和查询，为用户提供方便快捷的数据查询界面，提高用户对人、事、物等数据的全面掌控能力；
第二步：划分业务边界。
根据业务目标，来划分业务边界，可以一条对一个边界，也可以不对应的来，后期也可以适当调整。
在这一步中，还需要进行涉众分析，从用户的角度来看，我要跟哪些部门打交道，记录下来。
第三步：进行业务分析。
进行业务分析，又分成三步，a、针对某一业务边界的业务主角的确定，b、针对某一业务边界的业务用例分析，c、针对某一业务边界的业务用例实现。
a、
针对某一业务边界的业务主角的确定，业务主角是某一业务的发起者，也是承受者，也可能是使用者，就是有哪些用户来使用这个项目。
b、
针对某一业务边界的业务用例分析，将上面那些步骤中划分出的涉众、业务主角，它们在某一业务执行过程中（可以在某一业务边界中细分业务），是如何进行交流的，分析出来，画出泳道图。
下面是各个细分业务。
下面是查询A系统的业务用例的泳道图，它讲述了具体的交互流程。
到这里还是没有涉及到计算机这类概念，仍然完全是从用户的角度来考虑这些问题。
c、
针对某一业务边界的业务用例实现，这里可以涉及计算机，计算机作为我们这个系统能为用户做什么事情，以及如何跟涉众、业务主角进行交互的，在这一步需要详细列出。
下面是查询A系统数据业务用例实现的泳道图。
以上步骤下来，就能够把所有的需求理解清楚了，我们这个项目能做什么，怎么跟外部交互的都能够解释的清清楚楚。
下面还有系统分析（系统用例实现）、概要设计、详细设计等各个阶段。
具体的扒项目的过程，请关注后续总结。
“扒项目”的历程一(业务分析),布布扣,bubuko.com
“扒项目”的历程一(业务分析)
原文：http://www.cnblogs.com/wgp13x/p/3824964.html
