blog.casecomplete.com
Open in
urlscan Pro
54.226.9.109
Public Scan
Submitted URL: http://blog.casecomplete.com/
Effective URL: https://blog.casecomplete.com/
Submission: On May 12 via api from US — Scanned from DE
Effective URL: https://blog.casecomplete.com/
Submission: On May 12 via api from US — Scanned from DE
Form analysis 1 forms found in the DOM
Name: aspnetForm — POST /
<form name="aspnetForm" method="post" action="/" id="aspnetForm">
<div>
<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="">
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="">
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"
value="/wEPDwUKMTU0Njg0NDk0OQ9kFgJmD2QWBAIBD2QWAgIRDxYCHgdjb250ZW50BaIBdXNlIGNhc2VzLCByZXF1aXJlbWVudHMsIHVzZSBjYXNlIGRpYWdyYW1zLCB1c2UgY2FzZSB0b29sLCB1c2UgY2FzZSBzb2Z0d2FyZSwgQ2FzZUNvbXBsZXRlLEhvdy1UbyxSZXF1aXJlbWVudHMsU29mdHdhcmUgRGV2ZWxvcG1lbnQsU3VjY2VzcyBTdG9yaWVzLFRpcHMsVXNlIENhc2VzZAIDD2QWAgICDxYCHgdWaXNpYmxlaGRkaKUovwhHHGkdhFUUhPv2x0CQJTc=">
</div>
<script type="text/javascript">
//<![CDATA[
var theForm = document.forms['aspnetForm'];
if (!theForm) {
theForm = document.aspnetForm;
}
function __doPostBack(eventTarget, eventArgument) {
if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
theForm.__EVENTTARGET.value = eventTarget;
theForm.__EVENTARGUMENT.value = eventArgument;
theForm.submit();
}
}
//]]>
</script>
<script src="/WebResource.axd?d=VjwlIqi7esLpp02YYsQj5vb-ws10arl6pmfvuDlShTmJbrmWkcW18HyiP3-g-C-LuV80Q3XQAy-AV4njmeyBLCbw27o1&t=638286065964787378" type="text/javascript"></script>
<!-- header -->
<div id="wrapper">
<div class="navbar navbar-static-top">
<div class="navbar-inner">
<div class="container">
<div type="button" class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse">
<span class="icon icon-bar icon-white"></span>
<span class="icon icon-bar icon-white"></span>
<span class="icon icon-bar icon-white"></span>
</div>
<a class="brand" href="//www.casecomplete.com">
<img src="//c2w.s3.amazonaws.com/newCC_logo.png">
</a>
<div class="nav-collapse collpase">
<ul class="nav pull-right">
<li><a href="//www.casecomplete.com/product/tour">Tour</a></li>
<li><a href="//www.casecomplete.com/try">Try It</a></li>
<li><a href="//www.casecomplete.com/learn">Learn</a></li>
<li><a href="//www.casecomplete.com/pricing">Pricing</a></li>
</ul>
</div>
</div>
</div>
</div>
<!-- visual box -->
<div id="pageheader">
<div class="container">
<div class="row">
<div class="span7">
<h1 class="blog-name"><a href="http://blog.casecomplete.com/">The Use Case Blog</a></h1>
<p><strong>Managing Requirements with Use Cases</strong></p>
</div>
<div class="span5">
<div id="searchbox" class="buffer-top input-append">
<label for="searchfield" style="display:none">Search</label><input type="text" value="" id="searchfield" onkeypress="if(event.keyCode==13) return BlogEngine.search('/')" onfocus="BlogEngine.searchClear('')"
onblur="BlogEngine.searchClear('')"><input class="btn" type="button" value="Search" id="searchbutton" onclick="BlogEngine.search('/');" onkeypress="BlogEngine.search('/');">
</div>
</div>
</div>
</div>
</div>
<!-- content -->
<div id="content">
<div class="container">
<div class="row">
<div class="span10 offset1" id="post-area">
<div id="ctl00_cphBody_divError"></div>
<div id="ctl00_cphBody_PostList1_posts" class="posts">
<div class="post xfolkentry">
<h1 class="post-title"><a href="/post/User-Stories-and-Use-Cases-Not-All-That-Different" class="taggedlink">User Stories and Use Cases: Not All That Different</a></h1>
<div class="row">
<div class="span5">
<span class="author">by <a href="http://blog.casecomplete.com/contact.aspx">Matt Terski</a></span>
</div>
<!--REMOVE SHARE LINKS-->
<!--<div class="span5">
<div class="bookmarks pull-right">
<span class="st_twitter_large" displayText="Tweet" st_url='http://blog.casecomplete.com/post/User-Stories-and-Use-Cases-Not-All-That-Different' st_title='User Stories and Use Cases: Not All That Different'></span>
<span class="st_facebook_large" displayText="Facebook" st_url='http://blog.casecomplete.com/post/User-Stories-and-Use-Cases-Not-All-That-Different' st_title='User Stories and Use Cases: Not All That Different'></span>
<span class="st_email_large" displayText="Email" st_url='http://blog.casecomplete.com/post/User-Stories-and-Use-Cases-Not-All-That-Different' st_title='User Stories and Use Cases: Not All That Different'></span>
<span class="st_sharethis_large" displayText="ShareThis" st_url='http://blog.casecomplete.com/post/User-Stories-and-Use-Cases-Not-All-That-Different' st_title='User Stories and Use Cases: Not All That Different'></span>
</div>
</div>-->
</div>
<div class="post-body">
<p>TL;DR In the beginning, user stories and use cases are nearly indistinguishable. In the end, they serve distinct purposes and could look very different. Who cares? Anyone who wants to deliver projects in an agile way but still
have a written record of what was built when it's done.</p>
<h2>They Start Out the Same</h2>
<p>I know this is well traveled territory and the <a href="http://www.boost.co.nz/blog/2012/01/use-cases-or-user-stories/">consensus on the internet</a> is that user stories and use cases are so different that to suggest any
likeness between the two would be absurd. But before you lecture me about <a href="http://alistair.cockburn.us/Stop+confusing+use+cases+and+user+stories">gazelles and gazebos</a>, I humbly submit:</p>
<p>
<a href="https://blog.casecomplete.com/image.axd?picture=UserStoryVersusUseCaseChecklist.png"><img style="display: inline; border-width: 0px;" title="User Story Versus Use Case Checklist" src="https://blog.casecomplete.com/image.axd?picture=UserStoryVersusUseCaseChecklist_thumb.png" alt="User Story vs Use Case" width="1245" height="745" border="0"></a>
</p>
<p>I know what some of you are thinking, "Wait wait... user stories are lovingly written on index cards crafted from post-consumer content while use cases destroy countless trees each year to build the weighty tomes in which they
live!" To you, I humbly submit a use case:</p>
<p>
<a href="https://blog.casecomplete.com/image.axd?picture=UseCaseIndexCard.jpg"><img style="display: inline; border-width: 0px;" title="Use Case Index Card" src="https://blog.casecomplete.com/image.axd?picture=UseCaseIndexCard_thumb.jpg" alt="Use Case Index Card" width="800" height="533" border="0"></a>
</p>
<p>Sometimes, this is as far as I’ll take a use case. If I write my use case on an index card or sticky note, does it become a user story? The truth is, the amount of detail put into a use case is entirely up to you. You're free to
add more detail than is useful or necessary but, of course, you would be doing it wrong.</p>
<p>Let's look at a few definitions from respected authorities in this area:</p>
<blockquote>
<p>User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. <br>
<br><a href="http://www.mountaingoatsoftware.com/agile/user-stories">Mike Cohn - User story expert</a></p>
</blockquote>
<p>I like this. I like short and simple. I like writing from the perspective of a user. Am I allowed to write a short and simple use case? Or would that make it a user story? And here:</p>
<blockquote>
<p>A use case is all the ways of using a system to achieve a particular goal for a particular user.</p>
<p><br><a href="http://www.slideshare.net/MikeSorokin/use-case20">Ivar Jacobson - Inventor of use cases</a></p>
</blockquote>
<p>So you could say I'm wrong and that user stories and use cases are beyond comparison. And I could say, “Gosh, I certainly do see some similarities between the two.” For the record, I understand the nuance that the intent of a
user story is away from documentation and the intent of a use case is often to write things down.</p>
<h2>Why Do We Care?</h2>
<p>So why do I want to have this debate? Actually, I don't. I'm not a methodologist. I would rather get my hands dirty building something than have a debate over semantics. If you love user stories and don't care for use cases, then
write your stories, agree to have a conversation about them, and be happy. But here's the problem I'm trying to solve: there are a growing number of teams who want to achieve two objectives:</p>
<ul>
<li>They want to deliver a project with the agility afforded by user stories. They want to add value sooner and in smaller increments, whether doing sprints or continuous delivery.</li>
<li>Once their system is delivering value, they want to have a more detailed, written record of how parts of it are supposed to behave and they've found that use cases are at least one component of that record.</li>
</ul>
<p>We find these teams in regulated industries like finance, manufacturing, and biotech, as well as other places like the public sector.</p>
<p>If we want to be agile but also want use cases, we can't deliver them whole. They're too large to qualify as backlog items. We need to divide them into bite sized pieces that can be delivered incrementally. How do we do that?
Well, there are two ways to break down a use case: a) into scenarios or b) into smaller use cases.</p>
<h2>Use Cases to Scenarios</h2>
<p>A use case is a combination of its main success scenario plus extensions. The main success scenario is the simplest or most common path that achieves the use case goal. The extensions cover all the other ways the use case could
succeed or fail. Visually, these combinations would look something like this:</p>
<p>
<a href="https://blog.casecomplete.com/image.axd?picture=UseCaseScenarios.png"><img style="display: inline; border-width: 0px;" title="Use Case Scenarios" src="https://blog.casecomplete.com/image.axd?picture=UseCaseScenarios_thumb.png" alt="Use Case Scenarios" width="1245" height="962" border="0"></a>
</p>
<p>Each scenario could be delivered independently. This works because a scenario is obviously smaller than the entire use case and, in fact, there's good reason to deliver use cases this way. Add value early by shipping just the
simplest or most vital scenario first. Then, deliver extension cases later. The most obscure extensions might not be delivered at all, but instead get handled manually outside of the system (an idea I first heard from
<a href="http://www.vimstreet.com/">Jake Calabrese</a>).</p>
<p>Here's the rub: these scenarios are not user stories. If you're bent on delivering user stories, this approach isn't for you. Why? Because the goal of each scenario remains the same regardless of the path the user took to achieve
it. If you tried to write a user story for each alternate path (an extension that succeeds), they would all look the same. And, as far as I know, there is no such thing as a user story for an exception (an extension that fails).
</p>
<p>Although each extension isn't its own story, the relationship between a use case and its extensions resembles the relationship between a user story and its conditions of satisfaction, - a set of criteria that gauges whether the
story was successful.</p>
<h2>Use Cases to Smaller Use Cases</h2>
<p>Before I dive in here, understand that it's entirely possible that a use case might be small enough in scope to deliver on its own, as-is, in a single iteration. But if the use case goal is too lofty to deliver in one agile
swoop, we could just break it down into smaller use cases where each sub-use case is focused around an incremental goal - a step towards the overall goal of the parent use case. This sounds a lot like an Epic, a large user story
that gets broken down into smaller user stories so they can be delivered incrementally.</p>
<p>
<a href="https://blog.casecomplete.com/image.axd?picture=DividingUseCases.png"><img style="display: inline; border-width: 0px;" title="Dividing Use Cases" src="https://blog.casecomplete.com/image.axd?picture=DividingUseCases_thumb.png" alt="Dividing Use Cases" width="800" height="618" border="0"></a>
</p>
<p>This is where use cases and user stories really start to smell the same to me. I can break an epic user story down into smaller user stories until the stories are small enough to deliver in an iteration. I can break a large use
case down into smaller use cases until the use cases are small enough to deliver in an iteration.</p>
<p>As use cases become smaller in scope, we can vary the amount of detail we add to each one. I might write step-by-step scenarios for some, but for others I might write only a brief description. To some I might add a wireframe or
workflow diagram. For others, I might write acceptance tests only. At this point, the line blurs between use case and user story. A use case with only a name and description looks a lot like a user story. But with this approach,
you'll have organized your requirements into pieces small enough to deliver incrementally without losing the big picture view that comes from having a larger use case model.</p>
<p>To wrap up, I'm not advocating use cases over user stories nor am I advocating the opposite. My point is, if you want use cases, you can have them and you can still deliver value incrementally, the way you might with stories.</p>
</div>
<div class="footer">
<span class="pull-right">
<a rel="bookmark" href="http://blog.casecomplete.com/post.aspx?id=8545a4d4-c329-4978-9674-c2ea8cbb3b2e">Permalink</a> | <a rel="nofollow" href="/post/User-Stories-and-Use-Cases-Not-All-That-Different#comment">Kommentare (0)</a>
</span>
<div style="clear: both;"></div>
</div>
<hr>
</div>
<div class="post xfolkentry">
<h1 class="post-title"><a href="/post/Use-Cases-in-an-Agile-Backlog" class="taggedlink">Use Cases in an Agile Backlog</a></h1>
<div class="row">
<div class="span5">
<span class="author">by <a href="http://blog.casecomplete.com/contact.aspx">Matt Terski</a></span>
</div>
<!--REMOVE SHARE LINKS-->
<!--<div class="span5">
<div class="bookmarks pull-right">
<span class="st_twitter_large" displayText="Tweet" st_url='http://blog.casecomplete.com/post/Use-Cases-in-an-Agile-Backlog' st_title='Use Cases in an Agile Backlog'></span>
<span class="st_facebook_large" displayText="Facebook" st_url='http://blog.casecomplete.com/post/Use-Cases-in-an-Agile-Backlog' st_title='Use Cases in an Agile Backlog'></span>
<span class="st_email_large" displayText="Email" st_url='http://blog.casecomplete.com/post/Use-Cases-in-an-Agile-Backlog' st_title='Use Cases in an Agile Backlog'></span>
<span class="st_sharethis_large" displayText="ShareThis" st_url='http://blog.casecomplete.com/post/Use-Cases-in-an-Agile-Backlog' st_title='Use Cases in an Agile Backlog'></span>
</div>
</div>-->
</div>
<div class="post-body">
<p> A question I’ve been asked a lot lately is, “How do I make use cases work in an agile setting?” I found myself struggling for an answer because <strong>a)</strong> agile is a mindset not a methodology and <strong>b)</strong> I
didn’t think there was anything about use cases that prevented them from being used in an agile setting. So just do it. But I think the questioners were looking for something more prescriptive. So let’s break it down. </p>
<h2>The Backlog</h2>
<p>
<a href="/image.axd?picture=Windows-Live-Writer/7f754bd6927e/5DEA4445/Backlog.png"><img style="background-image: none; margin-top: 0px; margin-right: 0px; margin-bottom: 5px; margin-left: 5px; padding-left: 0px; padding-right: 0px; display: inline; float: right; padding-top: 0px; border-width: 0px" src="/image.axd?picture=Windows-Live-Writer/7f754bd6927e/6AE42456/Backlog_thumb.png" border="0" alt="Backlog" title="Backlog" width="272" height="480" align="right"></a>For
starters, use cases are a form of requirements, and when we’re being agile, requirements go in the backlog. Often, those requirements take the form of user stories, but they could also be use cases. If they were, how might this
work? Consider the composition of the backlog. The items down at the bottom, furthest away from being implemented, are described in a coarse manner. Probably just a name and maybe a description. This feels right since you don’t
want to invest much time or energy in requirements long before they will be designed or implemented. That would be the opposite of agile.
</p>
<p> So use cases would enter the backlog as a simple name and description. Almost like a placeholder – or an agreement to have a conversation later. This reminds me of the definition of a user story actually. One difference would
be, we’d eventually write down parts of that conversation in the form of a use case. </p>
<p> As use cases percolate higher up in the backlog, we’d add more detail to them: a success scenario, some alternate scenarios, maybe related requirements or a wireframe. The risk to avoid here is investing too much effort in
detailing use cases that are further down in the backlog. Don’t write documentation you don’t need. The line you want to to be weary of crossing is writing more detail than what is needed to deliver your next iteration. </p>
<h2>A Use Case: Too Big for a Sprint?</h2>
<p> I think of use cases as one way to group a set of requirements: a user goal, scenarios, constraints, business rules, wireframes, diagrams, etc. As much as I like use cases, one challenge with agile will be, they are too large to
be considered an atomic unit of work. By themselves, they don’t make for a useful burn down chart. In fact, you might not fit a complete use case into a single sprint. So the use case – this grouping of requirements – needs to be
broken down into some other logical chunks of work. </p>
<p> I’ll cover what those chunks are in my next post. </p>
<p>
<em>What do you think? Are use cases and an agile backlog a complete mismatch? Let me know in the comments.</em>
</p>
</div>
<div class="footer">
<span class="pull-right">
<a rel="bookmark" href="http://blog.casecomplete.com/post.aspx?id=205f810e-1d3a-44ae-a3e9-f6f7d8371125">Permalink</a> | <a rel="nofollow" href="/post/Use-Cases-in-an-Agile-Backlog#comment">Kommentare (0)</a>
</span>
<div style="clear: both;"></div>
</div>
<hr>
</div>
<div class="post xfolkentry">
<h1 class="post-title"><a href="/post/From-Goals-to-Use-Cases" class="taggedlink">From Goals to Use Cases</a></h1>
<div class="row">
<div class="span5">
<span class="author">by <a href="http://blog.casecomplete.com/contact.aspx">Matt Terski</a></span>
</div>
<!--REMOVE SHARE LINKS-->
<!--<div class="span5">
<div class="bookmarks pull-right">
<span class="st_twitter_large" displayText="Tweet" st_url='http://blog.casecomplete.com/post/From-Goals-to-Use-Cases' st_title='From Goals to Use Cases'></span>
<span class="st_facebook_large" displayText="Facebook" st_url='http://blog.casecomplete.com/post/From-Goals-to-Use-Cases' st_title='From Goals to Use Cases'></span>
<span class="st_email_large" displayText="Email" st_url='http://blog.casecomplete.com/post/From-Goals-to-Use-Cases' st_title='From Goals to Use Cases'></span>
<span class="st_sharethis_large" displayText="ShareThis" st_url='http://blog.casecomplete.com/post/From-Goals-to-Use-Cases' st_title='From Goals to Use Cases'></span>
</div>
</div>-->
</div>
<div class="post-body">
<p>Here’s a common scenario for many of us who have learned about uses cases but haven’t written one yet: You’ve identified the actors for your project. You’ve brainstormed a list of goals for each actor. You’re ready to create your
first set of use cases. And you feel stuck. Or at least uncertain. Call it use case writer’s block. You could point to a use case if you saw one, but what are <em>your</em> use cases?</p>
<p>When this happens, remember that use cases are based on actor goals. If a use case doesn’t describe how an actor gets something done, it’s not really a use case. Does that mean that every goal becomes use case? Not necessarily.
Goals address needs at many levels – from very high levels to very low levels and infinite shades in between. Consider the following goals:<img style="display: inline; margin-left: 0px; margin-right: 0px; border-width: 0px;"
title="actor goals" src="https://blog.casecomplete.com/image.axd?picture=WindowsLiveWriter/FromGoalstoUseCases/320CF415/iStock_000007623639XSmallresize.jpg" alt="actor goals" width="200" height="300" align="right" border="0">
</p>
<ul>
<li>Relax</li>
<li>Plan a vacation</li>
<li>Reserve a room</li>
<li>Find a resort</li>
<li>Pick a destination</li>
<li>Type the name of a city into a text box</li>
<li>Open a web browser</li>
</ul>
<p>These are all related goals, but at different levels. Not all of them will make for a good use case. Pick a high level goal and the use case will either be too big to comprehend or too imprecise to guide decisions. Pick a low
level goal and the use case will be too small and you’ll need too many of them to describe the system. This is starting to sound like a fairy tale involving three bears, but – you guessed it – the best goals are neither too high,
nor too low, but just right.</p>
<p>If you’re wondering what goal levels are <em>just right</em>, here’s a more concrete guideline from Craig Larman’s
<a href="http://www.craiglarman.com/wiki/index.php?title=Books_by_Craig_Larman#Applying_UML_and_Patterns" target="_blank">Applying UML and Patterns</a>: Write use cases at the level of the <em>elementary business process
(EBP):</em></p>
<blockquote>
<p>A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.</p>
</blockquote>
<p>There are exceptions to this guideline, of course. You might want a high-level use case that puts context around the EBP use cases. You might occasionally want a low-level use case that describes a complex sub-process. When
you’re identifying the bulk of your use cases, however, most will address goals at the EBP level – something one actor can complete in one place at one time.</p>
<p>To identify the use cases in your system, look at the list of goals you’ve brainstormed. Is each goal written at the elementary business process level? For goals that are written at a level lower than a business event, consider
<em>why</em> the actor wants to achieve that goal. It’s probably just a step towards a higher level goal. For goals that are written at a level higher than a business event, consider <em>how</em> the actor would go about achieving
that goal. There’s probably an intermediate step that has more business meaning in the system you’re defining.</p>
<p>So, back to our use case writer’s block. You’ve just broken through. Each of the EBP-level goals you identified answers the question: What are <em>your</em> use cases?</p>
</div>
<div class="footer">
<span class="pull-right">
<a rel="bookmark" href="http://blog.casecomplete.com/post.aspx?id=3b27cb89-b39f-4c3c-8566-cf2e64ae1f85">Permalink</a> | <a rel="nofollow" href="/post/From-Goals-to-Use-Cases#comment">Kommentare (0)</a>
</span>
<div style="clear: both;"></div>
</div>
<hr>
</div>
<div class="post xfolkentry">
<h1 class="post-title"><a href="/post/Agile-Use-Cases-in-Four-Steps" class="taggedlink">Agile Use Cases in Four Steps</a></h1>
<div class="row">
<div class="span5">
<span class="author">by <a href="http://blog.casecomplete.com/contact.aspx">Matt Terski</a></span>
</div>
<!--REMOVE SHARE LINKS-->
<!--<div class="span5">
<div class="bookmarks pull-right">
<span class="st_twitter_large" displayText="Tweet" st_url='http://blog.casecomplete.com/post/Agile-Use-Cases-in-Four-Steps' st_title='Agile Use Cases in Four Steps'></span>
<span class="st_facebook_large" displayText="Facebook" st_url='http://blog.casecomplete.com/post/Agile-Use-Cases-in-Four-Steps' st_title='Agile Use Cases in Four Steps'></span>
<span class="st_email_large" displayText="Email" st_url='http://blog.casecomplete.com/post/Agile-Use-Cases-in-Four-Steps' st_title='Agile Use Cases in Four Steps'></span>
<span class="st_sharethis_large" displayText="ShareThis" st_url='http://blog.casecomplete.com/post/Agile-Use-Cases-in-Four-Steps' st_title='Agile Use Cases in Four Steps'></span>
</div>
</div>-->
</div>
<div class="post-body">
<p><img style="display: inline; margin-left: 0px; margin-right: 0px; border-width: 0px" src="/image.axd?picture=WindowsLiveWriter/FourStepsTowardsAgileUseCases/13934406/AgileActor.jpg" border="0" alt="AgileActor" title="AgileActor"
width="200" height="172" align="right"> Are use cases agile? They’re sometimes regarded as the lumbering, heavyweight cousin of <em>user stories</em> – the requirements technique favored by agile teams.</p>
<h2>Use Cases ARE Agile. No… really.</h2>
<p>Being agile is an attitude and an approach, while use cases are simply a structure for organizing requirements. There’s nothing about use cases that make them ill-suited for agile teams. Rather, it’s the <em>way that use cases
are typically written</em> that is NOT agile (that is, written completely up-front).</p>
<p>So, “Are use cases agile?” is the wrong question. If you want to stay agile, but need something more than a user story, the question to ask is, “How can I write use cases in an agile manner?” Here are four steps to get you
started.</p>
<h2>Step 1: Start with Actors, Goals, Descriptions</h2>
<p>The agile approach favors early feedback and frequent person-to-person communication. Start delivering value right away by holding a kick-off session with the project’s stakeholders. In this session, brainstorm around two
questions:<img style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 5px; display: inline; border-width: 0px"
src="/image.axd?picture=WindowsLiveWriter/FourStepsTowardsAgileUseCases/730C0453/ContextDiagram.jpg" border="0" alt="ContextDiagram" title="ContextDiagram" width="200" height="164" align="right"></p>
<ul>
<li>Who needs to use the thing we’re about to build? </li>
<li>Why do they need to use it? </li>
</ul>
<p>To help the discussion, create a context diagram on the whiteboard. You can complete this first session in less than an hour and you’ll walk out with your first set of actors and goals.</p>
<p>From the goals you’ve just identified, create your first set of use cases (some goals will be too broad, some too detailed, some will simply turn into use cases). Name each use case with a verb-noun combination (e.g. Create
Account) then write a short description that people will actually read. To avoid getting bogged down while writing the descriptions, you can borrow from
<a href="http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template" target="_blank">a template for writing user stories</a>. Write each description like this:</p>
<blockquote>
<p> <strong>The [actor name] wants to [goal of use case] so that [reason for wanting to achieve that goal].</strong> </p>
</blockquote>
<p>Applying this template to the Create Account use case, I’d wind up with something like:</p>
<blockquote>
<p> <strong>The guest user wants to create an account so that they can access the features available to registered users.</strong> </p>
</blockquote>
<p>Writing the descriptions might take another hour our two. You can then go back and review the use cases and descriptions with your stakeholders. A few hours invested and already your use cases are adding value – getting everybody
aligned with regard to the scope and goals of what you’re going to build.</p>
<h2>Step 2: Write On Demand</h2>
<p>With a set of actors and use cases in hand, you now have the basic structure around which you can hang as much (or as little) requirements detail as the project requires. </p>
<p>Specifying requirements isn’t a matter of writing stuff down, it’s a process of discovery. Writing too much up-front, adding detail too early will only add to the amount of rework that you’ll be saddled with later. Agile
approaches prefer working software over comprehensive documentation. So don’t spend the time required write comprehensive detail to every use case up-front.</p>
<p>Instead, prioritize and decide which use cases will be addressed in the next sprint. Then flesh out those use cases, reviewing your work frequently with the developers who will be implementing them. This will not only preserve
your energy, but you’ll learn when it’s okay to stop adding detail to a use case and call it done (hint: it’s when the reader has enough information to move forward).</p>
<h2>Step 3: Write Effective Steps</h2>
<p>The core of a use case is its <em>main success scenario</em> – six to ten steps that describe how an actor gets something done. When written well, it gives a concise description of how the system needs to behave. When written
poorly, it’s a tedious mess that makes the readers’ eyes glaze over. Learning to write succinct, informative steps is the most important skill a use case author can have. It’s also the hardest skill to acquire, since use case
steps are so different from the traditional way of phrasing requirements.</p>
<p>Each step should describe an action taken either by the system or by the actor. The actions commonly fall into one of the following categories (if it doesn’t, that’s a clue you might not be getting the step right).</p>
<table border="0" cellspacing="2" cellpadding="2" width="600">
<tbody>
<tr>
<td width="296" valign="top"><strong>Kind of Step</strong></td>
<td width="296" valign="top"><strong>Example</strong></td>
</tr>
<tr>
<td width="296" valign="top">System provides information to the actor</td>
<td width="298" valign="top"><em>System displays the search results.</em></td>
</tr>
<tr>
<td width="296" valign="top">System prompts the actor</td>
<td width="298" valign="top"><em>System asks member to accept invitation.</em></td>
</tr>
<tr>
<td width="296" valign="top">System does work on the actor’s behalf</td>
<td width="298" valign="top"><em>System sends request to payment processor.</em></td>
</tr>
<tr>
<td width="296" valign="top">Actor makes a choice</td>
<td width="298" valign="top"><em>Member accepts invitation.</em></td>
</tr>
<tr>
<td width="296" valign="top">Actor provides information to the system</td>
<td width="298" valign="top"><em>Customer enters payment information.</em></td>
</tr>
</tbody>
</table>
<p>Keep the writing lively by describing the information being passed and the work being done. To keep the scenario readable and maintainable, omit details about:</p>
<ul>
<li>the user interface </li>
<li>the format of the data being passed </li>
<li>business rules and formulas </li>
<li>performance (and other non-functional) requirements </li>
</ul>
<p>Whether you capture these details at all depends on your project’s needs. If you do, the use cases provide a nice framework to hang these other requirements on. Use cases give context and keep readers from getting lost in a sea
of requirements. So it’s fine to capture this detail, just leave it out of the use case steps.</p>
<h2>Step 4: Adapt the Level of Precision</h2>
<p>The reputation use cases have as being non-agile stems from the fact that they are structured in nature (name, description, main success scenario, preconditions, etc). Use cases are typically written with a general-purpose tool
(that is, a word processor or spreadsheet). So writers use a template to give their use cases a consistent structure. The problem is, <a href="/post/Use-Case-Templates.aspx">use case templates</a> can lead to some very non-agile
behaviors: a box-checker mentality and doing work that just doesn’t matter. There’s nothing agile about filling out forms or writing something just because there’s an empty space in your template. This is what a template compels
you to do.</p>
<p>To keep it agile, be flexible about how much precision you capture. Learn when it’s okay to stop writing. Start with the name and description – akin to a user story. If your project can succeed without more, don’t add it. If the
stakeholders need more precision, write the main success scenario. Need still more? Write the extensions or add non-functional requirements. Use cases allow you to capture a lot of information, while giving each piece of
information the context it needs to remain understandable. But this doesn’t mean you need to capture all that detail unnecessarily.</p>
<h2>Yes, Use Cases Can Be Agile</h2>
<p>Use cases are just a way to write and organize requirements. While they’re not typically thought of as an agile practice, if you approach them with the right mindset, there’s nothing keeping you from using them in an agile
environment.</p>
</div>
<div class="footer">
<span class="pull-right">
<a rel="bookmark" href="http://blog.casecomplete.com/post.aspx?id=b75a6d52-d4b1-45fc-a394-7a6240ecd7d4">Permalink</a> | <a rel="nofollow" href="/post/Agile-Use-Cases-in-Four-Steps#comment">Kommentare (0)</a>
</span>
<div style="clear: both;"></div>
</div>
<hr>
</div>
<div class="post xfolkentry">
<h1 class="post-title"><a href="/post/Visualize-Business-Rules-with-Statecharts" class="taggedlink">Visualize Business Rules with Statecharts</a></h1>
<div class="row">
<div class="span5">
<span class="author">by <a href="http://blog.casecomplete.com/contact.aspx">Matt Terski</a></span>
</div>
<!--REMOVE SHARE LINKS-->
<!--<div class="span5">
<div class="bookmarks pull-right">
<span class="st_twitter_large" displayText="Tweet" st_url='http://blog.casecomplete.com/post/Visualize-Business-Rules-with-Statecharts' st_title='Visualize Business Rules with Statecharts'></span>
<span class="st_facebook_large" displayText="Facebook" st_url='http://blog.casecomplete.com/post/Visualize-Business-Rules-with-Statecharts' st_title='Visualize Business Rules with Statecharts'></span>
<span class="st_email_large" displayText="Email" st_url='http://blog.casecomplete.com/post/Visualize-Business-Rules-with-Statecharts' st_title='Visualize Business Rules with Statecharts'></span>
<span class="st_sharethis_large" displayText="ShareThis" st_url='http://blog.casecomplete.com/post/Visualize-Business-Rules-with-Statecharts' st_title='Visualize Business Rules with Statecharts'></span>
</div>
</div>-->
</div>
<div class="post-body">
<p>Because statechart diagrams are visually intuitive, they’re great for capturing business rules in a way that your stakeholders can understand. Statechart diagrams show the valid states that a business entity can take, and the
events that make the entity change state.</p>
<p>Suppose you are defining requirements for the order management system of a business that sells customized products. Consider the business rules and workflow for a custom order. The order has to be tracked through the process of
taking, planning, fulfilling and delivering it. </p>
<p>To create a statechart diagram (also known as a state diagram or state-transition diagram), think about the different states that an order can take. Each state is a distinct status and is drawn as a rectangle with rounded
corners.</p>
<p> <img style="display: block; float: none; margin-left: auto; margin-right: auto; border-width: 0px" src="/image.axd?picture=WindowsLiveWriter/VisualizeBusinessRuleswithStatecharts/0B915C88/statechart1.png" border="0"
alt="statechart1" title="statechart1" width="300" height="300"> </p>
<p>Show the valid ways the order can move from one state to another by connecting the states with <em>transitions</em>. The diagram begins with a start state (a filled small circle) and ends with a stop state (a small filled circle
within a larger concentric ring). Transitions between states are triggered by <em>events</em>. You can label each transition with the event that caused it to happen. For example, when an order is placed, the order enters the New
state (until something else happens).</p>
<p> <img style="display: block; float: none; margin-left: auto; margin-right: auto; border-width: 0px" src="/image.axd?picture=WindowsLiveWriter/VisualizeBusinessRuleswithStatecharts/188B3C99/statechart2.png" border="0"
alt="statechart2" title="statechart2" width="350" height="556"> </p>
<p>The statechart diagram will help ensure you <em>and</em> your stakeholders have the same understanding of the business rules. You’ll also discover new business rules by walking through the diagram. For example, can an order be
canceled once it is in progress? There’s probably a business rule that determines if and when that can happen. </p>
<p>Consider a business rule that states an in progress order can only be cancelled with a manager’s approval. We can add that to our statechart diagram using a <em>guard condition</em>. Guard conditions are like gates that only open
under certain conditions. Use a bit of text to state the condition that has to be true in order to follow a transition (e.g. “Manager Approval”).</p>
<p><img style="display: block; float: none; margin-left: auto; margin-right: auto; border-width: 0px" src="/image.axd?picture=WindowsLiveWriter/VisualizeBusinessRuleswithStatecharts/2E91A82B/statechart3_thumb.png" border="0"
alt="statechart3" title="statechart3" width="449" height="372"> </p>
<p>As you are developing requirements, you’ll likely discover new states, or realize that other states aren’t valid. Keep your states at a level that is of interest to your business stakeholders. It’s not necessary to capture every
possible state – just the ones that are meaningful in the scope of your requirements.</p>
<p>Getting stakeholders to actually read requirements is always a challenge. Put six important paragraphs of requirements next to a diagram and guess what your readers will study. The diagram, of course – everybody likes pictures.
Without any training, a business stakeholder can look at a statechart diagram, understand it, and point out where it falls short. This makes the statechart diagram a valuable tool for getting you and your readers on the same page
with regard to business rules.</p>
</div>
<div class="footer">
<span class="pull-right">
<a rel="bookmark" href="http://blog.casecomplete.com/post.aspx?id=48754e15-9de8-4547-a204-d632a2961548">Permalink</a> | <a rel="nofollow" href="/post/Visualize-Business-Rules-with-Statecharts#comment">Kommentare (0)</a>
</span>
<div style="clear: both;"></div>
</div>
<hr>
</div>
<div class="post xfolkentry">
<h1 class="post-title"><a href="/post/Use-Case-Templates" class="taggedlink">Use Case Templates</a></h1>
<div class="row">
<div class="span5">
<span class="author">by <a href="http://blog.casecomplete.com/contact.aspx">Matt Terski</a></span>
</div>
<!--REMOVE SHARE LINKS-->
<!--<div class="span5">
<div class="bookmarks pull-right">
<span class="st_twitter_large" displayText="Tweet" st_url='http://blog.casecomplete.com/post/Use-Case-Templates' st_title='Use Case Templates'></span>
<span class="st_facebook_large" displayText="Facebook" st_url='http://blog.casecomplete.com/post/Use-Case-Templates' st_title='Use Case Templates'></span>
<span class="st_email_large" displayText="Email" st_url='http://blog.casecomplete.com/post/Use-Case-Templates' st_title='Use Case Templates'></span>
<span class="st_sharethis_large" displayText="ShareThis" st_url='http://blog.casecomplete.com/post/Use-Case-Templates' st_title='Use Case Templates'></span>
</div>
</div>-->
</div>
<div class="post-body">
<p>Use cases and templates go together like peanut butter and jelly. No other analysis technique has become so associated with templates. <a href="http://www.google.com/search?q=use+case+templates" target="_blank">Search the web</a>
and you’ll find dozens. Just don’t become a <strong>template zombie</strong>.</p>
<blockquote>
<p> When you find a project team that is focused on producing a standard document rather than on considering the content of that document, then you are in the land of the template zombies. </p>
<p align="right"> <a href="http://www.amazon.com/Adrenaline-Junkies-Template-Zombies-Understanding/dp/0932633676" target="_blank">Adrenaline Junkies and Template Zombies</a> </p>
</blockquote>
<h2>Benefits and Dangers of Templates </h2>
<p><img style="display: inline; margin-left: 0px; margin-right: 0px; border-width: 0px" src="/image.axd?picture=WindowsLiveWriter/UseCaseTemplates_F095/iStock_000006319863XSmall-Resized_thumb.jpg" border="0"
alt="©iStockphoto/Maksym Yemelynov" title="©iStockphoto/Maksym Yemelynov" width="206" height="156" align="right">Templates are like checklists. They help ensure you haven’t missed anything. Write something into each field of the
template and all your bases are covered. Nothing missed.</p>
<p>The template’s comfortable consistency hides the danger: <strong>filling out the template gives a false sense of security</strong>. Each project is slightly different, but a template remains the same. We’re fooled into thinking
that consistency means quality. When in fact, applying a use case template <em>without thinking</em> introduces its own set of problems. It compels use case writers to:</p>
<ul>
<li>Include something that wasn’t needed just to fill in a section, making the requirements more difficult to read. </li>
<li>Skip an important piece of information because it wasn’t in the template (or throw up their hands and claim that use cases “don’t work”). </li>
<li>Force traditional declarative requirements into a use case format because they didn’t understand what a use case is. </li>
<li>Get hung up on <em>form</em> rather than <em>content</em>. </li>
</ul>
<p><strong>Use cases are not about changing the format of requirements – they are about changing the perspective.</strong> Rather than look inside-out (“What are all the the things the system must do?”), we look outside-in (“Who
needs to use this system? Why do they need to? How will they use it?”). This results in better requirements that are easier to read, and ultimately, better systems.</p>
<h2>The World’s Best Use Case Template</h2>
<p>There isn’t one. Being successful with use cases doesn’t mean finding the perfect template. So stop searching. Don’t be a template zombie. The best use case template is one that you aren’t afraid to change to best fit the
situation.</p>
</div>
<div class="footer">
<span class="pull-right">
<a rel="bookmark" href="http://blog.casecomplete.com/post.aspx?id=68541247-e6d1-4787-8cad-d8e648b2d9dd">Permalink</a> | <a rel="nofollow" href="/post/Use-Case-Templates#comment">Kommentare (0)</a>
</span>
<div style="clear: both;"></div>
</div>
<hr>
</div>
<div class="post xfolkentry">
<h1 class="post-title"><a href="/post/Writing-Use-Case-Extensions" class="taggedlink">Writing Use Case Extensions</a></h1>
<div class="row">
<div class="span5">
<span class="author">by <a href="http://blog.casecomplete.com/contact.aspx">Matt Terski</a></span>
</div>
<!--REMOVE SHARE LINKS-->
<!--<div class="span5">
<div class="bookmarks pull-right">
<span class="st_twitter_large" displayText="Tweet" st_url='http://blog.casecomplete.com/post/Writing-Use-Case-Extensions' st_title='Writing Use Case Extensions'></span>
<span class="st_facebook_large" displayText="Facebook" st_url='http://blog.casecomplete.com/post/Writing-Use-Case-Extensions' st_title='Writing Use Case Extensions'></span>
<span class="st_email_large" displayText="Email" st_url='http://blog.casecomplete.com/post/Writing-Use-Case-Extensions' st_title='Writing Use Case Extensions'></span>
<span class="st_sharethis_large" displayText="ShareThis" st_url='http://blog.casecomplete.com/post/Writing-Use-Case-Extensions' st_title='Writing Use Case Extensions'></span>
</div>
</div>-->
</div>
<div class="post-body">
<p><img title="©iStockphoto.com/WoodenheadWorld " style="border-top-width: 0px; display: inline; border-left-width: 0px; border-bottom-width: 0px; margin: 0px 0px 5px 5px; border-right-width: 0px" height="244"
alt="©iStockphoto.com/WoodenheadWorld " src="https://blog.casecomplete.com/image.axd?picture=WindowsLiveWriter/WritingUseCaseExtensions_F279/iStock_000007448564XSmall-Resized_3.jpg" width="165" align="right" border="0"> By the
time you write your first complete use case, you’ll realize you’re going to have more <em>extensions</em> than use cases. Extensions are the primary way that use cases help us uncover the most important, interesting requirements
that we might otherwise miss. So let’s talk about how to write a good use case extension.</p>
<h1>First Comes the Main Success Scenario</h1>
<p>To understand what an extension is, you must first understand the <em>main success scenario</em>. Of all the parts that make up a use case, the main success scenario is the most central. It describes the interaction between the
actor and the system as the actor completes the use case. Here’s a main success scenario for a use case named Create Account:</p>
<ol>
<li>System prompts Unregistered User for new account information: <br> Full name <br> Username <br> Password <br> Email address </li>
<li>Unregistered User enters new account information. </li>
<li>System validates new account information </li>
<li>System sends account verification code to Unregistered User’s email </li>
<li>System prompts Unregistered User for verification code </li>
<li>Unregistered User enters verification code </li>
<li>System creates account </li>
</ol>
<p>It’s called the main success scenario because it describes what happens when everything goes right. Of course, rarely does <em>everything</em> go right, but don’t worry about that just yet. Incidentally, if there is more than one
way for a use case to go right, pick the simplest way and make that the main success scenario.</p>
<p>We start with the main success scenario because it’s the shortest path between zero knowledge and understanding what a use case is about. Our readers need this base understanding before they can go any further.</p>
<h1>Then Come the Extensions</h1>
<p>We still need to describe how the system should respond when things either <em>do not </em>go right or <em>do </em>go right, but <em>not</em> in the way we described in the main success scenario. We call these situations
<em>extensions</em>. There are two varieties: <em>exceptions</em> and <em>alternates</em>. Exceptions are failure conditions (something went wrong). Alternates are simply a different way for things to go right. We treat them the
same, so I’m not sure why I just bothered to explain the difference.</p>
<p>To create an extension, we need three pieces of information:</p>
<ul>
<li>The condition that caused the extension to happen </li>
<li>The steps that will happen when the above condition is true </li>
<li>What happens when the steps are complete </li>
</ul>
<h1>The Extension Condition</h1>
<p>First, write the condition. <a href="https://www.amazon.com/Writing-Effective-Cases-Software-Development/dp/0201702258" target="_blank">Alistair Cockburn identifies two essential traits</a> for the condition: It must be something
that the system can detect and it must be something the system will handle. Why? If we don’t limit ourselves to the conditions the system can detect, the possible conditions are endless. And if the system can’t detect a condition,
we can’t do anything about it anyhow. So there’s no point in adding it to our requirements.</p>
<p>For example, in step 3 of the Create Account use case, <em>username is already in use</em> and <em>email address is already in use</em> are conditions the system can detect. In fact, since we’d handle both of these conditions in
the same way, it will be more effective to collapse them into a single condition: <em>username or email address is already in use</em>. </p>
<p>While conditions like <em>Unregistered User mistyped email address</em> or <em>Unregistered User enters someone else’s email address</em> seem valid at first, it’s not something the system can actually detect (How do we know what
the user’s email address is?). Now, if either of these things actually happened, the person who incorrectly received the email might choose to NOT verify the account in step 6. That’s something we can detect, and it’s a condition
we’d want to handle.</p>
<h1>The Extension Steps and Ending</h1>
<p>Next, write the steps that describe what will happen when the condition is true. These are just like any other steps in a use case – they explain the interaction between the actor and the system. For example:</p>
<blockquote>
<p>3.a. Username or email address is already in use.</p>
<ol>
<li>System displays an error message </li>
<li>The use case continues at step 1 </li>
</ol>
</blockquote>
<p>Finally, you might need to write what happens when the extension is complete. I have done this in step 2, above. After the extension, the use case might end, it might pick up right where it left off, or it might continue at
another step. If what’s going to happen is obvious, you might choose not to explicitly say so – in the name of simplicity and brevity.</p>
<p>As I said earlier, you’ll quickly find that extensions will outnumber use cases. To find them, consider each step of a use case and brainstorm for the things that could go wrong or vary. Throw out the conditions you can’t detect
or handle; combine the conditions that will be handled identically. Then describe how your system should handle them. You’re now prepared to uncover and handle requirements you might have otherwise missed.</p>
</div>
<div class="footer">
<span class="pull-right">
<a rel="bookmark" href="http://blog.casecomplete.com/post.aspx?id=db59bd83-6df7-4a16-9001-b161d349760f">Permalink</a> | <a rel="nofollow" href="/post/Writing-Use-Case-Extensions#comment">Kommentare (0)</a>
</span>
<div style="clear: both;"></div>
</div>
<hr>
</div>
<div class="post xfolkentry">
<h1 class="post-title"><a href="/post/Use-Cases-The-Center-of-the-Universe" class="taggedlink">Use Cases: The Center of the Universe?</a></h1>
<div class="row">
<div class="span5">
<span class="author">by <a href="http://blog.casecomplete.com/contact.aspx">Matt Terski</a></span>
</div>
<!--REMOVE SHARE LINKS-->
<!--<div class="span5">
<div class="bookmarks pull-right">
<span class="st_twitter_large" displayText="Tweet" st_url='http://blog.casecomplete.com/post/Use-Cases-The-Center-of-the-Universe' st_title='Use Cases: The Center of the Universe?'></span>
<span class="st_facebook_large" displayText="Facebook" st_url='http://blog.casecomplete.com/post/Use-Cases-The-Center-of-the-Universe' st_title='Use Cases: The Center of the Universe?'></span>
<span class="st_email_large" displayText="Email" st_url='http://blog.casecomplete.com/post/Use-Cases-The-Center-of-the-Universe' st_title='Use Cases: The Center of the Universe?'></span>
<span class="st_sharethis_large" displayText="ShareThis" st_url='http://blog.casecomplete.com/post/Use-Cases-The-Center-of-the-Universe' st_title='Use Cases: The Center of the Universe?'></span>
</div>
</div>-->
</div>
<div class="post-body">
<p>People have differing opinions about the role use cases play in the requirements process.</p>
<p>Some people think use cases are just one step in the process – something to start with. Others think that use cases bridge the gap between high-level business needs and functional requirements. Others think that use cases show
how functional requirements get realized.</p>
<p>In my view, use cases are the center of the requirements universe.</p>
<p><img title="Requirements Approaches" style="border-top-width: 0px; display: block; border-left-width: 0px; float: none; border-bottom-width: 0px; margin: 5px auto; border-right-width: 0px" height="287"
alt="Requirements Approaches" src="https://blog.casecomplete.com/image.axd?picture=WindowsLiveWriter/AreUseCasestheCenteroftheUniverse_AE29/RequirementsApproaches_3.png" width="450" border="0"> </p>
<p>Of course, I’m not saying use cases are the only kind of requirement. There are other categories:</p>
<ul>
<li><strong>Declarative Based.</strong> The traditional way to define requirements. These assert conditions that the system must adhere to. </li>
<li><strong>Model Based.</strong> These describe requirements using models that describe behavior (e.g. activity diagram) or structure (e.g. a data dictionary). </li>
<li><strong>Prototype Based.</strong> These describe requirements using a representation of the user interface. </li>
<li><strong>Testing Based.</strong> Test cases are another way to state the observable behavior the system must adhere to. </li>
</ul>
<p>But at the center of these are the <strong>Use Case Based</strong> requirements. Each use case is based on a goal of an actor using the system. All other kinds of requirements should relate in some way back to one of those goals.
Without the goal, there’s no need for the requirement to exist. So, in essence, use cases really are the center of the requirements universe.</p>
<p>What do you think?</p>
</div>
<div class="footer">
<span class="pull-right">
<a rel="bookmark" href="http://blog.casecomplete.com/post.aspx?id=ac42a8ca-7ba7-4459-a65b-5b098ca9a3c5">Permalink</a> | <a rel="nofollow" href="/post/Use-Cases-The-Center-of-the-Universe#comment">Kommentare (0)</a>
</span>
<div style="clear: both;"></div>
</div>
<hr>
</div>
<div class="post xfolkentry">
<h1 class="post-title"><a href="/post/Are-Your-Requirements-Fit-for-Consumption" class="taggedlink">Are Your Requirements Fit for Consumption?</a></h1>
<div class="row">
<div class="span5">
<span class="author">by <a href="http://blog.casecomplete.com/contact.aspx">Matt Terski</a></span>
</div>
<!--REMOVE SHARE LINKS-->
<!--<div class="span5">
<div class="bookmarks pull-right">
<span class="st_twitter_large" displayText="Tweet" st_url='http://blog.casecomplete.com/post/Are-Your-Requirements-Fit-for-Consumption' st_title='Are Your Requirements Fit for Consumption?'></span>
<span class="st_facebook_large" displayText="Facebook" st_url='http://blog.casecomplete.com/post/Are-Your-Requirements-Fit-for-Consumption' st_title='Are Your Requirements Fit for Consumption?'></span>
<span class="st_email_large" displayText="Email" st_url='http://blog.casecomplete.com/post/Are-Your-Requirements-Fit-for-Consumption' st_title='Are Your Requirements Fit for Consumption?'></span>
<span class="st_sharethis_large" displayText="ShareThis" st_url='http://blog.casecomplete.com/post/Are-Your-Requirements-Fit-for-Consumption' st_title='Are Your Requirements Fit for Consumption?'></span>
</div>
</div>-->
</div>
<div class="post-body">
<p>When writing requirements, how much consideration do you give to the reader?</p>
<p><a href="http://www.bridging-the-gap.com/">Laura Brandau</a> recently commented that <a href="http://twitter.com/ClearSpringBA/status/1116251293">high quality requirements are consumable</a>.</p>
<p>Do you think about who needs to consume your requirements and why? Requirements that are hard to consume are ineffective. A complete and accurate requirements specification that nobody reads might as well be incomplete and
inaccurate.</p>
<h2><em>Communication</em> not <em>Documentation</em></h2>
<p>The point of writing requirements down is to communicate - not just document. When creating a design or writing a piece of code, a developer needs to be able to understand which of the requirements are relevant to the task at
hand. The same can be said of a quality analyst devising a test scenario or a business stakeholder reviewing your spec. These people, like most of us, can only keep about
<a href="http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two">seven pieces of information</a> in their heads at any given time. If your document fails to communicate what the reader needs to know at the time
they need to know it, you've lost.</p>
<h2>Use Cases: Consumable Requirements</h2>
<p>Use cases go a long way towards making a large body of requirements more consumable. Yes, it's possible to write use cases that are hard to read - I know because I've done it myself. But ultimately, a use case describes how an
actor goes about achieving just one goal using your system, and it does it in less than ten steps. The relevant non-behavioral requirements are captured while writing the use case and kept nearby. That way, a reader can understand
those requirements in the proper context.</p>
<p>All of this leads to better communication, not just more documentation.</p>
<p>What do you think? Are use cases really more consumable? </p>
</div>
<div class="footer">
<span class="pull-right">
<a rel="bookmark" href="http://blog.casecomplete.com/post.aspx?id=e69433da-52c4-4a2a-98bc-2d60911b1805">Permalink</a> | <a rel="nofollow" href="/post/Are-Your-Requirements-Fit-for-Consumption#comment">Kommentare (0)</a>
</span>
<div style="clear: both;"></div>
</div>
<hr>
</div>
<div class="post xfolkentry">
<h1 class="post-title"><a href="/post/A-Podcast-on-Use-Cases" class="taggedlink">A Podcast on Use Cases</a></h1>
<div class="row">
<div class="span5">
<span class="author">by <a href="http://blog.casecomplete.com/contact.aspx">Matt Terski</a></span>
</div>
<!--REMOVE SHARE LINKS-->
<!--<div class="span5">
<div class="bookmarks pull-right">
<span class="st_twitter_large" displayText="Tweet" st_url='http://blog.casecomplete.com/post/A-Podcast-on-Use-Cases' st_title='A Podcast on Use Cases'></span>
<span class="st_facebook_large" displayText="Facebook" st_url='http://blog.casecomplete.com/post/A-Podcast-on-Use-Cases' st_title='A Podcast on Use Cases'></span>
<span class="st_email_large" displayText="Email" st_url='http://blog.casecomplete.com/post/A-Podcast-on-Use-Cases' st_title='A Podcast on Use Cases'></span>
<span class="st_sharethis_large" displayText="ShareThis" st_url='http://blog.casecomplete.com/post/A-Podcast-on-Use-Cases' st_title='A Podcast on Use Cases'></span>
</div>
</div>-->
</div>
<div class="post-body">
<p>I was recently interviewed by <a href="http://larryclarkin.com/">Larry Clarkin</a>, co-host of <a href="http://thirstydeveloper.com/2008/12/30/TheThirstyDeveloper46UseCases.aspx">The Thirsty Developer podcast</a>. The interview
was dedicated to the topic of use cases (big surpise!). We spent our time answering use case-related questions like:</p>
<ul>
<li>
<a href="http://thirstydeveloper.com/" target="_blank"><img style="border-width: 0px" src="/image.axd?picture=WindowsLiveWriter/APodcastonUseCases_EFFC/TheThirstyDeveloper_thumb.png" border="0" alt="TheThirstyDeveloper" width="240" height="240" align="right"></a>
What are use cases? </li>
<li>Why are they different or better than other forms of requirements? </li>
<li>Are use cases different than user stories? </li>
<li>What are the downfalls and pitfalls of use cases? </li>
<li>Do use cases have smells? </li>
<li>Can there be too many use cases? </li>
</ul>
<p>It was a lot of fun doing the interview. I hope you'll listen in. </p>
<p>You can download and listen to the show here:</p>
<p><a href="http://www.podtrac.com/pts/redirect.mp3/shows.thirstydeveloper.com/TD046.mp3">http://shows.thirstydeveloper.com/TD046.mp3</a></p>
</div>
<div class="footer">
<span class="pull-right">
<a rel="bookmark" href="http://blog.casecomplete.com/post.aspx?id=508093d4-16fe-44a7-9107-4f2a01a21f9a">Permalink</a> | <a rel="nofollow" href="/post/A-Podcast-on-Use-Cases#comment">Kommentare (0)</a>
</span>
<div style="clear: both;"></div>
</div>
<hr>
</div>
</div>
<div id="postPaging" style="display: none">
<a href="/?page=2" id="ctl00_cphBody_PostList1_hlPrev" style="float:left"><< Vorherige Artikel</a>
</div>
<div style="clear:both; display:block">
<ul id="PostPager" class="buffer-top">
<li class="PagerLinkDisabled btn disabled">Nächste Artikel</li>
<li class="PagerLinkCurrent btn btn-primary">1</li>
<li class="PagerLink btn"><a href="/?page=2">2</a></li>
<li class="PagerLink btn"><a href="/?page=3">3</a></li>
<li class="PagerLink btn"><a href="/?page=4">4</a></li>
<li class="PagerLink btn"><a href="/?page=2">Vorherige Artikel</a></li>
</ul>
</div>
</div>
<!--Excluded since we don't want to show the sidebar-->
<!--<div class="span4">
<p>
</p>
<div id="widgetzone_be_WIDGET_ZONE" class="widgetzone">
<div class="Widget recentposts" id="widget6bcfdd13-a41e-4b10-bf40-0c6e722daa5e">
<div class="WidgetHeader">
Recent Posts</div>
<div class="WidgetContent">
<ul class="recentPosts unstyled" id="recentPosts"><li><a href="/post/User-Stories-and-Use-Cases-Not-All-That-Different">User Stories and Use Cases: Not All That Different</a></li><li><a href="/post/Use-Cases-in-an-Agile-Backlog">Use Cases in an Agile Backlog</a></li><li><a href="/post/From-Goals-to-Use-Cases">From Goals to Use Cases</a></li><li><a href="/post/Agile-Use-Cases-in-Four-Steps">Agile Use Cases in Four Steps</a></li><li><a href="/post/Visualize-Business-Rules-with-Statecharts">Visualize Business Rules with Statecharts</a></li></ul><hr/>
</div>
</div>
<div class="Widget textbox" id="widgetf27f1082-cef2-4efe-9cdf-092129c6f62f">
<div class="WidgetHeader">
Subscribe to The Use Case Blog</div>
<div class="WidgetContent">
<p>Don't miss a single post. Receive updates to this blog in your RSS reader or have each new post sent to your email. </p><p><a rel="alternate" type="application/rss+xml" href="http://feeds.feedburner.com/TheUseCaseBlog"><img style="vertical-align: middle; border-style: initial; border-color: initial; border-width: 1px" src="/pics/rssButton.gif" alt="" width="12" height="12" /></a> <a rel="alternate" type="application/rss+xml" href="http://feeds.feedburner.com/TheUseCaseBlog">Subscribe in a Reader</a> </p><p><a href="http://www.feedburner.com/fb/a/emailverifySubmit?feedId=2455848&loc=en_US" target="_blank"><img style="vertical-align: middle; border-style: initial; border-color: initial; border-width: 1px" src="/pics/mail.gif" alt="" width="14" height="9" /></a> <a href="http://www.feedburner.com/fb/a/emailverifySubmit?feedId=2455848&loc=en_US" target="_blank">Subscribe via Email</a></p><hr/>
</div>
</div>
<div class="Widget textbox" id="widgetf90f485c-597c-4298-96d6-1d57ef30a171">
<div class="WidgetHeader">
Try CaseComplete Free for 30 Days</div>
<div class="WidgetContent">
<a class="btn btn-primary btn-block buffer-top" href="/download"><i class="icon-download-alt icon-white"></i> Get the Trial</a><hr/>
</div>
</div>
<div class="Widget twitter" id="widget212e40d6-980a-4308-bccd-cd8336aab10d">
<div class="WidgetHeader">
CaseComplete on Twitter</div>
<div class="WidgetContent">
<a id="ctl00_widgetContainer212e40d6980a4308bccdcd8336aab10d_212e40d6980a4308bccdcd8336aab10d_hlTwitterAccount" rel="me" href="http://twitter.com/casecomplete">Follow me</a>
</div>
</div>
<div class="Widget textbox" id="widget3f7348cf-0a81-4da4-bab2-478e1a028433">
<div class="WidgetContent">
<a class="buffer-top" href="http://www.linkedin.com/e/gis/1216497" target="_blank"><img src="/themes/CaseComplete/pics/UseCaseProfessionals.png" alt="" width="125" height="125" /></a><hr/>
</div>
</div>
<div class="Widget search" id="widgeta3bb8f9d-0443-4eac-bb1a-f503d3ce0f07">
<div class="WidgetContent">
<div id="searchbox" class="buffer-top input-append" >
<label for="searchfield" style="display:none">Search</label><input type="text" value="" id="searchfield" onkeypress="if(event.keyCode==13) return BlogEngine.search('/')" onfocus="BlogEngine.searchClear('')" onblur="BlogEngine.searchClear('')" /><input class="btn" type="button" value="Search" id="searchbutton" onclick="BlogEngine.search('/');" onkeypress="BlogEngine.search('/');" /></div>
</div>
</div></div>
<p>
Looking for something? See the <a href="http://blog.casecomplete.com/archive.aspx">Archiv</a>
</p>
</div>-->
</div>
</div>
</div>
<!-- footer -->
<div id="footer">
<div class="container holder">
<div class="row">
<div class="span2">
<ul class="nav">
<li>
<h4>Product</h4>
</li>
<li><a href="//casecomplete.com/product/tour">tour</a></li>
<li><a href="//casecomplete.com/try">try</a></li>
<li><a href="//casecomplete.com/learn">learn</a></li>
<li><a href="//casecomplete.com/pricing">pricing</a></li>
</ul>
</div>
<div class="span2">
<ul class="nav">
<li>
<h4>Company</h4>
</li>
<li><a href="//casecomplete.com/about">about</a></li>
<li><a href="//casecomplete.com/contact">contact</a></li>
<li><a href="//casecomplete.com/customers">customers</a></li>
<li><a href="//casecomplete.com/privacy">privacy</a></li>
</ul>
</div>
<div class="span2">
<ul class="nav">
<li>
<h4>Community</h4>
</li>
<li><a href="http://casecomplete.zendesk.com">support</a></li>
<li><a href="//casecomplete.com/news">news</a></li>
<li><a href="http://blog.casecomplete.com">blog</a></li>
</ul>
</div>
<div class="span1 offset4 buffer-top pull-right">
<a href="https://twitter.com/casecomplete" class="social-twitter"></a>
<a href="http://www.linkedin.com/e/gis/1216497" class="social-linkedin"></a>
<a href="https://www.facebook.com/SerlioSoftware" class="social-facebook"></a>
</div>
</div>
<div class="row">
<div class="span4 pull-right copyright">
<p><small>© 2002-2024 Serlio Software</small></p>
</div>
</div>
</div>
</div>
</div>
<div>
<input type="hidden" name="__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="CA0B0334">
</div>
<script type="text/javascript">
//<![CDATA[
var callBackFrameUrl = '/WebResource.axd?d=OvotMEOz-QGFMMYX26ThnAoqwfeSlyW75vTVlWl90kIrXKCWir6MMY3516hCKt9wXV-eekIgfVRU5QqrVnRaUGpjU6k1&t=638286065964787378';
WebForm_InitCallback(); //]]>
</script>
</form>Text Content
* Tour
* Try It
* Learn
* Pricing
THE USE CASE BLOG
Managing Requirements with Use Cases
Search
USER STORIES AND USE CASES: NOT ALL THAT DIFFERENT
by Matt Terski
TL;DR In the beginning, user stories and use cases are nearly indistinguishable.
In the end, they serve distinct purposes and could look very different. Who
cares? Anyone who wants to deliver projects in an agile way but still have a
written record of what was built when it's done.
THEY START OUT THE SAME
I know this is well traveled territory and the consensus on the internet is that
user stories and use cases are so different that to suggest any likeness between
the two would be absurd. But before you lecture me about gazelles and gazebos, I
humbly submit:
I know what some of you are thinking, "Wait wait... user stories are lovingly
written on index cards crafted from post-consumer content while use cases
destroy countless trees each year to build the weighty tomes in which they
live!" To you, I humbly submit a use case:
Sometimes, this is as far as I’ll take a use case. If I write my use case on an
index card or sticky note, does it become a user story? The truth is, the amount
of detail put into a use case is entirely up to you. You're free to add more
detail than is useful or necessary but, of course, you would be doing it wrong.
Let's look at a few definitions from respected authorities in this area:
> User stories are short, simple description of a feature told from the
> perspective of the person who desires the new capability, usually a user or
> customer of the system.
>
> Mike Cohn - User story expert
I like this. I like short and simple. I like writing from the perspective of a
user. Am I allowed to write a short and simple use case? Or would that make it a
user story? And here:
> A use case is all the ways of using a system to achieve a particular goal for
> a particular user.
>
>
> Ivar Jacobson - Inventor of use cases
So you could say I'm wrong and that user stories and use cases are beyond
comparison. And I could say, “Gosh, I certainly do see some similarities between
the two.” For the record, I understand the nuance that the intent of a user
story is away from documentation and the intent of a use case is often to write
things down.
WHY DO WE CARE?
So why do I want to have this debate? Actually, I don't. I'm not a
methodologist. I would rather get my hands dirty building something than have a
debate over semantics. If you love user stories and don't care for use cases,
then write your stories, agree to have a conversation about them, and be happy.
But here's the problem I'm trying to solve: there are a growing number of teams
who want to achieve two objectives:
* They want to deliver a project with the agility afforded by user stories.
They want to add value sooner and in smaller increments, whether doing
sprints or continuous delivery.
* Once their system is delivering value, they want to have a more detailed,
written record of how parts of it are supposed to behave and they've found
that use cases are at least one component of that record.
We find these teams in regulated industries like finance, manufacturing, and
biotech, as well as other places like the public sector.
If we want to be agile but also want use cases, we can't deliver them whole.
They're too large to qualify as backlog items. We need to divide them into bite
sized pieces that can be delivered incrementally. How do we do that? Well, there
are two ways to break down a use case: a) into scenarios or b) into smaller use
cases.
USE CASES TO SCENARIOS
A use case is a combination of its main success scenario plus extensions. The
main success scenario is the simplest or most common path that achieves the use
case goal. The extensions cover all the other ways the use case could succeed or
fail. Visually, these combinations would look something like this:
Each scenario could be delivered independently. This works because a scenario is
obviously smaller than the entire use case and, in fact, there's good reason to
deliver use cases this way. Add value early by shipping just the simplest or
most vital scenario first. Then, deliver extension cases later. The most obscure
extensions might not be delivered at all, but instead get handled manually
outside of the system (an idea I first heard from Jake Calabrese).
Here's the rub: these scenarios are not user stories. If you're bent on
delivering user stories, this approach isn't for you. Why? Because the goal of
each scenario remains the same regardless of the path the user took to achieve
it. If you tried to write a user story for each alternate path (an extension
that succeeds), they would all look the same. And, as far as I know, there is no
such thing as a user story for an exception (an extension that fails).
Although each extension isn't its own story, the relationship between a use case
and its extensions resembles the relationship between a user story and its
conditions of satisfaction, - a set of criteria that gauges whether the story
was successful.
USE CASES TO SMALLER USE CASES
Before I dive in here, understand that it's entirely possible that a use case
might be small enough in scope to deliver on its own, as-is, in a single
iteration. But if the use case goal is too lofty to deliver in one agile swoop,
we could just break it down into smaller use cases where each sub-use case is
focused around an incremental goal - a step towards the overall goal of the
parent use case. This sounds a lot like an Epic, a large user story that gets
broken down into smaller user stories so they can be delivered incrementally.
This is where use cases and user stories really start to smell the same to me. I
can break an epic user story down into smaller user stories until the stories
are small enough to deliver in an iteration. I can break a large use case down
into smaller use cases until the use cases are small enough to deliver in an
iteration.
As use cases become smaller in scope, we can vary the amount of detail we add to
each one. I might write step-by-step scenarios for some, but for others I might
write only a brief description. To some I might add a wireframe or workflow
diagram. For others, I might write acceptance tests only. At this point, the
line blurs between use case and user story. A use case with only a name and
description looks a lot like a user story. But with this approach, you'll have
organized your requirements into pieces small enough to deliver incrementally
without losing the big picture view that comes from having a larger use case
model.
To wrap up, I'm not advocating use cases over user stories nor am I advocating
the opposite. My point is, if you want use cases, you can have them and you can
still deliver value incrementally, the way you might with stories.
Permalink | Kommentare (0)
--------------------------------------------------------------------------------
USE CASES IN AN AGILE BACKLOG
by Matt Terski
A question I’ve been asked a lot lately is, “How do I make use cases work in an
agile setting?” I found myself struggling for an answer because a) agile is a
mindset not a methodology and b) I didn’t think there was anything about use
cases that prevented them from being used in an agile setting. So just do it.
But I think the questioners were looking for something more prescriptive. So
let’s break it down.
THE BACKLOG
For starters, use cases are a form of requirements, and when we’re being agile,
requirements go in the backlog. Often, those requirements take the form of user
stories, but they could also be use cases. If they were, how might this work?
Consider the composition of the backlog. The items down at the bottom, furthest
away from being implemented, are described in a coarse manner. Probably just a
name and maybe a description. This feels right since you don’t want to invest
much time or energy in requirements long before they will be designed or
implemented. That would be the opposite of agile.
So use cases would enter the backlog as a simple name and description. Almost
like a placeholder – or an agreement to have a conversation later. This reminds
me of the definition of a user story actually. One difference would be, we’d
eventually write down parts of that conversation in the form of a use case.
As use cases percolate higher up in the backlog, we’d add more detail to them: a
success scenario, some alternate scenarios, maybe related requirements or a
wireframe. The risk to avoid here is investing too much effort in detailing use
cases that are further down in the backlog. Don’t write documentation you don’t
need. The line you want to to be weary of crossing is writing more detail than
what is needed to deliver your next iteration.
A USE CASE: TOO BIG FOR A SPRINT?
I think of use cases as one way to group a set of requirements: a user goal,
scenarios, constraints, business rules, wireframes, diagrams, etc. As much as I
like use cases, one challenge with agile will be, they are too large to be
considered an atomic unit of work. By themselves, they don’t make for a useful
burn down chart. In fact, you might not fit a complete use case into a single
sprint. So the use case – this grouping of requirements – needs to be broken
down into some other logical chunks of work.
I’ll cover what those chunks are in my next post.
What do you think? Are use cases and an agile backlog a complete mismatch? Let
me know in the comments.
Permalink | Kommentare (0)
--------------------------------------------------------------------------------
FROM GOALS TO USE CASES
by Matt Terski
Here’s a common scenario for many of us who have learned about uses cases but
haven’t written one yet: You’ve identified the actors for your project. You’ve
brainstormed a list of goals for each actor. You’re ready to create your first
set of use cases. And you feel stuck. Or at least uncertain. Call it use case
writer’s block. You could point to a use case if you saw one, but what are your
use cases?
When this happens, remember that use cases are based on actor goals. If a use
case doesn’t describe how an actor gets something done, it’s not really a use
case. Does that mean that every goal becomes use case? Not necessarily. Goals
address needs at many levels – from very high levels to very low levels and
infinite shades in between. Consider the following goals:
* Relax
* Plan a vacation
* Reserve a room
* Find a resort
* Pick a destination
* Type the name of a city into a text box
* Open a web browser
These are all related goals, but at different levels. Not all of them will make
for a good use case. Pick a high level goal and the use case will either be too
big to comprehend or too imprecise to guide decisions. Pick a low level goal and
the use case will be too small and you’ll need too many of them to describe the
system. This is starting to sound like a fairy tale involving three bears, but –
you guessed it – the best goals are neither too high, nor too low, but just
right.
If you’re wondering what goal levels are just right, here’s a more concrete
guideline from Craig Larman’s Applying UML and Patterns: Write use cases at the
level of the elementary business process (EBP):
> A task performed by one person in one place at one time, in response to a
> business event, which adds measurable business value and leaves the data in a
> consistent state.
There are exceptions to this guideline, of course. You might want a high-level
use case that puts context around the EBP use cases. You might occasionally want
a low-level use case that describes a complex sub-process. When you’re
identifying the bulk of your use cases, however, most will address goals at the
EBP level – something one actor can complete in one place at one time.
To identify the use cases in your system, look at the list of goals you’ve
brainstormed. Is each goal written at the elementary business process level? For
goals that are written at a level lower than a business event, consider why the
actor wants to achieve that goal. It’s probably just a step towards a higher
level goal. For goals that are written at a level higher than a business event,
consider how the actor would go about achieving that goal. There’s probably an
intermediate step that has more business meaning in the system you’re defining.
So, back to our use case writer’s block. You’ve just broken through. Each of the
EBP-level goals you identified answers the question: What are your use cases?
Permalink | Kommentare (0)
--------------------------------------------------------------------------------
AGILE USE CASES IN FOUR STEPS
by Matt Terski
Are use cases agile? They’re sometimes regarded as the lumbering, heavyweight
cousin of user stories – the requirements technique favored by agile teams.
USE CASES ARE AGILE. NO… REALLY.
Being agile is an attitude and an approach, while use cases are simply a
structure for organizing requirements. There’s nothing about use cases that make
them ill-suited for agile teams. Rather, it’s the way that use cases are
typically written that is NOT agile (that is, written completely up-front).
So, “Are use cases agile?” is the wrong question. If you want to stay agile, but
need something more than a user story, the question to ask is, “How can I write
use cases in an agile manner?” Here are four steps to get you started.
STEP 1: START WITH ACTORS, GOALS, DESCRIPTIONS
The agile approach favors early feedback and frequent person-to-person
communication. Start delivering value right away by holding a kick-off session
with the project’s stakeholders. In this session, brainstorm around two
questions:
* Who needs to use the thing we’re about to build?
* Why do they need to use it?
To help the discussion, create a context diagram on the whiteboard. You can
complete this first session in less than an hour and you’ll walk out with your
first set of actors and goals.
From the goals you’ve just identified, create your first set of use cases (some
goals will be too broad, some too detailed, some will simply turn into use
cases). Name each use case with a verb-noun combination (e.g. Create Account)
then write a short description that people will actually read. To avoid getting
bogged down while writing the descriptions, you can borrow from a template for
writing user stories. Write each description like this:
> The [actor name] wants to [goal of use case] so that [reason for wanting to
> achieve that goal].
Applying this template to the Create Account use case, I’d wind up with
something like:
> The guest user wants to create an account so that they can access the features
> available to registered users.
Writing the descriptions might take another hour our two. You can then go back
and review the use cases and descriptions with your stakeholders. A few hours
invested and already your use cases are adding value – getting everybody aligned
with regard to the scope and goals of what you’re going to build.
STEP 2: WRITE ON DEMAND
With a set of actors and use cases in hand, you now have the basic structure
around which you can hang as much (or as little) requirements detail as the
project requires.
Specifying requirements isn’t a matter of writing stuff down, it’s a process of
discovery. Writing too much up-front, adding detail too early will only add to
the amount of rework that you’ll be saddled with later. Agile approaches prefer
working software over comprehensive documentation. So don’t spend the time
required write comprehensive detail to every use case up-front.
Instead, prioritize and decide which use cases will be addressed in the next
sprint. Then flesh out those use cases, reviewing your work frequently with the
developers who will be implementing them. This will not only preserve your
energy, but you’ll learn when it’s okay to stop adding detail to a use case and
call it done (hint: it’s when the reader has enough information to move
forward).
STEP 3: WRITE EFFECTIVE STEPS
The core of a use case is its main success scenario – six to ten steps that
describe how an actor gets something done. When written well, it gives a concise
description of how the system needs to behave. When written poorly, it’s a
tedious mess that makes the readers’ eyes glaze over. Learning to write
succinct, informative steps is the most important skill a use case author can
have. It’s also the hardest skill to acquire, since use case steps are so
different from the traditional way of phrasing requirements.
Each step should describe an action taken either by the system or by the actor.
The actions commonly fall into one of the following categories (if it doesn’t,
that’s a clue you might not be getting the step right).
Kind of Step Example System provides information to the actor System displays
the search results. System prompts the actor System asks member to accept
invitation. System does work on the actor’s behalf System sends request to
payment processor. Actor makes a choice Member accepts invitation. Actor
provides information to the system Customer enters payment information.
Keep the writing lively by describing the information being passed and the work
being done. To keep the scenario readable and maintainable, omit details about:
* the user interface
* the format of the data being passed
* business rules and formulas
* performance (and other non-functional) requirements
Whether you capture these details at all depends on your project’s needs. If you
do, the use cases provide a nice framework to hang these other requirements on.
Use cases give context and keep readers from getting lost in a sea of
requirements. So it’s fine to capture this detail, just leave it out of the use
case steps.
STEP 4: ADAPT THE LEVEL OF PRECISION
The reputation use cases have as being non-agile stems from the fact that they
are structured in nature (name, description, main success scenario,
preconditions, etc). Use cases are typically written with a general-purpose tool
(that is, a word processor or spreadsheet). So writers use a template to give
their use cases a consistent structure. The problem is, use case templates can
lead to some very non-agile behaviors: a box-checker mentality and doing work
that just doesn’t matter. There’s nothing agile about filling out forms or
writing something just because there’s an empty space in your template. This is
what a template compels you to do.
To keep it agile, be flexible about how much precision you capture. Learn when
it’s okay to stop writing. Start with the name and description – akin to a user
story. If your project can succeed without more, don’t add it. If the
stakeholders need more precision, write the main success scenario. Need still
more? Write the extensions or add non-functional requirements. Use cases allow
you to capture a lot of information, while giving each piece of information the
context it needs to remain understandable. But this doesn’t mean you need to
capture all that detail unnecessarily.
YES, USE CASES CAN BE AGILE
Use cases are just a way to write and organize requirements. While they’re not
typically thought of as an agile practice, if you approach them with the right
mindset, there’s nothing keeping you from using them in an agile environment.
Permalink | Kommentare (0)
--------------------------------------------------------------------------------
VISUALIZE BUSINESS RULES WITH STATECHARTS
by Matt Terski
Because statechart diagrams are visually intuitive, they’re great for capturing
business rules in a way that your stakeholders can understand. Statechart
diagrams show the valid states that a business entity can take, and the events
that make the entity change state.
Suppose you are defining requirements for the order management system of a
business that sells customized products. Consider the business rules and
workflow for a custom order. The order has to be tracked through the process of
taking, planning, fulfilling and delivering it.
To create a statechart diagram (also known as a state diagram or
state-transition diagram), think about the different states that an order can
take. Each state is a distinct status and is drawn as a rectangle with rounded
corners.
Show the valid ways the order can move from one state to another by connecting
the states with transitions. The diagram begins with a start state (a filled
small circle) and ends with a stop state (a small filled circle within a larger
concentric ring). Transitions between states are triggered by events. You can
label each transition with the event that caused it to happen. For example, when
an order is placed, the order enters the New state (until something else
happens).
The statechart diagram will help ensure you and your stakeholders have the same
understanding of the business rules. You’ll also discover new business rules by
walking through the diagram. For example, can an order be canceled once it is in
progress? There’s probably a business rule that determines if and when that can
happen.
Consider a business rule that states an in progress order can only be cancelled
with a manager’s approval. We can add that to our statechart diagram using a
guard condition. Guard conditions are like gates that only open under certain
conditions. Use a bit of text to state the condition that has to be true in
order to follow a transition (e.g. “Manager Approval”).
As you are developing requirements, you’ll likely discover new states, or
realize that other states aren’t valid. Keep your states at a level that is of
interest to your business stakeholders. It’s not necessary to capture every
possible state – just the ones that are meaningful in the scope of your
requirements.
Getting stakeholders to actually read requirements is always a challenge. Put
six important paragraphs of requirements next to a diagram and guess what your
readers will study. The diagram, of course – everybody likes pictures. Without
any training, a business stakeholder can look at a statechart diagram,
understand it, and point out where it falls short. This makes the statechart
diagram a valuable tool for getting you and your readers on the same page with
regard to business rules.
Permalink | Kommentare (0)
--------------------------------------------------------------------------------
USE CASE TEMPLATES
by Matt Terski
Use cases and templates go together like peanut butter and jelly. No other
analysis technique has become so associated with templates. Search the web and
you’ll find dozens. Just don’t become a template zombie.
> When you find a project team that is focused on producing a standard document
> rather than on considering the content of that document, then you are in the
> land of the template zombies.
>
> Adrenaline Junkies and Template Zombies
BENEFITS AND DANGERS OF TEMPLATES
Templates are like checklists. They help ensure you haven’t missed anything.
Write something into each field of the template and all your bases are covered.
Nothing missed.
The template’s comfortable consistency hides the danger: filling out the
template gives a false sense of security. Each project is slightly different,
but a template remains the same. We’re fooled into thinking that consistency
means quality. When in fact, applying a use case template without thinking
introduces its own set of problems. It compels use case writers to:
* Include something that wasn’t needed just to fill in a section, making the
requirements more difficult to read.
* Skip an important piece of information because it wasn’t in the template (or
throw up their hands and claim that use cases “don’t work”).
* Force traditional declarative requirements into a use case format because
they didn’t understand what a use case is.
* Get hung up on form rather than content.
Use cases are not about changing the format of requirements – they are about
changing the perspective. Rather than look inside-out (“What are all the the
things the system must do?”), we look outside-in (“Who needs to use this system?
Why do they need to? How will they use it?”). This results in better
requirements that are easier to read, and ultimately, better systems.
THE WORLD’S BEST USE CASE TEMPLATE
There isn’t one. Being successful with use cases doesn’t mean finding the
perfect template. So stop searching. Don’t be a template zombie. The best use
case template is one that you aren’t afraid to change to best fit the situation.
Permalink | Kommentare (0)
--------------------------------------------------------------------------------
WRITING USE CASE EXTENSIONS
by Matt Terski
By the time you write your first complete use case, you’ll realize you’re going
to have more extensions than use cases. Extensions are the primary way that use
cases help us uncover the most important, interesting requirements that we might
otherwise miss. So let’s talk about how to write a good use case extension.
FIRST COMES THE MAIN SUCCESS SCENARIO
To understand what an extension is, you must first understand the main success
scenario. Of all the parts that make up a use case, the main success scenario is
the most central. It describes the interaction between the actor and the system
as the actor completes the use case. Here’s a main success scenario for a use
case named Create Account:
1. System prompts Unregistered User for new account information:
Full name
Username
Password
Email address
2. Unregistered User enters new account information.
3. System validates new account information
4. System sends account verification code to Unregistered User’s email
5. System prompts Unregistered User for verification code
6. Unregistered User enters verification code
7. System creates account
It’s called the main success scenario because it describes what happens when
everything goes right. Of course, rarely does everything go right, but don’t
worry about that just yet. Incidentally, if there is more than one way for a use
case to go right, pick the simplest way and make that the main success scenario.
We start with the main success scenario because it’s the shortest path between
zero knowledge and understanding what a use case is about. Our readers need this
base understanding before they can go any further.
THEN COME THE EXTENSIONS
We still need to describe how the system should respond when things either do
not go right or do go right, but not in the way we described in the main success
scenario. We call these situations extensions. There are two varieties:
exceptions and alternates. Exceptions are failure conditions (something went
wrong). Alternates are simply a different way for things to go right. We treat
them the same, so I’m not sure why I just bothered to explain the difference.
To create an extension, we need three pieces of information:
* The condition that caused the extension to happen
* The steps that will happen when the above condition is true
* What happens when the steps are complete
THE EXTENSION CONDITION
First, write the condition. Alistair Cockburn identifies two essential traits
for the condition: It must be something that the system can detect and it must
be something the system will handle. Why? If we don’t limit ourselves to the
conditions the system can detect, the possible conditions are endless. And if
the system can’t detect a condition, we can’t do anything about it anyhow. So
there’s no point in adding it to our requirements.
For example, in step 3 of the Create Account use case, username is already in
use and email address is already in use are conditions the system can detect. In
fact, since we’d handle both of these conditions in the same way, it will be
more effective to collapse them into a single condition: username or email
address is already in use.
While conditions like Unregistered User mistyped email address or Unregistered
User enters someone else’s email address seem valid at first, it’s not something
the system can actually detect (How do we know what the user’s email address
is?). Now, if either of these things actually happened, the person who
incorrectly received the email might choose to NOT verify the account in step 6.
That’s something we can detect, and it’s a condition we’d want to handle.
THE EXTENSION STEPS AND ENDING
Next, write the steps that describe what will happen when the condition is true.
These are just like any other steps in a use case – they explain the interaction
between the actor and the system. For example:
> 3.a. Username or email address is already in use.
>
> 1. System displays an error message
> 2. The use case continues at step 1
Finally, you might need to write what happens when the extension is complete. I
have done this in step 2, above. After the extension, the use case might end, it
might pick up right where it left off, or it might continue at another step. If
what’s going to happen is obvious, you might choose not to explicitly say so –
in the name of simplicity and brevity.
As I said earlier, you’ll quickly find that extensions will outnumber use cases.
To find them, consider each step of a use case and brainstorm for the things
that could go wrong or vary. Throw out the conditions you can’t detect or
handle; combine the conditions that will be handled identically. Then describe
how your system should handle them. You’re now prepared to uncover and handle
requirements you might have otherwise missed.
Permalink | Kommentare (0)
--------------------------------------------------------------------------------
USE CASES: THE CENTER OF THE UNIVERSE?
by Matt Terski
People have differing opinions about the role use cases play in the requirements
process.
Some people think use cases are just one step in the process – something to
start with. Others think that use cases bridge the gap between high-level
business needs and functional requirements. Others think that use cases show how
functional requirements get realized.
In my view, use cases are the center of the requirements universe.
Of course, I’m not saying use cases are the only kind of requirement. There are
other categories:
* Declarative Based. The traditional way to define requirements. These assert
conditions that the system must adhere to.
* Model Based. These describe requirements using models that describe behavior
(e.g. activity diagram) or structure (e.g. a data dictionary).
* Prototype Based. These describe requirements using a representation of the
user interface.
* Testing Based. Test cases are another way to state the observable behavior
the system must adhere to.
But at the center of these are the Use Case Based requirements. Each use case is
based on a goal of an actor using the system. All other kinds of requirements
should relate in some way back to one of those goals. Without the goal, there’s
no need for the requirement to exist. So, in essence, use cases really are the
center of the requirements universe.
What do you think?
Permalink | Kommentare (0)
--------------------------------------------------------------------------------
ARE YOUR REQUIREMENTS FIT FOR CONSUMPTION?
by Matt Terski
When writing requirements, how much consideration do you give to the reader?
Laura Brandau recently commented that high quality requirements are consumable.
Do you think about who needs to consume your requirements and why? Requirements
that are hard to consume are ineffective. A complete and accurate requirements
specification that nobody reads might as well be incomplete and inaccurate.
COMMUNICATION NOT DOCUMENTATION
The point of writing requirements down is to communicate - not just document.
When creating a design or writing a piece of code, a developer needs to be able
to understand which of the requirements are relevant to the task at hand. The
same can be said of a quality analyst devising a test scenario or a business
stakeholder reviewing your spec. These people, like most of us, can only keep
about seven pieces of information in their heads at any given time. If your
document fails to communicate what the reader needs to know at the time they
need to know it, you've lost.
USE CASES: CONSUMABLE REQUIREMENTS
Use cases go a long way towards making a large body of requirements more
consumable. Yes, it's possible to write use cases that are hard to read - I know
because I've done it myself. But ultimately, a use case describes how an actor
goes about achieving just one goal using your system, and it does it in less
than ten steps. The relevant non-behavioral requirements are captured while
writing the use case and kept nearby. That way, a reader can understand those
requirements in the proper context.
All of this leads to better communication, not just more documentation.
What do you think? Are use cases really more consumable?
Permalink | Kommentare (0)
--------------------------------------------------------------------------------
A PODCAST ON USE CASES
by Matt Terski
I was recently interviewed by Larry Clarkin, co-host of The Thirsty Developer
podcast. The interview was dedicated to the topic of use cases (big surpise!).
We spent our time answering use case-related questions like:
* What are use cases?
* Why are they different or better than other forms of requirements?
* Are use cases different than user stories?
* What are the downfalls and pitfalls of use cases?
* Do use cases have smells?
* Can there be too many use cases?
It was a lot of fun doing the interview. I hope you'll listen in.
You can download and listen to the show here:
http://shows.thirstydeveloper.com/TD046.mp3
Permalink | Kommentare (0)
--------------------------------------------------------------------------------
<< Vorherige Artikel
* Nächste Artikel
* 1
* 2
* 3
* 4
* Vorherige Artikel
* PRODUCT
* tour
* try
* learn
* pricing
* COMPANY
* about
* contact
* customers
* privacy
* COMMUNITY
* support
* news
* blog
© 2002-2024 Serlio Software