<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: How to Write Good Use Case Names &#8211; 7 Tips</title>
	<atom:link href="http://tynerblain.com/blog/2007/01/22/how-to-write-good-use-case-names/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2007/01/22/how-to-write-good-use-case-names/</link>
	<description>Software product success.</description>
	<lastBuildDate>Thu, 18 Mar 2010 00:01:42 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: What is the key to writing a good Use Case?: Ask A Good Product Manager: Your product management questions answered</title>
		<link>http://tynerblain.com/blog/2007/01/22/how-to-write-good-use-case-names/comment-page-1/#comment-363597</link>
		<dc:creator>What is the key to writing a good Use Case?: Ask A Good Product Manager: Your product management questions answered</dc:creator>
		<pubDate>Sun, 04 May 2008 06:16:19 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/01/22/how-to-write-good-use-case-names/#comment-363597</guid>
		<description>[...] Define the use case names. Each name is in the form of subject-verb-object, with a clear goal implicit in the name. [...]</description>
		<content:encoded><![CDATA[<p>[...] Define the use case names. Each name is in the form of subject-verb-object, with a clear goal implicit in the name. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2007/01/22/how-to-write-good-use-case-names/comment-page-1/#comment-67236</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Fri, 26 Jan 2007 15:49:16 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/01/22/how-to-write-good-use-case-names/#comment-67236</guid>
		<description>Great additions Harry, thanks!</description>
		<content:encoded><![CDATA[<p>Great additions Harry, thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Harry Nieboer</title>
		<link>http://tynerblain.com/blog/2007/01/22/how-to-write-good-use-case-names/comment-page-1/#comment-67131</link>
		<dc:creator>Harry Nieboer</dc:creator>
		<pubDate>Thu, 25 Jan 2007 22:43:14 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/01/22/how-to-write-good-use-case-names/#comment-67131</guid>
		<description>I would add one tip and extend another of your seven:

Good Use Case Names Use Terms From The User Domain.

  As the name of the use case must make the meaning of the Use Case
  clear to the users it is a good idea to use terms from the users. 
  These terms should preferably be included in your glossary.

Good Use-Case Names Reflect User Goals, and not the way that goal is accomplished.

  Too often names like &quot;add appointment in Outlook&quot; are used, whereas
  a solution-neutral &quot;plan appointment&quot; definitely reflects the User Goal
  better.
  Try to avoid Use-Case names that begin with &quot;Do&quot;, &quot;Process&quot; or 
  &quot;Carry out&quot;

Good Use-Case Names Reflect one Goal for one User

  Use Cases are too big if the flow or alternate flows are only of value
  to distinct Actors.
  Use Cases are too big if they reflect multiple goals that would not
  necessarily be achieved at the same moment in time, e.g. &quot;Finish book
  and send it to editor&quot;
  Use Cases are too big if they reflect a goal that can not
  be achieved at a single moment in time, e.g. &quot;Write book&quot;</description>
		<content:encoded><![CDATA[<p>I would add one tip and extend another of your seven:</p>
<p>Good Use Case Names Use Terms From The User Domain.</p>
<p>  As the name of the use case must make the meaning of the Use Case<br />
  clear to the users it is a good idea to use terms from the users.<br />
  These terms should preferably be included in your glossary.</p>
<p>Good Use-Case Names Reflect User Goals, and not the way that goal is accomplished.</p>
<p>  Too often names like &#8220;add appointment in Outlook&#8221; are used, whereas<br />
  a solution-neutral &#8220;plan appointment&#8221; definitely reflects the User Goal<br />
  better.<br />
  Try to avoid Use-Case names that begin with &#8220;Do&#8221;, &#8220;Process&#8221; or<br />
  &#8220;Carry out&#8221;</p>
<p>Good Use-Case Names Reflect one Goal for one User</p>
<p>  Use Cases are too big if the flow or alternate flows are only of value<br />
  to distinct Actors.<br />
  Use Cases are too big if they reflect multiple goals that would not<br />
  necessarily be achieved at the same moment in time, e.g. &#8220;Finish book<br />
  and send it to editor&#8221;<br />
  Use Cases are too big if they reflect a goal that can not<br />
  be achieved at a single moment in time, e.g. &#8220;Write book&#8221;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
