are you looking for the clearest way to document behavioral
requirements if so check out this tutorial on use case descriptions
hey doc squad dr white here with the business analysis doctor today i'm giving a tutorial on
use case descriptions but before we get started if you want more business analysis training and tips
be sure to subscribe to the page and click the notification bell with that said let's get started
all right so use cases generally come in two forms a use case diagram and use case descriptions
the use case diagram is useful for representing the simple interaction of how an actor interacts
with the system however when we need the details of how this interaction works
the use case description is often required to supplement the diagram
so here's what you'll learn today we'll look at
what a use case description is the main components of a use case description an
example of a use case description and then we'll look at some use case description best practices
so what is a use case a use case is a functionality in a system that will
allow a user to achieve a goal a use case description is a narrative that describes
the relationships between actors and a solution and the details of how the interaction works
one thing to know is that a use case description is also called use case specification
now let's look at the main components of a use case description this includes the name actors
preconditions triggers post conditions flow of events and scenarios
the name is a unique name that represents the goal of the use case it generally includes a verb which
is an action taken by an actor and a noun which is what is being acted upon for example assigned task
an alternate name for a use case is the requirement id this is the unique id and
statement of the requirement from which the use case is derived from
all use cases should be traced back to a solution requirement
now the actor is any person or external system that uses or interacts with the solution to
achieve the goal each actor is given a role to represent their interaction with the solution
the names of human actors should be in the form of a role and should not specify an actual name
actors generally fall within the category of primary or secondary
now the primary actor is an actor that can initiate a use case the secondary actor
is an actor that reacts or responds to system responses or actions made by the primary actor
preconditions are conditions that are assumed to be in place before the use case can begin this may
act as a constraint to the completion of the use case a trigger is an event that initiates the flow
of events in a use case sometimes the trigger can also be the first step in the use case but it's
not always the case sometimes the trigger doesn't even have to occur for the use case to begin
triggers can either be actor actions or a temporal event after actions are when an action is taken by
the priority actor as an input that initiates the use case this is the most common type of
trigger a temporal event is a time related event that may trigger a use case it's commonly used
when actions need to be executed during a specific time of day or on a specific date
post conditions are the conditions in the form of guarantees that must be in place when the use case
is complete for all possible flows including the main success path the alternate path as well as
the exception path guarantees may be referred to as success guarantees or minimum guarantees the
success guarantees are the conditions that must be in place when the main success path
or alternate path is successfully executed the minimal guarantee are the conditions that must
be in place even when the exception path is taken and the actor's goal is not achieved
this may address non-functional requirements such as security
the next component is the flow of events or flows this is the set of steps that must be
taken by the actor and the solution while the use case is being performed
generally use cases consist of a main success path alternate paths and exception paths
now the main success path which is highlighted here this occurs when the inputs from the actors
and the system responses represent the most common successful path to accomplish the actor's goal
also when discussing use cases the terms flow and path are interchangeable
the next flow of events is the alternate path here the inputs from the actors
and the system responses represent a less common path to accomplish the actor's goal
now here even though the alternate path deviates from the main success
path it should re-enter the main path at some point in order to achieve the actor's goal
and the last flow of event is called the exception path here the inputs from the actors and the
system responses represent an unsuccessful path when the actor's goal is unachievable
the exception path does not re-enter the main path and should always end with use case ends
a scenario describes one way an actor can accomplish a specific goal
this is a single path written in a series of steps performed by an actor or the solution the use case
is composed of a collection of scenarios the main success path alternate path and exception path
are all types of scenarios that may be included in a use case now the difference between a flow
and a scenario is that scenarios describes the main success path alternate paths and exception
paths from start to finish flows on the other hand always start with the main success path
then extracts the alternates or exceptions in order to document a subset of steps that
delineate from the main success path and this is done to reduce redundancy in documentation
now let's look at an example of a use case description in my last video we discussed
the use case diagram for more on that you can click on the link in the description
but for now let's talk about transitioning from a use case diagram to a use case description
here is a use case diagram for a banking system
for this demonstration we'll focus on narrating the complete online transaction use case this
will also include the two sub-use cases in which it has a generalization relationship with
now while complete online transaction will be the name of the use case description
the sub use cases will serve as the main flow and the alternate flow
then we'll use our primary actor from the diagram as our actor for the specification document
also in this particular case the included login use case will translate into the
precondition for this specification now this isn't always the case but in this situation
it fits so our use case template looks like this when it's filled out but for illustrative purposes
i'll be extracting different components so that i can better explain the concepts
all right so let's start with the basics again our use case name is complete online transaction
now the requirement id could also be associated with the name in most cases the use case should
be derived from a solution requirement mainly functional requirements the actor is the customer
we see that our precondition is that the customer must be logged into the system
our trigger is that a payment is due and this is an example of a temporal event which is a time
driven event and so our post condition is that the payment is logged in the transaction history
now let's move on to the main success path which again is the primary flow the basic flow but it's
really the most common path or flow to achieve the use case goal now in the description box here
you want to provide a general description of the use case including the goal to be
achieved and when it ends notice the flow here in this template is separated by actor actions
and system responses not all approaches do this but i think it has clarity a common metaphor for
the interaction here is a tennis match or a ping pong table because of the back and forth nature of
the actions and the responses one thing to keep in mind here is that you need to keep
the numbering of the steps in the sequence for which they occur regardless of the column it's in
this becomes essential when you're dealing with alternate and exception flows now remember the use
case should always end with a step that makes it clear that the use case is complete so as you can
see here you start with the actor action here you go on to the system response actor action
system response now it's not always a one-to-one relationship here sometimes an actor action can
prompt two system responses in a row so that situation would kind of look like this and then
you would continue on back to the actor actions and then the system responses and again you would
end with some type of step to let you know that the use case is complete so you know a lot of
the times when you're making some type of payment you would see some type of confirmation page here
now let's look at the alternate path aka the alternate flow
you can have as many alternate flows as necessary which is why the alternate
flow should have a alternate flow id or unique id in this case it's called a1-3a
this indicates that it's the first alternate flow in the use case while the 3a indicates that
the flow alternates from the main flow at step 3. in the alternate flow description here you
want to describe how the step in the alternate flow is different from that of the main flow
now as you can see here we continue on with the sequence of steps that the alternate flow takes
using the same format as the main flow now remember that the alternate flow is
just an excerpt of steps from the use case that deviates from the main flow
so you'll start here where the alternate path begins and go throughout your sequence here
the alternate flow always ends by continuing back into the primary flow to continue the use case so
while the documentation only includes the steps on the alternate path experientially you would
start with the first step continue on to step two then go to steps three through nine and then
continue back here to step 8 and then finish out the use case to complete the actor's goal
now let's look at the exception flow the exception flow here is when the customer has insufficient
funds much like the alternate flow you can have as many exceptions to the use case as needed
so you would also want to provide a unique name for the exception it's also helpful to indicate
the step where the exception occurs so here we've got e1 dash 10a so this indicates that this is
the first exception and the exception happens at step 10 from the main flow
so to document the exception you simply begin with the step that creates the exception
and then you end with use case ends now this is a key delineation between the alternate flow and
the exception flow the alternate flow allows the use case to be completed by re-entering back into
the main flow while the exception flow does not and should always ends with use case ends
so when the customer experiences an exception the individual
would go through steps one through nine here and then the exception would occur
here at step 10 and then the additional steps would happen and then the use case would end
so to discuss the scenario section i'll be combining the steps of the main flow
and the alternate flow into one specific scenario to outline the user's interaction
remember that the main float is a scenario while the alternate
and exception flows are excerpts of a scenario that has some variances from the main flow
now let's look at scenarios so to create additional scenarios outside of the main path
you would integrate the alternate or exception flow steps to the main flow steps that are still
applicable when it occurs in this example i'll be swapping out the steps for the main flow and
filling them in with the steps from the alternate flow in order to form a specific scenario
so the scenario of a customer making a transfer can be documented as a full scenario on its own
versus being documented as an excerpt of a varying flow generally you would only
document scenarios that are important enough to be called out separately from the main flow
alternate flow or exception flow again you can have as many scenarios as required so each one
will have to have a unique id and a description to describe the key goal and when it's complete
so in this particular example instead of swapping out to the alternate flow this documents the first
initial step the system responses all the way down to the use case being completed
so as you can see the scenarios are much more comprehensive
than the alternate flows and the exception flows because these include the main success path steps
in addition to the alternate flow steps so you're documenting those scenarios from start to finish
all right now let's look at some use case description best practices
first use a consistent template or format using the same template across the organization helps
stakeholders get familiar with the structure of the use case also preconditions and post
conditions should be testable and verifiable these must be written in a way to clearly
determine if the condition has been satisfied next human actors should have defined roles
having a generalized role such as user can lead to ambiguity especially if there are multiple actors
without a specific role it's unclear which actors are performing which functions the only time
user is appropriate as a role is if the function applies to all users with no role-based variances
then each line in the use case should include a verb noun format
verbs convey action while the noun conveys the subject which is the thing that's being acted upon
the statements should also be an active voice this clarifies who is doing what
you also want to use the appropriate level of detail generally use cases can have about 10
to 15 steps also be sure to omit design details such as colors field locations button names etc
including too many details make the use case difficult to read and navigate through
also business rules should not be documented in use cases these should be managed separately in
the appropriate specification document again this superfluous information can make the
use case hard to read and finally decision path should not be captured in the main flow
any if then statements should not be included in the main flow that would be an indicator
that the varying step needs to be documented as an alternate flow or an exception flow
well that's what you need to know to outline a clearly articulated use case description
if you learned something new or like the video tell me about it in the comments
i'd love to hear your feedback also be sure to check out all the business analysis training
and certification resources at the ba.com that's t-h-e-b-a-d-l-c dot thank you so much
for watching i hope you have a productive and prosperous day until next time bye now