不同参与者的取消流程虽然不同，但在业务服务图中，实际要执行的业务服务都是“取消票”。培训专员和系统都可以处理票，区别在于一个是人工，一个是自动，后者的触发条件与触发时机相对比较复杂。对这些领域逻辑的描述可以在领域建模阶段通过业务服务规约进一步细化。
获得提名并参加培训的部门员工称为“学员”，如此可以更好地体现其身份。培训的业务服务图如图20-25所示。
培训业务规则规定，如果学员没有提交培训请假申请或请假申请未通过，却未曾参加培训且未签到，会被视为缺勤。在培训流程的服务蓝图中，根据业务规则，缺勤学员会被放入黑名单，然而这一活动并未在业务服务图中体现出来。这是因为学员被加入黑名单实际是“确认缺勤名单”业务服务产生的一个结果，并非一个独立的业务服务。
分析EAS的业务需求时，从业务流程到业务场景，再从业务场景到业务服务，应该是一个水到渠成的过程。在这个过程中，最好能引入“现场客户”（极限编程中的一个实践），共同探索业务需求，梳理出问题空间的业务需求全貌。
为了避免分析瘫痪，在全局分析阶段，业务需求分析在获得业务服务这个粒度时就可以结束，进入架构映射阶段。然而，对业务服务做进一步细化仍然属于需求分析的过程，与开发团队开展架构映射属于两个并行不悖的工作，细化获得的业务服务规约也将作为领域建模阶段的重要输入。因此，需求分析人员也可在全局分析阶段针对核心子领域的业务服务编写业务服务规约。
组成EAS全局分析规格说明书的业务需求如下所示。
1 业务流程
包括EAS的核心流程与各个具体的业务流程，可通过业务流程图或服务蓝图呈现。前文已述，现略去。
2 业务场景和业务服务
针对每个具体的业务流程，按照业务目标进行划分，获得每个具体的业务场景，并按照业务服务的判断标准识别业务服务，通过业务服务图呈现出来。前文已述，现略去。
3 业务服务规约
对每个业务服务进行细化，获得业务服务规约。
3.1 客户合作
3.1.1 市场需求管理
（1）创建市场需求
服务编号：EAS-0001
服务描述：
作为市场人员
我想要创建一条市场需求
以便随时了解市场需求的状态
触发事件：
市场人员输入市场需求，点击“创建”按钮
基本流程：
1．验证输入的市场需求，包括需求名称、描述、客户、备注
2．按照规则生成市场需求编号
3．验证市场需求名称是否已经存在
4．创建市场需求
替代流程：
1a．当市场需求名称在系统中已存在，给出提示信息
4a．若市场需求创建失败，给出失败原因
验收标准：
1．市场需求的名称只能为中文、英文或数字，长度不超过50个字符，不能重复
2．输入的市场需求中，必须包含市场需求名称、描述和客户，客户为系统已有客户，备注为可选
3．市场需求编号规则为：EAS-客户ID-自增长数，市场需求编号不允许重复
4．市场需求被成功创建
3.1.2 合同管理
（1）归档合同
服务编号：EAS-0011
服务描述：
作为市场人员
我想要对合同进行归档
以便保存合同副本，避免合作纠纷
触发事件：
市场人员选择合同文档，点击“上传”按钮
基本流程：
1．验证文档类型的有效性
2．上传合同文档
3．保存合同文档
4．更新合同信息
替代流程：
1a．若上传的文档类型并非PDF文档，给出提示信息
2a．若上传的文档超出系统规定的文件大小，给出提示信息
3b．若上传合同文档时，文件传输失败，给出失败原因
4a．更新合同信息失败，给出失败原因
验收标准：
1．归档的合同文档只能为PDF文件，可仅验证文档文件的扩展名
2．服务器归档主文件夹为contract/archive，归档保存时，需验证该文件夹是否存在，如果不存在，需要创建该文件夹
3．为合同归档文件创建子文件夹，子文件夹名为合同ID
4．若归档时，在指定文件夹中已有同名文件存在，则为“另存为”操作，当前文件名增加“（1）”作为后缀
5．合同的归档文件属性添加归档文件夹路径
……
3.3 项目管理
……
3.3.3 项目成员管理
（1）添加项目成员
服务编号：EAS-0105
服务描述：
作为项目管理者
我想要添加项目成员
以便管理项目成员
触发事件：
项目管理者选定员工和项目角色，点击“添加”按钮
基本流程：
1．验证员工是否工作在其他项目
2．将员工加入项目团队，成为项目成员
3．修改员工的工作状态
4．发送邮件通知员工
5．为员工简历追加项目经验
替代流程：
1a．选定员工如果已经加入其他项目，给出提示
2a．添加员工失败，给出错误信息
5a．若员工已具备该项目经验，则忽略
验收标准：
1．选定的员工应为“on bench”状态
2．员工被加入项目团队后，状态应变更为“项目中”
3．员工简历中的项目经验信息不能重复
4．员工简历中的项目经验包括：项目名称、项目描述、担任的项目角色
3．划分子领域
全局分析阶段对问题空间的识别也是对客户痛点与系统价值的识别。之所以要开发目标系统，就是要解决客户的痛点，并为客户提供具有业务价值的功能。在识别痛点与价值的过程中，需要始终从业务期望与愿景出发，与不同的利益相关者进行交流，如此才能达成对问题空间的共同理解。
对EAS而言，集团决策层要解决“供需平衡”这一根本的痛点，就需要及时了解当前有哪些客户需求、目前又有哪些人力资源可用，这就需要打破市场部、人力资源部和项目管理部之间的信息壁垒，对市场需求、人力资源、项目的信息进行统计，提供直观的分析结果，进而根据这些分析结果为管理决策提供支持。我们需要就这几个主要部门了解部门员工的痛点和对价值的诉求。
市场部员工（市场人员）面临的痛点是无法通过人工管理的方式高效维护与客户的良好合作关系，故而其价值诉求就是提高客户关系管理的效率，使得能够快速地响应客户需求，敏锐地发现潜在客户，掌握客户动态，进而针对潜在客户开展针对性的市场活动。市场部员工希望能够建立快速通道，及时明确项目承担者（即子公司）是否能够满足客户需求，降低市场成本。市场部门还需要准确把握需求的进展情况，跟进合同签署流程，提高客户满意度。
人力资源部员工（招聘专员）的痛点是需要制订合理的招聘计划，使得聘用的人才满足日益增长的客户需求，又不至于产生大量的人力资源闲置，导致集团的人力成本浪费。站在精细管理的角度考虑，从潜在的市场需求开始，招聘专员就需要与市场部、子公司共同确定招聘计划。制订计划的依据在于潜在的人力资源需求，包括对技能水平的要求、语言能力的要求，同时也需要考虑目前子公司的员工利用率，并参考历史的供需关系来做出尽可能准确的预测。员工的技能是一种重要的输出资源，人力资源部需要针对客户对人员能力的要求制订培训计划，在企业内部组织员工培训，提升员工技能，如此就能以最小成本输出最大的人力资源价值。因此，人力资源部的价值诉求就是让招聘与培训具有计划前瞻性与精确性，更好地在客户需求与人力资源之间维护供需的平衡。
项目管理部负责企业的“生产管理”，对项目以及项目成员的管理直接关系到客户满意度。在没有EAS之前，市场部的苦恼是不了解已签合同的项目执行情况，即使市场部主动与项目管理部进行沟通，项目管理部也无法提供精确的项目信息，更谈不上及时了解项目的进度情况。因此，市场部的价值诉求是了解项目进度以促进与客户的良好合作关系，而项目管理部的价值诉求是及时了解项目过程执行情况，发现不健康的项目，通过项目管理手段规避延迟交付甚至交付失败的风险，提高项目的成功率。
识别了痛点与价值，即可借此划分子领域细分问题空间。并通过识别核心子领域、通用子领域和支撑子领域来区分核心问题和次要问题。
由于EAS是为软件集团应用信息化服务的，我们可以在识别出痛点与价值的基础之上，从业务职能与业务概念相结合的功能分类策略确定整个问题空间的子领域，由此获得的核心子领域如下：
q决策分析；
q市场需求管理；
q客户关系管理；
q员工管理；
q人才招聘；
q技能培训；
q项目进度管理。
除了这些核心子领域，诸如组织结构、认证和授权都属于通用的子领域，每个核心子领域都需要调用这些子领域提供的功能。注意，虽然通用子领域提供的功能不是系统业务的核心，但缺少这些功能，业务却无法流转。之所以没有将这些功能识别为核心子领域，是因为有对问题空间的理解分析。例如，组织结构管理是保证业务流程运转以及员工管理的关键，用户的认证与授权则是为了保证系统的访问安全，都没有直接对“供需平衡”这一业务愿景提供业务价值，因而不是利益相关人亟待解决的痛点。
在分辨系统的利益相关者时，服务中心作为参与EAS的业务部门，主要为项目及项目人员提供工位和硬件资源，要解决的是资源分配的问题。这一功能的引入固然可以帮助企业降低运营成本，却与价值需求中的系统愿景没有直接关系，因此可以将该子领域作为一种支撑子领域。除此之外，消息通知和文件上传下载也支持了大部分核心领域的执行活动，都属于独立的支撑子领域。
EAS的子领域映射图如图20-26所示。
划分子领域分解了问题空间，使得团队能对EAS达成共同理解，识别出来的各个子领域也将作为解空间形成的架构方案的参考，尤其是系统分层架构的参考。子领域也属于全局分析规格说明书的一部分。
