What's up geeks and welcome to the channel! If you think about it there are two ways to
describe what an application is meant to do you can focus on the features
or the requirements of your app where you say the system must do this
or the application must achieve that or you can focus on the users
of your application by answering how does a certain user accomplish a
particular goal with our application describing your application
in a user-focused manner and contrary to the feature-focused manner
allows you to write these requirements in everyday language as non-technical as possible
a typical user of this app should be able to read one of these descriptions and understand it.
Now there is no one required way to write these but there are two formats commonly used
in this phase of the design process one is called a use case and
the other is a user story. In this video we're going to talk about both
and in a later video we are going to expand on how we can design or draw these use cases.
So the most essential parts of a use case are the title that describes the goal we are looking for,
the person or actor who wants that goal satisfied, and the scenario or series of steps
needed to accomplish the goal. These steps describe a complete encounter
between the actor and our system hence can have multiple possible results and can
even include sections for when things go wrong. Now the best title for a use case is
a short phrase with an active verb examples here might be: "Add a new
member", "Send mail", "Purchase items in cart", "Create note" and so on...
These could all be separate use cases which define distinct goals of our application.
Then we have the actor, the reason that we say actor rather than just user
is because we often need to identify exactly who is having this interaction
it could be a generic user, but also a customer member or administrator,
and it even doesn't have to be a human, being it could be another computer system
or service interacting with our application. So any external entity that
acts on our system is an actor. Now comes the scenario or the details
that will help us achieve this one goal. This could be written as a single paragraph
like the one you see in front of you this paragraph should be short and easy to
understand by any typical user of the application it's also very common to write the scenario
as individual steps as a numbered list Now notice that in both examples we wrote
we described the normal expected flow or what we call the success scenario
again this is not pseudo code this is not something we take to our
code editor and start writing we are not there yet and we're not trying to be
Now depending on the situation you can add extensions to your success scenario
steps for alternative flows like what happens when items are out of stock
or for when things go wrong like payment problems and if it's more useful you can add
more specific details about the scenario one common example would be a precondition
what must be true to begin this use case here perhaps the precondition would be a customer
has added at least one item to the shopping cart that's the only way this use case makes sense.
Okay after writing the title, actor, scenario, and possibly a precondition for your use case
you should be fine and ready to go and 95% of the time you won't be required to write more than that
However you may sometimes encounter fully dressed use cases
and these go beyond the usual fields we just discussed to include
multiple placeholders for a trigger and description, preconditions,
post conditions, stakeholders, etc. and these often exist as PDF templates or
Word document templates that you can fill in. Now as I mentioned earlier
there are also use case diagrams but forget about the diagram for a
moment because use cases are first and foremost written texts and not diagrams
we will see the use case diagrams in a future video but as with all diagrams they are here to
support written use cases and not replace them. Let's go ahead now and expand
on actors and scenarios. An actor in a use case is
anything with behavior who lives outside of our system outside of our application
but has a goal they want to accomplish within and these are usually human beings but not always
sometimes coming up with the actor is very straightforward like if you are
building a simple one-person application and sometimes you might need to spend
a few minutes brainstorming the main actors of your app or a particular use case
what you can start by doing is separate human and non-human interactions between
your app and the outside world You see it's quite common that
use cases involve multiple actors and will typically refer to them as the primary
actors and the secondary or supporting actors Now the primary actors aren't necessarily
the most important actors in the scenario they're just the one who
initiated this particular use case so in the example we previously wrote
the primary actor was the customer anyone else is a secondary actor
now the initiated use case might go through a lot of steps and some of these steps might fail
and that leads us into talking more about sketching out these steps in the
scenario part of our use case when we describe a use case scenario we're
typically looking at describing a goal that an actor can accomplish in a single encounter
and we're trying to stay focused on the user's goal, on their intention
so for example login to the application might first sound like a use case
it has an active verb, it typically has multiple steps, multiple conditions, you could forget the
password or be required to register and so on... But if we emphasize on the user's goal we realize
that their goal with our system is not to login the reason they want to login is to do
something so what is that something in your system? Is it to purchase items,
to check their account balance, these are user-focused goals
each with several steps that could be accomplished in one encounter
logging in might be part of these use cases part of one of these goals
but it's not a use case on its own when writing a scenario you want to
focus on the true goal of the user emphasize on one of the encounters.
Now a simple casual use case can still have multiple scenarios
we've talked about the main success scenario that's the one you want to focus on
but when necessary you also need to describe the alternate path or extensions
so in the case of purchasing items you might have a couple of options for what
happens when something is out of stock what happens if the customer
payment method is rejected however here you're not trying to lay out all
the possible events just the typical situations that would occur and what would you
want to do with those situations when you're writing use active voice, emit
needless words, omit needless details, it's very common to see sentences
like "the system is provided with the payments information by the customer"
but you could just as easily say "customer provides payment information" active
voice, easier to read, short, concise. Notice also that we're describing
all this without the words like: page, click, button, select, mouse, none of that
there's no "click the checkout button" we're focusing on the intention
the user interface will follow, the function of our application and what we want to do
Now once you come up with your first actors and goals you should ask yourself a few more
questions to see if you've missed anything like do we have role-based actors and if so
who is the administrator of our system or who manages the users of our system
what happens if the system fails, is anyone monitoring our system's activity or storing logs?
You will often find that these questions will reveal a couple obvious
actors for your application. Finally before ending the video I
want to briefly mention user stories. A user story is simpler
and shorter than a use case it still describes a single small
scenario from a user's perspective focused on their goal rather than on the system
but unlike a use case which could be extended as we discussed to several pages
a user story is typically written as just one, perhaps two sentences,
this forces us to keep them very short and that's kind of the point here
user stories follow a particular format and the format looks something like this
"As a user or role, I want a particular goal so that I benefit from it in this particular way"
an example could be that "as a user I want to be able to sort the entries by date so
that I can find the most recent content" focused on one specific goal of one specific
user for a particular reason or benefit user stories focus on intent what
we're doing is expressing one need we're not detailing alternate path or
exceptions or listing any technical information they're very quick readable summary of what
a specific goal is and why the user wants it when you first hear about them it can be tempting
to regard a user story as just a shorter use case but that would be a mistake they
are really very different things A user story is a placeholder for a
conversation, it's a reminder that we need to get deeper into the details of something
whereas a use case can be regarded as a record of a conversation that already happened
it will detail the steps of how a particular goal may or may not be achieved
use cases are regarded as the more formal unified process methodology you'd use
but if you're working in a SCRUM environment which we will discuss in future videos
you should expect to see a focus on user stories anyway however you do it I assure you that
describing your system in simple language and easy to read terms is incredibly useful.
So, that's it for this video, I hope it was helpful thank you guys for watching take
care and I will see you in the next one!
