需求分析的常见方法 | 讲故事说ITIL

需求分析是我们信息科工程师的基础性技能。作为承接最终用户与开发人员（一般医院都是由外包公司承接）沟通的桥梁，我们的任务就是收集清楚用户的需求，梳理总结需求，根据管理要求和“质量与安全”的原则，结合所需要的资源，形成最终的需求报告，为系统设计提供帮助。但是在实际工作中，这项基础技能，其实我们还没有掌握的很好。需求收集不完整，分析不到位，控制不力的情况经常出现。如何做好需求分析呢？今天我们就一起来学习ITIL中有关需求调研的相关内容。在ITIL中也对此给予了很重篇幅的讲解，因此我会分几次分享相关内容。

【需求分析的概念】

需求分析是一种方法，该方法要求在了解和记录业务和用户需求的过程中必须非常严格地按照标准进行，它可确保每个需求的变化都可跟踪。需求设计流程由收集、分析(反馈给收集) 和验证这三个阶段组成。每一阶段对最终的需求文档都是必须的。此文档的核心是储存各个需求，以供开发和管理使用。这些需求通常由用户提出，信息科启动调研工作，最终的需求报告还应得到业务部门的认可和同意。

需求分类

一般说来，任何系统都有三类主要的需求，即功能需求、管理和运营需求、易用性需求。

功能需求专门用于满足支持特定业务功能这一需要；管理和运营需求(有时称为非功能需求) 用于满足对服务的易响应、高可用和安全的需要，并处理易于部署、运营、管理的需要和安全性之类的问题；易用性需求用于满足用户对“外观和感觉”的需要，并产生促进服务易用性的服务功能。
功能需求

描述服务应该做的事情，可以表示成组件必须执行的任务或功能。功能需求通常使用用例模型这样的方法。这也是教科书上常用的方式，用例模型定义外部行动者与所设计的服务之间的一组面向目标的交互模式。参与者是在服务以外，但与服务有关的各方。行动者可反映用户可扮演的一类角色，或者反映其他服务及其需求。用例建模主要用于确立所计划系统的界限并全面指定要交付给用户的功能。用例还有助于在业务部门与应用开发人员之间建立沟通。它们为调整和完善易用性需求的定义奠定了基础。用例定义应用必须支持的所有情景，因此可以很容易扩展为测试案例。在成熟的需求建模过程中，CASE 工具可以帮助实现并保持这些模型一致、正确和完整。
管理和运营需求

(非功能需求) 用于定义对IT服务的要求和限制。此类需求是系统和服务早期调整及成本估算的基础，用于支持该IT服务可行性的评估。管理和运营需求的内容包括:
可管理性: 是否可以运行? 是否会发生故障? 会发生怎样的故障?
效率: 需要哪些资源的配合，项目才能正常运行。比如护理绩效管理就涉及到护理人员、成本核算人员、人力资源管理等多部门的合作。

可用性和可靠性: 需要具有怎样的可靠性?在医疗信息化需求时，我们更应该考虑到是否会对患者安全造成影响，并准备好应对措施。

容量和性能: 我们需要哪一级容量？是本地存储还是网络存储，或者是云存储，这样的存储又会带来哪些需要解决的问题。

安全性: 需要哪一类安全性？
安装: 安装应用要花费多少精力？是否使用自动安装步骤？
连续性: 需要那一级别的适应能力和恢复能力？

可控性: 是否可监视、管理和调整？       

可维护性: 针对未来需求可对应用进行怎样程度的调整、校正、维护和更改？

可操作性: 应用间的功能是否相互干扰？
测量和报告能力: 是否可以测量和报告所需的各个应用方面?
管理和运营需求可用于指定在建应用的质量属性。这些质量属性可用于设计测试计划，以便测试应用是否符合管理和运营需求。

易用性需求

的主要目的是确保服务达到用户对其易用性的期望。为了实现这一目的，需要:为评价易用性建立性能标准。为易用性测试计划和易用性测试定义测试场景。与管理和运营需求类似，易用性需求也可用作设计测试计划的质量属性，这些测试计划用于测试应用是否符合易用性需求。易用性很大程度是一种感受，ITIL里没有太多涉及到如何建立评价标准。以后我们可以专门篇幅来学习。

支持需求一用户角度

在需求定义和验收测试中，作为用户代表的用户具有正式定义的角色和活动。在确定服务需求的各个方面时，应积极让这些用户参与进来。其中除了上述三种服务需求外，还包括:用户培训和硬件支撑和故障报修流程。

【需求调查方法】

很多时候，临床和业务部门不完全确定自己的实际需求是什么，因此需要设计者或需求收集者提供某种帮助和提示。两种最常用的方法是访谈和研讨会，除此之外还有观察和场景模拟。

访    谈

访谈是一个重要的工具，通过访谈可以达到多个目的，例如:与关键的利害干系人进行最初的接触，为发展关系建立基础。与不同的用户和管理人员建立并发展友好关系。因此访谈不仅能获得用户需求，还可以通过沟通获得用户信任。当然访谈的主要任务是获得业务状况信息，包括存在的问题和目前的困难以及用户的期望。

下面是访谈时要考虑的三个内容:

