3　系统集成的应用需求分析

系统集成的基本目标是满足最终用户的需求，是按照用户的需求，建立应用需求规格书，构建信息化集成系统。系统集成过程中，将用户的实际需要变为对信息化集成系统的功能要求，变为信息化集成系统的应用需求规范是一件十分困难的事情。一个企业的信息化集成系统项目伊始，应用需求分析便成为最初的难点。对应用经验不足的系统集成商，或是对较大的系统集成项目，应用需求的把握可能始终伴随着工程全过程，直到项目的后期，还需回过头来进行需求分析。应用需求分析是信息化集成系统项目成败的关键因素之一。

应用系统开发实施过程中，由于从事的职业和技术的局限，用户很难准确地把应用系统的需求表达给系统开发人员；由于业务知识的局限，开发人员也很难准确获取用户真实的应用需求，因此，需求信息的不对称和需求描述的错位，往往容易引起系统设计的缺陷，从而导致应用系统不理想甚至系统失败。需求调研和分析是信息化集成系统建设的第一步，也是非常关键的一步。本讲对应用需求的分析面向工业信息系化集成项目的领导者、管理者、系统设计师、软件架构师、软件开发团队负责人和项目相关的工程技术人员，提供信息化集成系统应用需求分析的总体技术观点。需求分析的技术细节特别是软件需求工程的技术细节，诸如，建模、软件需求分析的具体方法等应去参考专著和专门的技术文件。

3.1　应用需求分析的一般方法

3.1.1　应用需求分析的四个过程

大型工业企业构建其信息化集成系统的第一步是进行系统的规划，此项工作一般由一些著名的做信息化规划的大公司来完成。应用需求的总体要求包含在这些信息化规划之中。具体应用需求分析包括四个过程：

应用需求定义：应用需求就是从用户的应用特点出发，依据企业总体规划和目标，对系统进行细化描述，就系统功能、性能、规格、行为、运行环境等提出要求。

从系统特点分析，应用需求主要分为功能需求和性能需求；功能需求主要描述系统要完成的目标，系统能够解决的问题，帮助用户完成什么工作；性能需求主要描述系统性能指标上要达到的要求，主要包括系统可靠性，系统响应性指标（响应时间、平均无故障工作时间、故障后自动恢复时间等）软硬件环境的限制指标和其他的设计约束等。

从应用特点分析，系统需求可分为基本需求和特定需求（许多大型信息化集成系统项目中，称为用户通用要求与专用要求）。在特定需求中又可细分为必需的特定需求和非必需的特定需求。一般来说，特定需求往往决定系统的二次开发。

在系统集成工程中，一种较为成功的方法是开发出功能点表。功能点表详细列出了功能要求及其实现的场景，系统集成师与软件开发人员将这些功能分为现有软件平台可以实现的功能和需要在开放平台上开发的功能。进而言之，应用需求分析的核心和落脚点是软件需求分析，最终要将系统的功能需求转化为软件架构和编程的需求。

应用需求调研：需求调研的过程是获取用户需求的过程。首先要调查清楚系统应用部门的所有用户类型以及潜在的类型，根据他们的要求来确定系统的整体目标和系统的工作范围，然后对用户进行访谈和调研，交流的方式：专题座谈会、单独面谈、电话交流、电子邮件、小组讨论、模拟演示等不同形式。交流一定要有记录，交流的结果进行分类，以便于后续的分析活动。

需求调研通常涉及三个问题：（1）如何确定调研人员；（2）如何确定被调研对象；（3）采用何种调研方法。需求调研人员的组成应以互补为原则，至少要由三类人员组成：技术人员、业务专家和管理者。调研范围包括关键域和关键活动。关键活动又由关键流程和关键点构成。找到关键域，明确关键流程的关键点，对于需求调研至关重要，需要专家或咨询顾问介入。而能否把握这一时机并找准需求提炼的关键点，是考验需求调研人员的重要方面。优秀的需求调研人员不仅能认识问题之所在，还能藉此获取足够多的知识，最后成为这些问题领域的专家。

对于用户提出的每个需求都要弄清“为什么”，并判断用户提出的需求是否有立足的理由；将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；分析由用户需求衍生出的隐含需求（有可能是实现用户需求的前提条件）。

用户需求调研涉及到用户和系统分析人员双方，为了使用户需求调研工作顺利进行，必须事先制定一个调研计划。调研计划中包含调研计划基本信息、时间安排、调研内容、接待部门和人员、调研成果等5个方面的信息。具体调研方法较多经常采取的调查方法主要有表格调查法、座谈调查法、查阅资料法和现场观察法4种。

