基于统一建模语言的软件需求分析应用研究

邹楠，厉志成

摘要：需求是软件产品开发的重要输入，好的需求分析可以有效规避后期开发风险。软件领域提出了许多需求分析方法，然而随着软件的规模和复杂程度与日俱增，传统需求分析方法的局限性日益凸显。基于统一建模语言的软件需求分析方法通过对现实问题做抽象映射，将需求以模型语言的方式进行可视化表达，可以有效解决传统需求分析方法中存在的不足，使开发人员可以很好地理解用户需求，从而提升产品开发效率和质量。

关键词：统一建模语言；软件需求；需求分析

中图分类号：TP311        文献标识码：A

文章编号：1009-3044（2022）35-0022-03

1 概述

随着软件工程技术的不断发展，软件开发关注的重点已经逐渐从后端的编码向前端的需求分析转移，需求分析的好坏对软件成功与否至关重要[1]。据权威部门统计，目前软件的成功率约为25%，75%的软件是失败的。在这75%的失败中，约有50%以上的软件是在需求分析阶段存在问题[2]。

为了能够有效地进行分析和设计活动，需要相应的技术和工具支持。软件行业经过多年的发展，目前有许多需求分析的方法，对于普通软件而言，用户需求相对简单，传统的分析方法可以应对，然而对于大型复杂系统如ERP等，其规模和设计都比较复杂，传统的需求分析方法已经不能满足要求，存在开发人员不能识别业务需求书、需求反复确认等问题，影响开发效率[3]。

因此，需要研究应用一种新的需求分析方法，促进业务人员与软件开发人员之间一致且高效地交流，帮助开发人员深入理解用户需求，从而实现系统设计的可读性、可理解性和通用性。

2 传统结构化需求分析

传统需求分析主要以结构化分析方法为主，是面向过程的以功能为驱动的分析方法。其主要是根据用户需求，确定大致业务框架以及系统的功能范围，采用非开发人员也易于理解的图形符号结合文字等形式来描述每个功能的处理逻辑和业务规则，并适当辅助一些功能分解图和数据流图等[4]。

这种分析方法适用于一些简单场景，可以快速灵活地定义需求，但在复杂的业务场景下，其以功能为驱动的逻辑导致该方法对需求变化的适应能力比较弱，尤其是在易变化的场景下，其面临的问题较多，程序的可重用性和可维护性较低[5]。此外，开发人员可能无法准确识别业务需求语言，在设计阶段需要重新去做分析，导致开发效率低下。

3 统一建模语言

与传统结构化方法不同，面向对象的需求分析方法注重于现实问题的底层逻辑，将实际问题抽象化以此来解决问题，其从类与对象的关系上出发，具备更强的通用性，可以有效支持变动的业务需求。同时，面向对象的需求分析全流程是以对象作为分析与设计的目标，在最终编码中也都是对象，可以有效保证从需求到分析、从分析到设计、从设计到编码的一致性。

统一建模语言（Unified Modeling Language，UML）作为面向对象需求分析方法的建模工具，具有规则统一、易于表达、功能强大的优势，适用于各类软件系统的需求建模，从一般的信息管理系统到大型复杂工程系统都可以用UML来描述、构建需求分析模型[6]。

UML是一种可视化的建模语言而非程序设计语言，目的在于对系统进行抽象化并构建可视化分析模型，包括对象模型、动态模型以及功能模型，如表1所示。功能模型是从用户的视角来描述系统的功能，最常用的是用例圖；对象模型用来分析识别系统的对象与类，以及它们之间的静态关系，主要用到类图和对象图；动态模型用来展现系统的内部行为、时序关系及状态变化，包括活动图、时序图和状态图[7]。

4 统一建模语言在软件需求分析中的应用

软件需求通常分为功能性需求和非功能性需求（如可靠性、可支持性等）。在这些需求中，功能性需求是需求定义的重点。本文以某企业仓库管理系统为例，利用统一建模语言进行功能性需求分析，分为用例建模和用例分析两大阶段。

4.1 用例建模

用例建模需要用到用例图，用例图为组织需求模型提供了有效手段，它通过将功能抽象为用例，进而为系统构建合适的用例模型。通过用例模型完成对需求的开发和管理，同时为后续用例分析提供输入。本节详细介绍构建用例模型的四个步骤：获取原始需求、识别参与者、识别用例、绘制用例图。

4.1.1 需求获取

企业仓库管理系统主要是解决如何合规化、精益化的管理企业库存的问题。系统功能涵盖出库、入库及库存管理等，用户涉及生产、销售、仓储、采购、财务等多个部门。通过对系统进行调研，将业务需求、痛点问题整理到调研表中，为接下来的UML建模分析做准备，如表2所示。