1.在所有新业务系统和服务中都需要履行的当前业务流程。

2.当前业务存在需要解决的问题。

3.新的业务系统或服务以及任何支持IT服务需要具备的新功能。

在做访谈前，访谈者应做好准备工作，以节省时间。典型的提问结构是“原因、内容、对象、时间、地点、方式”。

在结束采访时以下内容应该得到确认:总结涉及到的要点和议定的行动；说明接下来要做的工作；获取联系方式。

访谈完毕后整理详细访谈记录，并与采访者确认是否理解正确。

访谈的优点有:

与用户建立关系，便于下一步开展工作；
能够获取与项目有关的其他重要信息；
有机会了解整个用户群体中的不同观点和态度；
有机会研究出现的新情况；
收集文档和报告样本；
理解设计到的政策因素；

研究新服务的目标运营环境。
访谈的缺点: 太花费时间、没有机会解决冲突。因为访谈是一个一个干系人进行的，就会出现不同部门不同人对同一件事情的不同看法，这种冲突在访谈时是没法达成一致的。

研讨会

研讨会提供了一个开放环境，在此可以讨论问题、解决冲突并能引出需求。对于如下情况，研讨会特别有用: 时间和预算有严格限制，有多个观点需要征求意见，且采用循环渐近式服务开发方法。
研讨会的优点有:

广泛了解调查研究的领域，把一组利害干系人集中到一起，就可以更全面了解问题和困难；提高速度和效率，与逐一访谈相比，一群人在一起开会更有效率；

赢得对IT服务的认可和接受；

如果所有利害干系人都参与，大家更有可能接受结果，获得共识。

缺点:

组织会议可能耗费时间，例如，把所有人同时聚在起不是件容易的事；

可能难以召集到全部具有所需级别权力的参与者；可能难以同时召集到业务和运营相关人员来了解不同的需求。

研讨会的成败在很大程度上取决于研讨会主持人和业务负责人的准备工作。在开会之前，应该规划好以下事项:

研讨会的目标，必须在研讨会规定时间内达成共识。
邀请哪些人参加研讨会，一般原则是邀请所有对研讨会目标感兴趣的利害干系人参加或派代表出席。

研讨会的结构和要采用的方法。需要对这二者进行调整以实现既定目标，例如需求征集或优先级划分，进行此规划时还应考虑参与者的需要。安排合适的会议地点。

研讨会期间，主持人需要确保问题讨论、观点宣扬及会议进展都必须围绕着要实现的既定目标来进行。讨论中出现的要点需随时记录下来。研讨会结束时，主持人需要总结要点和行动。每项行动都应落实到人。研讨会需要采用两类主要方法一发现方法和记录。

观 察

观察工作场所非常有助于获取临床工作环境和工作习惯方面的信息。该方法有两个优点;更好地了解用户面临的问题和困难会有助于设计可用的解决方案，更容易被用户所接受。相反，可能造成被观察者紧张，有句老话说得好，“被人关注时，你就不再是你自己”，因此在所采用的方法和得出的结果中，要考虑到这种因素。正式观察包括观察所执行的具体任务。虽然存在只看到“表面文章”这一缺陷，而不能了解任何日常变化，但该方法仍不失为一个有用的工具。

协议分析

协议分析就是让用户执行一项任务，且用户在执行该任务时，描述任务每个步骤，便于我们分析需求时了解用户所做工作。

跟  踪

跟踪包括跟踪用户一段时间(例如一天)，以查明某项特定工作的情况。这是了解特定用户角色非常有效的方法。询问完成工作的方式或工作流程可以澄清某些假设。在JCI和等级医院评审中也有类似的方法，患者追踪法和系统追踪法。通过对患者某项治疗活动进行全程追踪，了解所涉及到的各个部门和环节对此项工作的开展情况，尤其是在业务协同上是否满足“质量和安全”的原则。在我们做需求调研时也应该用好此方法，才能清楚的知道在信息系统中业务协同该如何设计，数据交互该如何进行。

场景分析

场景分析在本质上是构思并讲述一项任务或交易。它的价值在于如果用户不确定新服务需要提供哪些内容，则可以帮助用户更好地认清这一点。分析或重新设计业务流程时，场景也有用。场景会跟踪交易过程，从最初的业务触发事件到实现目标所需的每个步骤。场景为发现替代途径提供了一个框架，可能需要按照这些途径来完成交易。因为讨论的是现实情况(包括异常情况)，所以这在得出和分析需求时非常有用。

场景分析的优点:

具体化的描述能够让用户考虑每个步骤，解决了隐性知识的问题；帮助用户了解所有的意外事件，有助于处理未来系统和服务的不确定性研讨小组对场最方案进行提炼后，就会确定那些不适合企业文化的途径为准备测试脚本提供工具。

场景分析的缺点：

是开发它们可能耗费时间，并且某些方案可能变得非常复杂。如果遇到这种情况，那么将每个主要的替代途径都视为一个单独的方案就更容易进行分析。
记录场景方案描述的常用方法是开发用例描述，以支持用例图。但还有很多图形方法也可用来记录方案，例如故事板、活动图、任务模型和决策树状图。