应用需求分析：应用需求分析是信息化集成系统系统集成中非常重要的内容。应用系统需求分析应包括应用需求调研、模拟和分析需求、需求描述、需求认可、需求演进五个层次。应用需求分析是信息化系统软件工程的核心，贯穿于系统整个生命周期。

应用需求分析和模拟又包含三个层次的工作：需求定义、需求建模、需求模拟。需求定义是对经调研获取的需求进行初步整理，抽取其中基本需求和关键需求予以界定，并为需求建模提供必要的需求元素。需求建模是把抽象的需求通过概念、符号、数学模型及逻辑结构表现出来。表现形式有自然语言、半形式化（如图、表、结构化英语等）和形式化表示等三种。

在很多情况下，分析用户需求和获取用户需求往往是并行的，通过建立需求模型的方式来描述用户的需求，为系统客户、用户、开发方等不同参与方提供一个交流的平台和遵循的依据。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的渠道。分析用户需求的过程实际上也是一个建立模型的过程。

用于系统需求建模的方法有很多种，按照软件工程的方法，最常用的包括数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式。

在面向对象分析的方法中，通常使用Use Case来获取软件的需求。Use Case通过描述“系统”和“活动者”之间的交互来描述系统的行为。通过分解系统目标，Use Case描述系统可见对象的交互行为。UseCase方法最主要的优点在于它是用户导向的，用户可以根据自己所对应的Use Case来不断细化自己的需求。此外，使用Use Case还可以方便地得到系统功能测试的用例。

需求风险及控制：既然应用需求对构建信息化集成系统成败起到如此关键之作用，对应用需求风险的控制就变得尤为重要。在应用软件开发过程中，由于软件需求本身的隐含性、用户与开发者之间的沟通障碍，以及需求随着时间、用户的变化而变更等原因，可能使需求分析偏离实际需求而最终导致软件开发的失败，这种可能性称为需求风险。总结企业信息化集成项目实施过程中遇到的需求问题，大致可将需求风险归纳为如下几种类型：（1）需求频繁变更，项目范围被随意扩大，导致项目的成本费用增加、开发周期延长、开发质量和工作效率下降；（2）缺乏明确的部门或人来真正对需求负责，造成业务需求缺乏规划，需求的片面性和矛盾性比较突出，需求质量受到需求提出者个人能力的影响；（3）受专业领域所限，技术人员和业务人员在沟通上存在着一些障碍。（4）开发人员将兴趣点更多放在技术产品和程序编码上，对需求分析工作的关注度和精力投入不足，造成了实际系统与用户期望不符；（5）业务人员对项目初期的需求确认缺乏足够重视，往往等到系统上线后才提出各种问题，严重影响了项目的实施效果。

针对上面谈到的那些典型需求风险，通常可考虑从以下3个方面实施风险控制：

对需求变更的控制：通常会采取以下几种措施来实施需求变更控制；（1）建立项目需求变更管理流程，由开发人员和需求人员共同组成需求评审组，对变更需求进行严格评审；（2）需求确定后，要建立明确的需求基线，并敦促业务人员要对需求确认这个环节的工作给予高度重视，以正式文件形式发送至业务部门签署确认意见；（3）与业务人员一起对变更的需求建立优先级，采取分批方式逐步实现，并注意确保核心模块的相对稳定；

对需求质量的控制：对需求质量控制的关键是要保证找到理想的需求调研对象。需求调研对象的角色、个人经验和能力将直接影响到需求的全面性、有效性和合理性。针对不同类型的调研对象，应注意采取适合的访谈方式，并在提问时给予必要的引导。开发人员可以根据以往项目积累的经验，提出一个比较成熟的原型需求，交给业务人员进行确认。

对需求理解差异的控制：由于业务人员和技术人员在专业背景上的不同造成对需求理解上存在差异，是导致项目返工和实施效果不理想的重要因素。要尽可能减小差异量，就需要双方对需求的沟通要尽可能充分。特别是开发人员，在进行需求调研时要注意多主动提问题，对不清楚的地方一定要反复确认，切不可含糊过关。此外，针对不同业务领域，可指定业务部门有经验的代表全程参与项目建设过程，随时进行需求沟通，及时消除在需求上的误解。　　

3.1.2　需求分析的两个阶段

在应用需求分析的过程中，一般分为：第一，用户需求分析、系统需求分析阶段。第二，软件需求分析阶段。

从用户角度看，第一阶段是他们的需求按照专业领域的要求来描述，似乎并不需要对软件开发需求负责。从软件开发的视角，第一阶段的需求应该完整、一致，明确无误，最好是稳定的不发生重大变化的。第二阶段的应用需求分析看似由软件开发人员来进行，但必须要应用系统设计人员与工程实施者从始至终参与。实质上，两个阶段的工作任务是一个整体，应以系统设计团队与软件开发团队密切合作为根本。最终制定出软件需求规格说明书（Software Requirements Specification，SRS）作为应用需求分析的成果。

