Talk:Use case

From Wikipedia, the free encyclopedia

To-do list for Use case: edit · history · watch · refresh
  • Mention of user stories because of overlap
  • Need to add stakeholder and interests model
  • Add controversies and current developments section
    • Levels
    • Limitations
  • Add section on writing process
      • Add a whole discussion on why Main flow + multiple Alternate Flows leads to complex documentation. The origination being tool driven for tests scripts - prior to Rose Use case scripting was detailed by conditional logic or structured english and led on to OIDs (object interaction diagrams - one per use case. Instead of the modern practice of Sequence diagrams - one per flow.
  • Add section on use case driven design
  • Use case template
    • Add stakeholders and interests section
    • Add Cockburns titles for sections because so commonly known
  • Precursors of use cases
  • Wikify
  • Add a link to systems-of-systems from http://en.wikipedia.org/wiki/System_of_systems
  • Standardize references

Contents

[edit] 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)

[edit] 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.

[edit] 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)

[edit] 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.

[edit] 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)

[edit] 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)

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

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

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)

[edit] 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)

[edit] 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

[edit] 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).

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)