{"id":7815,"date":"2016-05-12T11:30:37","date_gmt":"2016-05-12T16:30:37","guid":{"rendered":"http:\/\/www.watermarklearning.com\/blog\/?p=7815"},"modified":"2021-10-21T11:58:17","modified_gmt":"2021-10-21T16:58:17","slug":"a-pms-guide-to-use-cases-part-3","status":"publish","type":"post","link":"https:\/\/www.watermarklearning.com\/blog\/a-pms-guide-to-use-cases-part-3\/","title":{"rendered":"A PM&#8217;s Guide to Use Cases Part 3: Use Case Narratives"},"content":{"rendered":"<p><strong>Originally published in PM\u00a0Times on December 8, 2015.<\/strong><\/p>\n<hr \/>\n<p>As promised, this is the fifth article in our modeling series and the third on use cases. We\u2019ll start with a short summary of the main concepts covered previously.<\/p>\n<h2><img loading=\"lazy\" decoding=\"async\" class=\"alignright wp-image-7910\" src=\"\/blog\/wp-content\/uploads\/2016\/05\/time-for-review-510x414.jpg\" alt=\"review use case articles\" width=\"150\" height=\"122\" srcset=\"https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2016\/05\/time-for-review-510x414.jpg 510w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2016\/05\/time-for-review-768x624.jpg 768w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2016\/05\/time-for-review-369x300.jpg 369w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2016\/05\/time-for-review.jpg 1000w\" sizes=\"auto, (max-width: 150px) 100vw, 150px\" \/>SUMMARY OF PREVIOUS ARTICLES<\/h2>\n<p>Here are the highlights of the requirements modeling articles written to date:<\/p>\n<ul>\n<li>To get good requirements, we need to ask the right questions. We need to ask both high-level consultative questions to determine the true business need, as well as questions about the features, characteristics, and functionality needed to develop the end product (solution). Modeling helps uncover requirements related to these product features and functions. Asking questions enables us to model the requirements. Modeling requirements, in turn, uncovers gaps that lead to further questions and ultimately helps us deliver the product that our stakeholders want and expect. For more, view <a href=\"\/blog\/a-pms-guide-to-requirements-modeling-part-1\/\" target=\"_blank\" rel=\"noopener\">part 1 of the modeling series<\/a>.<\/li>\n<li>A model is a representation of reality, like a model car, airplane prototype, or graphical design (e.g., a CAD drawing) of a house. As they relate to requirements, models usually consist of text, graphics representations, or both. For more, view\u00a0<a href=\"\/blog\/a-pms-guide-to-requirements-modeling-part-1\/\" target=\"_blank\" rel=\"noopener\">part 1 of the modeling series<\/a>.<\/li>\n<li>As PMs, we might not do business analysis work ourselves, but we need to ensure that work is done. So it\u2019s important for us to be able to have enough understanding of these models to ask the right project questions of the resources who will be doing the elicitation and modeling. For more,<br \/>view <a href=\"\/blog\/a-pms-guide-to-requirements-modeling-part-2\/\" target=\"_blank\" rel=\"noopener\">part 2 of the modeling series<\/a>.<\/li>\n<li>There are different categories of requirements, including data and process. Use cases describe a third category\u2014interaction. When we use any kind of user interface, such as a mobile phone app or enter any information into any screen or web page, we are interacting with the \u201csystem.\u201d Use cases describe this interaction between us (actors) and the system. For more, view <a href=\"\/blog\/a-pms-guide-to-use-cases-part-1\/\" target=\"_blank\" rel=\"noopener\">part 1 of the use case\u00a0series<\/a>.<\/li>\n<li>In other words, a use case describes the conversation back and forth between actors and a system. The system contains all the work we want to do on the project, and a use case diagram is useful in helping us determine this scope of work as it relates to the final product. Actors always interact directly with the system, but are always outside the system. They can initiate a use case, provide input to it, and\/or receive outputs from it. Actors can be people, other systems, time triggers, or event triggers.\u00a0For more, view <a href=\"\/blog\/a-pms-guide-to-use-cases-part-1\/\" target=\"_blank\" rel=\"noopener\">part 1 of the use case\u00a0series<\/a>.<\/li>\n<li>Use cases help our projects in two very different ways. Use case diagrams are immeasurably helpful in understanding scope and the use case narrative is invaluable for getting the detail needed to build the product or service. Although used primarily in software development, use cases are also helpful when creating processes and developing equipment. They work wherever there is interaction between people and what those people need to do. For more, view <a href=\"\/blog\/a-pms-guide-to-use-cases-part-1\/\" target=\"_blank\" rel=\"noopener\">part 1 of the use case\u00a0series<\/a>.<\/li>\n<li>Use case models contain the use case diagram that we <a href=\"\/blog\/a-pms-guide-to-use-cases-part-2\/\" target=\"_blank\" rel=\"noopener\">described in the last article<\/a> and a textual description of each use case shown on the diagram. We have described the diagram in great detail in the last two articles. Here, we will describe the purpose of the use case narrative, the five questions these narratives help answer, and how invaluable this information is to both the business stakeholders and development team.<\/li>\n<\/ul>\n<h2>USE CASE NARRATIVES<\/h2>\n<p>The use case diagram shows the use cases, which are the features contained in the system. Each use case is shown as an oval and named as a-process with a verb to describe the action, such as Request Item or Ship Item. Use case narratives describe the process steps inside each use case. The narratives are needed because while it is great to see the features at a glance, no one really understands what these process names mean until we describe the detailed steps. If we told a developer to build a feature and all we gave them was the name \u201cRequest Item,\u201d they would have to ask tons of questions and\/or make lots of assumptions about how people would interact with the system when they wanted to request items from a website. We have found that those developers who actually read them love these narratives because they save so much time.<\/p>\n<p>Below is an example of a use case narrative that describes the process steps involved in reserving an item in inventory in an Order system. To create the narrative we include the following:<\/p>\n<ul>\n<li>A <strong>number and name<\/strong> that identify the use case. These are often assigned according to the organization\u2019s standards, templates, and\/or requirements processes.<\/li>\n<li>The <strong>pre-and post-conditions<\/strong> describe the scope of each use case. Since each use case begins and ends, we need to tell it where to begin and when to end.<\/li>\n<li>A matrix with <strong>what the actor does<\/strong> and how the system responds to each actor request.<\/li>\n<li><strong>Primary, alternate, and exception flows<\/strong>, which we explain below.<\/li>\n<\/ul>\n<p>Below is an example of a use case narrative. The numbers on the use case narrative correspond to five important questions that use case narratives answer and which are listed below the narrative example.<\/p>\n<p style=\"text-align: center;\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-medium wp-image-7816\" src=\"\/blog\/wp-content\/uploads\/2016\/03\/Example-of-a-Use-Case-Narrative-510x264.png\" alt=\"Example of a Use Case Narrative\" width=\"510\" height=\"264\" srcset=\"https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2016\/03\/Example-of-a-Use-Case-Narrative-510x264.png 510w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2016\/03\/Example-of-a-Use-Case-Narrative-768x398.png 768w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2016\/03\/Example-of-a-Use-Case-Narrative-1024x530.png 1024w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2016\/03\/Example-of-a-Use-Case-Narrative-500x259.png 500w\" sizes=\"auto, (max-width: 510px) 100vw, 510px\" \/><\/p>\n<ol>\n<li><strong>At what point is the use case ready to begin?<\/strong> That is, what has to occur before the use case process can begin? Our example is about what the system does to reserve an item in inventory after it has been requested by a customer. When does this use case begin? Is the customer already logged in? Can they reserve items without being identified as a customer? These are business rules that have to be answered by stakeholders. Is the system available? Which user interface (screen\/web page) are they on? The use case pre-condition answers this important question and if it is not known when the developers start working on it, they will struggle and lose time arguing about it.<\/li>\n<li><strong>When is the use case complete?<\/strong> \u00a0In other words, when is done \u201cdone?\u201d What do we mean by complete? That\u2019s another tricky question to answer. The use case narrative answers this question in the post-condition(s). The post-condition(s) together with the pre-condition set the boundaries of the use case. Again using our example, is the use case done when the item is shipped to the customer? When the item information is sent to the warehouse for packing and shipping? We don\u2019t know and we should not assume. If the use case is about reserving items in inventory, shipping the item to the customer is clearly out of scope for this use case, although in scope for a different use case, one relating to shipments.<\/li>\n<li><strong>What is the most common way of getting from the beginning of the use case to the end?<\/strong> That is, from the pre- to the post-condition. This is our primary path, sometimes known as the happy path. Let\u2019s have a quick peek at the happy path. We always start with the actor action and always end with the system response, or how the system responds to the actor request. The system response lists all the process steps in response to an actor action until another actor, if any, triggers another response from the system. These steps continue until the post-condition is reached.<\/li>\n<li><strong>What other ways can we get from the beginning to the end?<\/strong> These are our alternate paths. We\u2019ll reach our post-condition, but not in the most routine way. That is, we\u2019ll take a different route. Sometimes we return to the main path, sometimes not. In the above example, we return to the primary path.<\/li>\n<li><strong>What might prevent us from reaching our post-conditions?<\/strong> These are our exceptions. Exceptions take us off the path entirely and terminate the use case.<\/li>\n<\/ol>\n<p>To better explain this example, let\u2019s use the example of getting home from work\u2014in this case by car. Let\u2019s say that our pre-condition is that we have left our office building. Our post-condition is that our car is parked in our garage at home. Our routine way to get home is to drive on the interstate. Some days, however, the traffic is so bad that we take side roads. We still get to our post-condition, just in a different way. This path, then, is the alternate path. However, let\u2019s say that we try to start the car and the car won\u2019t start and has to be towed some place for repairs. That is an exception that prevents us from reaching the post-condition.<\/p>\n<h2>TEST SCENARIOS, ACCEPTANCE CRITERIA, AND \u201cGIVEN-WHEN-THEN\u201d<\/h2>\n<p>The three narrative flows are similar to test case scenarios. One of the advantages of taking the time to create use case narratives is that test scenarios will be pretty much complete as well. In addition, the post-condition(s) will help us determine the acceptance criteria. Finally, many Agile projects use a \u201cgiven-when-then\u201d format to help with testing. The use case narratives provide this information. The \u201cgiven\u201d is the pre-condition(s), the \u201cwhen\u201d are the actor actions, and the \u201cthen\u201d are system responses. Let\u2019s refer to our use case narrative example.<\/p>\n<p>Given that the system is available, the customer is logged on, and that the customer has navigated to the page to enter line items, when the customer enters the item number, then the system verifies the number with a digit check verification, and so forth.<\/p>\n<h2>SUMMARY<\/h2>\n<p>Use case narratives take time to create. However, it\u2019s not creating the model that takes the most time. It\u2019s the thought process about the interactions between actors and the system that take the most time. The time that it takes to think through these interaction steps is time that has to happen regardless of what format is used to document it. Use case narratives provide a structured way to get us through the thought process, helping us ask the necessary questions, and giving us complete interaction requirements, which are needed to build a solution that works for our stakeholders.<\/p>\n<p>\u00a0<\/p>\n\n\n<figure class=\"wp-block-image size-medium\"><a href=\"https:\/\/www.watermarklearning.com\/course\/business-process-modeling-27.php?utm_source=Watermark+Blog&amp;utm_medium=CTA&amp;utm_campaign=A+PM%27s+Guide+to+Use+Cases+Part+3+Use+Case+Narratives\"><img loading=\"lazy\" decoding=\"async\" width=\"510\" height=\"181\" src=\"https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2021\/10\/CTA-PM-Guide-to-Use-Cases-510x181.png\" alt=\"\" class=\"wp-image-10232\" srcset=\"https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2021\/10\/CTA-PM-Guide-to-Use-Cases-510x181.png 510w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2021\/10\/CTA-PM-Guide-to-Use-Cases-1024x363.png 1024w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2021\/10\/CTA-PM-Guide-to-Use-Cases-768x272.png 768w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2021\/10\/CTA-PM-Guide-to-Use-Cases-1536x544.png 1536w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2021\/10\/CTA-PM-Guide-to-Use-Cases-500x177.png 500w, https:\/\/www.watermarklearning.com\/blog\/wp-content\/uploads\/2021\/10\/CTA-PM-Guide-to-Use-Cases.png 1785w\" sizes=\"auto, (max-width: 510px) 100vw, 510px\" \/><\/a><\/figure>\n","protected":false},"excerpt":{"rendered":"<p>Originally published in PM\u00a0Times on December 8, 2015. As promised, this is the fifth article in our modeling series and the third on use cases. We\u2019ll start with a short summary of the main concepts covered previously. SUMMARY OF PREVIOUS ARTICLES Here are the highlights of the requirements modeling articles written to date: To get [&hellip;]<\/p>\n","protected":false},"author":4,"featured_media":10486,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"content-type":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[4,211,13,57,78,1],"tags":[],"coauthors":[141,138],"class_list":["post-7815","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile","category-project-management","category-requirements-analysis","category-use-cases","category-use-cases-agile","category-watermark-learning"],"_links":{"self":[{"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/posts\/7815","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/comments?post=7815"}],"version-history":[{"count":10,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/posts\/7815\/revisions"}],"predecessor-version":[{"id":10246,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/posts\/7815\/revisions\/10246"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/media\/10486"}],"wp:attachment":[{"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/media?parent=7815"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/categories?post=7815"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/tags?post=7815"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.watermarklearning.com\/blog\/wp-json\/wp\/v2\/coauthors?post=7815"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}