（1）用户需求分析、系统需求分析阶段：此阶段包括业务需求分析，用户需求分析及系统需求分析。应由用户项目负责人与系统集成师为主制定用户需求规格书URS (User Requirement Specification) 。这是需求调研和分析的直接成果。好的需求规格书，其需求层次清晰，语言专业且精练，基本需求描述完整。特定需求既有现实性又有前瞻性，流程和结构定义准确，有可操作性等。需求规格说明书的主要服务对象可来自于用户、系统分析员、软件需求分析员、软件开发人员、程序员、测试员和项目管理人员等，但归根结底还是要尊重用户发展战略和机构运行策略所必需的现实和潜在的期望。如何及时获取和适应需求变化，并适时修改和整理系统需求文档而保持系统的进化，是系统成功的又一关键环节。可以说，基于需求演进项目管理效率直接决定系统能否支持用户的持续变革。

URS描述了信息化集成系统软件平台所应具有的外部行为，它包括最终交付的软件必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件（对开发人员在软件产品设计和构造上的限制）及质量属性。质量属性是通过多种角度对软件产品的特点进行描述，从而反映交付系统的功能，这些要求对用户和开发人员都极为重要。

URS必须满足以下要求：（1）完整性。每一项需求都必须将所要实现的功能描述清楚，以使开发人员能设计和实现这些功能。（2）正确性。每一项需求都必须准确地陈述其要开发的功能。这里只有用户代表才能确定用户需求的正确性。（3）可行性。每一项需求都必须是在已知系统和环境的能力和限制范围内可以实施的。（4）必要性。每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。（5）一致性。对所有需求说明都只能有一个明确统一的解释。（6）划分优先级。给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。（7）可验证性。检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现。

URS初始输入来自业务人员、用户，侧重于把系统要解决的业务逻辑、要实现的功能描述清楚，更宏观。在现代工业的系统集成项目中，URS更强调软件开发人员的参与，已经有了许多行之有效的编制URS的软件，甚至使用专门的URS APP软件来生成信息化集成系统的用户需求规格书。

（2）软件需求分析阶段：在URS的基础上，进入软件需求分析。在确定了系统的总体结构方案基础上，确定应用程序的结构、系统开发环境和系统的功能模块。从用户应用角度来看，可把应用程序系统的组成部分分成数据存储层、业务处理层和界面表示层等3个层次，而应用程序结构可归纳为：集中式应用程序结构、单用户应用程序结构、多层服务器应用程序结构、浏览器／服务器应用程序结构、客户机／服务器应用程序结构等5种类型。一个具体的软件开发项目，应该将应用程序的结构首先确立。

在基本功能块框架确定后，应由软件团队为主，进行软件需求分析工作，主要是完成软件需求规格书SRS（Software Requirements Specification）的制定。与URS相似，SRS也独具特点：（1）完整性。需求的完备性表达，不能遗漏任何必要的需求信息。注重用户的任务而不是系统的功能将有助于避免不完整性。（2）一致性。一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。（3）可修改性。在必要时或为维护每一需求变更历史记录时，应该修订SRS。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在SRS中出现一次，这样更改时易于保持一致性。（4）可跟踪性。应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（fine-grained）的方式编写并单独标明，而不是大段的叙述。

SRS与URS不同点是：（1）面向设计、开发人员。（2）侧重于把系统的约束、输入、输出和处理过程定义清楚并更具体。（3）是从业务规则讲起的，偏向于软件的概要设计，是从开发、测试的角度去说明产品功能，包含原型界面、业务接口、活动图等。

关于软件SRS，国际标准中推荐有SRS的模板供参考，重要的是理解其中的含意，这是软件需求分析阶段最重要的工作。

作者简介：

魏晓东，1967年毕业于天津大学精仪系。1984~1991年任安徽工业大学自动化系副教授。1991年出版《分散型控制系统》（ 上海科技文献出版社） 。2000~2012年任北京和利时系统工程公司副总工、事业部总设计师，北京地铁13号线、深圳地铁一期工程、广州地铁3号线综合监控系统工程技术总负责人。2006、2010年出版《城市轨道交通自动化系统与技术》初版与第二版（电自工业出版社）；2010年主编国家标准《城市轨道交通综合监控系统工程设计规范》（GB50636-2010）《城市轨道交通综合监控系统施工与质量验收规范》（GB/T50732-2011）；2010年主编关于两化融合的国家标准《工业企业信息化集成系统规范》（GB/T26335-2010）。2013年至今任清华同方数字城市工程中心技术专家，住建部城市轨道交通标注技术网Eu委员会委员，全国自动化系统与集成标准技术委员会委员。

摘自《自动化博览》2017年3月刊