在軟件工程領域，將系統定義為一組實體和這些實體之間的關系所構成的集合，其功能要大于這些實體各自的功能之和。從定義中可以看出，軟件系統設計是一個非常復雜的工作，醫療系統軟件的設計尤其如此。特別是隨著互聯網應用的日益深入和醫院管理精細化要求越來越高，醫療系統軟件的設計面臨著巨大挑戰。系統軟件為管理服務，因此要設計好系統，首先要做好業務分析。

圖1 在信息系統中，人與人的關系很復雜

　　系統業務分析是針對業務領域的建模，產出就是系統業務分析模型。分析模型描述系統的邏輯設計與結構，一般會包括需求用例、實體模型以及業務場景的交互流程、狀態轉換等。業務分析模型讓非技術人員能夠理解系統是如何構造的，讓技術開發人員能夠以此為基礎構建系統。

如何進行業務分析?

　　業務分析很難一次性完成，過程是不斷迭代的。特別是對于復雜、涉及多個業務領域的業務需求，第一步往往需要在整體系統層級進行分析，將模型劃分到多個子系統，然后再在子系統的層級進行更細節的分析與建模。另一方面，分析過程需要不斷的優化和調整。例如在確定實體的行為細節時，發現兩個實體的耦合很高，那么可能需要重新進行抽象建模，調整實體的功能范圍。

如何理清業務需求?

　　搞清楚業務需求是做好業務分析和系統設計的前提和基礎，因為業務需求確定系統的利益相關者及他們的關注點;確定系統的功能需求，即“誰”使用這個系統，使用這個系統“干什么”;確定系統的范圍，即該系統包含“什么”，不包含“什么”。

　　系統需要滿足利益相關者的關注點，所以要確保所有這些關注點都有涉及到。最重要的利益相關者就是系統用戶，此外包括供應商、合作方等。系統用戶需要細分到角色，即使有些角色實際可能是同一個人。比如對于門診業務，可能有護士、醫生、系統管理員等，不同用戶可以進行不同操作。簡單的需求范圍確定，用表單列出即可，較復雜的就需要使用用例圖工具。下圖2是一個簡單的門診業務用例圖。

圖2 門診業務用例圖

建立實體模型

　　建立實體模型就是確定系統包含的實體以及它們之間的關聯過程，包括理清業務概念，統一業務術語;抽象業務實體，包括事件、人/角色、地點和事物等;識別實體關系：繼承、聚合、關聯等。實體關系模型，即通常所說的E-R(Entity-Relation)模型，一般使用類圖或組件圖表示，如下圖3所示為一個簡單的門診業務ER圖。

圖3 門診業務ER圖

分析業務場景

　　業務場景分析確定具體業務場景中各個參與者的交互過程，從而進一步完善分析模型，包括分析具體業務場景，確定業務規則，梳理業務流程;如果涉及復雜的狀態轉換，需要確定狀態轉換邏輯;補充和完善實體模型的內容描述。

　　對于一個業務場景，參與者可能包括人、內部模塊、外部服務等，這一步需要理清楚整個業務過程和規則。需要注意的是，對于一些次要路徑或者異常路徑，也一定要考慮到。對于業務過程和規則，可以使用普通的流程圖、泳道圖，也可以考慮UML的活動圖，狀態轉換過程則可以通過UML的狀態圖展示。對于場景分析中不太確定的需求，或者可能會有技術難點地方，可以記錄下來，后面確認和驗證。下圖4是一個簡單的門診業務流程圖。

圖4 門診業務流程圖

　　通過文中介紹的幾個過程，基本能夠比較好的完成對系統的業務分析工作，設計人員對系統需要提供哪些功能，會有哪些主要用戶，以及整個業務流程基本有了比較清晰的認識。后續的技術性設計工作，在此基礎上就可以比較順利的開展。系統開發團隊，要高度重視這一工作，如果有可能，信息部門工作人員也可以參與到這個工作中來，助力系統研發上線成功。

　　作者簡介

　　吳坤，計算機專業碩士，華中科技大學同濟醫學院附屬同濟醫院信息中心軟件工程師。專業計算機程序員，國內在醫療行業積極推廣IT技術的青年工程師和技術踐行者，熱衷于以信息技術提高醫療行業服務質量和改善患者就醫體驗。