1　概述

1.1　需求分析的概念及意义

即使计算机编程技术已经有很多年头，软件从业者仍然在激辩“需求”的准确定义。我们不想在本书中继续这种争论，只想从实用定义的角度简单表述一下。

顾问布莱恩·劳伦斯（Brian Lawrence）认为，需求是“任何能够驱动设计做出选择的东西。”这种口语化定义不错，因为很多信息都印证了他的说法。毕竟，开发需求的目的就是要做出合适的设计选项，最终满足客户需要。另外一种定义认为需求是产品所必备之属性，目的是向干系人提供价值。这也没错，但不太准确。我们比较倾向于：需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。

这个定义认为“需求”是多种不同类型的信息的统称。需求涵盖来自客户视角的外部系统行为以及来自开发人员视角的一些内部特征。它们包含系统在特定条件下的行为和属性，使目标用户觉得系统易于甚至乐于上手。

需求分析（requirement analysis）是调查用户对新开发的信息系统的需要和要求，结合组织的目标、现状、实力和技术等因素，通过深入细致的分析，确定出合理可行的信息系统需求，并通过规范的形式描述需求的过程。

从需求分析开始，开发人员需要把注意力转移到要开发的信息系统上来。在开发信息系统之初，分析人员需要先了解用户希望建立怎样一个信息系统，这个系统能够为用户解决哪些问题，信息系统应该具备哪些功能，用户与信息系统都会交互哪些信息，用户通过怎样的方式来使用信息系统等问题。

用户是站在信息系统的使用者角度提出需求的，他一般不会细致考虑自己所提出的需求与组织的目标是否吻合，与组织的业务模式是否一致，组织目前的经济能力是否能够承担他所提出的系统要求，新系统给组织所带来的效益是否就一定高于所花费的成本。这些需求，从技术上是否能够实现和便于实现，用户所提出的需求是否十分完满而不存在疏漏等问题。以上这些问题都需要系统分析员综合组织的目标、业务现状、技术条件和投资能力等因素进行分析，以便确定出合理、可行的信息系统需求。

1.2　需求分析的工作内容

1.2.1　需求调查

需求调查（requirement investigation）也被称为需求获取，是由分析人员通过座谈、走访、问卷、召开座谈会等形式，深入了解用户对新建立信息系统的需要和要求，来获取用户需求。

1.2.2　需求分析

需求分析是对获取的用户需求，通过综合考虑组织目标、现状、技术条件、投资能力等因素，从信息系统目标、结构、功能、性能、风险等方面进行深入分析，最终确定出合理、可行的信息系统需求。

1.2.3　需求描述

需求描述（requirement description）是建立信息系统的需求说明文档，把需求分析的结果采用规范的形式描述出来，形成需求规格说明，作为下面开发工作的依据。

1.2.4　需求验证

需求验证（requirement validation）是由分析人员通过一定手段对初步确定的信息系统需求的正确性和可行性进行验证，以确定正确和可行的需求，排除不可行的需求。需求验证的方法很多，在此，我们仅介绍四种需求验证的基本方法。

自查法：自查法由需求分析人员对自己所确定的信息系统需求进行审核和验证，纠正需求中存在的问题。自查法又可以分为多种具体方法。第一种是小组审查法，即由一名分析人员向开发小组中其他人员介绍信息系统需求，小组中的成员进行提问，由介绍人进行解答。

用户审查法：用户是需求的提出者，也是信息系统的最终使用者，因此，由用户来审查需求是最权威的审查。分析人员可以把《信息系统需求说明书》提交给用户，有条件时可以同时编写一份针对此需求的《用户使用说明书》并提交给用户。用户通过对需求文档的阅读找出不符合用户意图或用户认为不能实现的需求，双方再对这些有争议的需求进行讨论，最后达成一致认识。

专家审查法：专家审查法是指聘请业务领域、信息系统、政策、法律等方面的专家对信息系统需求进行审查。专家能够对用户和分析人员存在争议的需求以及隐藏着重大问题的需求进行甄别和判断。

原型法：原型法是对存在的有争议或拿不准的需求，通过建立原型进行验证，以确定需求的正确性。原型法是验证需求的一种十分有效的方法，同时也是帮助用户理解需求的一种好方法，但它要求有原型生成环境的支持。

1.3　需求分析应注意的几个问题

1.3.1　充分认识需求分析的重要性和复杂性

需求是所要开发的信息系统的依据和准绳。如果需求出现缺陷和漏洞，开发出来的信息系统肯定满足不了应用的要求。另外，信息系统开发具有错误放大效应。在前期存在的问题如果留到后续阶段解决，所要花费的气力和代价会成数倍到数十倍增大。因此，分析人员需要高度重视需求分析工作，把需求分析工作做细致、扎实，保证能够得出合理、可行的需求，不要把前期能够确定的需求问题遗留给后续阶段。

