HIT专家网
【编者按】
医疗信息化建设最主要的任务是规划、设计、开发以及部署医疗信息系统。如何开发设计性能良好的医疗信息系统，对于提高医院临床科室的工作效率和医疗信息化工作水平而言至关重要。
在本系列文章中，笔者将围绕“如何开发性能良好的医疗系统软件”这一主题，并结合自身工作经历，分别从软件系统架构设计、程序开发设计、数据库设计开发、项目管理、典型案例等几个方面分享和总结相关经验和教训。
来源：HIT专家网 作者：华中科技大学同济医学院附属同济医院 吴坤
需求分析是软件开发项目的第一步，也是极为关键的一步。对于数据库设计而言，需求分析为后续数据库设计阶段提供蓝图指导，直接影响整个项目的质量和成效。因此需求分析对于数据库设计而言至关重要，也是数据库设计过程中参与人员较多的一个环节。
软件开发人员通过与用户进行一系列沟通交流，从而确定用户想在系统中存储什么数据以及想怎样使用这些数据。整个数据需求分析可以大致划分为两个过程：用户需求获取和理解、确定业务规则。本文主要谈“用户需求获取和理解”。
无论开发何种软件，甚至是设计制作任何一种非软件产品，设计人员要做的就是，将用户脑海中关于产品的诉求、功能、外观、性能等模糊的想法和概念，用专业的方法和工具挖掘、整理、翻译出来，最终转化成一个满足用户设想的实际产品。这个关于用户想法的挖掘和翻译过程的第一步，就是要理解用户需求。如果理解有误，例如最终设计一个电商销售系统对于医疗机构用户而言毫无意义，与他们所设想的产品完全是南辕北辙。这不仅影响了项目进度，浪费了资金时间，也极大损害了客户的利益。需求分析如此重要，我们必须制定一个详细的计划，不可盲目开展相关活动。
在制定需求分析计划后，按照该计划开展一系列活动，以逐步获取和挖掘客户需求，例如实地调研、与用户面对面沟通、召开会议等。如下10个步骤是一个可行的计划模板，遵循这些步骤开展活动，能够更好地理解用户需求，但在实际工作中，可以根据具体的项目需求来开展，只要能明确清晰地理解和挖掘用户需求即可。
1．问题预想
在与客户沟通交流之前，我们需要尽可能设想到用户提哪些问题，确定问题的边界和范畴。以便在与用户沟通时，能争取更多的主动，而不是完全依赖用户陈述，导致沟通效率低下，甚至会产生很多理解失误的需求。在进行问题设想时，可以从以下几个方面入手：
（1）系统功能
- 为什么要开发这款系统软件？
- 系统应该给用户提供哪些功能？做什么？
- 系统用户都有哪几类人员？
- 系统大概长什么样子？
- 系统需要提供哪些查询报表?
（2）数据需求
- 系统应该展现哪些数据？
- 这些数据提供者是谁？使用目的是什么？
- 这些数据之间有何关联关系？
- 这些数据来源何处？目前是如何采集的？
（3）数据完整性
- 哪些数据信息是必须的（患者信息是否必须提供身份证号）？
- 数据字段有效格式如何限制（电话号码格式是否固定规则）？
- 是否需要提供邮政编码、省市地址等有规定格式的数据？
- 医嘱申请状态信息有哪些？状态信息如何影响业务流程？
（4）上下文环境
- 是否要求不同用户不同密码？密码格式是否严格要求？
- 是否严格控制不同用户的数据访问权限？
- 系统用户是否需要分级？每个级别用户有哪些？
- 存储在数据库中的数据是否需要加密？哪些数据需要加密？
- 是否需要建立日志，记录用户操作数据库的行为？
2．用户交流沟通
了解需求的最精确的方式就是咨询用户，当然与用户沟通是一个冗长繁琐的过程，很考验需求收集人员的耐心和毅力。特别是在医疗机构，主要的用户是临床医疗工作人员，他们往往工作非常繁忙，没有太多时间和耐心与开发人员进行面对面详细沟通。如果一直穷追不放，追着用户询问，往往会让用户感到非常反感，甚至质疑开发团队的技术与管理能力。
针对这样的情况，开发人员应该更加有耐心，可以分多次会议来了解需求，每次针对几个问题或流程咨询不同的用户，最终的目标是对我们要解决的问题有一个完全彻底的理解。这只是整个业务流程的一部分，如果条件允许，应尽量多地了解整个业务流程。
3．弄清楚项目干系人
不同的用户，对于软件系统可能会有不同的要求和期望。开发人员需要分辨出谁是领导，谁是积极支持者，谁是旁观者，谁是唱反调者。常见的项目干系人角色包括如下几个：
（1）项目发起人，一般是管理层的某位领导，他是项目的最高推动者。他会为项目协调资源，解决项目遇到的一些障碍，但他不会参与到项目每天的事务中。
（2）项目执行负责人，他对于用户的需求和整个业务最为了解。他是了解用户需求阶段最重要的人，他必须有足够的时间来帮助开发团队定义项目目标，并回答开发人员的问题。
（3）客户代表，是回答我们问题的人，他们也可能成为系统的最终用户。他们可能是某一部分业务的专家（例如临床业务科室专业），我们需要与多个客户代表进行访谈，来了解业务全貌。
（4）利益相关者，这是项目将影响到的人，其中某些人可能同时也是用户代表。这些人可能对项目也有兴趣，但未必对系统都有发言权。我们在进行系统设计时也需要考虑对这些人的影响（特别是附带损害），用户的体验是项目成功的直接体现。
（5）唱反调者，这是我们需要关注的一些人。如果唱反调者只是让其他人理性或现实地来看待项目，而并不是彻底反对这个项目的话，他将是我们非常好的资源，他将帮助我们说服其他对项目抱有不切实幻想的客户。而如果唱反调者对整个项目抱有抵触情绪时，我们就必须非常小心，有时需要项目执行负责人出面来协调这些人。不过对于医疗机构而言，个别唱反调者对于项目的开展一般不会起到太大的阻碍，只要最终经费验收签字领导支持即可。
4．挖掘潜在需求
了解项目相关干系人后，开发团队更多的是与项目执行负责人沟通。在医疗机构，项目执行负责人可能是信息科或者业务科室某个负责与软件公司对接的工作人员。在与项目执行负责人沟通时，需要讨论和了解清楚客户最终期望的方案是怎样的、需要哪些数据信息、这些数据信息之间的关联关系如何以及数据如何展现等。
当然，这些需求的获取来源于不同的用户，在需求讨论时如果出现问题或矛盾，可由项目执行负责人进行协调。对于一些需求不明确或者对于产品需求毫无概念的用户，可由项目执行负责人进行引导，以挖据出用户需求。
5．了解用户实际业务流程
在进行初步的需求了解后，如果依然存在一些不清晰、模棱两可的需求。可以通过实地体验，实际去了解用户的业务流程和操作步骤，例如以患者的身份去挂号，一步一步实际走完业务流程，这样对于整个业务就有了很清晰的认识。还可以通过现场参与，充当客户工作人员，帮助工作人员完成工作，或者作为助手实习生，通过实际动手操作，了解客户的实际业务操作步骤。
即使我们不能实际尝试客户的工作，也可以通过近距离观察，询问客户即将开发的产品该如何提高他们的工作效率，以及他们目前急切需要解决的问题。在这个过程中要进行记录，学习尽可能多的东西。有些时候外行者的一些看法可能转化为客户怎么也不会想到的好主意。了解客户现在使用的数据存储方式，可能是关系型数据库系统或是电子表格或是纸质的单据等。了解这些数据是怎样使用的、之间是如何关联的。
6．需求思考与展望
完成需求采集和业务流程了解后，下一步需要进行深入思考并展望，以确保没有需求遗漏。召集项目执行负责人和尽可能多的客户代表与利益相关者，向他们描述前期了解到的需求情况，之后让他们畅所欲言地谈谈其中有什么问题或还缺什么。
对于客户提出的需求，要逐一记录下来，确保用户提出的需求都有考虑，切记不要立即答应客户，不要立即给客户允诺，待后面与项目执行负责人进行详细的讨论分析。同时，询问客户他们的业务在将来是否会变化或他们希望系统将来能包含什么功能，以便在数据库设计时能预先留有余地。有时客户并不了解自己的真正需求。他们能看到问题的表象，但未必清楚其根源。开发人员需要帮助客户寻找到问题的根源，并针对问题的源头提出解决方案。
7．应对客户质疑
对于开发人员的设计方案，可能会遇到客户群体的质疑，特别是一些略懂技术的客户代表。站在开发人员的角度，你可能对客户的质疑不了解，甚至觉得可笑。但不能忽视这些质疑，我们应谨慎思考用户提出这些建议或质疑的深层原因是什么。客户比我们更了解业务，他们的建议或质疑中可能蕴含着我们还未了解到的业务变化点或某些特殊业务情况。
8．安排优先级
经过前述步骤，大致可以列出数据库涉及相关的需求单了。其中的某些功能可能不切实际或超出了当前项目的范畴。为了使项目规模可控，需要与客户一起定义功能的优先级。
一般我们可以把功能分为三个等级：第一优先级是在本期开发中必须包含的功能，没有完成这些功能就意味着项目的失败；第二优先级是可以放到下一期开发的功能，当第一优先级的功能完成后，我们可以把第二优先级的部分功能提到当期开发；第三优先级是那些相对不重要或超出项目范畴的功能，我们可以忽略这些功能。
有些情况下优先级是可能转化的。当第一优先级的某功能非常难实现时，我们可以与客户进行沟通，确认该功能是否如此重要，是否能移到第二优先级，以避免影响项目进度。如果第二优先级中的某些功能很容易实现，我们可以把该功能调整到第一优先级列表中。但做这些调整之前必须与客户沟通，得到客户的认可。
9．需求确认
对需求和业务进行梳理，并逐一与客户进行确认。对于客户之前提出的一些可有可无需求，要进一步确认，确定不需要或者需要。特别是一些例外情况，例如，所有患者必须先充值缴费才能执行检查检验，但是对于某些特殊患者，没有充值缴费，也可以执行检查检验。对于这些影响数据库设计的例外情况，要与客户进行确认。对于需求的优先级，从技术开发和业务需要两方面，与客户达成一致。技术上有前置关系的需求，需要向用户说明，并征得用户的理解同意。
10．撰写需求文档
需求文档也称为需求规格说明书，描绘了项目开发设计的系统。需求文档要讲清楚我们将构建怎样的系统，该系统会完成什么工作，包含哪些功能点，并描述客户如何使用该系统来解决他们的问题。在需求文档中，要定义各阶段的里程碑，即各阶段交付的成果以及最终项目交付的成果。在需求文档撰写时，可以利用UML用例建模，通过用例图来进行需求分析描述。本文对需求文档的撰写，不做详细描述，后续视读者需求，可以专门撰文讲解。
【作者简介】
吴坤，计算机专业硕士，华中科技大学同济医学院附属同济医院信息中心软件工程师。专业计算机程序员，医疗信息技术推广者，积极参与社会活动，热衷于以信息技术提高医疗行业服务质量和改善患者就医体验。
想加入HIT专家网专业交流群吗？请添加“HIT专家网”小助手微信好友
（请务必注明姓名、单位名称、职务、主管技术或产品领域等实名信息）
【责任编辑：谭啸】
评论前必须登录！
注册