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)

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.

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)

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.

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)

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)

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)

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)

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

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).

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)

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)

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 • 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)

Non-software USE CASE examples - USE CASE for other systems

USE CASE formatting is useful for defining non-software systems due to its clear disambiguation of ACTORS, INPUTs and OUTPUTs.

See an example of the USE CASE for the [spam link redacted]

This is an important tool as it easily permits Socratic Questioning's best-practice separation of terms.

Take an example term - "Socialism" - which, depending on your nation, can include discussions of:

1. Ownership (of production) by the state
2. Merit
3. Ethics
4. Social Programs ([spam link redacted])
5. Fiscal and Budgetary Responsibility
6. Economic Performance — Preceding unsigned comment added by Edtilley4 (talk • contribs) 17:44, 23 April 2019 (UTC)
7. Non-monetary systems of commerce - like Communism, Bartering, etc.
8. Ownership of private property and title

Disambiguation permits terms that have been misused, mixed, and obfuscated (over centuries of economic theorist meanderings in this case) to be laid simple and open to clear solutioning. — Preceding unsigned comment added by Edtilley4 (talk • contribs) 20:02, 21 April 2019 (UTC)

Are you suggesting a new article or a generalization of this article? Walter Görlitz (talk) 14:53, 23 April 2019 (UTC)

I was thinking a new section ("USE CASE as a systems analysis tool - Non-software"); with a new intro sentence that explains USE CASE's usefulness in analyzing systems - and not just software systems alone, which is the messaging of the current page. — Preceding unsigned comment added by Edtilley4 (talk • contribs) 17:37, 23 April 2019 (UTC)

Is there enough in the way of sources to support such a section?

The section's heading shouldn't repeat the article title, so possibly Non-software systems analysis tool. Walter Görlitz (talk) 01:12, 26 April 2019 (UTC)

May we please ensure restricting usage to the strict definition of a 'use case' throughout Wikipedia

Typically, the phrase 'use case' has been loostened to become synonymous with any form of application software. Specifically, a single 'use case' is just that; it describes the path followed by a user, usually while using a piece of software, throughout a single example use. It does not describe the application as a whole. Any single application will typically offer many, if not many hundreds, of different individual possible use cases. Taking for example a simple appliction such as a Cash Machine, even such a simple machine will offer many, and probably many dozens, of seperate use cases. If you track the usage of a cash machine by one hundred people, then each interaction with the machine by each individual person offers a single example use case. Vapourmile (talk) 15:57, 21 May 2019 (UTC)

Proposed merge of Scenario (computing) into Use case

The article Scenario (computing) Does not provide any enough coherent or additional information to merit a seperate article. Ethanpet113 (talk) 00:04, 18 June 2020 (UTC)

• Oppose They're distinct. There is even scenario testing. A use case is distinct from a scenario as is presented in the references. Unlike with use cases, you have negative scenarios or misuse cases. In fact, many of the items in the negative section here are addressed in scenarios. Walter Görlitz (talk) 21:13, 20 June 2020 (UTC)
• Oppose They're distinct. A use case is not a scenario, even if sometimes scenario are used to describe a use case. These are two different concepts with only a very small overlap. Scenarios can be used to elicit requirements, to validate a design model, to test, to train, to document, even when no use-case is used in the methodology. Use-case is also a very precisely documented technique and not just a way to represent scenarios. See also SWEBOK, which is an authoritative source on this kind of questions--Christophe (talk) 10:07, 20 July 2020 (UTC)

Recommend: Highlighting example cases of when "use-case" has been incorrectly used.

The phrase is commonly used far too lazily and liberally. The most common example is incorrectly replacing the word "application" with the phrase "use-case".

I encountered this incorrect use in a blog post today:

"I’m pretty sure that the majority of current use of '--no-binary' is focused on the “I don’t want to download pre-built binaries, I want to install everything from source” use case"

That isn't an example of a use-case, if anything it's an example of a personality or Agile persona. A use-case is just a single example of somebody operating a system. An entire computer application is not a single use-case. A general attitude towards software isn't a use-case, it's a persona or personality. An example of a use-case would be somebody using an auto-teller machine to see their bank balance. Another example of a different use-case is somebody using that same auto-teller machine to withdraw money. A use-case is a single example of a use of a system. For any system, of even small sophistication, a pocket calculator for example, there are many different possible examples of use-cases. A Word Processor is not a use-case, it's a computer application. Vapourmile (talk) 11:47, 5 August 2020 (UTC)

