00:13hello I'm Tom Hathaway I'm wearing my VA
00:17hat so let's talk business analysis in
00:20this knowledge nugget I want to
00:22introduce the concept of use cases as a
00:25tool for defining user interaction
00:27requirements since this is an
00:29interactive knowledge nugget I will also
00:32give you an opportunity to try your hand
00:34at creating a version of a very simple
00:37use case these techniques will help you
00:40when you are the one wearing the BA hat
00:45defining a proposed information
00:47technology or IT application can be a
00:50daunting challenge whether you're tasked
00:53with defining a brand new application or
00:55making changes to an existing one an
00:58immense number of decisions await you
01:01one of the very early and critical
01:03decisions you have to make is how you
01:06will represent the requirements that the
01:08solution must fulfill ensuring that both
01:11the business community and the
01:14developers share a common understanding
01:16of the requirements is notoriously
01:19difficult any standard method for
01:22structuring the communication between
01:23these two parties drastically reduces
01:26the probability of miscommunication with
01:29all of the related costs and misery
01:33the use case paradigm is one specific
01:36method that you should have in your
01:38repertoire of tools for representing how
01:41the proposed application should interact
01:43with the external world use cases were
01:47introduced as a method for defining
01:48requirements for IT solutions in the
01:51late 1980s by Ivar yaqoob son and they
01:54spread like wildfire like all great
01:58techniques practitioners have modified
02:00augmented adapted and otherwise refined
02:04the basic concept over the years and
02:06most of the add-ons are valuable in the
02:09proper context regardless of the context
02:13one of the common pillars of all use
02:15cases is that they define the
02:17interaction between two or more entities
02:20called actors in use case parlance this
02:25correctly implies that the use case
02:27paradigm is not well-suited for defining
02:30systems lacking interaction ie patch
02:36to address the communication issue a use
02:39case is often presented in plain text
02:41and as a diagram the use case
02:45description represents the interaction
02:47between involved actors textually had an
02:50appropriate level of detail the use case
02:53diagram is a visual representation of
02:56one or more use cases depicting the
02:58actors stick figure symbol with the name
03:01actor below it and their connections a
03:03simple solid line to the use case an
03:07oval with the name of the use case
03:10inside it due to the intentional
03:13simplicity of the use case diagram it is
03:16considered optional in many
03:18organizations it does however provide a
03:21great tool for representing the context
03:24of the use case in relatively intuitive
03:26symbols the diagram is particularly
03:30useful if the use case involves a lot of
03:32different actors which is often the case
03:35in embedded and real-time applications
03:38here's a very simple little exercise to
03:40demonstrate the use case concept you
03:44need access to a cell phone to complete
03:47assume you just got off the airplane
03:49meaning that your cell phone was off and
03:51you missed a call from a friend that you
04:07note this interaction was created using
04:10a samsung s4 cell phone the phone is
04:14powered off s0 5 i press the power
04:18button and hold for 4 seconds as 10 the
04:22phone displays my home menu and plays a
04:24sound s 15 i press the phone symbol on
04:29the menu as 20 the phone displays the
04:35s25 I press the recent tab as 30 the
04:41phone displays recent calls f-35 I tap
04:45the actions bar s40 the phone displays
04:49the options as 45 I tap the view option
04:53as 50 the phone displays all view
04:57options as 55 I select the missed call
05:02option s60 the phone displays all missed
05:06calls s65 I click on the missed call
05:10from Dan as 70 the phone displays Dan's
05:13contact info I am ready to click the
05:17green phone to place the call
05:22assuming you actually did the exercise
05:24your solution can look very different
05:26from ours and still be correct your
05:29solution depends on the specific phone
05:31you have and how you set it up it also
05:34depends on how you perceived your
05:37interactions we have seen solutions with
05:40as few as four steps and as many as 21
05:44all of which were correct
05:49the key characteristics of a correct
05:51answer are the following a you
05:55documented a precondition eg the phone
05:58is powered off B you documented the
06:02interaction step by step in the form of
06:05a dialogue you are having with the phone
06:07I did this the phone reacted like this
06:11see you documented the post condition AG
06:16I am ready to click the green phone to
06:18place the call all that is left for you
06:22is to give this a name return missed
06:24call and you have the basic framework
06:27for a use case congratulations
06:32okay let me correct a couple of
06:34oversimplifications what you really
06:37created is technically a use case
06:39scenario meaning a specific interaction
06:43with a specific device to achieve a
06:46desired outcome given a specific initial
06:51scenarios are instances of a single use
06:54case I could give this scenario and my
06:58cell phone to a friend and ask her to
07:00return the call assuming they followed
07:03the steps faithfully they would probably
07:05achieve the same outcome however there
07:10could be situations in which they were
07:11unable to achieve it
07:13for instance what would happen if they
07:16pushed the power button on my phone and
07:18the battery was empty they wouldn't even
07:21get to step 2 let alone complete the
07:23entire scenario to ensure that this
07:26situation is covered I could add a
07:29second precondition the phone has
07:31sufficient power adding that condition
07:35would not change the scenario I
07:36described it simply clarifies it by
07:39documenting a precondition that I didn't
07:41think about because it didn't happen
07:43when I executed the scenario
07:47now assume that I do not want to limit
07:49my ability to return the missed call to
07:52situations where my phone has power
07:55instead of adding the precondition I
07:57could define what action I would take if
08:01the battery was empty that implies I'm
08:04going to define an alternate set of
08:07actions I only do under specific
08:09circumstances I do have a problem
08:12however there's a fundamental philosophy
08:15of the use case paradigm there are no
08:18ifs in a use case okay if I'm not
08:23allowed to use an if how do I introduce
08:25the concept of alternate actions
08:30to answer that I need to introduce
08:32another use case term the path the steps
08:36you documented represent a specific path
08:39through the use case they were the exact
08:42actions and reactions that you
08:43experienced in executing the assignment
08:46if you had to create a different use
08:48case every time something was different
08:50eg no power you'd end up with a
08:53thundering heard of use cases and a lot
08:56of the steps would be identical meaning
08:59to avoid redundancy the use case
09:02paradigm differentiates between a
09:06aka basic course of events VCO II or
09:10happy path which we do not recommend as
09:13it implies an emotional component and
09:17alternate paths ie the path less taken
09:21the standard path represents the
09:24interactions under normal circumstances
09:26meaning nothing ever goes wrong which
09:29was by the way the rationale for calling
09:31this the happy path generally speaking
09:35there will only be one standard path in
09:37a use case it can have any number of
09:40alternate paths one for each time you
09:42want to document how to deal with a
09:45what do you represent this in the
09:47scenario we just created there are
09:50several possible solutions and we
09:53recommend using the at convention if I
09:56add an alternate path for dealing with
09:58the dead battery situation my solution
10:01would look like this
10:06precondition the phone is powered off
10:09standard path s 0 5 I press the power
10:13button and hold for 4 seconds s 10 the
10:16phone displays my home menu and plays a
10:18sound as 15 I pressed the phone symbol
10:22on the menu and so on until s 70 the
10:26phone displays the caller's contact info
10:28the post condition I am ready to click
10:32the green phone to place the call
10:35alternate paths a 0 1 @ s 0 5 the phone
10:43does not turn on a zero 1.05 I locate an
10:49electrical outlet a 0 1 10 I plug the
10:53phone into the outlet a 0 1.15 the phone
10:58displays the charging symbol a 0 1 20
11:03resume at s 0 5 you may note that this
11:08alternate path ends with a resume
11:10statement this convention allows me to
11:13return to the standard path s 0 X at a
11:16specific step to attempt again to
11:19achieve the ultimate goal of the use
11:21case namely return the missed call
11:24assuming that I am able to place a call
11:26while my phone is charging a situation
11:29I've not personally tested everything
11:31should then follow the standard path
11:36if you'd like to try your hand at adding
11:38alternate paths to your scenario here
11:41are a couple of ideas to get you started
11:43you don't have to limit yourself to
11:45these scenarios consider Murphy's Law
11:47whatever can go wrong will
11:50we encourage creative thinking
11:53a zero - at s40 the phone displays
11:57delete call a zero for at s60 the phone
12:02displays only received calls
12:05a zero five at s70 the phone displays
12:13this brings us to the end of this brief
12:15introduction to use cases obviously
12:18there's much more to learn about using
12:20this phenomenally simple but powerful
12:22tool to define requirements for IT
12:24solutions but that will have to wait for
12:27future knowledge nuggets meanwhile I
12:30hope you can make good use of the
12:32information provided in this knowledge
12:34nugget when you are the one wearing the
