首先，我们应该明确进行需求分析的目的。我认为，进行业务需求分析的直接目的就是为了进行信息系统的开发，所谓的需求，就是信息系统建设的需求。如果一个业务不需要信息系统就能有效开展，就不需要进行需求分析，直接开展业务就行。进行需求分析，是为开发信息系统服务。是为了让系统开发者明白，需要开发一个怎样的信息系统。如，需要什么样的功能，有什么样的输入输出，有什么样的交互界面，业务处理的规则是什么等等。当然，在需求分析过程中，有可能使得业务人员更加清晰其原来对业务的考虑，进而对其业务进行重新定义。但归根结底，进行业务需求分析还是为了开发出一个信息系统，支持业务的开展。
其次，我们要问，怎样进行业务需求分析，才能有效地表达需求。所谓的有效地表达需求，就是让业务部门知道，他的业务得到了准确而完整的描述，让系统开发部门也明白，看得懂关于业务的描述，从而让技术人员能够开发出符合业务开展需要的信息系统。这是一个很专业的工作。而从事需求分析的人员，必须精通业务和技术两头的工作。否则无法起到一个桥梁的作用，帮助企业把信息系统建立起来，推动业务的发展。他的产出，一定是业务和技术两方面都能看得懂的。产出只有一方能看的懂的东西，不叫业务需求。做业务需求，好比一个翻译器，把业务人员描述的东西，翻译成技术人员能看得动的东西。就好像把英语翻译成汉语一样。如果翻译官的水平不高，翻译的效果可能就会大打折扣。就会出现把Mr Green翻译成绿色先生的情况。
为了能做出有效的业务需求，可以通过一些约定好的方法来进行。通过这些约定好的方法，开发出业务需求产出物。技术人员就能大致地知道想要建立一个什么样的系统。业务部门也知道，他的业务会不会被系统有效地支持。由此，这个约定的，制作业务需求的方法，就很关键。从计算机系统被研制出来到今天，已经产生了很多方法和体系，对于不同的企业，其方法和体系也不尽相同。但都不排除一些共性。做业务需求，首先就得明确一个大家都知道的方法，否则容易产生混乱。如果你这边讲活动，我那讲用例，就无法高效地建立信息系统，支持业务发展了。
本文简要讨论一下，根据工作经验总结出的一个支持需求开发的方法。其实，一篇文章不足以完整描述一套业务需求方法。在此只是基于一个已开发出的企业架构管理系统做一个介绍。说是企业架构管理系统，其实就是一个需求描述和分析的系统。把做业务需求的方法固化到了系统中。通过一个独立的信息系统（工具）来管理（或者说建立）一个具有复杂业务的企业的业务需求，以支持开发整个企业所需要的信息系统。
对于一个如银行这样的大型企业，仅仅靠传统的需求文档，已经很难支持其高效地开发完整的信息系统。所以必须有工具来支持。其实市场上早已有了若干需求管理工具，但是大多数都只是把传统的需求分析文档电子化，然后分了个类。不足以动态支持从需求分析到系统设计的整个过程。我们开发的这个企业架构管理系统，正是基于曾经经历的信息系统建设的经验，把企业建立信息系统的从需求描述到系统设计整个过程进行有效的支持。所有的工作件都得到动态的展示，然后还能有效地分析和管理，十分明确地知道业务是否得到了完整有效描述，系统设计是不是完全支持了业务开展的需要。而不是需要人工去看文档才知道。
我们一开始就需要明确地是，大家约定了什么方法来描述业务需求。这个约定的方法，可以叫做企业架构元模型，如果只是描述业务部分的，叫业务架构元模型，只是描述技术部分的，叫技术架构元模型。这只是一个大概的分类，从细分的角度，还可以分为，应用架构，数据架构的原模型等。所以这些分类，必须是一个完整的，结构清晰的整体，才能有效支持开发企业需要的信息系统。否则将陷于一片混乱。下图为企业架构元模型的一部份。
从图中可以看到，要开发出一个完整的企业信息系统，就要对其进行完整的描述。描述的要素很多。各要数之间的关系也很复杂。大概很少有人能够把所有的要素及其相互之间的关系都记在大脑里面。因此，依靠专业的信息系统来进行记录和管理就很有必要。他保证了方法和规则的唯一性。尽管每个人对系统的理解可能会不一样，但是至少有一个地方整体地记录了所有的环节。从而尽可能地避免了理解上的歧义。从整体上，描述系统的要素很多，一个人只能掌握其中的一小部分，而由系统来保证了所有人的理解是一致的。这就是企业架构系统的作用所在。
基于企业架构系统，相关业务人员和技术人员在上面开展工作，各自发挥出自己的专长，设计出最好的产出成果。然后开发出企业需要的信息系统。保证企业的业务的发展。由此，企业架构系统的功能，就很关键。
首先，他要能够定义 各种元素 ，用以描述所需要建立的信息系统。比如，我们需要把企业的业务分成各个领域，就要能够在系统上定制出“业务领域”的概念，我们还要定义各种流程，就要在系统上定义“活动”，“任务”，“步骤”，“事件”的概念，为了描述系统本身，我们还需要定义出“业务功能”，“系统用例”，“构件”的概念，如此等等。根据不同的情况，定义不同的概念，这是企业架构系统的一个基本功能。这种功能很多工具都有。
其次，各元素定义好以后，还需要描述各元素之间的关系。上图中所有的连线，就是关系的一种示意。具体的关系的表达，还需要在架构系统内部进行详细的定义。比如我们可以通过列表的形式，来描述各元素之间的关系。一方面是便于使用者进行查阅，一方面是让系统能够根据规则自动进行相互间逻辑的检查，从而保证了一致性。
对于大部分人来说，不会关心系统所有的方面，对于业务专家，他只关心业务逻辑是什么样的，甚至他只关心其所涉及的领域的业务逻辑，比如风险专家只关心风险模型。资产负债管理专家关心资金转移定价。而应用架构专家关心交易线，数据专家只关心数据模型，系统设计人员关心有哪些构件、接口、工作流，项目管理专家只关心项目进展，而企业高管，只关心有哪些业务组件 等等。因此，架构系统需要根据不同的人群建立不同的视图，只展现其所关心的那部分工作内容，而不是把所有的信息全部都展现给他，否则会产生干扰和信息冗余。当然，也会存在那种关心所有要素的人员，要么确实在信息系统建设方面很资深，要么就是好奇打酱油的。本人虽然一直关心所有的要素，但至今也没能够把所有的要素和关系理清晰。不过在架构系统的帮助下，整体功能一定会井然有序。
把所有元素和关系表达清楚，仍然不能保证信息的完整性，因为你不知道他所表达的业务的逻辑对还是不对。靠眼睛看能解决一部分问题，但毕竟有限。如果等系统建设好了才发现逻辑错误，或者在系统开发过程中发现错误，耽误的功夫就比较大了。因此，我们在需求分析阶段，就希望知道业务需求提供的信息是否是充分和必要的。为此，架构系统提供了一个模拟仿真功能。用报表，流程引擎，规则引擎的方式方法，把目标系统模拟地运行分析一遍，看看哪个环节出会出问题。最终形成一个完整的经过严格验证的图纸。这样业务人员能很直观地知道为他所设计的系统是什么样，技术人员也很放心地明白他所拿到的开发需求是经过了严格验证的。
定义元素，定义关系，建立视图，模拟仿真，是架构系统的几个核心功能，根据这些功能，就能开发出业务需求，支持业务信息系统的建设。此外还有系统管理，版本管理，用户管理，报表功能等一些通用功能。
通过架构系统，我们能够有效地进行业务的描述，分析，仿真，系统的设计等工作。以保证信息系统建设的成功。当然，关键的因素，还是人的因素。系统是起到一个帮助的作用，人的智慧的发挥，才是最重要的，不用心去做，再好的系统也是屠龙刀而已。