Talk:Use case

src: image.slidesharecdn.com

Video Talk:Use case

Basic course of events

The steps under "Basic course of events" are a poor example of a use case. Use cases should be expressed in terms of the goals of the stakeholders. "Enter password" isn't a goal, it's an implementation detail. The whole login process is not really a goal; the goal (from the resource owner's POV) is authenticating the user. Logging in with a password is a solution for doing that.74.229.8.169 (talk) 00:15, 26 May 2008 (UTC)

Maps Talk:Use case

Encyclopedian Usage

Is there any comprovation of setence: "the most influential and comprehensive, in terms of defining what use cases are and how to write them effectively, was provided by Alistair Cockburn, in his 2000 book Writing Effective Use Cases."

I think you mean "comprobation" here. No, this is clearly an opinion that is unsupported by objective data. Consequently, the sentence should be modified to indicate that Cockburn is a notable contributor.

src: static1.squarespace.com

Capitalization

The fact that "software engineering" was (no longer is) written with two inappropriate capital letters makes me suspect that the capital letters in "Use Case" are similarly inappropriate. Could someone explain? Michael Hardy 19:24, 19 Aug 2003 (UTC)

src: slideplayer.com

Numbers of use cases

In an application, is there a rough correspondence between the numbers of menu entry vs. numbers of total use cases? What is the conventional wisdom?

LL

Why would you think in those terms? User interface design comes after identifying requirements. : ChrisG 23:11, 13 Oct 2004 (UTC)

No. Usecases is an analysis tool for producing goal oriented business scenarios. Single usecase may result in a single 'menu entry' or but it could just easily contain many usecases.

I think it is best to think in terms of "what is the use trying to acomplish". If they want to save a file, then you need the File, Save, and Save As menu items. Possibly a Convert To menu item as well. If they are trying to open a file, then you only need one. If they want to bold a line of text, then all you need is the B toolbar icon.

src: i.ytimg.com

Diagrams

The use case diagrams were moved to a sperate page because a lot of people consider them to be a seperate topic. - JLA

That Use Case diagram is not very appealing to the eyes. Would anyone have an issue with me updating it with a nicer-looking graphic (same content)? - drosboro

Please do thats the purpose of a wiki. :ChrisG 09:33, 3 August 2005 (UTC)

src: pbs.twimg.com

Merge from Use-case survey & Use-case model

These are one sentence articles, certainly easy to merge, but I'm not sure if they realy belong here and where. You'll certainly see that with a glance. Nabla 20:51, 18 September 2005 (UTC)

The Use-case model should defintely be a seperate article. This article is about the use case which is distinct from UML. The Use Case Model is a artefact in UML and could and should certainly be expanded I've added a link from here and from the UML article. Neither article can really do it full justice because they are summary articles.:ChrisG 17:17, 19 September 2005 (UTC)

The Use-case survey is a stage in the stage in the development of use cases; but I haven't added a section on it yet; but again it is a topic in its own right; which could expand substantially. :ChrisG 17:17, 19 September 2005 (UTC)

The pages should be moved to Use case survey and Use case model.:ChrisG 15:17, 24 September 2005 (UTC)

Ok. *That* I can do... Merge tags removed, now tagged as Software engineering stubs. Nabla 00:33, 25 September 2005 (UTC)

src: i.ytimg.com

Section 'Software': Request for deletion of UML tools from list

I intend to delete the following entries from the section 'Software':

• Altova UModel 2005. Reason for deletion: Is an UML tool. Already listed on List of UML tools.
• Dia: Reason for deletion: Is a 'general-purpose diagram creation software program'. Already listed on List of UML tools.
• Poseidon for UML: Reason for deletion: is an UML tool. Already listed on List of UML tools.
• Rational Rose: Reason for deletion: is an UML tool. Already listed on List of UML tools.
• Umbrello: Reason for deletion: UmrelloUmbrello is a redirect to Umbrello UML Modeller. Is an UML tool. Already listed on List of UML tools.
• Enterprise Architect: Is an UML tool. Already listed on List of UML tools.
• Borland Together: Is an UML tool. Already listed on List of UML tools.

This means, I would delete most of the entries listed. The entries 'Case Complete' and 'eRequirements' would remain. If there are no objections, I'm going to do these deletions. --Adrian Buehlmann 10:38, 1 November 2005 (UTC)

Done. --Adrian Buehlmann 15:03, 7 November 2005 (UTC)

src: pbs.twimg.com

Refs to less formal but similar approaches?

I was surprised to see no references to, or more importantly from, similar approaches (eg scenario-based design, personas, etc). (Ronz 00:54, 1 June 2006 (UTC))

Hey! This is a wiki. Why don't you add them to the article? You can edit the page :] --Ligulem 09:44, 1 June 2006 (UTC)

I'd prefer someone with more expertise to, but I'm thinking along the lines of Human-computer interaction rather than just software engineering. --Ronz 23:32, 8 June 2006 (UTC)

Hi, I'm interested in making this addition. I'm new to editing Wikipedia, so please let me know what the etiquette is around doing so. However, I wasn't thinking of it in terms of adding scenario-based design and personas as "similar approaches". I think the term "scenario" is misused in this article, and should be clarified as being a higher-level framing of problem statements from a user (or "persona") perspective. What this article refers to as a "scenario" is what I would typically think of as being a "user task".

Certainly the article that is linked to for "scenarios" does not correspond with the way it is used here. As I understand scenarios (both in the sense that the linked article describes them, and as defined in the seminal work on the subject - "About Face" by Alan Cooper) they are a tool for envisioning a product at the user level, and are ideally as minimal as possible in terms of describing the actual implementation. This would be exactly the opposite of how this article uses the term, in fact suggesting that a "scenario" is a lower level description of a part of a Use Case.

I see that this is likely a result of competing terminology from differing systems of design (as suggested by the previous commenter) but as a practitioner who is working on this very thing with people from other disciplines it would be nice if they could be reconciled. Is anyone familiar with a good published source for doing so? Nroberton (talk) 22:02, 30 September 2009 (UTC)

src: pbs.twimg.com

Confusion between use case and use case diagram

When you talk to people of use cases, they tend to think of the UML diagram instead of the technique. That was the ground why I decided to use the template "confuse", even though the introduction chapter distinguish clearly one from the other. I thought that by adding this template it would avoid even faster confusion. And I mean there has been loads of confusion on this article (see diff) and on other version of the same article in other languages. So in my humble opinion, adding the template {{confuse}} was a good way to avoid future problem. What do you think? (Note: this message is esp. intended to user User:SunSw0rd). --Huygens 25 08:51, 28 February 2007 (UTC)

In my experience, most people who have done use cases do know the difference between use cases and UML use case diagrams. It is true that OO developers may first encounter the concept via UML -- but those are not the people who create use cases. The diagrams sometimes add value, especially when dealing with very high level use cases. For a standard business use case, the diagram often shows merely a single actor, or very few actors, interacting with a system. For a typical system level use case, the UML diagram (IMO) adds no value whatsoever. In fact I will go so far as to say, in the arena of UML diagrams, the use case diagrams are only of use at the very highest levels of system specification.

I further note that the people who actually capture and document requirements, who are the same people who create use cases, tend to be fairly ignorant of UML. Remember that use cases capture information from the business perspective. This primarily a textual approach, and diagrams tend to be added only when there are many actors involved (and obviously, use cases with many actors are high level.) So for the vase majority of use cases generated during requirements gathering and system specification, the UML diagrams are unnecessary.

As to why people might be confused about UML diagrams versus textual use cases, I would point to RUP as a root cause of the confusion. RUP assumes that use case modeling proceeds from a use case diagram, to actor specifications, to the use case textual description. It should clearly be noted that even today most organizations do not follow the RUP methodology. Even where it is followed, the analysts who gather and specify requirements rarely do the UML diagram for any but the highest level use case (again, IMO.) SunSw0rd 14:19, 28 February 2007 (UTC)

I think we are on the same understanding/ground. As for my own experience, people know little about UML (more as a buzz word than anything else) and tend to put this keyword here and there. As for the textual use case, they don't even know it exists. For them a use case is the UML diagram. :-( Quite sad confusion. That was one of the reason I decided to add the template on top of the article, because so many people confuse it. And perhaps, we are talking here old vs. new school, as new graduated worker tend to know use case from the UML point of view (or RUP as you suggested), whereas other have studied textual use case, and then later in the career did they encounter UML.

Therefore, I would still suggest to use the (anti-)confuse template. So new generations clearly learn the difference a few second after opening the article, and other (and I am one of them, so don't expect me to say older ;-) ) who have learn it the other way around, won't get disturbed by this banner, because they know it (or perhaps they would learn that UML offers a diagram to illustrate them).

For my point of view, I use UML use case diagram as a higher level view (similar to what you're stating). Usually I would have a textual use case per cases of the UML diagram. So the diagram is really telling nothing apart making it easy for the reader to have a quick overview (a kind of index) of the textual use cases, as well as an overview about how all those use cases are bound together.

As said another major reason, was the confusion already on the article. Like it was pointed out in my first message, this article was in the UML category and it was pointing to articles in wikipedia in other languages that were concerning the UML use case diagram only. What do you think? IMHO, we should keep the template. --Huygens 25 16:33, 28 February 2007 (UTC)

I inserted "UML" in front of "use case diagrams" in the text in the first paragraph. That should help clarify the point. However I am confused by your reference to this article being in the UML category. I looked on the bottom of the page at categories and saw no such category. I did see the category SysML (Systems Modeling Language) which points to both use cases and use case diagram (as well as a few others.) SunSw0rd 19:55, 28 February 2007 (UTC)

If you had follow my link (see the diff link in the first post), you would have found that there was the category UML in the past. But I have corrected this and now you cannot see it anymore. As for SysML, I barely know but not enough that I could judge it. As of avoiding confusion, Wikipedia offers the template I was using. It is a much better way than just trying to rework the text again and again to make it clearer (and potentially more heavy to read). I think that my point is also not to clarify the introduction, I think it was already making a good deal. I wanted to make clear from the beginning of the article and using Wikipedia tool for this that this article is not about the UML diagram. If people do not read the introduction carefully, they might think that the article is missing some diagrams... So I really insist on using the template. --Huygens 25 10:55, 6 March 2007 (UTC)

(Alistair Cockburn here:) A use case diagram serves well as a table-of-contents into the set of use cases. The oval names the use case; the use case itself is whatever lies behind the oval (whether text or activity diagram). I offer this thought in case it helps you refine your text in the article (which I don't wish to mess with). --Alistair Cockburn

I believe that there is another fundamental confusion that most users have about use cases, including the above wikipedians. It is true that a use case is not a diagram. But it is also not an oval. And it is also not the text. Careful writers would say that the use case oval represents a use case and the text documents a use case. Similarly, a use case is not (normally) created by the analyst, it is discovered (or found). A use case is the goal that an actor has while using the system. Such goals can be found, and then diagrammed and/or documented, but they are not created by analysts Mjchonoles 05:58, 1 March 2007 (UTC)

I hope we are not going to get into a discussion of what "is" is. You are correct, technically a "use case" is a specific way to "use" the system. It is the description of the use case that is textual or diagrammatic. However, in convention the description is commonly called "the use case" rather than "the documented use case." In the context of the discussion, I suggest we don't want to rename this article the "use case textual description" to offset it from the other article titled "use case diagram" -- rather when someone searches for "use case" in wikipedia they will come here -- and that is what we all want, I assume. SunSw0rd 15:21, 1 March 2007 (UTC)

I was not recommending a change of name of the article, however, within the article correct usage would be an improvement. I've seen the consequence of the sloppy terminology in my consulting -- for example, management insisting that a set number of use cases be made, perhaps too high or too low -- but from a belief that the number of use cases are under the control of the developers, rather than being inherent in the complexity of the system. Mjchonoles 09:44, 7 March 2007 (UTC)

(Alistair Cockburn here:) Don't know if this affects the text in the article --- this probably isn't the place to delve into use case specifics --- but one typically means by "use case" the stuff inside the use case; one typically says "the name of the use case" to mean the title or the text written into the oval. Also, although the number of use cases is largely inherent in the complexity of the system, as you write, they contain a fair number of design decisions already (business level, and to some degree even technical architecture decisions). If this doesn't help you with what you're trying to accomplish with this article, then I apologize for distracting you. --Alistair Cockburn

src: i.ytimg.com

Cockburn's Degree of Detail section of the article

Alistair Cockburn here: I changed the text from "Detailed" to "Fully Dressed", because that section is quoting my book. Since it is introducing the terminology from the book, it has to do so correctly. The three levels are Brief, Casual, Fully Dressed, and not Brief, Casual, Detailed as was written earlier. You can delete this paragraph as soon as the change gets accepted by whomever wrote the previous version. -- Alistair --The preceding unsigned comment was added by 72.174.169.204 (talk) 04:21, 21 April 2007 (UTC).

src: pbs.twimg.com

Use Case Templates section

This currently reads "...individuals are encouraged to use templates that work for them or the project they are on." Who is the agent of this passive sentence? Surely not everyone who wants someone to write use cases for them, right? My guess is that this has been lifted from some company's guidelines for how to write use cases, and that it expresses that particular company's view. (That, or it expresses the view of whoever wrote this part of the wikipedia article; but that would be inappropriate.) The paragraph goes on to say "Standardization within each project is more important than the detail of a specific template." Again, it reads like some particular company's guidelines.

My suggestion would be to simply omit these two sentences; but I know next to nothing about Use Cases (that's why I came to this page), so I feel like I should leave the decision to someone who knows more about it than I do. Mcswell (talk) 18:53, 12 May 2008 (UTC)

src: i.ytimg.com

Restored History Section Header

I restored the History section header and reapplied the pararagraph that was deleted by an anonymous user. If someone disagrees with the history they may edit it, but it is useful to have the section. Secondly I added an Overview header to make the article appear better from a formatting perspective. SunSw0rd 13:16, 23 April 2007 (UTC)

src: pbs.twimg.com

Who is Gagan Rana?

Gagan Rana has been added to the history section (not by me, by 194.168.3.18). I did a google search on '"Gagan Rana" use case' and came up with a total of six hits -- and none of them had anything to do with use cases. So who is Gagan Rana and why is this person listed? SunSw0rd 18:12, 10 May 2007 (UTC)

Given what else has come from that ip editor, I've removed it. Most likely it's vandalism like the other recent edits from that editor. --Ronz 18:17, 10 May 2007 (UTC)

Thanks. SunSw0rd 20:07, 10 May 2007 (UTC)

References

The references at the bottom of the article seem to be using two systems. Additionally, there are references made in the article in the form of "name1 and name2 said ...", without any full citation of the actual source. I'm a bit short on time now, but it seems to me that the references need to be standardized into one format, and the inline references lacking full citations need to be qualified by the people who put them in, or hunted down by someone else and verified. I've added a point to the todo list. -Kieran 07:46, 8 June 2007 (UTC)

Opening sentence

I found the opening sentence of the "Use case" article kind of awkward (although it's better than it was at the start of the day today!), so I added a quotation from one of Cockburn's articles which says pretty much the same thing. You seem to not like the "prose" in Cockburn's quotation. Rather than starting an edit war, how about compromising on something like:

A use case is a "description of a system's behavior when interacting with the outside world."[1]

although I am uncomfortable with deleting words that I don't like from a quotation.

Comments? Shanemcd (talk) 21:38, 12 February 2008 (UTC)

To address the prose issue first, Cockburn himself says (p. 1) that use cases " can be written using flow charts, sequence charts, Petri nets, or programming languages". In the context of the UML activity diagrams may often be preferred. So although they may usually be narrative, they need not be, and that is not one of their defining features.

On your proposed wording, while I broadly agree with it, I think it lacks the precision of the current version; a use case is not describing an interaction the system has "with the outside world", but with a specific primary actor in the outside world. --Malleus Fatuorum (talk) 21:59, 12 February 2008 (UTC)

I agree about the prose issue. Looking over the article, though, I don't see anywhere where it mentions alternate formats of use cases besides the prose form. Specifically, the "Degree of detail" subsection implies prose: "A brief use case consists of a few sentences...", "A casual use case consists of a few paragraphs of text". I think the concept of non-narrative formats, specifically referencing the quotation you provided above, would be valuable to work into in the article somewhere.

I agree. --Malleus Fatuorum (talk) 23:23, 12 February 2008 (UTC)

With regards to the opening sentence wording, I find the current wording slightly confusing for someone unfamiliar with the subject. I believe that it makes sense in the context of remainder of the lead section. I think my problem is with the "one of the external entities interacting with that system" phrase. That might be better summed up as "actor", although someone new to the subject doesn't know what an actor is. Perhaps "user", but that may imply a person, as opposed to any external entity. The best I can come up with is "A use case is a description of a system's behaviour as it responds to a request from a user of that system". Hmmm, that's still not right, as it seems to imply a single request, as opposed to an interaction working towards a specific goal. --Shanemcd (talk) 23:16, 12 February 2008 (UTC)

What about something like: "A use case is a description of a system's behaviour as it responds to a request that originates from outside of that system"? --Malleus Fatuorum (talk) 23:27, 12 February 2008 (UTC)

Looks good to me! --Shanemcd (talk) 23:49, 12 February 2008 (UTC)

Excellent, job done. Well, half done anyway. We still need to add something about alternatives to narrative in use cases. --Malleus Fatuorum (talk) 00:01, 13 February 2008 (UTC)

Origin of the term

"Originally he used the terms usage scenarios and usage case, but found that neither of these terms sounded natural in English, and eventually he settled on the term use case."

This is not correct. According to Jacobson himself the term "use case" is a literal translation of the Swedish term, and at the time he created it he wasn't very fluent in English. He has suggested that the term "usage scenario" is a more correct translation.

I have the source in print. I will provide it once I have located it (One of the Addison Wesley UML books, but I don't recall which one.)

---

Adam Sroka --Preceding unsigned comment added by Xagile (talk o contribs) 08:58, 15 August 2008 (UTC)

Disambiguation: User story, Use case and Scenario

There are a few pages, which I do not recognize by their meaning. What is the difference between these topics: User story, Use case and Scenario ? ...thus, what are the reasons these are not merged together?

And once such will be stated, some disambiguation, comparison or summary of the differences would be surely helpful, even for others! ;) Thanks! Franta Oashi (talk) 01:13, 28 June 2009 (UTC)

AFAIK they have different origins, purposes and levels of granularity. But I have no references for a definition or comparison, and they are sometimes used interchangeably anyway.Diego (talk) 08:50, 9 July 2009 (UTC)

"used interchangeably anyway" Exactly! That would be a solution for this as well: Not only a disamb, but to merge them together, and explain some possible their "different origins, purposes and levels of granularity" on just one page. Hm, merge these three together would be even better than a fourth disamb page, I like that! ;) --Franta Oashi (talk) 12:18, 9 July 2009 (UTC)

I'd also like to see disambiguation added to these articles - or have them merged in case there is no difference in meaning. --Abdull (talk) 22:06, 6 September 2010 (UTC)

These do differ, and they are confused, and I think disambiguation - especially in practical application - would be very useful to a notable audience. --Justapersona (talk) 17:30, 12 April 2010 (UTC)

Broken reference link

http://www.omg.org/docs/formal/07-02-03.pdf reference 2, has gone missing--404. 12.7.248.5 (talk) 02:03, 9 June 2010 (UTC)

Pronunciation

I've always wondered whether the term use case is pronounced with use as English verb (/juz/) or noun (/jus/)... I expected the noun (as in: "a case of its use"), as a common English noun-noun construction, and I asked around with other programmers, and they were unanimous in the noun-noun reading, /jus/. But it's not entirely self-evident-- a verb-noun compound (/juz/ case) is plausible (cf. "kill switch"). So I'm adding a pronunciation note to the entry. That may seem odd to some editors, but this is one of those situations where the information is self-apparent, but only once you already know it. So I judge this to be authentically informative. Now I get to go hunt for where best to put it, and also wrangle Wikipedia's joyous implementation of IPA for English. -Sean M. Burke (talk) 02:28, 10 November 2010 (UTC)

Features & Use Cases

"Use cases should not be confused with the features of the system. One or more features (a.k.a. "system requirements") describe the functionality needed to meet a stakeholder request or user need (a.k.a. "user requirement"). Each feature can be analyzed into one or more use cases, which detail cases where an actor uses the system. Each use case should be traceable to its originating feature, which in turn should be traceable to its originating stakeholder/user request."

-> this is not correct. the correct order and the correct dependencies are: 1.: we identify the actors 2.: we identify the system boundary 3.: we identifiy the user goals (a.k.a. use cases). 4.: we identify the steps of the use cases. --> 5. this leads to features which a system has to provide to accomplish the use cases' goals!

use cases are a way to develop the requirements of a system. features are a product of the use case method!

(e.g. compare to cockburn & writing effective use cases). --Preceding unsigned comment added by 194.97.67.1 (talk) 12:54, 29 April 2011 (UTC)

Limitations

"For some products and systems, use cases are complex to write and to understand, for both end users and developers." It's like saying that one limitation of spanish, or physics, or any discipline, are their difficult to understand by some people. The problem then is the practitioner not the use case concept or artifact. All the section should be rewritten to specify real limitations of use cases as the exclusion of non-functional requirements, the absence of an accepted standard, or the exponential increment of extensions/alternatives with lots of paths and deviations of some cases.

Klodr (talk) 18:20, 27 September 2014 (UTC)

Where are the six elements of a use case?

There are six elements of a use case, right? WHY AREN'T THEY IN THE ARTICLE? -- Preceding unsigned comment added by 24.125.163.223 (talk) 14:40, 1 September 2011 (UTC)

Yes, there is a need for simplicity and clarity here. We need to add a description (probably from Cockburn 2001) to define at least one of the ways use cases can be structured. Chiswick Chap (talk) 08:42, 16 December 2011 (UTC)

Parenthetical marks in Goal level icon

Cockburn use in his book is not a sufficient explanation of these marks. It must be explained further. Walter Görlitz (talk) 15:07, 15 August 2013 (UTC)

Sometime in text writing, a use-case name followed by an alternative text symbol (!, +, -, etc.) is a more concise and convenient way to denote levels, e.g. place an order!, login-. --Softzen (talk) 04:38, 16 August 2013 (UTC)

Thank you for expanding it. The image helps and the additional copy also assists. Walter Görlitz (talk) 04:33, 16 August 2013 (UTC)

Cheers! --Softzen (talk) 04:44, 16 August 2013 (UTC)

I had to nominate the image for deletion in the commons though since it's taken from http://alistair.cockburn.us/Use+case+icons and it's copyrighted there. Perhaps someone can make a free version. Walter Görlitz (talk) 04:48, 16 August 2013 (UTC)

It's already free for public use, as Alistair declares on the page: "Please feel free to use the icons..." --Softzen (talk) 05:00, 16 August 2013 (UTC)

That appears to be for the second image provided by "Djwonk". Walter Görlitz (talk) 05:05, 16 August 2013 (UTC)

By common sense, 'the icons' include the two pics there. You can also download the free ppt file. And it is funny that Alistair would be unhappy if he saw his icons here on the Wikipedia. --Softzen (talk) 08:19, 16 August 2013 (UTC)

A few points on this.

1. There's a copyright on the bottom of the page. By American law, all content on that page is copyrighted.
2. Two items were posted by different individuals. Common sense states that the copy for the second item does not apply to the copy of the first.
3. Alistair would have to send a letter to release copyright for the image to Creative Commons if he actually wanted to release them to Creative Commons.
4. Now that I've reported the image, we can discuss it there, not here. It's up to a commons admin.

Sorry. Walter Görlitz (talk) 15:11, 16 August 2013 (UTC)

I should explain just a bit more on that last point. The reason I started the discussion here was that I didn't know if you would be notified of the nomination there. You apparently were, and so discussing this in two places is not necessary. Walter Görlitz (talk) 15:56, 16 August 2013 (UTC)

Throw-away phrase

I have not objected to recent edits, but the phrase "However, this may not be true" is not necessary and is WP:WEASEL words: "words and phrases aimed at creating an impression that something specific and meaningful has been said, when in fact only a vague or ambiguous claim has been communicated".

Look at the paragraph with and then without the sentence.

Since the inception of the agile movement, the user story technique from Extreme Programming has been so popular that many think it is the only and best solution for agile requirements of all projects. However, this may not be true. Alistair Cockburn lists 5 reasons why he still writes use cases in agile development.

Since the inception of the agile movement, the user story technique from Extreme Programming has been so popular that many think it is the only and best solution for agile requirements of all projects. Alistair Cockburn lists 5 reasons why he still writes use cases in agile development.

Nothing is lost. I will be making one further change now. Walter Görlitz (talk) 06:39, 24 July 2015 (UTC)

Article incorrectly claims that actors are a subset of stakeholders

In the actors section of the Wikipedia entry it is claimed that "actors [in a use case] are always stakeholders." However, that is not true. Sometimes use-case actors are stakeholders, but not always. There are many use-cases where an actor a piece of equipment or a computer program. For example, in a use-case you might have an actor which is a Washing machine and a another actor might a person who puts dirty laundry into the Washing machine. The person who loads the washing machine might be a stakeholder, however, the washing machine (another actor) certainly is not. As another example, you could create a use-case where there are two actors: an ATM and a person who uses the ATM. The person who uses the ATM is a stakeholder, but the ATM is not.

A stakeholder is an individual or organization, that cares about outcome of a project. For example, the customer who paid for the project cares how it turns out. The end-users will be using the product, so they care how it turns out. The development team might care how it turns out, etc... However, a washing machine or automated teller machine doesn't particularly care about how successful the project is. Yet washing machines and ATMs can be actors in a use-case. If an actor in a use-case actor is a piece of software or hardware, then it is not a stakeholder.

50.155.254.229 (talk) 17:41, 23 March 2017 (UTC)

The statement is sourced to Cockburn. If you can prove that the document does not support the claim, we can remove it.

For the record, if your use cases state a piece of equipment or a computer program is an actor, you should get them changed, because that's not correct. In your example, the washing machine is not the actor, the person using the washing machine is the actor. The ATM is not the actor, but person who is trying to get cash or an account balance from the machine is the actor. The actors are the stakeholder, not the devices. In your second paragraph you validated the statement that all actors are stakeholders, but not all stakeholders are actors. Walter Görlitz (talk) 19:14, 23 March 2017 (UTC)

Source of the article : Wikipedia