1.3.2　充分重视需求的全面性和合理性

信息系统为组织管理服务，组织中的所有人员都有可能成为信息系统的使用者，他们对信息系统都有各自的要求，信息系统也应该尽量满足各个用户的工作需要。信息系统需求应该具有全面性。

信息系统需求还应该具有合理性。每一个用户都是站在各自的角度提出需求，所提出的需求就有可能与组织的目标、现状、能力相矛盾，用户所提出的需求之间也可能存在矛盾和冲突。这就要求分析人员对用户需求进行认真分析和取舍，最后确定出既能够照顾到各方面用户的要求，又符合组织目标和业务管理现状的合理、可行的信息系统需求。

1.3.3　充分尊重用户意见

用户是信息系统的使用者，也是信息系统的投资者，用户对信息系统需求具有决定权。在需求分析中，开发人员应该充分了解用户的意图和想法，尽可能地满足用户的要求。如果因为技术、环境、投资等方面的原因不能满足或不能完全满足用户要求时，必须给用户讲清楚，征得用户的理解和承认。最后形成的信息系统需求分析结论也必须征得用户的同意。

1.4　需求调查

1.4.1　需求调查的内容

总体需求：总体需求是用户对所建立的信息系统的总体要求。它包括信息系统应该达到的总目标，信息系统的范围，信息系统的总体构成和结构，信息系统应该具备的核心功能等。

功能需求：功能需求是信息系统应该提供的功能和能够达到的效用。功能需求是对总体需求的分解和细化。信息系统的功能具有层次性。按不同的划分标准，有信息系统总体功能、子系统功能和明细功能；有抽象功能和具体功能；有核心功能和辅助功能。

性能需求：性能需求包括信息系统的效率、处理方式、可靠性、安全性、适应性等技术要求。不同系统具有不同的性能要求。例如，联机事务处理型信息系统要求具有较快的响应速度，而一般事务处理系统对响应速度的要求则可以相对低一些。

其他需求：除了以上三方面的需求之外，还应该调查用户的投资能力、开发时间、开发队伍、社会法律等方面的非技术性需求。

1.4.2　需求调查的方法

系统调查的工作应该遵循如下几点：自顶向下全面展开，分析有无改进的可能性，工程化的工作方式，全面铺开与重点调查结合，主动沟通和亲和友善的工作方式。

自顶向下全面展开：系统调查工作应严格按照自顶向下的系统化观点全面展开。首先从组织管理工作的最顶层开始，然后再调查下一层（第二层）的管理工作。完成了这两层的调查后，再深入一步调查下一层（第三层）的管理工作。依此类推，直至摸清组织的全部管理工作。这样做的目的是使调查者既不会被组织内部庞大的管理机构搞得不知所措、无从下手，又不会因调查工作量太大而顾此失彼。

弄清它存在的道理再分析有无改进的可能性：组织内部的每一个管理部门和每一项管理工作都是根据组织的具体情况和管理需要而设置的，我们调查工作的目的正是要搞清这些管理工作存在的道理、环境条件以及工作的详细过程，然后再通过系统分析讨论其在新的信息系统支持下有无优化的可行性。所以在系统调查时最好是保持头脑冷静和敞开；实实在在地搞清现实工作和它所处的环境条件。如果调查前脑子里已经有了许多的“改革”或“合理化”设想，那么这些设想势必会先入为主，妨碍你接收调查的现实情况信息。这样往往会造成还未接触实质问题，就感觉到这也不合理，那也不合理，以至无法客观了解实际问题。

工程化的工作方式：对于任何一个企业来说，其内部的管理机构都是庞大的，这就给调查工作带来了一定的困难，对于一个大型系统的调查一般都是多个系统分析人员共同完成的，按工程化的方法组织调查可以避免调查工作中可能出现的一些问题。所谓工程化的方法就是将工作中的每一步事先都计划好，对多个人的工作方法和调查所用的表格、图例都统一规范化处理，保证群体之间的沟通和协调。另外所有规范化的调查结果（如表格、问题、图、所收集的报表等）都应整理后归档，以便进一步工作时使用。

全面铺开与重点调查相结合：如果是开发整个组织的信息系统，开展全面的调查工作是当然的。如果我们近期内只需开发组织内部某一局部的信息系统，这就必须坚持全面铺开与重点调查相结合的方法，即自顶向下全面展开，但每次都只侧重于与局部相关的分支。例如我们只需开发企业生产作业计划部分，调查工作也必须是从组织管理的顶层开始，先了解总经理或厂长的工作，公司或工厂管理委员会的分工，下设各个部门的主要工作，企业年度综合计划的制定过程以及所涉及的部门和信息，然后略去其他无关部门的具体业务调查，而将工作重点放在生产部的计划调度和物资供应的具体业务上。

