浅析需求分析在业务系统开发中的重要性

2021-01-12帅晓华

数字通信世界 2021年12期

帅晓华

（长江职业学院，湖北武汉 430000）

0 引言

功能完善的业务系统是实现业务办理规范化、流程化、系统化的重要保障。业务系统功能是否完善，是否符合使用单位的业务流程以及操作习惯，将直接影响业务办理的效率和办理质量。业务需求是使用单位对业务系统诉求的直接表现，是业务系统的核心，需求分析则是实现业务需求收集、整理、深入挖掘使用单位潜在需求，进行需求确认的过程，该过程为正确的开发业务系统奠定基础[1]。

1 软件生命周期概述

软件的生命周期同其他事物一样，都会经历酝酿、产生、成长、成熟、衰退的过程，根据各个过程的特点，软件的生命周期主要分为以下几个阶段：

1.1 问题定义

问题定义就是确定好要解决什么问题，这些问题解决后要达到什么效果，会带来多少经济效益，生产力能提高多少，出错率可以降低到什么程度等。要确定解决什么问题，通常是通过对系统使用单位进行深入调研，通过多次的沟通和详细访谈，需求分析师整理出关于问题的性质、建设目标、预计使用范围以及系统规模等内容的书面报告，经过讨论和必要的修改之后得到客户的确认。

1.2 可行性研究

可行性研究是指对系统使用单位要解决的问题，是否存在一套可以解决的方案、在该阶段的任务不是具体的解决问题，而是研究问题的范围。问题范围可包括是否存在可以解决的方法，是否存在技术风险、时间风险、资金风险、运行环境风险以及人员风险等，如果存在这些问题，是否有稳妥的解决方案。可行性研究的结果以可行性研究报告体现，可行性研究报告是业务系统使用单位决定是否进行该业务系统开发的重要依据。在可行性研究报告中，要对项目执行过程中可能产生的问题和风险进行逐一论述，给出明确的处理办法。

可行性研究报告包括技术可行性、资金可行性、时间可行性等方面。技术可性主要对技术是否可以实现进行详细阐述；资金可行性主要是根据用户预算情况以及资金情况进行可行性分析，该工作由用户进行分析并给出分析结论；时间可行性主要是涉及用户对业务系统的上线时间的预期，该工作由双方共同进行分析并给出分析结论。只有可行性分析报告中的重要问题全部解决，才能进行后续工作。

1.3 需求分析

需求分析首先要收集需求，然后再对收集到的需求进行分析。收集需求主要是通过深入了解业务系统使用单位的诉求，在业务系统中要解决什么问题以及解决问题的方式方法等细节与业务系统使用单位达成完全一致；明确业务系统的建设目标、检验标准、业务系统必须实现哪些功能以及系统界面中要包含哪些数据元素等。分析需要主要是分析需求的合理性、完整性、冗余性、可扩展性、可合并性以及需求是否收集完整、是否还有遗漏、多个需求之间的强关联性，通过多次与使用单位使用人员以及高层领导进行沟通，最终形成《需求规格说明书》，《需求规格说明书》需要得到使用单位的最终认可和确认[2]。

1.4 系统设计

系统设计以《需求规格说明书》为依据。按设计的详细程度不同，系统设计又分为概要/总体设计和详细设计。在实际工作过程中，根据业务系统的复杂程度决定是进行概要/总体设计还是详细设计。

概要/总体设计是对系统整体功能、系统架构、运行环境、网络结构以及系统实现方式进行粗略设计，不要求详细到完整的功能界面和功能点的输入输出参数的定义和说明。概要/总体设计以《概要/总体设计说明书》的形式呈现。

系统详细设计以《概要/总体设计说明书》或《需求规格说明书》为依据，对系统具体的功能实现方式、业务流程、页面元素以及数据逻辑校验规则进行详细的阐述，同时详细说明各项功能之间的逻辑关系，数据约束关系，数据库表之间的关联关系、各个数据表中字段名称、字段类型、数据长度、是否为空，字段取值范围的详细规划，各业务功能模块使用到数据表说明等。详细设计以《详细设计说明书》的形式体现。

1.5 编码和单元测试

编码和单元测试以《详细设计说明书》或《概要/总体设计说明书》为依据进行编码和单元测试，最终形成系统源代码和《单元测试报告》。在编码过程中对功能需求有疑问时，需要查看原始需求、需求规格说明书以及与需求分析人员进行讨论，甚至需要到客户现场与具体使用人员进行沟通并确认。单元测试主要是测试功能模块的完整性、健壮性、执行结果的正确性以及与设计说明书中对功能描述的一致性，特定功能性能是否达到设计要求等多方面的测试。