I think it might be confusing if there would be a long list of what a use-case is not. This article is dedicated to a specific technique/practice in the area of software engineering and system engineering. It was already extended to business modelling by Jacobson himself in his book "The object advantage". But the term is also used in other areas especially in product management and business analysis where use-case means "when to use this product" or "the situation when the product is used". I'd propose to add a section "Variants and related concepts", like in the French version of this article, in which we could clarify that "use case" is sometimes used with a different meaning, and also move all the explanations about differences with scenarios, user stories, etc... --Christophe (talk) 14:10, 7 August 2020 (UTC)

We define what notable subjects are, and we do not try to list all the things that they are not. Walter Görlitz (talk) 03:44, 9 August 2020 (UTC)

Improvement of the article structure needed

This article is historically grown, and has a structure that is difficult to follow:

• It starts with an outdated definition of use cases that refers to a more specialized modelling language (SysML) that is not relevant in most of the context where use cases are applied. THis para should be rewritten, and the reference to SysML moved to another place
• The second paragraph makes some undocumented claims and immediately pushes forward a set of 5 proprietary methods. While this information may be relevant within the article, it gives disproportionate emphasis to these methods , that almost look like advertisement. Most of these methods are btw of the Unified Process family, which is by far not the most used methods representative nowadays. This para should be moved elsewhere.
• The article then immediately moves to UC representations (Section "Template", about textual representations), gives then some general explanation on actors, then gives some information about a specific use of use cases (Section "Business Use cases"), then goes back to reppresentation (Section "Visual modelling"), then gives some example and some pros/cons/limitations etc... without clearly explaining what the use case is, to someone who is not interested in all the details. The information is there but split across different sections with a structure that does not follow a clear path.

I therefore propose to adapt the structure as follows:

1) Create a section Principle, to clarify what a use case is and for what purpose it is used, independently of any specific representation. Since the use-case have evolved significantly in 2011, but the initial practice is still heavily used, the wording should be compatible with both approaches.

2) Add to this section several subsections, to facilitate for the readers to get the big picture:

• Elements of a use case (Typically, the section about actors could be moved to that place),
• Types of use cases, the section about business use case would be moved there, as well as some other paragraphs
• Goal levels : the Cockburn/Goal levels could be moved there as an example (other variants exist but Cockburn's is the most complete.
• Scope: THe Cockburn/scopes could be moved there as an example

3) Create a section Representation, and immediately move the visual modelling and the textual templates therein (two subsections).

4) Pros/cons/limits as today

5) Section Variants and similar concepts to replace and enrich Section Misconceptions Most of the "misconceptions" seem related to confusion with other concepts. And some comments above in this discussion, show that other delimitations are necessary. I therefore propose to reformulate the misconceptions in a more neutral way.

6) Create section Applications or Practical use: this would be a good landing place for the second para about all the methods that use use cases, as well as for SysML, and maybe the use in BPR proposed by Jacobson in one of his books could also be mentioned.

Since this is a long article, it is difficult to do everything without errors in one edit. I'd therefore suggest to follow the steps as numbered here and do every day a little bit. Since I'm not native speaker, I'd ask for indulgence and support.

Would there be any opposition to this proposal?

Christophe (talk) 23:09, 11 August 2020 (UTC)

Please learn about wiki markdown language before you continue to edit, and learn how to reference. I had to clean your earlier mess up and was no mood to do so again. I just left a welcome message on your talk page that should help with that.

As for outdated, if the definition was correct at one point, and if it has changed, a good encyclopedia should explain the transition, not remove it.

Do not re-use the title in the section headings (see MOS:HEADING), and do not use slashes (see MOS:SLASH).

Finally, I get the feeling English is not your first language. You may want to create a temporary workspace so other editors can comment and improve your proposed changes. Walter Görlitz (talk) 00:25, 12 August 2020 (UTC)

Please note that I used exclusively the visual editor and its automatic sourcing tool. If this result in a mess, it must be a bug and I am not the one to blame. I accept nevertheless the critic about unnecessary spaces, and positioning relative to punctuation, which seems to be different in other languages.

This is exactly what I proposed: in the section "Principles" that I tried to add, I wanted to show how the definition evolved. But you deleted it saying it was not needed. THis is very confusing.

