Pass First Time By Choosing an Endorsed IIBA Training Provider

This article describes the structure of a use case in some depth and introduces other important use case concepts. For detailed use case narrative (also known as use case description) guidelines you can refer to the modelling guidelines article. The article provides a use case narrative / use case description example including a use case example so that you get a better idea of the use case description requirements steps look like. Some readers may be interested in a recommended use case training course. Table of Contents Use Case Description In use cases - an introduction, it was explained how the use case, in essence, describes the interaction between an actor (or category of users) to achieve a goal of observable value. The use case description must provide more elements than a simple sequence of user to system interactions. The following elements constitute the bare essentials for a use case: Name and Unique Number The name is what appears on the accompanying use case diagram. The number or other unique reference is useful when it is being discussed. It is essential when considering requirement traceability. It can be used when cross referencing more technical design artefacts but will definitely be required when tracing through to test conditions and scripts to verify the delivery of the requirements. Brief Description This provides an informal, natural language description of the use case and the goal that is being satisfied. There should be no requirements or functionality in this section, all functionality should be in the main body. It can also be used in a use case catalogue which is simply a list of all the use cases and their attributes. Preconditions This describes what must be true at the outset of the use case. It can relate to conditions within the system or also conditions outside of the system under study. For example, when withdrawing money from an ATM from a specific bank, the customer must be an existing customer of the bank. Basic Flow Of Events (aka Happy Path or Basic path) This is the 'guts' of the use case and describes the sequence of user to system interactions and related system behaviour or rules. It is commonly referred to the primary scenario or happy path which indicates what happens where everything is straightforward with no complications. This is discussed later in this article along with alternate flows. Alternative Flows These describe variations when things don't follow the 'happy path'. This may be because it is a valid variation or it may be an exception where an error occurs which prevents the actor from achieving their goal. Postconditions These are things that are true at the conclusion of a use case. Traditionally, these identify things that are always true regardless of what path is taken through the use case description. If the use case has many alternate flows, there may be a whole series of possible outcomes with different post conditions that have little cross over. In some cases, it is useful to identify post conditions for the basic flow and each of the alternate flows.https://youtu.be/RHdGn7WMWos Other Elements There are many other possible elements that can be used within a use case description. It is crucial that whenever a IT project decides to start using use cases that the template to be used is agreed and the value of each element is understood and recognised before modelling is started. There is no value in blindly following an approach hoping that it is 'right' as time can be wasted on populating attributes of the template that are not fully understood. There is also some degree of personal preference for which items should be included. Two items that have not been discussed but may be required in a use case are business rules and non-functional requirements that are specific to the use case under consideration. Additional detail regarding a complex business rule can be in a separate section. Non-functional requirements such as response time can be included in the use case. Separate sections may improve readability. These are some of the elements that I dislike and the reasons why (I would be interested in hearing other views): https://youtu.be/rThKZtYFXbAAdditional Notes or Notes or Special Requirements This is very dangerous as it can conceal requirements. Firstly, the basic and alternative flows are the right places for any requirements relating to functionality. Secondly, if there are any requirements in this section, they may be ignored by the designers of the system. Actors Primary, Secondary or Others The right place for actors is on one or more use case diagrams. If they are also in the use case narrative, they will appear in two distinct places which must be kept synchronised. If the use case diagram gets out of sync with the use case narrative, it is necessary to determine whether the use case narrative or the use case diagram accurately reflects which actors invoke this use case. There are other elements which can be useful during certain phases but become irrelevant. This would include, for example, To Do and Issues which would be relevant before the use case has been agreed by the stakeholders. Use Case Description Examples - Basic Flow and Alternative Flow An use case narratives example / use case description example is shown below with the basic and alternate flow: The basic flow describes one particular scenario or sequence of events. There will be a number of variations on this which make up the alternate flows. The basic flow is often the most common path or the typical case and the stakeholders should agree this. Agreeing the basic flow allows the stakeholders to focus on the most obvious and then move to the variations or alternate flows after the basic flow has been established. It is quite normal for an early draft of a use case model to consist entirely of basic flows with no alternate flows detailed or described. This is helpful when trying to map out the overall scope of the system without getting distracted by the details. It allows the stakeholders to see the overall system functionality before prioritising and planning the areas to be the subject of more detailed work. More on requirements gathering techniques that can be used alongside use case modelling can be found in - requirements gathering alongside use cases. Useful Links for Use Case Templates Here are some use case narrative templates on the web: Use Case Template from Bridging the Gap Use Case Template Provided by TechnoSolutions (Tool Vendor) Recommended Use Case Books The following books (available on amazon) are recommended on use cases: Use Case Training If you wish to learn further with use cases - you can browse our recommended use case training courses. If you wish to get a free use case narrative template recommended business analysis templates then please browse our list of . Thank you for reading this article, please make comments if you have questions, disagree or wish to discuss further.