?? lib0013.html
字號(hào):
<html>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<head>
<title>Writing Use Cases</title>
<link rel="STYLESHEET" type="text/css" href="images/xpolecat.css">
<link rel="STYLESHEET" type="text/css" href="images/ie.content.css">
</head>
<body>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/teamlib.gif" width="62" height="15" border="0" align="absmiddle" alt="Team LiB"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href="LiB0012.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0014.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
<br>
<div class="chapter">
<a name="ch02"></a>
<div class="section">
<h2 class="first-section-title"><a name="68"></a><a name="ch02lev1sec3"></a>Writing Use Cases</h2><p class="first-para">A <i class="emphasis">use case</i> is a description of something a system does at the request of or in response to an action by one of its actors. You should write use cases in business terms, not technical ones. Anyone on the business side should be able to read the text without a translator or technical glossary. Use cases containing technical terms often indicate that technical design assumptions are being made at this stage, and they shouldn't be. Use cases can also serve as a casual "contract" between the business and development sides of the organization as to what will be delivered in what increments.</p>
<p class="para">Use-case text should begin "The system (or application) will." If you identify a use case that cannot be written in this form, it's likely not a valid use case but part of another one. Note that use cases often service multiple actors. I recommend explicitly listing all affected actors in the use case.</p>
<p class="para">The following are examples of use cases from a reporting system:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">The system will provide an interface that will accept report template definitions from an existing MVS/CICS application.</p>
</li>
<li class="listitem">
<p class="first-para">The system will allow application administrators to control the report templates that members of a trust customer organization can run.</p>
</li>
<li class="listitem">
<p class="first-para">The system will run reports at least as fast as its predecessor system did on average.</p>
</li>
<li class="listitem">
<p class="first-para">The system will restrict reported data for all trust customer users to that of the trust customer organization to which they belong.</p>
</li>
<li class="listitem">
<p class="first-para">The system will allow banking support customers to execute all report templates using data from any trust customer organization.</p>
</li>
</ul>
<p class="para">Some of these use cases have additional detail beyond the summary sentences. For example, complete use-case text for the performance requirement is:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">The system will run reports at least as fast as its predecessor system did on average. Trust customer users and banking support users run reports. The primary measurement is the clock time measured from <a name="69"></a><a name="IDX-20"></a>the time the submit button is pressed until the time the user is able to view the report in the browser. CPU time is not relevant to this use case. Performance and scalability were the entire reason the rewrite project was funded.</p>
</li>
</ul>
<p class="para">Uses cases can be written with a more formal organization and content. See <a href="LiB0017.html#82" target="_parent" class="chapterjump">Cockburn (2001)</a> for more details.</p>
<p class="para">
<b class="bold">There are no rules about how long a use case should be.</b> Generally, more information is better. I find it helpful to start with and include a summary for each use case that is no longer than two sentences. This simplifies organizing the use cases as the list grows. As analysis proceeds, you will attach additional detail to most use cases.</p>
<p class="para">
<b class="bold">Avoid use-case diagrams.</b> The UML specification does define a graphical representation scheme for use cases. However, graphical schemes are rarely used, and I purposely do not discuss them in this book. My experience has shown that use-case diagrams confuse both the business side and developers, and that the costs of creating, explaining, and maintaining these graphical constructs far outweigh any benefits they provide.</p>
<p class="para">
<b class="bold">Writing use cases requires in-depth participation from the business side. </b>From the technical side, some business analysts may be able to help construct an initial draft, but the process should not end without direct business side participation and review. Although enlisting the involvement of business users is sometimes easier said than done, their input is valuable. In my experience, insufficient business support for analysis efforts such as use-case review can cause a project to fail.</p>
<p class="para">
<b class="bold">Facilitate use-case analysis by starting with a small group.</b> Technical architects can speed this process along by working with one business side user or a business analyst to draft a set of use cases that can initiate discussion. These draft use cases will be incomplete, and some will be incorrect, but you'll get feedback easier and quicker than you would if you started with a blank sheet of paper. You can use objections to your assumptions to refine and improve the draft use cases.</p>
<p class="para">
<b class="bold">Consider recording use cases in a database.</b> I find it helpful to enter the use cases into a database rather than using a word processor. Please see the "Use Case Template Database" (defined using Microsoft Access) on the Internet at <a target="_top" class="url" href="http://www.dvtpress.com/javaarch/">http://www.dvtpress.com/javaarch/</a>.</p>
<a name="70"></a><a name="IDX-21"></a>
<p class="para">
<b class="bold">Enlist someone to act as "scribe" for the use-case discussions.</b> When you're facilitating a discussion, you won't have time to take good notes. Having someone other than the facilitator write the discussion notes helps ensure that they will be complete and understandable.</p>
<p class="para">
<b class="bold">Write use cases so they can be amended as more information becomes</b> <b class="bold">available.</b> Use cases are always evolving. If you discover additional information in the modeling phases or in later portions of the project, add this material to the use cases.</p>
<p class="para">
<b class="bold">Use-case analysis is finished when team members feel they can estimate</b> <b class="bold">a time to implement each use case.</b> Estimates may be in terms of number of weeks rather than hours. Some developers don't feel comfortable providing estimates until they've essentially coded the application. You may need to gently remind these developers that some difference between the estimate and the actual amount of time a task takes is expected.</p>
<p class="para">
<b class="bold">Be sure to include requirements for security, scalability, and availability. </b>The following are use cases for these three topics from systems I've architected in the past:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">The system will require senior approver users to approve cash transactions exceeding $5 million.</p>
</li>
<li class="listitem">
<p class="first-para">The system will require separating the transaction entry user and the approver.</p>
</li>
<li class="listitem">
<p class="first-para">The system will have reasonable response times for all users with at least eighty concurrently running reports.</p>
</li>
<li class="listitem">
<p class="first-para">The system will be available 24x7x365 with the exception of a fifteen-minute maintenance window on Thursdays at 10 p.m., provided that Thursday is not within five business days of month-end.</p>
</li>
</ul>
<p class="last-para">
<b class="bold">Do not slow down if the group has trouble articulating requirements.</b> Make assumptions and proceed. If your use cases are not right, the objectors have the responsibility to tell you what's wrong so you can correct the problem. You can use that information to refine and improve the use cases.</p>
</div>
</div><br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/teamlib.gif" width="62" height="15" border="0" align="absmiddle" alt="Team LiB"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href="LiB0012.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0014.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
</body></html>?? 快捷鍵說明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號(hào)
Ctrl + =
減小字號(hào)
Ctrl + -