4.1.2 识别参与者

参与者是指在系统之外，通过系统边界与系统进行交互的任何事物。识别模型中的参与者可以更好地去识别用例。对于仓库管理系统而言，识别参与者过程如表3所示，参与者包括生产人员、销售人员、仓库管理员、采购人员、财务人员、系统管理员，如图1所示。

4.1.3 识别用例

用例是参与者可以感受到的系统服务或功能单元，它从用户的角度定义了系统要实现的一个目标[8]。用例不是功能分解，一个用例可能需要多个功能来实现，一个功能也可能被用于多个用例，所以将系统需求表示成用例的过程并不等同于传统方法中对系统进行功能分解的过程。

将获取到的需求进行总结提炼、分类，通过参与者与系统交互需求说明，明确业务活动，进而识别业务用例，如表4所示。

4.1.4 绘制用例图

识别系统的参与者和用例后，就可以采用用例图表示，如图2所示。通过用例图可以清晰地构建需求模型。

4.2 用例分析

在用例建模阶段，得到初步的需求模型。接下来的用例分析阶段则需要采用另一种建模方案对用例进行精确化的描述，将以用户视角描述的需求模型转换为以开发团队视角描述的分析模型，从而保证设计开发的准确性[9]。

4.2.1 识别分析类

在对象系统中，系统的所有功能都是通过相应的类来实现。因此，首先需要从用例模型中抽象出这些可用的类，再将系统行为分配到这些类中。

为了识别分析类，UML扩展出三种不同的分析类：1）边界类，比如UI界面；2）控制类，即控制业务流程的类，如销售出库业务类；3）实体类。即问题空间中的业务对象的集合，比如出库信息类。由于边界类和控制类比较容易确定，因此，对实体类的识别才是整个分析阶段的重点。以出库管理业务为例，抽象出的实体类包括系统用户类、出库信息类、货品信息类、销售信息类和生产信息类，通过确定类之间的关系创建实体类图，如图3所示。

4.2.2 分析交互

目前，所识别的类都是静态的描述，而为了确认所识别的类是否达成用例实现的目标，必须分析由这些类所产生的对象的动态行为。利用UML时序图来描述对象间的交互行为，可以表示用例实现是如何达成用例目标[9]。以销售出库业务为例，其时序图模型如图4所示，开发人员通过时序图可以清晰地理解业务间各个对象交互及消息传递的过程。

至此，已经建立了一套需求分析模型，系统用例及用例实现的相关交互分析以可视化的表达形式记录在模型里。接下来，需求分析人员需要基于系统用户目标、范围和需求模型，完成用例的细化描述，并在此基础上，结合非功能性需求、约束条件以及外部关联接口等完成需求文档的编写。最后還需要评审审查，从而确保在开始架构设计时需求是完整的、一致的，规避后期开发风险。

5 结论

需求分析是整个软件项目开发的关键环节，不同的分析方法各有侧重，业务人员需要根据所开发的项目特点找到适合的分析方法。本文以某企业仓库管理系统为例，详细阐述了基于统一建模语言的软件需求分析方法的应用过程。通过该分析方法，能够有效地保证需求开发的质量，产出符合规范性和完整性要求的需求，大大提高沟通效率，并减少需求变更带来的麻烦。

软件开发实践表明，在提高软件工程质量、降低软件开发风险、处理复杂功能需求、减少代码开发工作量等诸多关键问题上，基于统一建模语言的需求分析方法是行之有效的。

参考文献：

[1] Maciaszek L A.需求分析与系统设计[M]. 马素霞，王素琴，谢萍，等译.北京：机械工业出版社，2009.

[2] 吴政.软件开发过程中的需求分析探讨[J].电脑知识与技术，2008，4（32）：1125-1128.

[3] Wiegers K，Beatty J.软件需求[M].3版. 李忠利，译.北京：清华大学出版社，2016.

[4] 黄蓝会.基于UML进行软件需求分析的研究[J].微型电脑应用，2016，32（7）：9-11.

[5] 李鸿君.大话软件工程需求分析与软件设计[M].北京：清华大学出版社，2020.

[6] 田林琳，李鹤.UML软件建模项目教学版[M].北京：北京理工大学出版社，2018.

[7] 袁涛，孔蕾蕾.统一建模语言UML[M].2版.北京：清华大学出版社，2014.

[8] 赵会盼.一种基于UML的面向对象的软件需求分析方法[J].电子技术与软件工程，2021（9）：63-65.

[9] 谭火彬.UML 2面向对象分析与设计[M].2版.北京：清华大学出版社，2019.

【通联编辑：唐一东】