主动沟通和亲和友善的工作方式：系统调查项涉及组织内部管理工作的各个方面，涉及各种不同类型的人，因此调查者主动地与被调查者在业务上进行沟通是十分必要的。创造出一种积极、主动、友善的工作环境和人际关系是调查工作顺利展开的基础，一个好的人际关系会使调查和系统开发工作事半功倍，反之则事倍功半。但是这项工作说起来容易，做起来却很难，它对调查者和开发者的主观态度和心理行为等方面都有较高的要求。

需求调查的方法与现行组织系统的调查方法很类似，需要通过面谈、走访、问卷调查、召开座谈会等形式进行。一般用户在开发之初，对所要开发的信息系统应该具有的功能和所能达到的结果并没有清楚的认识，因此，需求调查比现行组织系统调查难度更大，除了采用一般调查方法之外，还需要采用以下辅助方法。

启发法：由于用户对所要开发的信息系统应该具有的功能和能够达到的效果并不十分清楚，这就需要调查人员在需求调查过程中，能够对用户进行引导和启发，向用户详细介绍信息技术对人们工作和生活方式所带来的巨大变化，信息技术的巨大能力，信息技术可以对现行组织管理和业务过程能够进行的革新和改造，信息技术在本领域中的应用范例等。让用户产生信息系统的感性认识，启发和引导用户发现现行组织管理和业务处理中所存在的问题，发现潜在的需求。

观摩法：在系统开发之初，可以让用户参观同行业或同类型成功的信息系统。用户看到这些具体系统，将会对信息系统的功能、作用、外在效果、人机交互方式等产生直观印象，这样就会引导和启发用户，通过类比思维，提出自己信息系统的需求。对信息系统没有直观感觉的用户采用观摩法是一种十分有效的方法。

原型法：原型法是通过原型生成系统，根据用户的初步需求，构造出信息系统的初步原型。用户和调查人员针对所生成的原型进行讨论，分析原型是否准确地反映了用户的初衷，哪些方面还应该改进和加强。原型给用户和开发人员的交流和讨论提供了一个具体的参照物，有原型作为对象，需求调查就有针对性，可以澄清和纠正许多模糊和矛盾的用户需求。

1.4.3　详细调查的目的和原则

详细调查的对象是现行系统（包括手工系统和已采用计算机的管理信息系统），目的在于完整掌握现行系统的现状，发现问题和薄弱环节，收集资料，为下一步的系统化分析和提出新系统的逻辑设计做好准备。

详细调查应遵循用户参与的原则，即由相关部门的业务人员、主管人员和系统分析人员、系统设计人员共同进行。设计人员虽然掌握计算机技术，但对相关部门的业务不够清楚，而管理人员虽熟悉自身业务，却不一定了解计算机，两者结合，取长补短，有助于更深入地发现对象系统存在的问题，共同研讨解决的方案。

调查的方法可以采用：①召开调查会；②访问；③发调查表；④参加业务实践。参加业务实践是了解系统的一种很好的形式，对于复杂的计算过程如能亲自动手算一算，对以后设计和编写程序设计说明书都是很有益的一步。一个好的方法是在这个阶段就收集出一套将来可供程序调试用的试验数据，这对系统实施阶段考核程序的正确性很有用处。为了便于分析人员和管理人员之间进行业务交流和分析问题，在调查过程中应尽量使用各种形象、直观的图表工具。图表工具的种类很多，通常用组织结构图描述组织的结构，用管理业务流程图和表格分配图描述管理业务状况，用数据流图描述和分析数据、数据流程及各项功能，用判断树、决策表等描述处理功能和决策模型。

1.4.4　详细调查的范围

详细调查的范围：组织目标和发展战略，组织机构和功能业务，业务流程和产品构成，数据与数据流程，管理方式和具体业务的管理方法，决策方式和决策过程，可用资源和限制条件，现存问题和改进意见。

详细调查的范围应该是围绕组织内部信息流所涉及领域的各个方面。但应该注意的是，信息流是通过物流而产生的，物流和信息流又都是在组织中流动的。因此调查的范围就不能仅局限于信息和信息流，应该包括企业的生产、经营、管理等各个方面。下面我们把它大致地归纳为九类问题：①组织机构和功能业务；②组织目标和发展战略；③工艺流程和产品构成；④数据与数据流程；⑤业务流程与工作形式；⑥管理方式和具体业务的管理方法；⑦决策方式和决策过程；⑧可用资源和限制条件；⑨现存问题和改进意见。

