这是一个让我困惑了很久的问题。
对于stakehoder的定义，我可以理解为stakeholder不一定是actor。比如建一个核电站，国家核安全局可能是利益相关者，但它和电站没有互动，所以不是演员。
但另一方面，演员总是利益相关者？
考虑一下：我们建造了一个地下电缆系统，一些老鼠咬了电缆。在用例分析中，我想将老鼠建模为演员，但它绝对不是这个系统的利益相关者。
【问题讨论】：
标签： uml use-case use-case-diagram
好吧，老鼠有兴趣不被电死。所以是一个利益相关者。问题是，你认为它有多重要。可能没那么多。
此外，您不会分析用例“满足对电缆的渴望”.相反，你应该分析如何“保护电缆免受老鼠咬伤”.两者都是有效的用例，但我假设您不希望以第一种方式使用您的系统，因此您不应该对其建模。第二个只是一个用例，如果你的系统应该有驱赶老鼠的功能。
UML 并没有过多说明如何描述用例。我总是建议从结果对他们有价值的利益相关者的角度来描述它们。
【讨论】：
是的，每个参与者都是利益相关者。但并非每个利益相关者都是演员。
在 UML 规范中，没有利益相关者的定义。但据说：
[一个用例]指定了该主体执行的一组行为[即系统]，它会产生一个可观察到的结果，该结果对参与者或主题的其他利益相关者有价值。
这种措辞还表明参与者是利益相关者：如果不是，就不需要“其他”一词。
顺便说一句，这显然将老鼠从可疑演员中排除了，因为布线系统不应该为老鼠产生有价值的结果。在老鼠身上观察到的结果对其他利益相关者没有价值。
涉众如何与用例相关？
许多系统会产生一个可观察到的结果，该结果对于与系统交互的参与者来说是有价值的：参与者在提款后获得现金收益，参与者可以通过系统完成任务，等等......
但价值并不总是针对演员。如果您在机场走过人体扫描仪，作为用户，您可能不会完全重视自己扫描的结果。但是机场、航空公司、国土和安全部门以及其他乘客可能非常重视用例的结果。这表明并非所有对系统感兴趣的利益相关者都一定是用户。
第二个定义
听起来很奇怪，SWEBOK 也没有定义利益相关者。他们只是列举了一些例子，比如用户、客户、监管者等。ISO 21500 也有一个例子的定义。
此外，我们必须牢记，利益相关者的利益不仅是自己的利益，还可能相反。如果您的邻居安装了一个带有摄像头的视频监控系统来捕捉您家的入口，那么您既不是客户也不是用户，但您可能是利益相关者，认为您的隐私权受到威胁。
因此，一个流行的定义是 PMI：
可能影响、被影响或认为自己受到项目、项目群或项目组合的决策、活动或结果影响的个人、团体或组织。
我们可以根据这个定义交叉检查所有参与者都是利益相关者，因为他们将受到未来系统的影响。
老鼠呢？
老鼠原则上不是地下布线系统的参与者，因为该系统不是为给它们提供价值而构建的，也不是为了让它们参与为其他利益相关者提供价值。如果我们将这个概念扩展到动物，老鼠可以被视为利益相关者：它们可能会受到或认为会受到所有这些电缆的影响。最有可能的是，它们只是系统环境中故障的根源。
这让我想起了 30 年前一位老系统工程师告诉我的故事，那是他职业生涯开始时发生在他身上的故事，可能又是 30 年前。这是他的第一个更大的计算项目，一个大型机电计算机，旨在计算一个大型组织的工资单。由于某些原因，每个月都会出现一些错误，但从不相同。经过几个月（昂贵的）调试，他们发现确实有一些老鼠吃掉了超大计算机下方地板空间中一些电缆的外壳，如果一只老鼠在错误的时刻踩到电线，它会随机关闭本应保持开路的电路。 first bug 的更现代版本？
【讨论】：
Stakeholder 可以应用于演员或班级（不是关联）。这是否意味着有些参与者不是利益相关者？由于规范没有说明Stakeholder必须适用于演员。