这个问题困扰了我很长时间。
对于stakehoder的定义，我可以理解利益相关者并不总是参与者。例如，为了建造一座核电站，国家核安全局可能是利益相关者，但它不与核电站互动，因此它不是参与者。
但另一方面，行动者是否总是利益相关者？
考虑一下：我们建造了一个地下电缆系统，一些老鼠咬了电缆。在用例分析中，我想将老鼠建模为一个参与者，但它绝对不是这个系统的利益相关者。
嗯，老鼠对不触电很感兴趣。因此，它是利益相关者。问题是，你认为它有多重要。可能没有那么重要。
此外，您不会分析用例"满足对电缆的渴望">。相反，您应该分析如何"保护电缆免受老鼠叮咬">。两者都是有效的用例，但我认为，你不希望你的系统以第一种方式使用，因此你不应该对其进行建模。如果你的系统具有赶走老鼠的功能，那么第二种只是用例。
UML并没有说明如何描述用例。我总是建议从利益相关者的角度来描述它们，对他们来说，结果是有价值的。
简而言之
是的，每个参与者都是利益相关者。但并不是每个利益相关者都是行动者。
还有一些想法：
第一个定义
在UML规范中，没有利益相关者的定义。但据说：
[用例]指定了该主体[即系统]执行的一组行为，该行为产生了对主体的参与者或其他利益相关者有价值的可观察结果。
这句话也表明参与者是利益相关者：如果他们不是；其他"；不需要。
顺便说一句，这显然将老鼠从可疑行为者中排除了出来，因为布线系统不应该产生对老鼠有价值的结果。在老鼠身上观察到的结果对其他利益相关者没有价值。
利益相关者如何与用例相关
许多系统都会产生一个可观察的结果，对与系统交互的参与者来说是有价值的：参与者在提款后从现金中受益，参与者可以用系统完成任务，等等
但价值并不总是对演员而言。如果你在机场通过身体扫描仪，作为一名用户，你可能不会完全重视自己被扫描的结果。但机场、航空公司、国土安全部和其他乘客可能非常重视用例的结果。这表明，并非所有对系统感兴趣的利益相关者都一定是用户。
第二个定义
尽管听起来很奇怪，SWEBOK也没有定义利益相关者。他们只是列举了一些例子，比如用户、客户、监管机构等。ISO 21500也有一个具体的定义。
此外，我们必须记住，利益相关者的利益不仅是自身的利益，而且可能是相反的。如果你的邻居安装了一个带有摄像头的视频监控系统，可以捕捉你的房屋入口，你既不是客户，也不是用户，但你可能是感知到隐私权受到威胁的利益相关者。
因此，一个流行的定义是PMI：
可能影响、被影响或认为自己受到项目、计划或投资组合的决策、活动或结果影响的个人、团体或组织。
根据这个定义，我们可以交叉检查所有参与者都是利益相关者，因为他们将受到未来系统的影响。
老鼠呢
原则上，老鼠不是地下布线系统的参与者，因为该系统的构建既不是为了给老鼠提供价值，也不是为了让老鼠参与为其他利益相关者提供价值。如果我们将这一概念扩展到动物身上，老鼠可以被视为利益相关者：它们可能会受到或被认为受到所有这些电缆的影响。最有可能的是，它们只是系统环境中故障的来源。
这让我想起了一个30年前一位老系统工程师告诉我的故事，这件事发生在他职业生涯开始的时候，可能是30年前。这是他的第一个更大的计算项目，一台大型机电计算机，旨在计算大型组织的工资。由于某些原因，每个月都会出现一些错误，但从来没有出现过。经过几个月的(昂贵的)调试，他们发现一些老鼠确实吃掉了超大计算机下地板空间中的一些电缆外壳，如果一只老鼠偶然在错误的时刻走在电线上，它就会闭合本应保持打开的随机电路。第一个bug的更现代的版本