我们应当怎样做需求分析：业务领域分析

在需求分析工作中，最后一项分析工作就是业务领域分析啦。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。前面我们谈到了功能角色分析，或者说用例分析，它是从整体的角度对整个系统人机交互的分析与整理。随后我们谈到了业务流程分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及组成这些流程的一个个业务操作。业务流程分析是对系统进行的一种动态的分析，分析的是那些行为，那些操作。但是，所有的行为，所有的操作，最终施与的对象都是那些实体。这句话怎么理解呢？比如，我们执行填写操作，施与的对象必然是那些表单，最终产生的结果必然是形成一份完整的表单，表单就是那个行为施与的对象。再比如，我们执行查询操作，施与的对象必然是一个报表，最终产生的结果必然是查看到了这个报表的结果。这里的表单、报表，都是存在于系统的静态实体，它们中的大多数也最终以数据结构的形式持久化保存于系统的数据库中。因此，系统中应当有哪些实体，这些实体都有哪些属性，被赋予了哪些行为，它们之间的相互关系是怎样的，就成为了业务领域分析的重要内容，而业务领域分析也就成为了对系统进行的一种静态分析。

我们的软件系统，毫不夸张地说，就是对现实世界的真实模拟。现实世界中的事物，在软件世界中就被模拟成一个对象。该事物在现实世界中赋予什么职责，在软件世界中就赋予什么职责；在现实世界中拥有什么特性，在软件世界中就拥有什么属性；在现实世界中拥有什么行为，在软件世界中就拥有什么函数；在现实世界中与哪些事物存在怎样的关系，在软件世界中就应当与它们发生怎样的关联。这正是面向对象编程的核心思想。



我们进行业务领域分析，就是基于这样一个思想进行的。什么叫业务领域，就是客户所在的知识领域，譬如财务人员所在的是财务领域，税务人员所在的是税务领域，营销人员所在的是销售领域。不同的知识领域拥有各自不同的领域知识，需求分析人员就应该通过客户中的领域专家去学习这些知识、掌握这些要点，并最终体现在我们的需求分析中。然而，这必然是一个长期的过程。从这个角度说，业务领域分析不仅出现在需求分析阶段，还应当贯穿与设计阶段、开发阶段、测试阶段，甚至延续到后期的维护与升级。从另一个角度讲，现在的软件研发概念，已经不再是一锤子的买卖，而是延续到数年的不断升级完善中了。而软件的升级完善，从本质上说就是对业务领域不断深入的认识。我们对业务领域的认识深入一点儿，我们的软件系统就完善一分，再深入一点儿，就再完善一分。这就是世界级软件分析大师Eric Evans提出的领域驱动设计的核心思想。

因此，我们进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。日后我们去设计开发系统时，应当设计哪些类，类中都应当有什么属性和行为，以及怎样去设计数据库，都是以这个领域模型为基础的，虽然有时并不完全与领域模型完全一致。过去，没有一个切实可行的方法来指导我们的业务领域分析，而现在，我们可以通过两种分析方法一步步进行：原文分析法与领域驱动设计。随后，我们将就这两种方式进行详细分析。

我们应当怎样做需求分析
我们应当怎样做需求调研：初识
我们应当怎样做需求调研：拜访
我们应当怎样做需求调研：研讨会
我们应当怎样做需求调研：需求研讨
我们应当怎样做需求调研：迭代
我们应当怎样做需求调研：需求捕获（上）
我们应当怎样做需求调研：需求捕获（下）
我们应当怎样做需求分析：功能角色分析与用例图
我们应当怎样做需求分析：业务流程分析（上）
我们应当怎样做需求分析：业务流程分析（下）
我们应当怎样做需求分析：用例说明
我们应当怎样做需求分析：查询报表分析
我们应当怎样做需求分析：子用例与扩展用例
我们应当怎样做需求分析：行动图和状态图
我们应当怎样做需求分析：业务领域分析
我们应当怎样做需求分析：原文分析法
我们应当怎样做需求分析：领域驱动设计
我们应当怎样做需求分析：非功能需求
我们应当怎样做需求确认：需求列表
我们应当怎样做需求确认：一个需求列表的实例
我们应当怎样做需求确认：快速原型法
我们应当怎样做需求确认：需求规格说明书
我们应当怎样做需求确认：评审与签字确认会

（续）

楼主可以整一个框架或者规范出来了，厉害，学习中。

写的好，赞一个。