吴坤：做好业务分析，开发人性化系统

　　在软件工程领域，将系统定义为一组实体和这些实体之间的关系所构成的集合，其功能要大于这些实体各自的功能之和。从定义中可以看出，软件系统设计是一个非常复杂的工作，医疗系统软件的设计尤其如此。特别是随着互联网应用的日益深入和医院管理精细化要求越来越高，医疗系统软件的设计面临着巨大挑战。系统软件为管理服务，因此要设计好系统，首先要做好业务分析。

图1 在信息系统中，人与人的关系很复杂

　　系统业务分析是针对业务领域的建模，产出就是系统业务分析模型。分析模型描述系统的逻辑设计与结构，一般会包括需求用例、实体模型以及业务场景的交互流程、状态转换等。业务分析模型让非技术人员能够理解系统是如何构造的，让技术开发人员能够以此为基础构建系统。

如何进行业务分析?

　　业务分析很难一次性完成，过程是不断迭代的。特别是对于复杂、涉及多个业务领域的业务需求，第一步往往需要在整体系统层级进行分析，将模型划分到多个子系统，然后再在子系统的层级进行更细节的分析与建模。另一方面，分析过程需要不断的优化和调整。例如在确定实体的行为细节时，发现两个实体的耦合很高，那么可能需要重新进行抽象建模，调整实体的功能范围。

如何理清业务需求?

　　搞清楚业务需求是做好业务分析和系统设计的前提和基础，因为业务需求确定系统的利益相关者及他们的关注点;确定系统的功能需求，即“谁”使用这个系统，使用这个系统“干什么”;确定系统的范围，即该系统包含“什么”，不包含“什么”。

　　系统需要满足利益相关者的关注点，所以要确保所有这些关注点都有涉及到。最重要的利益相关者就是系统用户，此外包括供应商、合作方等。系统用户需要细分到角色，即使有些角色实际可能是同一个人。比如对于门诊业务，可能有护士、医生、系统管理员等，不同用户可以进行不同操作。简单的需求范围确定，用表单列出即可，较复杂的就需要使用用例图工具。下图2是一个简单的门诊业务用例图。

图2 门诊业务用例图

建立实体模型

　　建立实体模型就是确定系统包含的实体以及它们之间的关联过程，包括理清业务概念，统一业务术语;抽象业务实体，包括事件、人/角色、地点和事物等;识别实体关系：继承、聚合、关联等。实体关系模型，即通常所说的E-R(Entity-Relation)模型，一般使用类图或组件图表示，如下图3所示为一个简单的门诊业务ER图。

图3 门诊业务ER图

分析业务场景

　　业务场景分析确定具体业务场景中各个参与者的交互过程，从而进一步完善分析模型，包括分析具体业务场景，确定业务规则，梳理业务流程;如果涉及复杂的状态转换，需要确定状态转换逻辑;补充和完善实体模型的内容描述。

　　对于一个业务场景，参与者可能包括人、内部模块、外部服务等，这一步需要理清楚整个业务过程和规则。需要注意的是，对于一些次要路径或者异常路径，也一定要考虑到。对于业务过程和规则，可以使用普通的流程图、泳道图，也可以考虑UML的活动图，状态转换过程则可以通过UML的状态图展示。对于场景分析中不太确定的需求，或者可能会有技术难点地方，可以记录下来，后面确认和验证。下图4是一个简单的门诊业务流程图。

图4 门诊业务流程图

　　通过文中介绍的几个过程，基本能够比较好的完成对系统的业务分析工作，设计人员对系统需要提供哪些功能，会有哪些主要用户，以及整个业务流程基本有了比较清晰的认识。后续的技术性设计工作，在此基础上就可以比较顺利的开展。系统开发团队，要高度重视这一工作，如果有可能，信息部门工作人员也可以参与到这个工作中来，助力系统研发上线成功。

　　作者简介

　　吴坤，计算机专业硕士，华中科技大学同济医学院附属同济医院信息中心软件工程师。专业计算机程序员，国内在医疗行业积极推广IT技术的青年工程师和技术践行者，热衷于以信息技术提高医疗行业服务质量和改善患者就医体验。