https://freemind.sourceforge.io/wiki/index.php?action=history&feed=atom&title=Talk%3AUse_case 2026-04-06T08:08:55Z Revision history for this page on the wiki MediaWiki 1.38.7 https://freemind.sourceforge.io/wiki/index.php?title=Talk:Use_case&diff=9551&oldid=prev 2007-10-14T19:32:33Z

<p><span dir="auto"><span class="autocomment">Use Case Granularity</span></span></p> <table style="background-color: #fff; color: #202122;" data-mw="interface"> <col class="diff-marker" /> <col class="diff-content" /> <col class="diff-marker" /> <col class="diff-content" /> <tr class="diff-title" lang="en"> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td> <td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 19:32, 14 October 2007</td> </tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l4">Line 4:</td> <td colspan="2" class="diff-lineno">Line 4:</td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><br/></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><br/></td></tr> <tr><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>You can write use cases that cover a lot of territory, they don&#039;t have to be nearly so detailed as test cases, but they should still be written with the idea of testing them in mind. If a use case calls for something that can&#039;t be tested, you can be fairly sure there will be conflict over that issue later on in the project.</div></td><td class="diff-marker"></td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>You can write use cases that cover a lot of territory, they don&#039;t have to be nearly so detailed as test cases, but they should still be written with the idea of testing them in mind. If a use case calls for something that can&#039;t be tested, you can be fairly sure there will be conflict over that issue later on in the project.</div></td></tr> <tr><td colspan="2" class="diff-side-deleted"></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"></ins></div></td></tr> <tr><td colspan="2" class="diff-side-deleted"></td><td class="diff-marker" data-marker="+"></td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">--[[User:Rben13|Rben13]] 12:32, 14 Oct 2007 (PDT)</ins></div></td></tr> </table>

Rben13 https://freemind.sourceforge.io/wiki/index.php?title=Talk:Use_case&diff=5945&oldid=prev 2007-10-14T19:32:02Z

<p></p> <p><b>New page</b></p><div>==Use Case Granularity==<br /> <br /> In my experience as a QA analyst and software designer, the best use cases have been those that do a good job communicating both to the user community and the engineers. They&#039;ve usually been written in narrative form. The first set developed usually document typical usage of the system. As users, designer, and developers work through the implications of the design, additional cases are written to illustrate corner cases, places where the usual logic can lead to unexpected results.<br /> <br /> You can write use cases that cover a lot of territory, they don&#039;t have to be nearly so detailed as test cases, but they should still be written with the idea of testing them in mind. If a use case calls for something that can&#039;t be tested, you can be fairly sure there will be conflict over that issue later on in the project.</div>

Rben13