Finally, I thank you for the friendly welcome message on my discussion page. I liked especially your advice on remaining civil with other people. Following this constructive discussion and considering all the mess I may have done or could do in future, I came to the conclusion that I'd better avoid this kind of stress and let this article in its current state. Christophe (talk) 19:15, 12 August 2020 (UTC)

No, you control where the punctuation goes in relation to the reference. You cannot blame the tool for your lack of understanding. That is exhibited in the way you just responded. I know that in some forums and email threads it is appropriate to interleave your responses. Not on Wikipedia. The welcome message I left on your talk page should point to articles that discuss this. Walter Görlitz (talk) 19:53, 12 August 2020 (UTC)

Was the spacing and punctuation the only issue? Was that, what you called "a total mess" leaving me worried that I caused a real catastrophe? Until now I stayed very polite and kept low profile. I can understand and excuse that you once had a hard day and that you were "not in the mood" and therefore reverted arbitrarily 1 hour of my work that I dedicated to the community. We are all humans. And maybe you were right and my last edit needs some more thoughts. But I cannot accept repeatedly harsh language, unpleasant remarks and authoritarian tone. I kept until now a friendly and conciliating attitude, but if the hostile language and mean remarks continue, I will report the bullying. Maybe you do not realise how hard your language is. No editor is allowed to demotivate wikipedia contributors who act in good faith just because of personal mood and personal opinions! I propose now that we all cool down and re-read about keeing cool and staying civil. I will rethink my edits, and if you have any comments on the suggestion above, they will be welcome. I will do my best to take your criticism into account, but I might nevertheless still make some errors and typos. I'm human too. My edits are nevertheless thoroughsly sourced and I have all the books at my fingertip, so please do not revert arbitrarily because "probably...". By the way, I took a quick look at the first few of your 60 reversals and deletions and 34 edits on this page since December 2014: the ones I consulted oseemed in majority justified. So despite our clash, I thank you for your contributions to the community, and expect now mutual respect. Christophe (talk) 00:35, 14 August 2020 (UTC)

I'm not sure where I used the total mess term, but this is what I reverted. Punctuation after the reference was a problem. The reference naming is fine, but actual names would be better. MOS:ACRO1STUSE ignored; should have been Software Engineering Body of Knowledge (SWEBOK). Too many extended quotes. Walter Görlitz (talk) 06:14, 14 August 2020 (UTC)

Thank you very much for this additional information. The point about extended quoting and punctuation, as well as the MOS references appeared very useful. I now revised my contribution and hope that you will now find it more valuable. I unfortunately have no control on the naming of the links (the sourcing tool just allows to pick the existing reference to be reused, and apparently names it automatically). Christophe (talk) 15:11, 16 August 2020 (UTC)

You also might want to avoid copyright violations. I grabbed one section of text and searched using Google and found it was copy and pasted from https://www.wizardtechsolutions.com/solutions/use-cases/ among other locations. I have to remove the content completely. Walter Görlitz (talk) 20:24, 16 August 2020 (UTC)

The sentence that you refer to, is indeed as-is on the mentioned external web page. But it was already in the article before my edit, in the second paragraph (the one where I stated here above that it looked like an advertisement); I just moved it around. I have no problem removing this particular one including the unsourced claims that I flagged. But the question could also be inversed: didn't the site copy some elements of the previous article? Or is the author of that sentence the same in both case: some archeology is necessary. So I'll restore 3 of the usages that I verified using my own formulation and keep the litigious part deleted (how come that nobody noticed before my edit? Or am I the only one who gets such a scrutiny?). Christophe (talk) 21:04, 16 August 2020 (UTC)

I see. Makes sense. Feel free to restore that copy. Walter Görlitz (talk) 21:36, 16 August 2020 (UTC)

For the sake of curiosity, I did some more research. The litigious paragraph was published on wikipedia, as it was before my edit, on 20 March 2015. Its previous version, one hour earlier, shows a first sentence that is very different, but the second part ("Use case driven...") was already there. This second part was published by yet another author on 22 August 2013. Interestingly, the wayback machine's earliest snapshot of the web page that shows the same content, is from May 2017. The domain name was already registered on 24 March 2013 according to WHOIS, but the content is copyrighted 2017 according to the website itself, so after the wikipedia's first publication. Anyway, in the meantime I restored the core information : it is now presented with a more objective style. Christophe (talk) 22:24, 16 August 2020 (UTC)

Looks good. It was clearly a case of those sites copying from the article and not providing attribution. Thanks for updating the article. Walter Görlitz (talk) 23:41, 16 August 2020 (UTC)