[论文阅读] 软件工程 | 如何挖掘可解释性需求?三种方法的深度对比研究

如何挖掘可解释性需求?三种方法的深度对比研究

研究背景:当软件变复杂,我们需要"说明书"

想象你买了一台智能家电,却发现它的运行逻辑完全看不懂,按钮按下后毫无反应,故障时也不提示原因------这就是现代软件系统面临的困境。随着AI、大数据技术的普及,软件功能越来越强大,但复杂度也呈指数级增长。用户看不懂系统如何运作,开发者说不清决策逻辑,监管机构更难判断是否合规,这种"黑箱化"问题催生了对可解释性需求的迫切需求

可解释性需求就像软件的"说明书",它能告诉用户"系统为什么这样做""出错时如何解决",甚至帮助开发者优化设计。但问题来了:如何高效收集这些需求?传统的访谈、焦点小组和问卷调查,哪个更适合?就像去医院看病,有的医生喜欢问详细病史(访谈),有的擅长组织病友讨论(焦点小组),还有的习惯用问卷做大规模筛查(调查),但哪种方法能更精准地找到"病因"?这正是本文要解决的核心问题。

主要贡献:给需求工程师的"工具箱"指南

本文就像一份"需求收集方法论地图",为开发者提供了3大核心价值:

  1. 方法效率排行榜:告诉你"哪种方法最省时间""哪种方法能挖到最多需求",比如访谈是"时间杀手"但精准度高,调查是"海量数据收割机"但重复率高。
  2. 分类工具的使用时机:发现"先让用户自由表达,再用分类框架引导"(延迟分类法)能收集到更丰富的需求,就像先让孩子自由画画,再教他们色彩理论,反而能激发更多创意。
  3. 混合方法的黄金组合:提出"调查+访谈"的组合拳,既能覆盖大规模用户,又能深入挖掘细节,好比先用CT做全身扫描,再用显微镜分析病灶。

创新点:打破"分类工具越早用越好"的迷思

以往研究总认为"分类框架能让需求收集更有条理",但本文却发现:太早给用户分类表,反而会限制他们的想象力!就像你去餐厅点菜,如果服务员一开始就递上固定套餐菜单,你可能想不到尝试隐藏菜品;但如果先让你自由描述想吃的口味,再推荐对应的菜品分类,反而能点到更合心意的菜。

本文提出的**"两阶段需求收集法"**(先开放收集,再分类引导),就像给需求工程师一把"万能钥匙",既保留了用户的原始创意,又能通过分类框架提升需求的结构化程度,堪称"鱼和熊掌兼得"的典范。

核心方法:一场真实企业里的"需求收集实验"

实验场景

选一家德国大型IT公司的人事管理软件作为研究对象,因为这类软件涉及员工考勤、绩效、薪资等敏感操作,用户对"系统如何运作"的解释需求格外强烈,就像员工每天都在问"为什么我的工资算错了?""为什么考勤记录消失了?"

实验方法

  1. 样本选择

    • 焦点小组:2组,每组6人,模拟"头脑风暴式讨论"
    • 访谈:18人,一对一深入交流,像"心理咨询式提问"
    • 问卷调查:188人,大规模收集数据,类似"全民普查"
  2. 关键变量

    • 分类工具的使用时机
      • 直接法:一开始就给用户分类表(如"系统行为""隐私安全"等类别)
      • 延迟法:先让用户自由描述需求,再用分类表补充
  3. 数据指标

    • 效率:每人每小时收集的独特需求数(避免重复劳动)
    • 效果:总需求数需求多样性(覆盖多少种不同类型的需求)

核心结果:用数据说话的"方法优缺点清单"

1. 效率对比:访谈是"时间管理大师"

  • 访谈 :每人每小时能收集12.42个独特需求,就像高效的"需求挖掘机",适合时间有限但需要深度挖掘的场景。
  • 调查 :虽然总需求数最多(471条),但重复率高达22.7%,相当于10个人里有2个人说了同样的话,需要花大量时间去重。
  • 焦点小组:效率最低,因为小组讨论容易"跟风发言",独特需求数最少。

2. 效果对比:调查是"需求广度王者"

  • 调查 :覆盖了7个需求类别(如系统行为、用户界面等),尤其在"用户界面"需求上占比18%,说明大规模用户更关注"界面是否易懂"这类直观问题。
  • 访谈:在"业务领域知识"需求上占比41%,比如员工更关心"绩效计算规则是否合理",这类深层需求需要一对一交流才能挖掘。
  • 焦点小组:意外发现"功能缺失"需求占比22%,比如用户集体吐槽"缺少假期审批进度提醒",体现了群体讨论激发共性需求的优势。

3. 分类工具的魔法时刻:延迟使用更有效

  • 延迟分类法 让访谈的独特需求数提升了26%,就像先让用户"自由联想"再"归类整理",能同时收获创意和结构。
  • 直接分类法会导致需求集中在"系统行为"等常见类别,而延迟法能挖掘出"隐私安全"等容易被忽视的需求,就像先让学生自由写作文,再教他们划分段落,反而能写出更有层次的文章。

论文引文格式

复制代码
Obaidi M, Droste J, Deters H, et al. How to Elicit Explainability Requirements? A Comparison of Interviews, Focus Groups, and Surveys[J]. arXiv preprint arXiv:2505.23684v1, 2025.
相关推荐
奇妙之二进制1 小时前
软件功能模块归属论证方法
软件工程·架构设计
workflower6 小时前
量子比特实现方式
数据仓库·服务发现·需求分析·量子计算·软件需求
张较瘦_20 小时前
[软件工程] 文档 | SpringBoot3的API接口文档开发教程
软件工程
张较瘦_20 小时前
[论文阅读] 人工智能+软件工程 | 用大模型优化软件性能
论文阅读·人工智能·软件工程
张较瘦_1 天前
[论文阅读] 软件工程 | 量子计算如何赋能软件工程(Quantum-Based Software Engineering)
论文阅读·软件工程·量子计算
奇妙之二进制3 天前
架构设计的目标:高内聚、低耦合的本质
架构·软件工程·架构设计
摘星编程3 天前
工厂方法模式深度解析:从原理到应用实战
java·设计模式·软件工程·工厂方法模式
鼓掌MVP3 天前
面向对象系统中对象交互的架构设计哲学
软件工程