科技应用项目中软件需求分析探究

荆 澎

一、引言

软件工程中，软件需求分析 （Software Reguirement Analysis）是指研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，从而导致投入分析的精力和时间过少，启动开发过快。在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程。假如在需求分析时我们作为系统分析和开发人员，未能正确地认识到用户的需要的话，那么最后的软件实际上不可能达到用户的需要，或者软件无法在规定的时间里完工，软件项目失败的风险倍增。

我们做需求分析的目的是完整、准确地描述用户的需求，跟踪用户需求的变化，将用户的需求准确地反映到系统的分析和设计中，并使系统的分析、设计和用户的需求保持一致。合理划分需求分析工作流程、掌握科学的方法和手段，进而形成确定、严谨的交付物，才能为后续开发、测试、运维奠定可靠、坚实的基础。

二、软件需求分析的流程划分

需求分析的流程可划分为三大阶段，分析流程与需求组成如图1所示：

图1

（一）明确项目意义、背景以及技术实现框架

第一阶段首先要充分理解项目立项的背景、意义及目标要求，即业务需求。要充分了解项目所处的业务领域，明确该项目在整个领域的位置、作用以及与正在运行的项目、系统的关系，包括业务交叉关系以及技术依赖，等等。完成上述工作后，要结合已知情况选择技术实现的框架，包括开发工具、组件 （包括现有平台组件及可能需要的第三方组件）、开发、测试和运行的基础环境等。

（二）明确项目核心需求定义

第二阶段，我们需要做的工作就是确定项目的核心需求，即需求调研报告中涉及的用户使用系统必须完成的任务，也叫用户需求。同时，要完成用户需求对应的核心功能、质量和相关的制约条件。

所谓核心功能是指根据对项目的分析和调研规划，找出当前最迫切需要实现的、最能体现项目价值的关键功能。对于技术风险大的、与现有项目功能有歧义的，或者核心功能中相互冲突的功能要进行前期取舍。确定核心功能的过程是一个和用户不断沟通、技术上不断递归的过程。

此阶段在确定核心功能的同时要引入质量的概念，也叫非功能需求，即结合功能定义，从性能、可靠性、可扩展性、可维护性、可移植性即易用性、安全性等多个质量指标进行筛选，标准就是第一阶段获取的信息。

确定了核心功能、质量后还要充分考虑限制条件，即项目需求实现的特殊情况或者可能限制实现的条件，分为业务级、用户级和开发级等。例如业务表单流转依赖HB2008工作流组件设计等属于业务级；某些功能可能需要协勤人员操作，其认证等需要 “三统一”平台额外开发或者审批开通权限等属于用户级；必须运行在Windows操作系统下、必须使用国有自主知识产权的数据库产品或者一些不熟悉的技术领域依赖开发人员的水平等都属于开发级。

（三）进行项目详细需求分析

项目详细需求分析就是针对核心功能进行细化的业务逻辑和数据流需求调研分析过程，形成功能需求。此阶段要紧紧围绕核心功能做好以下工作：一要调查组织机构情况，包括了解部门组成情况，各部门的职能等，对其管理层次与线条建立全局了解，为分析信息流程作准备。二要调查各部门的业务活动情况，包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。特别要针对这些业务流程，绘制出跨部门职能流程图，帮助后续开发人员对用户的业务流程建立宏观、清晰的认识，以便更加有的放矢地进行进一步的需求捕获工作，此项过程要与用户反复验证，使需求功能描述明确清晰。三要协助用户明确对新系统的各种要求，包括信息要求、处理要求、完整性要求。四要确定新系统的边界，确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成，由计算机完成的功能就是新系统应该实现的功能，同时要注意提醒用户开始着手建立系统使用和操作规范及管理制度。

此阶段形成 《需求规格说明书》（SRS），内容包括功能描述、用户用例、数据流转图、业务逻辑图等，应包括上述三阶段软件系统所应具有的全部外部行为。其在后续开发、测试、质量保证、项目管理以及相关项目功能中都将起到重要的作用。

三、软件需求分析过程中存在的问题

由于软件需求分析的重要地位，这一过程中存在或者隐藏的问题直接会导致项目失败或者崩溃，应引起高度重视。问题主要存在以下几个方面：

（一）用户参与度不够

很多项目经常是由领导层面自上而下提出的，但由于工作繁忙，领导或者发起人不能保证具体参与需求讨论和调研，下属用户有时只能凭靠揣测领导意图来提需求。有时用户对项目非常渴望，但由于缺乏软件系统建设方面的专家和相关知识，对需求只有朦胧的感觉，具体说不清楚，就会泛泛而谈或者干脆要求分析人员替代他们设想需求，技术人员主观性早早带入分析过程，为未来的开发建设埋下了隐患。还有部分用户自侍业务精通，“越俎代庖”告诉技术人员很多其他部门业务需求，将需求调研带入歧途。

（二）不清晰、不稳定或无休止的需求

软件需求分析人员不可能都是全才，更不可能是行业方面的专家。对客户表达不清晰的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，后续可能使测试者与开发者所期望的不一致，导致开发工作劳而无功。另一方面，根据以往经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更，这都导致需求的不稳定。此外，用户不断地补充需求，项目就越变越庞大以致超过其计划及预算范围。计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致，这使得用户业务问题更难解决。

（三）不重视用户分类

根据以往项目经验，大多数系统是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果不在需求分析阶段就针对所有用户进行分类，考虑个性化需求的话，必然导致有的用户对交付的系统感到失望。

