这是一个困惑我很长时间的问题。
对于 Stakehoder 的定义，我可以理解利益相关者并不总是演员。例如，为了建立一个核电站，国家核安全管理局可能是利益相关者，但与该站没有互动，因此它不是演员。
但另一方面，演员总是利益相关者吗？
考虑一下：我们构建了一个地下电缆系统，有些鼠咬住了电缆。在用户酶分析中，我想将老鼠作为演员建模，但绝对不是该系统的利益相关者。
This is a question confused me for a rather long time.
For the definition of stakehoder, I can understand that a stakeholder is not always an actor. For example, to build a nuclear power station, the National Nuclear Safety Administration may be a stakeholder, but it does not interact with the station, so it's not an actor.
But on the other hand, is an actor always a stakeholder?
Consider this: we build a underground cable system, and some rat bite the cable. In usecase analysis, I would like to model the rat as an actor, but it is definitely not a stakeholder of this system.
发布评论
评论（2）
好吧，大鼠有兴趣不被电死。因此，它是利益相关者。问题是，您认为它的重要性。可能不是那么多。
另外，您不会分析用例“满足电缆的满足饥饿” 。相反，您应该分析如何“保护电缆免受老鼠的咬合” 。两者都是有效的用例，但我认为您不希望以第一种方式使用您的系统，因此您不应对其进行建模。第二个只是用例，如果您的系统具有驱动大鼠的功能。
UML对如何描述用例并不多。我始终建议从结果具有价值的利益相关者的角度来描述它们。
Well, the rat has an interest in not being electrocuted. So, it is a stakeholder. The question is, how important you consider it to be. Probably not so much.
Also, you would not analyse the use case "satisfy hunger for cables". Rather you should analyse how to "protect cable against rat bites". Both are valid use cases, but I assume, that you don‘t want your system to be used in the first way and therefore you should not model it. The second one is only a use case, if your system shall have functions to drive off rats.
The UML doesn‘t say much about how to describe use cases. I always recommend to describe them from the viewpoint of the stakeholder for whom the result is of value.
简而言之
，每个演员始终是利益相关者。但是，并非每个利益相关者都是演员。
更多想法：
UML规范中的第一个定义
，没有利益相关者的定义。但据说：
该措辞还表明，演员是利益相关者：如果不是利益相关者，则不需要“其他”一词。
顺便说一句，这清楚地消除了可疑参与者的大鼠，因为电缆系统不应该为大鼠产生价值的结果。对于其他利益相关者而言，可以在大鼠上观察到的结果并不具有价值。
利益相关者与用例有何关系？
许多系统会产生可观察的结果，这对与系统互动的演员有价值：撤离后现金的演员收益，演员可以通过系统完成任务等...
但是，该价值并不总是适合演员。如果您穿过机场的车身扫描仪，则作为用户，您可能不会完全重视自己被扫描的结果。但是机场，航空公司，祖国和安全以及其他乘客可能会非常重视用例的结果。这表明，并非所有对系统感兴趣的利益相关者都一定是用户。
第二个定义
听起来很奇怪， swebok 也不定义利益相关者。他们只是列举了一些示例，例如用户，客户，监管机构等。 iso 21500 也确实有示例定义。
此外，我们必须记住，利益相关者的利益不仅是自己的好处，而且可能是相反的。如果您的邻居使用捕获房屋进入的相机安装视频监视系统，那么您既不是客户，也不是用户，但是您可能会成为利益相关者，认为对您的隐私权威胁。
因此，流行的定义是PMI的：
我们可以按照此定义进行检查是否所有参与者都是利益相关者，因为他们将受到未来系统的影响。
还有老鼠？
在原则上，大鼠不是地下电缆系统的参与者，因为该系统不是为了提供价值而建立的，也不是让它们为其他利益相关者提供价值。如果我们将这一概念扩展到动物：它们可能会受到影响或认为受所有这些电缆的影响，可以将大鼠视为利益相关者。萧条很可能只是系统环境中故障的来源。
这使我想起了一个老式的系统工程师30年前告诉我的故事，这发生在他职业生涯的开始，大概是30年前。这是他的第一个较大的计算项目，这是一款旨在计算大型组织工资的大型机电计算机。由于某些原因，每个月都有一些错误，但绝不会有相同的错误。经过几个月的调试，他们发现一些老鼠确实在非常大的计算机下的地板空间中吃过一些电缆的船体，如果在错误的时刻，偶然的老鼠在电线上行走，它会随机关闭应该保持打开的电路。 首先bug ？
In short
Yes, every actor is always stakeholder. But not every stakeholder is an actor.
Some more thoughts:
First definition
In the UML specifications, there is no definition of stakeholders. But it is said that:
This wording also suggests that actors are stakeholders: if they weren't, the word "other" wouldn't be needed.
By the way, this clearly eliminates the rat from the suspected actors, since the cabling system is not supposed to produce results of value for rats. And the result that could be observed on the rats is not of value for the other stakeholders.
How are stakeholders related to use cases?
Many systems produce an observable result that is of value for the actor interacting with the system: the actor benefits of cash after a withdrawal, the actor could achieve a task with the system, etc...
But the value is not always for the actor. If you walk through a body scanner at the airport, as a user you might not fully value the results of being scanned yourself. But the airport, the airline, homeland and security, and the other passengers may very well value the result of the use case. This shows that not all stakeholders who have interest in a system, are necessarily users.
Second definition
As strange as it may sound, the SWEBOK does not define the stakeholder either. They just enumerate some examples, such as users, customers, regulators etc. ISO 21500 does also have a definition by example.
Moreover, we must keep in mind that the interest of a stakeholder is not only the own benefit, but could be the opposite. If your neighbor installs a video surveillance system with a camera that captures the entry of your house, you're neither the customer, nor the user, but you will probably be a stakeholder perceiving a threat for your right to privacy.
A popular definition is therefore the PMI's:
We can cross check that according to this definition that all actors are stakeholders, since they will be affected by the future system.
And the rats?
Rats are in principle not actors of an underground cabling system, as the system is not build for providing them value nor to involve them to provide value to other stakeholders. Rats could be considered as stakeholders if we'd extend the concept to animals: they may be affected or think to be affected by all this cables. Bust most probably, they are simply a source of malfunctions in the system's environment.
This reminds me a story that an old system engineer told me 30 years ago, and that happened to him at the begin of his career, probably another 30 years before. It was on his first bigger computing project, a large electromechanical computer designed to compute the payroll of a large organisation. For some reasons, there were some mistakes every month, but never the same. After months of (expensive) debugging, they found out that some rats indeed have eaten the hull of some cables in the floor space under the very large computer, and if a rat by chance walked on the wires at the wrong moment, it closed random circuits that were supposed to stay open. A more modern version of the first bug?