📄 lib0014.html
字号:
<html>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<head>
<title>Common Mistakes</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="LiB0013.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0015.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="71"></a><a name="ch02lev1sec4"></a>Common Mistakes</h2><a name="72"></a><a name="IDX-22"></a>
<p class="para">This section contains examples of use cases that have various defects.</p>
<p class="para">
<b class="bold">Imposing a technical design assumption under the guise of a requirement. </b>This is the mistake I see most frequently. Consider the following use case paraphrased from the reporting system example used earlier in the chapter:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">The system will allow application administrators to limit system load by setting rules that prohibit report execution for groups of users or redirect their execution to a batch stream.</p>
</li>
</ul>
<p class="para">This use case made several unwarranted assumptions and had us solving the wrong problems. It assumed that the hardware/software architecture used by the application could not be scaled to handle the load and that some alternative processing route was necessary. It assumed that the application could not be made as efficient as the "batch stream" mentioned. And it assumed that the batch stream environment in fact had surplus capacity to handle the load that the application should have been handling.</p>
<p class="para">Even if some of the assumptions made in this use case turned out to be true, we should have started by planning an architecture that more than supported our load. In fact, most of the assumptions turned out to be false: The architecture could handle the load efficiently; the batch stream was a frequent performance bottleneck and, in fact, did not have surplus capacity; and the efficiency of the application more than satisfied users.</p>
<p class="para">A better way to write this use case would have been:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">The system will support up to 200 concurrently running reports with a maximum daily volume of 500,000 reports.</p>
</li>
</ul>
<p class="para">
<b class="bold">Including physical design assumptions in use cases.</b> For example, one of the developers submitted the following use case for the reporting system:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">The system will insert a row into the report request table after the request is completed.</p>
</li>
</ul>
<p class="para">This use case made the physical design assumption that we were recording request runs in a table. But at that point, we had not decided whether we would or wouldn't do so, nor should we have. After some discussion, I learned that application administrators needed a way to know what reports a user ran so they could reproduce problems a trust customer reported to the help desk. Given these requirements, a better way to word the use case would have been:</p>
<a name="73"></a><a name="IDX-23"></a>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">The system will record report request history for at least thirty-six hours for the benefit of application administrators and report template developers investigating reported problems.</p>
</li>
</ul>
<p class="para">
<b class="bold">Not keeping analysis sessions productive.</b> Analysis efforts can stall for many reasons, including ineffective facilitation or leadership, an extremely low level of detail in the discussion, and lack of information. Technical architects can steer the development team away from all these problems.</p>
<p class="para">
<b class="bold">Failing to document use cases, even when the project is small.</b> Most developers assume that documenting use cases is unnecessary when the project has only one developer. Use cases should be documented anyway. Documented use cases target the development effort and make tangents less likely. Further, documented use cases communicate the objectives of the development to management and the business side and assist in project transition if additional developers join the team or the project is assigned to another developer.</p>
<p class="para">
<b class="bold">Repeatedly defining terms in every use case.</b> Even for complicated applications, it's unnecessary to define terms repeatedly in every use case in which they appear. Instead, you can define and maintain them once in a separate list of business terms. For example, <i class="emphasis">cash transaction</i> (a term used in an earlier use-case example) refers to money transferred from one account to another. The characteristics of a transaction are that it has an identifier, a date, a cash amount, at most one account from which the money is taken, and at most one account to which the money is transferred.</p>
<p class="last-para">If you think writing use cases seems easy, you're right. The corollary to this is that if you think you're missing something and that writing use cases should be harder than this chapter makes it appear, you're making the task harder than it needs to be. If writing use cases required more than common sense, the practice would not be successful because you would never get a room full of people to agree on the outcome.</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="LiB0013.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0015.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
</body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -