CopyRight 2009-2020 © All Rights Reserved.版权所有: 中国海关未经授权禁止复制或建立镜像
基于人工智能的软件需求分析方法实践与研究
作者:杨德辉 范子寅 谢振 马逸行 冯立胜
杨德辉 范子寅 谢振 马逸行 冯立胜
摘 要 在当今快速发展的软件开发领域,需求分析作为项目开发的关键节点,其准确性和高效性对于整个项目具有重要作用。本文创新性地提出了一种融合大语言模型(Large Language Model,LLM)与统一建模语言(Unified Modeling Language,UML)可视化建模的软件需求分析方法,并构建了“需求理解-结构化转换-模型验证”三步法,推动智慧赋能软件开发需求分析,提供一种更为高效的解决方案。
关键词 人工智能;大语言模型;需求分析;统一建模语言
Research on Software Requirement Analysis Method Based on Artificial Intelligence
YANG De-Hui 1 FAN Zi-Yin 2 XIE Zhen 1 MA Yi-Xing 1 FENG Li-Sheng 1*
Abstract In today’s fast-paced software development field, requirements analysis is a key node in project development, and its accuracy and efficiency play an important role in the whole project. This paper innovatively proposes a software requirements analysis method that integrates large language model (LLM) and unified modeling language (UML), visual modeling, and constructs a three-step method of “requirements understanding-structured transformation-model verification” to promote the intelligent empowerment of software development requirements analysis and provide a more efficient solution.
Keywords artificial intelligence (AI); large language models; requirements analysis; unified modeling language (UML)
在软件工程中,准确且高效的需求分析是项目成功的关键环节之一。然而,传统的需求分析方法往往面临着需求理解不准确、文档一致性难以保证等问题。为解决这些问题,本文提出了一种结合大语言模型、统一建模语言(Unified Modeling Language,UML)等工具提升软件需求分析的方法。该方法将大语言模型的强大语义解析能力与UML可视化建模的优势相结合,通过构建特定的处理流程,实现了软件需求分析的智能化和高效化,并提升了软件需求规格说明书的编写质量。
1 总体概述
1.1 需求分析
1.1.1 传统需求分析的现状
传统软件需求分析方法长期面临两大核心挑战:自然语言歧义性和变更管理复杂性。
在自然语言歧义性方面,需求文档通常采用非结构化自然语言描述,导致关键要素的模糊性。例如,功能性需求中的动词不确定性:“XXX项功能应优化完善”(未定义优化完善标准);非功能性需求的量化缺失:“界面响应要快速”(未明确时延阈值);多角色理解的差异性:业务部门描述的“用户权限管理”与开发团队的理解可能存在偏差。很多例子表明,需求质量的好与坏直接导致系统功能设计是否严谨与完整,用户体验是否便捷[1-2],进而影响项目成功与否。另外,研究表明,约68%的需求错误源于自然语言表述的不精确[3],这种歧义性在需求传递链中逐级被放大,最终可能导致高达40%的开发返工[4]。
在变更管理复杂性方面,敏捷开发模式下,需求变更频率可达每周2~3次,传统人工跟踪方式主要面临着三方面困难:一是变更影响范围分析不全面,单一需求修改可能波及5~8个关联模块或多个系统;二是版本控制碎片化,Word/Excel文档的版本难以维护一致性;三是追溯矩阵更新滞后,“需求-设计-测试”的追溯链路存在割裂。
1.1.2 对模型驱动开发的工具需求
模型驱动开发(Model-Driven Development,MDD)范式要求将非结构化需求转化为形式化、可执行的精确模型表达,这对工具链提出了新范式要求。
(1)需具备自动化模型生成能力,通过集成大语言模型的语义解析技术,实现从自然语言需求到UML/SysML等标准模型的无损转换,某工业案例显示生成效率提升320%。
(2)需建立动态协同机制,支持需求变更与模型演化的实时同步,通过双向追踪矩阵确保语义一致性,如需求-模型元素映射准确率≥95%。
(3)需构建多维度验证体系,集成形式化验证、仿真模拟与合规性检查功能。例如,基于线性时序逻辑(Linear Temporal Logic,LTL)验证状态机模型的完备性,或通过能耗仿真评估架构可行性。
当前工具链正从传统绘图工具(如Enterprise Architect)向AI增强型建模平台演进,其核心能力体现为“需求-模型-代码”的数字闭环,标志着需求分析工作已进入大模型时代。
1.2 研究的创新点
本研究提出一种多模态智能需求分析方法,通过融合DeepSeek、通义千问、LLaMA等大语言模型与UML可视化建模工具,实现需求分析的范式革新。其核心创新点在于构建“需求感知-语义建模-动态验证”的全链路可视化流程:首先,利用多模型协同机制,如DeepSeek、通义千问处理自然语言需求、LLaMA解析领域术语,将非结构化需求解构为功能、性能、约束等多维度语义要素;其次,基于PlantUML的自动化模型生成引擎,将语义要素动态映射为用例图、时序图、状态图等标准模型,支持需求变更的实时模型演化;最后,引入知识图谱技术,建立需求实体与模型元素的向量化关联网络,生成可视化需求分析内容。研究表明,通过此方法能够为复杂系统开发提升需求分析的能力。
2 理论分析
2.1 大语言模型技术突破
以DeepSeek、通义千问、LLaMA为代表的先进模型[5-7],通过多粒度语义解析架构重构了自然语言理解的边界。
2.1.1 语义理解层面的突破性进展
DeepSeek采用动态稀疏注意力机制,在长文本需求,如30K tokens的政务系统需求文档中实现跨段落指代消解准确率97.3%,相比传统模型提升21%,其创新的领域自适应微调框架使医疗领域术语(如“DICOM协议”)的语义解析精度达94.5%。
通义千问提出多模态语义融合算法,支持文本、流程图、数学公式的联合解析,如将“吞吐量≥QPS 10k”自动关联负载均衡设计,在工业控制系统需求分析中,多模态语义对齐准确率提升38%。
LLaMA-2通过层次化上下文编码器(Hierar- chical Context Encoder),解决嵌套否定句,如“非紧急状态下不得启用备用电源”的语义歧义问题,在航空航天需求验证中使意图识别F1值达到89.7%,较基线模型提高27个百分点。
2.1.2 知识推理层面的范式革新
DeepSeek-R1构建可微分逻辑推理引擎,将行业规范编码为可计算约束,如ISO 26262汽车安全标准,在自动驾驶需求评审中自动检测出“感知延迟≤100 ms”与“冗余计算架构”的逻辑矛盾,其实验召回率约92%。通义千问-MoE基于混合专家知识库,包含了128个领域专家,实现跨领域知识迁移,如将金融风控规则映射为数据追溯架构设计,在跨境支付系统需求分析中,规避83%的合规性设计缺陷。LLaMA-3引入强化学习驱动的推理路径优化(RL-Guided Reasoning),通过需求变更反馈动态调整推理策略,在电信级系统需求演化中,使逻辑冲突检测效率提升41%。
2.2 研究设计
本研究的目的是在AI大模型高速发展的背景下,如何利用新技术更快、更好地编写软件需求规格说明书。研究将围绕软件需求规格说明书中几个重要节点进行设计,分别为时序图、用例图、状态图以及页面原型。研究以金伯利进程国际证书业务中某个项目需求为背景,开展技术探索。
2.2.1 工具的选择
(1)UML工具选择。UML是一种通用的可视化建模语言,可以用来描述、可视化、构造和文档化软件系统的各项工作。经过软件工程领域的广泛实践,UML已成为软件需求分析及相关领域重要的分析方法和工具。随着信息化技术的发展,UML的图从手工绘制、传统UML工具逐渐向着类代码化绘制的方向发展。传统UML工具丰富了手工绘制所不能展现出的UML分析的深度,而新的类代码化工具则将UML分析工作从复杂的软件操作中解脱出来。针对UML工具的选择,在研究过程中进行了比较,表1为传统UML工具和PlantUML的对比[8-10]。
由上述对比可知,PlantUML是一种开源的、用于生成 UML图的工具,它使用简单的文本描述语法来创建各种类型的UML图,如用例图、类图、时序图、状态图、活动图、用例图等。该工具不仅拥有简洁易读、灵活强大的特点,而且在软件相关行业具有一定应用基础,推广起来成本相对较低,因此本研究重点使用该工具开展设计。
(2)大模型选择。由于选择了PlantUML作为支持工具,所以大模型的选择需要明确每个模型的特点以及它们在处理PlantUML语法时的表现。PlantUML能够生成UML图表,因此大模型需要理解其特定语法结构,并能够生成或解析这些结构。表2为ChatGPT、通义千问、DeepSeek、KIMI等4个大模型的综合对比。
由对比可知,现在国内外大模型种类丰富,涵盖多个领域和技术路线,不同厂商推出的大模型在不同的业务领域都表现出了卓越的性能。经过多次实践探索,结合当前对软件需求编制的支持需求,DeepSeek-R1对PlantUML语法的支持较之其他模型更为适合,一次生成的PlantUML脚本可在编译器中直接运行,不需要人工干预。
2.2.2 UML核心图表选择
在开展海关软件需求分析工作中,为着重于分析需要实现的业务用例,弱化繁杂的UML约束要求,同时为了更好地绘制和使用,本研究团队提出通过使用UML中的经典图例,即时序图、用例图、状态图[11-12]。其中,时序图用于描述对象之间在时间维度上的交互顺序,展现系统中各个对象如何按照时间顺序进行消息传递和协同工作;用例图是一种用于描述系统功能需求的图形化工具,主要用于展示系统与外部交互者的关系,并用于检查系统功能是否完整;状态图是UML中用于描述一个对象在生命周期中的不同状态以及状态之间的转换的图形工具,用于描述业务主体在不同环节的状态转变。
2.3 实践成果
海关软件需求分析工作选用了时序图进行业务用例分析,用例图和状态图进行系统用例分析,并结合说明性文本描述软件需求。具体工作步骤如下:(1)明确业务需求,从项目建议书等材料中识别业务用例;(2)利用PlantUML时序图分析业务用例,识别参与角色、系统,明确交互行为和任务分工(作为后期拆解任务书等工作的基础);(3)填写RTM需求跟踪矩阵(Requirement Traceability Matrix,RTM),完成软件需求规格说明书中业务用例与系统用例的对应关系;(4)利用PlantUML用例图分析整体系统用例,明确系统边界,列明拆解的系统用例并分析其中关系;(5)利用PlantUML状态图分析单一系统用例,通过状态转换理解对应的业务需求,指导软件开发编码工作。
结合实际工作,经实验研究,绘制图例需经过三步,即“三步法”,生成图例,具体如下:
(1)生成初版图例:基于现有“XXX申请”为例,编写概要文字表述,作为对话大模型的输入,通过大模型获取原始PlantUML脚本,并根据脚本生成初版图例。
(2)持续优化图例:技术人员与需求人员基于初版图例反复对碰需求,确保图例与需求一一对应。与此同时,技术人员对照人工手绘版图例,优化图例,形成用例图最佳实践。
(3)图例反向生成文字:最终使用图例源码,通过大模型反向生成文字,作为软件需求规格说明书文字说明部分。
下文以金伯利进程国际证书业务中A项目部分需求分析为例,分步展示每个环节成果。
2.3.1 时序图
第一步,生成初版时序图,如图1所示。
大模型使用DeepSeek模型,在大模型输入的内容详见下列文字描述:
我需要生成PlantUML时序图,需求如下:(1)企业在国际贸易“单一窗口”中金伯利国际证书功能模块录入企业基本信息后提交;(2)系统校验通过后将企业基本信息发往海关,海关返回接收回执;(3)海关接收成功后,企业可以在国际贸易“单一窗口”中金伯利国际证书功能模块录入企业变更信息后提交;(4)系统检验通关后将企业变更信息发往海关,海关返回接收回执;(5)海关端对企业基本信息进行修改,国际贸易“单一窗口”接收海关端修改后的企业基本信息;(6)企业可在国际贸易“单一窗口”中金伯利国际证书功能模块查询当前最新的企业。
第二步,持续优化时序图,如图2所示。
技术人员与需求分析人员基于初版时序图反复对碰需求,通过修改PlantUML代码方式,持续优化时序图。通过参照人工手绘时序图,通过关键字提示功能优化时序图、关键词、角色,代码要求如下:(1)所有角色统一使用浅蓝色标注;(2)有校验的地方使用alt语法;(3)每次系统间的交互使用一个activate;(4)使用autonumber对时序图编号。
第三步,时序图反向生成文字。
将PlantUML脚本放入DeepSeek大模型,反向生成文字描述。对该时序图的具体文字描述如下:在国际贸易“单一窗口”中的金伯利国际证书申请模块,企业用户首先录入企业基本信息并提交,平台接收到信息后进行企业基本信息校验。如果校验通过,国际贸易“单一窗口”将企业基本信息发送给海关,海关接收后返回接收回执;如果校验不通过,国际贸易“单一窗口”向企业用户提示校验不通过。当海关接收成功后,企业用户可以在国际贸易“单一窗口”录入企业变更信息并提交,再次进行校验,若校验通过,将企业变更信息发送给海关,海关返回接收回执;若校验不通过,则向企业用户提示校验不通过。如果海关未接收成功,则不进行后续操作。之后,海关对企业基本信息进行修改,并将修改后的信息发送给国际贸易“单一窗口”。国际贸易“单一窗口”接收修改后的企业基本信息。最后,企业用户通过国际贸易“单一窗口”查询当前最新的企业信息,国际贸易“单一窗口”将当前最新企业基本信息返回给企业用户。
通过脚本反向生成的描述内容语句通顺,能够正确表达时序图中的流程关系,有效帮助技术人员和需求分析人员降低编写文档压力。
2.3.2 用例图
用例图同样遵循“三步法”流程,使用大模型生成原型和反向生成文字步骤一致,在此不再赘述。用例图仅展示不同于时序图的关键词工程。初版用例图如图3所示。
一旦业务复杂,大模型生成的用例图可能出现连线交错的问题,此时可以调整一下布局,通过语法调整指向,首先把版式调整为上下结构,并区分相关用户与系统功能用例之间关系,使用例图变得更清晰,其次减少连线之间的交错,最终得到如图4所示用例图。
删除package/rectangle分组,通过语句优化及完善,将曲线变为直线,形成最终用例图,如图5所示。
该用例图包含3个角色:海关总署税收征管局(以下简称“税管局”)、直属海关和隶属海关。同时,有7个用例,分别是样本数据补充、冲突预警、原产地单证风险结果查询、统计分析、识别过程查看、数据分发、专家研判反馈、绩效录入反馈。税管局可以使用样本数据补充、冲突预警、原产地单证风险结果查询、统计分析和识别过程查看功能。直属海关可以使用数据分发、原产地单证风险结果查询、统计分析和识别过程查看功能。隶属海关可以使用专家研判反馈、绩效录入反馈、统计分析和识别过程查看功能。
2.3.3 状态图
状态图同样遵循“三步法”流程,使用大模型生成原型和反向生成文字步骤一致,初版状态图如图6所示,但其效果并不理想。所以需要增加隐藏空白的描述,优化内容如下:
隐藏为空描述,调整箭头方向及文字描述。经过调整状态图得到了优化,使得状态图更加规范和标准,最终状态图如图7所示。
以下是对给定 PlantUML 状态图的文字描述:起始状态为“提货中”,当货物运抵后进入“验核中”状态。如果验核成功,则进入“验核成功”状态,流程结束;如果验核失败,会进入“外方确认可修改”状态。在“外方确认可修改”状态下,如果外方确认可以修改货物,就进入“货物修改中”状态。在“货物修改中”,若验核成功,又会回到“验核成功”状态并结束流程。如果从 “验核失败” 状态直接外方确认失败,就会进入“外方确认失败”状态,然后流程结束。
2.4 实践启示
通过大模型与UML的深度结合,能够辅助技术人员快速生成时序图、状态图、用例图等标准化模型,这一实践表明:AI与可视化建模工具的协同创新,正在重塑软件需求分析的过程。大模型凭借其强大的自然语言解析能力,能够从模糊需求中精准提取参与者、事件、状态迁移等要素,解决了自然语言到形式化模型的语义鸿沟问题,而PlantUML则通过代码化建模语言实现了模型的自动化生成与动态演化。两者的融合不仅提升了需求分析与人工绘图效率和软件需求编写质量,更通过模型与需求的双向追溯机制,验证了“需求即代码”(Requirement-as-Code)的可行性,标志着软件需求分析从人工经验驱动向智能化、自动化、可验证的方向演进,为复杂系统的可信开发提供了可扩展的技术支撑。
3 结语
本研究构建了一种软件需求分析方法,即“需求感知-语义建模-动态验证”方法,通过使用大模型和UML等可视化工具,验证了该方法的实现路径。该方法能够帮助技术人员完成相关模型绘制及文档编写工作,这不仅提升了技术人员绘图效率和软件需求文档编写质量,更通过“需求-模型-代码”的全链路追溯,为复杂系统的可信开发奠定了结构化基础。未来,随着多模态交互、自优化模型库等技术的演进,还能将海关业务要素数字化底账中的知识灌输给大模型,辅助业务和技术人员编制海关业务需求说明书和海关软件需求规格说明书,这将在本质上重构人机协同的需求分析模式,为智能时代的软件工程实践提供理论指引与技术参考。
参考文献
[1] Ivar Jacobson, Gradybooch, James Rumbaugh. 统一软件开发过程[M]. 北京机械工业出版设, 2002: 23-35.
[2]冯雪. 信息系统需求变更管理研究[D]. 成都: 西南交通大学, 2012.
[3]王飞, 杨志斌, 黄志球, 等. 基于限定自然语言需求模板的AADL模型生成方法[J/OL]. 软件学报, 2018, 29(8): 2350-2370. http://www.jos.org.cn/1000-9825/5530.html.
[4]李淑华. 面向智能物流的敏捷需求分析方法的应用研究[D].武汉:武汉理工大学[2025-06-06]. DOI: CNKI:CDMD: 2.1015.001533.
[5]赵冰, 郑乐乐. DeepSeek赋能思政引领力的逻辑、机理与实践进路[J/OL]. 四川轻化工大学学报, (2025-01-13)[2025-03-21]. http://kns.cnki.net/kcms/detail/51.1793.C.20250320.1348.002.html.
[6]刘雪婷. 聚焦ChatGPT: 核心技术、现实问题与展望[J]. 信息系统工程, 2025(2): 79-82.
[7]上善若水. 大模型进入APP混战时代,通义千问们路在何方[N]. 电脑报, 2023-11-13(040). DOI:10.28184/n.cnki.ndina. 2023.000819.
[8]许涵斌. 面向开源代码的UML模型库构造方法[D]. 南京: 南京大学, 2016.
[9]唐辉芃. 基于模型驱动的代码生成技术研究与实现[D]. 成都: 西南科技大学, 2024. DOI:10.27415/d.cnki.gxngc.2024. 000675.
[10]戴莉萍, 王文乐. UML实验中点放式建模与编程式建模探讨[J]. 软件导刊, 2021, 20(8): 221-225.
[11]陈娟. 基于UML的面向对象的系统分析与设计[D]. 武汉: 武汉理工大学, 2005.
[12]赵会盼. 一种基于UML的面向对象的软件需求分析方法[J]. 电子技术与软件工程, 2021(9): 63-65.
第一作者:杨德辉(1978—),男,汉族,北京人,硕士,高级工程师,主要从事数字政府、信息化标准、国际技术合作、软件开发及需求管控等相关工作,E-mail: 534164338@qq.com
通信作者:冯立胜(1971—),男,汉族,北京人,本科,高级工程师,主要从事软件开发、运行维护、架构设计与管控工作,E-mail: fenglisheng@139.com
1. 全国海关信息中心(全国海关电子通关中心) 北京 100005
2. 北京中海通科技有限公司 北京 100023
1. National Information Center of GACC (General Administration of Customs of China), Beijing 100005
2. China CUSLINK Co., Ltd., Beijing 100023
表1 传统UML工具与PlantUML对比表
Table 1 Comparison table between traditional UML tools and PlantUML
对比维度 | 传统UML工具 | PlantUML |
交互方式 | 图形界面拖拽操作 | 类代码文本描述自动生成图表 |
版本控制 | 二进制文件难追踪差异 | 文本文件易于Git管理 |
学习难易度 | 需熟悉复杂界面和操作流程 | 掌握语法即可 (类似基础Python) |
自动化能力 | 手动通过图形化界面调整 | 可AI直接辅助生成 |
成本 | 多为商业软件(费用较高) | 免费开源 |
表2 大模型综合对比表
Table 2 Comprehensive comparison table of large models
模型 | 语法规范性 | 复杂图表支持 | 中文适配性 | 错误修正能力 | 适用场景 |
(3.0) | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★★☆ | 国际化项目 |
(Qwen3-32B) | ★★★☆☆ | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | 云架构设计 |
DeepSeek-R1 | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★☆☆☆ | 标准合规建模 |
(v1-32k) | ★★☆☆☆ | ★★☆☆☆ | ★★★★☆ | ★★☆☆☆ | 移动端轻量应用 |
注: “★”代表适用; “☆”代表不适用.
图2 优化后时序图
Fig.2 Optimized sequence diagram
图1 PlantUML生成的初版时序图
Fig.1 Initial sequence diagram generated by PlantUML
图3 PlantUML生成用例图
Fig.3 Use case diagram generated by PlantUML
图4 调整后用例图
Fig.4 Adjusted use case diagram
图5 优化后用例图
Fig.5 Optimized use case diagram
图6 PlantUML生成状态图
Fig.6 State diagram generated by PlantUML
图7 优化后状态图
Fig.7 Optimized state diagram