以上九个方面只是一种大致的划分，实际工作时应视具体情况增加或修改。总之，目的就是真正弄清处理对象现阶段工作的详细情况，为后面的分析设计工作做准备。详细调查主要针对业务流程调查和数据流程调查两部分进行。

1.4.5　详细调查与初步调查的区别

详细调查与初步调查的区别：①目的不同，初步调查明确问题和系统开发要解决的主要问题和目标，论证系统开发的必要性和可能性；详细调查为了弄清现行系统的基本功能及信息流程，发现问题和薄弱环节，收集资料，为新系统逻辑模型提供基础。②内容不同，初步调查重点是了解现行系统的概要情况及与外部的关系，包括资源情况、能力情况、外部影响情况等；详细调查重点在于更详细和更具本系统的内部情况，从而可以提供在新系统建设时改进或更换的内容。

1.5　明确需求的方法

业务分析（business analysis）的目的是分析和认识现行组织系统。信息系统是为现行组织系统服务的，现行组织系统也是信息系统的基础和赖以存在的环境，只有对现行组织系统做到全面的解刨和分析，才能够开发出符合组织要求的信息系统。

需求分析的主要目的是详细了解现行系统的工作过程、业务流程，发现问题，寻找解决办法。基本任务：了解用户需求，提出这些需求的实现条件，以及需求应达到的标准；确定新系统初步逻辑模型；编写系统分析报告。拟解决的关键问题是对现行系统的组织结构、功能、业务流程进行详细分析，明确要解决的具体问题。

随着需求在开发过程中的不断演化，项目经常会超出计划的时间和预算（计划几乎总是过于乐观）。为了管理范围蔓延，必须一开始就对项目的业务目标、战略愿景、范围、边界和成功标准给予明确说明。以此为参照，对所有的新特性或者需求变更进行评估。需求会变，会发展。项目经理应当在时间表中设置应急缓冲区，以免打乱时间表。

软件客户的需求权利：① 期望业务分析师用自己的语言进行交流；② 期望业务分析师了解自己的业务和目标；③ 希望业务分析师用了解合适的形式记录需求；④ 收到需求实践和交付物的相关解释；⑤变更需求；⑥ 期望一个相互尊重的环境；⑦ 聆听关于需求以及解决方案的建议和替代方案；⑧描述能够提高产品易用性的特性；⑨ 了解调整哪些需求可以实现复用，加速产品开发；⑩ 收到满足自己功能需求和质量预期的系统。

软件客户的需求责任：① 给业务分析师和开发人员传授你的业务知识；② 准备足够的时间用来澄清需求；③提供具体而准确的需求；④ 及时对需求的进行确认；⑤尊重开发人员针对需求可行性和成本的估算；⑥和开发人员协作设置符合实际的需求优先级；⑦ 评审需求和评估原型；⑧ 设定验收条件；⑨及时沟通需求变更；⑩ 尊重需求开发流程。

明确需求的方法：①抽象，从含糊的要求中抽象出对信息和信息处理的要求；②量化，对各种要求确定定量的标准；③汇总，对于罗列出来的各种问题及要求，应认真分析它们之间的相互关系，根据实际情况抓住其中的实质需求。

1.6　系统分析的工作步骤

1.6.1　详细调查、收集和分析用户需求

在系统规划时所做的初步调查只是为了总体规划和进行可行性分析的需要，相对来说是比较粗糙的。现在，则应在初步调查的基础上，进一步收集和了解、分析用户需求，调查用户的有关详细情况。

1.6.2　确定初步的逻辑模型

逻辑模型是指仅在逻辑上确定的目标系统模型，而不涉及具体的物理实现，也就是要解决系统“干什么”，而不是“如何干”。逻辑模型由一组图表工具进行描述。用户可通过逻辑模型了解未来的目标系统，并进行讨论和改进。

1.6.3　编制系统说明书

对上述采用图表描述的逻辑模型进行适当的文字说明，就组成了系统说明书。它是系统分析阶段的主要成果。系统说明书既是用户与开发人员达成的书面协议或合同，也是管理信息系统生命周期中的重要文档。

1.7　医院信息系统需求分析

需求分析是系统开发工作中最重要的环节之一，实事求是地全面调查是分析与设计的基础，这一步工作的质量对于整个开发工作的成败来说都是决定性的。同时需求分析工作量大，涉及的业务和人、数据、信息都非常多。因此如何科学地组织和有效地展开这项工作是非常重要的。

医院信息系统不是简单地模拟现行手工管理方法，而是根据医院管理模式采用科学化、信息化、规范化、标准化理论设计建立的。在建设医院信息系统前，医院必须首先规范自身的管理制度及运行模式。医院信息系统建立的过程，应是医院自身规范管理模式和管理流程，提高工作效率，不断完善机制的过程。