Here's the third part of The Use Case Chronicles, where after discussing and , I'll give some guidance and tips on how to find them. what use cases are how they're structured Use cases might be like a giant wave crashing over you. When working with use cases, you will eventually ask yourself two main questions: how long can this go on for, and how can I describe ALL of it? In this article, you will find tips and templates to help you deal with this wide range of use cases. Expanding the use case You don't always have to describe a use case with all its details. In the book "Writing Effective Use Cases," Alistair Cockburn considers two templates: the casual use case and the fully dressed use case. Those are different levels of expansion of use cases, from simple to detailed ones: A top-level description – it’s likely to be less accurate and missing some details; mostly it identifies just basic elements (name, actor, association). simple A and rigorous description – it uses one of the accepted full templates and identifies all elements of the use case (actors, scope, trigger, precondition, etc..). full Actually, these are two sides, and you can use various intermediary levels. Note that you don’t need to describe all use cases with the same level of expansion. 💡 Tip The fully dressed template is useful when: throughout the project the development team and user representatives are not closely involved; the system is complex, and potential system failures pose significant risks; the use cases present a new set of requirements that the developers are not familiar with; the use cases are the most comprehensive set of specifications that will be provided to the developers; QAs will create thorough test cases that align with the use cases. Creating levels of detail You don't have to describe use cases all at once. Instead, use different levels of detail to avoid drowning in use cases. 💡 Tip Identifying use cases in a top-down direction is more convenient – from the top-level description to the details. Big picture + certain parts For example, you can give a big picture and then describe certain parts of the system. Levels in certain elements One more point is that you can use different levels of detail when describing certain elements of the use case. For example, you can list alternative flows in the use case description and elaborate on them in another document. Levels in the same scope Another way is to describe the same scope of use cases but show more and more details. For example, let's take a look at the simple example from for a mobile application for food ordering. The Use Case Chronicles – Part 2: Unveiling Use Case Structure Here, I use a diagram to describe the top level without any use case details. Drawing helps to see all the connections between cases and the big picture. Then, I describe some use cases and include more details such as Preconditions, Trigger, Goal, and so on.  Some elements can be described as more casual, and some as more dressed up. 💡 Tip Don't spend much time trying to fit every detailed requirement into use cases, especially if you are not going to implement them for months or years. Requirements may change or disappear before development begins. 💡 Tip Large amounts of data are hard to take in. If your text or diagram becomes too lengthy and requires endless scrolling, break it down into several levels of detail. Otherwise, you'll only confuse your readers. Identifying use cases Identifying use cases can also be tough, sometimes I don't know what to hit on, and this is where the following strategy helps me. Actually, there are several methods for identifying use cases; they basically consist of the same questions but in a different order. The following is the order I have seen most often from different authors and found it to be the most convenient. 1. Identify the System You can describe either a system or a part of it. 2. Identify the Actors They can be determined by asking the following questions: Who uses the system? Who installs the system? Who runs the system? Who maintains the system? Who shuts down the system? What other systems use the system? Who receives information from the system? Who provides the information to the system? Is anything happening automatically in the system? It is not necessary to use all actors in every aspect of the system description, but it is useful to consider all actors and ask all questions so that important actors are not lost. 3. What do actors want to get? Then, examine the visible and observable value each actor wants to get to identify potential use cases. Key questions to help with this process include: What system functions does the actor require? What information does the system store? Who will create, read, update, or delete this information? Should the system notify actors of changes in the internal state? Are there external events that the system needs to be aware of? Who will inform the system of these events? 4. What are the associations and relationships? When you have actors and use cases, you need to arrange and link them. Pay attention to the following points here: It is more convenient to structure the description from the actors' point of view, i.e. first place the actors and build their relationships, and then look at their associations with use cases. If there are too many use cases, you can: simplify them by reducing the number of use cases and their descriptions divide them into levels of detail Use case diagrams are based on functionality and should focus on the "what" rather than the "how." 5. General check When you have described all the use cases, go through and read them all. Note the following points: Don't put in requirements that don't fit the purpose and format of the use cases; there's no need to try to cram everything in or adapt requirements that don't really fit the format. Check all intersections and junctions: ensure that there are no conflicting use cases ensure that multiple levels of detail are consistent both horizontally and vertically. For each use case, there is a clear understanding of the goal for which the actor triggers the case and how the case ends for the actor. The cases are described briefly and in a clear manner to ensure maximum comprehension. Useful case = understandable case. Formulate cases in a way that they are easy to understand and avoid complex grammatical constructions. 💡 Tip Don't try to include every new requirement with use cases. You can use different levels of detail and extensions to existing templates to include new details. But you cannot describe all functional requirements in scenarios and may end up in an endless circle of revisions. 💡 Tip We all make mistakes sometimes, so it's always a good idea to ask for feedback from developers, users (if possible), and other interested stakeholders. Don't feel like you have to wait until you've completed your entire specification to ask for review feedback, as every review can help improve your subsequent requirements work. Conclusion This concludes the third part of the Use Case Chronicles. These guidelines and tips help me in my work with use cases. Feel free to share your tips in the comments below! Check out other parts of the Use Case Chronicles: and . Part 1: Who, What, and How to Use Cases Part 2: Unveiling Use Case Structure

This story contains new, firsthand information uncovered by the writer.

The Use Case Chronicles – Part 3: Insights and Tips for Writers

Too Long; Didn't Read

@nastyakostina

Credibility

RELATED STORIES