Sticky Bits » Blog Archive » The Baker’s Dozen of Use Cases. Use cases have become a core part of the requirements analyst’s arsenal. Used well they can bring dramatic increases in customer satisfaction and a whole host of other subtle benefits to software development. The use case itself is very simple in concept: describe the functionality of the system in terms of interactions between the system and its external interactors. The focus of the use case is system usage, from an external perspective.
Despite this apparent simplicity, requirements analysts frequently struggle to write coherent, consistent use cases that can be used to facilitate development. Often, the use case analysis becomes an exercise in confusion, incomprehension and the dreaded ‘analysis paralysis’. This article aims to aid use case writers by presenting a set of rules to follow when performing use case analysis. A brief introduction to use cases The Baker’s Dozen ‘rules’: Rule 1: Use cases aren’t silver bullets Rule 2: Understand your stakeholders Rule 3: Never mix your actors. Agile Development of Use Cases.
We proposed a strategy for developing use cases as part of an agile development methodology last week. In this article, we will look in more detail at that proposal, and also look at a specific way to apply agile techniques to the development of the use cases. What we propose is essentially incremental development of use cases, and starting what comes next as soon as you can. Why Bother to Write Use Cases? There are four main reasons to write use cases: Discover requirements that would otherwise go undiscovered.Capture the correct requirements.Communicate the requirements effectively.Prioritize the requirements.
We discussed these goals of writing use cases last summer. Why Bother With Agile Development? There are significant benefits to using an incremental delivery process. Incremental delivery has two primary benefits over waterfall processes: An Agile Approach to Use Cases Any agile development approach to anything better be aligned with the agile manifesto. Getting To Working Software. OO design process: Use cases, an introduction. This article continues my series on the OO-design process. The first four parts are: This month I move on to analyzing the dynamic (runtime) behavior of the program. I'll do that by introducing the notion of a use case and talking about how one of these beasts is organized. Next month, I'll put this organization into the framework of the Bank of Allen.
Introducing use cases The "problem statement" looks pretty good at this point. I've probably forgotten something critical, but there's no point in sitting around hoping that these missing pieces will spring from my head, fully armed, like Athena from the head of Zeus. The dynamic definition of the problem focuses, not on what has to be done, but on how you do it. First of all, a definition: A use case is a single task, performed by the end user of a system, that has some useful outcome. You can think of a use case in terms of user intent. Back to top Presenting a use case We designers have several major goals in creating use cases: Table 1. Informal Use Case Template. Free Microsoft Word 2003 template for creating informal use cases. This template is built as a form with guiding text and help text.
Read how to use it and download it today. Informal Use Cases As part of our series on use cases, we included an article on informal use cases. Informal use cases are designed to provide as much information as possible without the overhead formal use cases. An informal use case includes a minimal set of header information for administrative purposes, and immediately gets to the meat of the use case – describing what the user (also known as the actor) does.
Informal Use Case Template This free template (MS Word 2003 – 34K) can be downloaded from Tyner Blain right now. Above is a screen shot of the template as you see it when you first open it in MS Word. If you want to modify the template to add header and footer information, for example, you have to open it differently. Using the Informal Use Case Template Informal Use Case Fields Summary Thanks in advance! UC_Vorlage_V01. UCD03_record_code_def. D82. Use Case Series: Formal Use Case. This is the classic use case as described by someone who talks about Software Engineering. All of the training classes (other than Agile classes) that I’ve been to teach formal use case development as a component in a system of requirements management. Here’s an introductory article on how to read a formal use case. Pros: Detailed information about use cases, making it easy to estimate the cost of implementation.Thorough coverage of the use cases is influenced by the use of a template.Easy for readers to absorb.
Cons: Expensive to maintain. The formal, or classic use case, is a tool used to gather structured information about how users will use the software. Some common elements in a use case template: Actor – The person or people who will perform the steps of this use case.Preconditions – A description of the relevant and non-trivial state(s) of the system prior to the use case starting.Normal course – A description of the use case itself. Quick links to posts in this series. Robustheitsanalyse. Die Robustheitsanalyse ist ein Verfahren in der Softwaretechnik, mit dem man Use Cases auf verschiedene Aspekte untersuchen kann. Dabei wird der vorhandene Use Case Text analysiert und in seine Bestandteile zerlegt. Als Ergebnis der Analyse wird ein Robustheitsdiagramm erstellt, welches im Grunde einem vereinfachten Kollaborationsdiagramm entspricht. Durch die Anwendung der Analyse wird in erster Linie ein Sanity Check des Use Cases durchgeführt. Es wird geprüft, ob der Text in sich schlüssig ist oder irrationale Abläufe möglich sind.
Die Robustheitsanalyse schließt die Lücke zwischen der reinen Analyse (Use Case – Was soll geschehen?) Bestandteile[Bearbeiten] Die Robustheitsdiagramme bestehen aus 3 unterschiedlichen Objekten und dem Akteur. Boundary object[Bearbeiten] Entity object[Bearbeiten] Repräsentieren Objekte aus dem DomänenmodellOft entsprechen sie DatenbankeinträgenDie Information die von dem Objekt gehalten wird, überlebt den Use CaseSind Substantive im Use Case Text. Anwendungsfall. Ein Anwendungsfall (engl. use case) bündelt alle möglichen Szenarien, die eintreten können, wenn ein Akteur versucht, mit Hilfe des betrachteten Systems ein bestimmtes fachliches Ziel (engl. business goal) zu erreichen.
Er beschreibt, was inhaltlich beim Versuch der Zielerreichung passieren kann und abstrahiert von konkreten technischen Lösungen. Das Ergebnis des Anwendungsfalls kann ein Erfolg oder Fehlschlag/Abbruch sein. Allgemeines[Bearbeiten] Anwendungsfälle werden klassischerweise so benannt, wie die Ziele aus Sicht der Akteure heißen: Mitglied anmelden, Geld abheben, Auto zurückgeben. Die Granularität von Anwendungsfällen kann sich stark unterscheiden: Auf sehr hohem Niveau beschreibt ein Anwendungsfall lediglich sehr grob und abstrakt, was passiert. Die Technik des Anwendungsfall-Schreibens kann jedoch bis auf Ebene von IT-Prozessen verfeinert werden, sodass das Verhalten einer Anwendung detailliert beschrieben wird.
Aufbau eines Anwendungsfalls[Bearbeiten] Name und Identifier. Introduction to Robustness Diagrams. A robustness diagram is basically a simplified UML communication/collaboration diagram which uses the graphical symbols depicted in Figure 1. As you can see robustness diagrams depict several types of concepts: Actors. This is the same concept as actors on a UML use case diagram. Boundary elements. These represent software elements such as screens, reports, HTML pages, or system interfaces that actors interact with. Figure 1. Figure 2 shows a whiteboard sketch of a robustness diagram representing the logic contained in the Enroll in University system use case. Add a boundary element for each major user interface element such as a screen or a report. Figure 2. By drawing a robustness diagram we quickly gain a sense for the work that we need to do to implement this use case because it helps to visualize the potential elements we'll have to build.
How do you keep robustness diagrams agile? Active stakeholder participation. What is next after robustness diagrams? Source Translations Japanese.