需求文档是否包含业务实体分析？

    【主要观点来自经典书籍：软件需求最佳实践---SERU过程框架与应用】

 

    最近在做软件需求规格说明书模板规划，其中涉及一个主题是否报业务实体分析，大多数人对于这个基本处于不知的状态，有人不知道干吗用，有人不知道图例，有人不知道怎么分析。。。。。

   从现象看，已经偏离了建模的目的，最终将走向形式。

    周末在家专心读书学习相关知识，主要是看徐锋的经典著作：软件需求最佳实践---SERU过程框架与应用，帮我解了很多的疑惑。

   1.  什么是业务实体分析

       在业务流程中，必然会涉及许多业务实体或称为业务数据、业务术语，要正确地构建出信息系统，就必须对这些业务实体建立正确的认识。

      具体来说，就是要了解这个问题域中有哪些业务实体，它们之间存在什么样的逻辑关系、数量关系，以及有什么相应的结构规则。实际上这样的工作就是“领域建模”、“概念建模”。

  2. 业务实体分析的方法

     在领域建模的过程中，应该更多的采用“自底向上”的方法，也就是针对每一个业务事件、每一类报表创建局部的领域类图片段，然后完成这些建模工作后，在对其进行抽象、提炼，形成全局的领域模型。

     针对每一个业务事件、每一类报表进行领域类图片段得绘制时，主要包括三个步骤：

• 识别出业务实体
• 确定实体之间的关系
• 定义实体的关键属性

  3.业务实体分析的模型

     业务实体分析的产物有两种可选的模型：

• 类图：类图是面向对象分析与设计方法引入的，它是UML规范的一部分，在语义上要比传统的E/R模型更强，在领域建模更加合适一些。
• E/R图：E/R模型也叫实体关系图，历史悠久，与数据库结合的更加金币，但在领域建模阶段语义阶段不够丰富
            

   4. 问题

      在我们技术人员团队中有人看不懂的情况下，客户是否能理解呢？

   5.解决方案

     a) 基本技能：  团队需要从根本上来理解业务实体分析（领域建模）这件事情的重要性，制定出响应的策略。

         在我们的人员不具备领域建模能力的时候，需要采用什么样的策略：技能培训？决定在什么时间段进行纳入正式的文档范畴当中？

     b)有给非技术背景的用户解释模型的能力

        不能用聚合、泛化、关联之类的术语，要用客户听得懂的话来解释。

        例如：客户有两类，个人客户和公司客户，某个客户有且只能属于其中一类，每个客户都会下很多订单.....