1.6 综合测试

综合测试以《测试方案》、《需求规格说明书》、《概要/总体设计说明书》、《详细设计说明书》为依据进行系统各项功能测试，测试内容和范围包括业务功能实现的正确性，数据逻辑正确性，业务功能实现与需求规格的一致性，业务模块之间的耦合性、完整性以及业务功能实现是否有遗漏，系统并发处理能力以及业务响应速度等方面进行测试。综合测试以《综合测试报告》的形式体现。同时《综合测试报告》的结果直接决定该业务系统是否具备上线试运行以及是否达到交付标准。

1.7 系统上线试运行

业务系统经过综合测试并达到上线标准后，进行客户现场安装部署，进入试运行期。试运行期间主要收集系统业务功能是否满足日常业务办理需要，系统运行是否稳定、业务功能实现与实际工作流程是否一致等，根据收集结果定期对系统进行系统功能完善和系统性能调整，使系统逐步完善和稳定。

1.8 系统维护

系统正式上线后，在业务系统功能满足的条件下进行系统验收，系统验收后进入系统维护阶段。在系统维护阶段主要解决系统功能缺陷问题以及系统运行性能问题。

2 需求分析在业务系统开发中的重要性

通过对软件生命周期的分析可以发现需求分析贯穿于软件的整个生命周期，只是在项目前期阶段需求分析的工作量比较大，在进入系统设计、编码、测试、上线试运行以及维护阶段，需要分析的工作量占比明显减少。

通观软件生命周期，我们发现需求分析阶段的工作是后期所有工作的基础，如果在需要分析阶段出现问题，可能导致项目严重延期、甚至造成系统功能完全不能满足或完全错误的情况发生。

2.1 需求分析的正确性

需求分析需要专业的需求分析人员与业务系统使用人员进行充分沟通，认真听取并记录业务系统使用人员的全部诉求，用自然的、通俗易懂的语言对用户需求进行完整的、原始的记录，并将记录给客户确认，做到记录与客户描述一致，从而正确理解用户的原始需求，形成原始需求。对客户诉求是否能够正确理解将直接关系到后期开发出来的业务功能是否是用户最终所需，如果对客户的原始需求理解错误将导致后期开发出来的功能不是用户所需，甚至与用户需求大相径庭，可能导致某个业务功能开发返工、甚至造成为正确满足用户业务需求而进行系统基础架构重构、造成人力成本增加、交付延期、客户满意度下降等不良后果。

2.2 需求分析的完整性

需求分析是否完整将直接影响业务功能、业务流程是否完整。如果在需求分析阶段对用户需求没有记录完整或没有询问完整，后期将导致部分业务功能缺失，给用户使用造成极大不便，甚至导致部分或全部业务功能无法正常使用，从而不得不对已开发完毕的业务功能进行打补丁，这样有可能造成已有业务系统的架构混乱，甚至造成只有大量修改系统基础架构才能勉强满足用户真正的业务需求的情况出现，给系统的稳定性埋下祸根，造成系统性能下降，甚至严重影响到开发测试人员的情绪，给项目团队管理增加额外的负担，给客户造成不良影响。

2.3 潜在需求的挖掘

在实际工作中，大多数业务系统使用者是不专业的，他们提出的业务系统需求在通常情况下是不完整的，大多数只是提到在工作中经常使用的业务功能，对于部分在工作中使用频率不高但是又必须使用的功能往往会忽略，甚至会由于考虑不周而没有提出来，对于这部分潜在需求，在进行需求分析时需要专业的需求分析师给用户提出来，告诉用户这些功能如果没有将会给后期系统使用造成哪些不便，以便用户进行选择和确认是否需要这些功能。

这些潜在需求一般情况下是在业务系统开发完毕交付用户正式使用后，用户在实际的业务办理过程中才会逐渐发现，这些潜在的需求对用户顺利使用系统可能会造成极大不便，甚至给用户使用系统办理业务增加不必要的工作量，导致用户抵制使用系统的情绪产生，甚至影响到系统的正常验收。

对于强势的用户可能会要求在本期项目建设中将这些潜在的功能全部实现，造成项目建设周期延长，人力成本增加；同时由于在项目前期完全没有考虑这些潜在需求的存在，要实现这些潜在的需求可能会造成数据库大量数据表的修改，通过大量程序代码修改以及系统界面的调整用于满足这些潜在需求，导致开发测试人员抵制情绪加深以及对需求分析师的不满、产生内部矛盾，使团队的稳定性受到影响。