（四）技术人员的 “自以为是”

“自以为是”是指开发人员力图增加一些 “用户欣赏”但用户并未提及的新功能。经常发生的情况是用户并不认为这些功能有用，导致开发人员徒劳无功。

（五）轻视与过度重视

有些项目组在需求调研和分析时缺乏计划性、科学性，“走过场”。需求调研仅简单与用户闲聊、收集一些文档、表格就草草结束，轻率地开始编码，这种轻视的后果往往导致需求无法验证，很多情况下到项目交付时才开始履行验证过程，产生大量的需求变更，后果非常严重。另一种情况，项目组过度重视需求规格说明书的编写，为编写而编写，甚至出现工程组内部 “白天写文档，晚上写代码”的情况。产生出的文档经常与实际开发脱节，完成后就束之高阁，不再使用、不再验证和更新，这也是需求崩溃的一个重要原因。

四、软件需求分析的几种方法和工具

由于对需求分析的理解不同，使用的方法也多种多样。根据以往我们的经验，业界比较成熟的“三步法”更符合海关实际工作。

（一）“访谈式”（Visitation）

第一步关键是要与项目提出人、用户领导层、业务层，即持有重要业务信息的人进行访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等具体情况、客观的信息。访谈的渠道和方式可以多样，例如需求专题会议、电话、邮件等，并针对具体的部门指定项目的业务联系人。沟通应尽可能高效，应先根据已掌握的信息和需求列出问题提纲，既提高效率，又增加用户对技术人员的好感和信任。对不同的访谈对象，询问和讨论的主题和内容应注意区分：一般对于领导，要讨论目标、方向以及总体要求等问题，而不是业务细节。对于用户的业务层领导，要多询问一些业务流程方面的问题，他们在这方面最熟悉并有见解，软件的大部分需求一般都是这个层次的人员提出的，和这个层次的人员要注意关系上的协调；对于具体操作人员，可以多询问一些对方的操作习惯、业务处理的细节等问题；对于系统管理员，则可以讨论一些技术上的问题。每次访谈都应有详细的书面记录，可以使用Excel、Word等工具形成调查表格、报告，这是形成需求分析结果的基础和下次需求调研的前提，应力争每次访谈都使需求分析向前推进一个阶段。记录使用的语言须是用户熟悉的词汇，要使用明确肯定性语句，不要使用模糊的说法。

（二）“诱导式”（Inducement）

这一步是在充分访谈沟通、对用户获取了大量信息数据基础上，结合现有的硬件、软件实现方案，通过制作原型、统一建模语言、用例和敏捷软件开发等方法，使用Visio或者Axure RP等工具做出简单的用户流程演示及系统界面。同时，结合以往的项目经验，对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的DEMO，来感受整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。通过诱导和充分的再次交流，可以形成调研分析报告、原型反馈报告、业务流程报告等二次调研成果。

（三）“确认式”（Confirmation）

这一步是在访谈、诱导两步成果的基础上，进行具体的流程细化、数据项的确认阶段。这个阶段技术人员必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户可以通过审查业务流程报告、数据项表以及操作DEMO或者原型系统提出反馈意见，并对已经可接受的报告、文档签字确认。目前海关科技应用项目管理中推广使用的 “任务书”即为确认步骤的成果和载体。

整体来讲，需求分析的三个步骤是需求调研中不可忽视一个重要的部分，它们的实施和采用为项目成功提供了保证。在目前广为流行的 “迭代法”开发模式时，需求分析的工作将贯穿整个开发过程，需求改进中，主要工作则集中在后两个步骤中。

五、软件需求分析的人员配置

需求分析人员即需求工程师，其必须具有开发背景和实战经验，和程序开发人员针对问题采用技术解题的 “分解能力”相比，其更应该具有的是与用户沟通交流、找出问题的 “合成能力”。需求工程师与人的交流能力要胜于与机器的交流能力，他的自然语言表达能力要胜于编程语言表达能力。需求分析是一个综合团队的工作，是在需求分析理论的指导下，对用户需要进行渐进方式逐步深化，应以产品的眼光看待每个项目，因此，需求分析可以看做是商务行为，是一个商业化操作，要求由商务活动人员 （包括需求工程师）、项目管理人员、设计技术人员等结合的团队共同合作，各自明确负责范围、工作目标，解决需求和设计的同步问题，努力做到设计符合需求。

六、结束语

需求分析作为项目开发阶段的开端，是软件工程的真正开始。需求分析是所有软件成功要素发挥作用的前提，它的好坏直接影响着后面的各个阶段，关系着软件的成败。软件项目中40%至60%的问题都是在需求分析阶段留下的隐患。青岛海关技术处近十年来，注意跟踪业界先进的软件开发管理理念，高度重视需求分析工作，自2005年以来，先后在所承办的署级 “保税作业监控分析系统”、“海关政府采购业务信息平台”、H2010工程 “海关综合业务管理平台”等重大软件应用项目中遵循软件开发的客观规律，组建专门的需求分析团队，全面启用科学的需求分析方法，保证了项目开发建设质量，所开发的系统易用性、可靠性、稳定性以及可扩展性得到显著提升，获得海关业务部门和人员的广泛好评。

〔1〕Karl E.Wiegers，刘伟琴，刘洪涛 .软件需求 〔M〕.第2版 .北京：清华大学出版社，2004.

〔2〕徐赛华 .软件需求分析研究 〔J〕.吉林师范大学学报，2006 （1）.