Operational Profile of Use Case Scenarios
| Let's begin with the operational profile for the scenarios that make up a single use case. Figure 3.1 shows a stylized use case with numbered blocks representing steps in the use case. This use case is made of six scenarios that represent different paths through the use case. Figure 3.1. Stylized use case with six scenarios. Numbered blocks are steps in use case.
The scenarios for the use case in Figure 3.1 can be described in terms of the steps that make each up; they are:
An operational profile of this use case will spell out the relative amount of traffic, so to speak, that we expect each of these scenarios to receive. Decision GraphsA common technique for producing an operational profile is a decision graph, and it works perfectly for building an operational profile of a use case's scenarios. A decision graph is a means for calculating the probability of an event; in this case, the probability that the user will use one scenario (i.e., path through the use case) over the next. Calculating Probabilities of ScenariosAs Figure 3.2 illustrates, our use case of Figure 3.1 is easily converted to a decision graph model. Figure 3.2. Decision graph of use case.
In a decision graph model of a use case, each path (or edge as they are called in graph theory) leaving each step in the use case is assigned a probability. It is the probability with which we expect that path to be used relative to alternate paths leaving the same step. The probability of all paths leaving a step must sum to 1. So for example, after a user has executed step 2 in Figure 3.2, we expect that 80% of the time the user will go to step 3 next and 20% of the time they will go to step 3a. After probabilities are assigned to each path, the probability of each scenario is calculated by taking the product of the probabilities of paths in that scenario. For example, the probability of scenario 1, 2, 3, 4 is
What this means is that we expect this scenario to receive 64% of user traffic through the use case. The probability of each scenario of Figure 3.2 is shown in Table 3.1 and displayed as a pie chart in Figure 3.3. A pie chart in particular helps drive home the point that traffic loads through a use case can vary dramatically between scenarios.
Figure 3.3. Probability of each scenario of Table 3.1 displayed as pie chart.
Implementing a Decision Graph as a Spreadsheet MatrixCalculating probabilities for each scenario can be a chore. One idea to address this is to replace or augment the decision graph with a matrix implemented as a spreadsheet. Figure 3.4 provides a matrix implementation of the decision graph of Figure 3.2. Figure 3.4. Spreadsheet matrix implementation of decision graph of Figure 3.2. Rows and columns are steps in the use case. Circled cell says that from use case step 2 (row), there is an 80% probability that the user will next go to step 3 (column). All values in a row must sum to 1.0.
In the matrix of Figure 3.4, rows and columns are labeled with the steps in the use case. Cells provide the probability of user traffic moving from step X (row) to step Y (column). For example, the circled cell in Figure 3.4 states that from use case step 2 there is an 80% probability that step 3 will be next. A matrix such as this, implemented as a spreadsheet, allows one to then quickly determine the probability of each scenario, as illustrated in Figure 3.5. Broekman and Notenboon (2003) use the matrix approach in lieu of the pictorial decision graph. Which you use is a matter of taste. Figure 3.5. Arrows indicate probabilities used to calculate scenario made of steps 1, 2, 3a, and 4. The probability is 1x0.2x0.64 = 0.13. Figure 3.2, Table 3.1, and Figure 3.5 collectively form the operational profile for our use case. You are quite likely to find instances in the literature where the table, the pictorial decision graph, or the matrix, each by itself, is presented as the operational profile. They are essentially different views of the same thing. Pareto Principle and GuesstimatesWithout empirical results from the field or usability studies, the probabilities you use in your use case decision graph will likely be "guesstimates." Rather than spending a lot of time agonizing over the numbers, there's always the Pareto Principle, which you might find useful to apply to the operational profile. The term "Pareto Principle" (or Pareto Law, or simply the 80/20 rule) was coined by Joseph Juran in his Quality Control Handbook, first released in 1951. He based the term on the work of Italian economist Vilfredo Pareto who observed that in modeling the distribution of wealth and land, 80 percent was held by 20 percent of the population. Juran's original application of this distribution was applied to manufacturing where he observed that 80% of the problems reported stemmed from 20% of all types of defects. The Pareto Principle has subsequently proved a good model for many phenomena, both in the natural and social world, including software engineering, with rules of thumb such as "20% of the modules contain 80% of the defects" (Juran 1988). So, when all else failsyou have no empirical data from the field, you don't have time for a usability study, and you are frustrated at guessingyou might find it useful to apply the Pareto Principle to operational profiles: 20% of the paths exiting a use case step will carry 80% of the user traffic. I can't offer you any scientific study that says the Pareto Principle is a proven success on this, but I do think it will help you and your team get over the "analysis paralysis" of agonizing over probabilities of use case step exit paths. Let's see how this works. Quick, Low-Tech ApproachHere's a really quick, low-tech approach. Take the number of paths exiting a use case step and multiply by 20%; for most use cases this will yield 1 or 2 exit paths (e.g., 20% of 10 exit paths = 2). Distribute 80% of the traffic across these 1 or 2 steps. For the remaining steps, distribute 20% of the traffic across them. It doesn't have to be a uniform distribution. After you've kind of thrown the probabilities out there, step back and let your intuition take over to readjust. For this to work, you still have to be able to put the exit paths in order from high-traffic to low, but that's a lot easier to do than assigning probabilities. This quick approach to the Pareto Principle will give you a rational approach for guesstimating the probabilities to kind of get you past analysis paralysis. Your intuition can then be used to fine tune things. Successive Application of ParetoIf you want to get more rigorous in the application of the Pareto Principle, you can do successive applications. For example, after you've split a set of exit paths into two groups, one receiving 80% of the traffic and the other receiving 20%, you can reapply the Pareto Principle to the exit paths within each set. Figures 3.6 and 3.7 illustrate this notion of successive application for the two examples where the initial 80% of traffic is allocated to 1 and 2 exit paths, respectively. Figure 3.6. Successive application of Pareto Principle where initial 80% is allocated to a single use case exit path.
Figure 3.7. Successive application of Pareto Principle where initial 80% is allocated to two use case exit paths.
Notice that in both these cases, with just two successive applications of the Pareto Principle, you will have allocated 96% of the traffic. The remaining 4% can then be allocated as you see fit. So keep these two Pareto patterns in your back pocket; they may be all you need for most use case exit paths:
Using one of these two patterns is probably as safe a guesstimate as any other. |
EAN: 2147483647
Pages: 109