由此可见，在需要分析阶段对用户潜在需求的深入挖掘和正确引导、可以减少系统功能的缺失和功能不完善的情况发生，将这些问题解决在系统设计和编码之前，从而使系统功能更完整，系统运行更稳定，最终用户更满意，开发团队更和谐，系统交付进度更快速。

2.4 需求分析贯穿系统开发整个过程

需求分析贯穿于业务系统开发的整个过程，直至业务系统下线。只是在项目前期工作比较集中，在代码开发、综合测试、系统上线试运行以及业务系统维护阶段需求分析工作比较少，但并不表明在这些阶段需求分析的工作不存在。

3 正确的需求分析方法及注意事项

正确的、完整的需求分析，以及对潜在需求的深度挖掘是保证系统成功交付的重要条件。只有使用正确的需求分析方法才能保证需求分析的正确性、完整性以及对潜在需求的深度挖掘。

在进行需求调研前，需求分析师要先深入了解用户业务特征、业务流程、业务涉及的政策法规和法律条文等，从而为进行需求收集做好充分的准备。在进行需求收集和需求分析时，可以根据不同的用户对象以及系统分析师的自身技能选择使用有效的需求分析方法。

3.1 表格记录法

表格记录法是指在进行业务功能调研前，对该业务功能可能涉及的法律条文、业务特征、业务流程、业务功能、业务数据元素、数据间的约束关系进行表格化和明细化，在与客户沟通过程中对表格中已记录的内容进行不断完善和修改，使表格中最终记录的内容与用户描述完全一致，最终由业务系统使用人员进行确认，避免双方对相同的业务功能理解产生分歧。

在使用表格记录法时，对业务功能中涉及的数据元素的来源、取值范围、数据元素之间的逻辑关系也要详细说明并与最终用户进行一一确认。

3.2 系统原型法

系统原型法是最直接最有效的需求分析方法，该方法通过与客户进行详细沟通，制作系统原型，在系统原型中除了业务数据是静态的以外，其他的业务流程、业务数据项、数据项在界面中的位置、数据项之间的约束关系全部得以体现，同时在使用系统原型法进行需求分析时，最好能够拿用户实际办理的业务，与用户一起在原型系统中进行全流程的操作，从而记录系统原型与实际业务之间的差别，进行修改系统原型并进行再次确认，直到系统原型完全满足用户业务需求。

在使用系统原型法时，一定要与客户一起拿实际业务进行演练，不可将系统原型直接发给客户，最后问客户该原型是否满足他们的业务要求。如果这样做则可能会因为客户只是对系统原型进行大致浏览，总体上感觉已满足实际工作需要，可能导致实际上并不能完全满足业务需求的情况发生，为后期业务系统功能开发埋下祸根。

在使用系统原型法时，特别是对业务系统各功能界面中的以选项形式出现的数据要与客户确认这些选项是固定的还是可变的，选择不同的选项是否会对业务流程造成影响、选项数据的来源依据。

系统原型法在实际使用过程中会增大人力成本的投入，如果人力成本紧张可选择重点业务功能使用系统原型法，部分业务功能使用表格法的方式进行[3]。

3.3 类似项目对比法

类似项目对比法也是行之有效的需求调研方法，该方法可以让用户直接的体验系统的各项功能，从而判断哪些功能是用户需要的，哪些与用户的实际工作类似但又不能满足实际工作需要。

该方法是在用户基本上无法提出自己的具体业务需求或用户已经考查过多家兄弟单位的系统后又觉得已有系统均无法完全满足自己实际业务需求的情况下使用。在使用该方法时，最好能够找到两个以上的应用系统，需求人员与最终用户一起对多个系统中用户要使用的功能进行具体操作，详细记录用户需要的功能以及这些功能不满足日常工作的原因或需要加强的内容，提出改进建议并征得用户的确认。在此基础上可结合表格法、系统原型法进行最终需求收集及确认，完成需求调研工作及确认工作。

3.4 需求一致性确认法

该方法适用于同一个业务功能有多人使用的情况，在这种情况下不同人对同一业务功能的要求也不完全相同，甚至对于界面操作提出完全不同的要求，在此情况下应该将所有的需求全部进行收集整理，最后给出多套解决方案，通过开会讨论的形式进行确认，使所有使用该业务功能的人员对需求达成一致，否则该功能将导致后期系统推广障碍。如果在开会讨论时无法达成一致，可以再次开会讨论会并邀请用户的领导参与，最由终领导督促形成统一意见。