Scenario Analysis

1. Scenario Analysis

2. Scenario analysis Scenario analysis is an apparently simple process that has considerable power in breaking down a complex problem into manageable parts. This will form the basis for both business process analysis and use case analysis. The approach used is to break any process down into simple sequences. By collecting them in a disciplined way, it is possible to gather a considerable amount of detail. Do not be deceived by the apparent naivety of the approach. After a while you will get used to analysing situations by looking for primary and alternative paths. A scenario is a sequence of events. Computer systems and businesses can be viewed as sequences of events. These sequences interact with each other. What we need is to collect some representative scenarios, and organise them. Once we have systems that can deal with some of the scenarios, we will find that they themselves develop very complex behaviour and cope with a much broader range of scenarios. Here is a scenario for someone ordering a product from an internet store. • Go to web site • Browse catalogue • Choose product • Give delivery and credit card details • Submit order Now this sort of scenario can vary endlessly. A customer might go back and choose several products. A customer might deselect a product. Credit card details may not be correct. There could be thousands of scenarios.

3. Scenario analysis, the 80-20 rule It is a known rule of thumb (=πρακτικός κανόνας) that "80% of effort goes on 20% of activity", sometimes known as the Pareto rule. This means that we spend most of our effort to perform a small part of what we have to do. For example, most of the transactions at a bank till are fairly swift, but a small number take four or five times the effort from the clerk. This is very true of computer systems development. Most of the effort in developing computer systems focuses on dealing with things that might go wrong or things that are unusual. If everyone typed accurately the right information into a computer system, then most of the development of computer systems would be much easier. But they don't. So you have to consider what might go wrong as well as what can go right. In order to cater for the majority of cases, you can probably build a computer system fairly quickly. It is very useful if you can identify the majority case and leave the difficult cases until later. We can never design the perfect system from the outset, so what we really need is a way of building good systems that can be extended. What we are going to do now is look at a way of applying this rule to analysing a system. We will look for ways of satisfying most of the users most of the time, and do this as cost-effectively as possible…

4. The Primary Path When you are analysing an activity, you can usually identify a path that is most commonly used, with a few variances. This is known as the primary path, or sometimes figuratively as the happy path. The primary path is the one that is used most of the time. If you can identify that, then you can satisfy the majority of your customers. Looking for primary paths first cuts down complexity. It stops "analysis paralysis" where analysts get too focused on the detail and forget that at the end of the day they have to deliver a working system, not a perfect system. So we will develop our systems from hereon in by looking for primary paths first, and worrying about the alternatives and problems later

5. The Alternative Path and Exceptions Once you know the primary paths for a system, you can look for alternative paths. These are paths (flows of activities) that might be subtle (=small) changes to the routine. Note, that by defining the primary path, you have provided yourself with a good checklist to look for alternatives. Once the primary path is developed, you can ask at each step what the alternatives are. The next question is what you can do with alternatives. The answer is usually to try and return them to the primary path as quickly as possible. Exceptions are alternatives that are usually more drastic. An alternative is something that routinely happens, but not as often as the primary path. Exceptions are things that are rarer and require different levels of recovery. An example might be in the web ordering system that someone submits a fraudulent credit card. The response to that might be to accept the details and the order, but instead of issuing goods the police would be advised.

6. An example PRIMARY PATH • Go to web site • Browse catalogue • Choose product • Give delivery and credit card details • Submit order ALTERNATIVE PATHS 2.1 Catalogue database not available • Put up error screen, apologising to customer and asking them to check later. 4.1 Credit card details invalid so: • Put up error screen explaining problem • Ask customer to re-enter details • Re-check details, and if ok, continue to step 5 (submit order) 4.2 Credit card details invalid after second attempt • Abandon transaction 4.3 Postcode does not match address line • Put up error screen explaining problem • Ask customer to re-enter details • Re-check details, and if ok, continue to step 5 (submit order)

7. Include, Extend, a deeper view • A Use Case can use another Use Case. If you have a piece of well-defined functionality, it makes sense to re-use this wherever possible. Also, sometimes a Use Case gets too big to manage sensibly and it makes sense to break this down into smaller Use Cases. There are two ways Use Cases can relate. The first is where a Use Case "includes" another Use Case. In this case the second Use Case is always invoked as part of the execution of the first. This is drawn with an arrow pointing to the Use Case that is included, • Sometimes a Use Case is only called occasionally from another Use Case. From the scenario analysis of the business, this will often be to support an alternative path or an exception. We draw this with an arrow pointing the other way (yes, it is confusing at first) where the arrow points to the calling Use Case. When we have a functionality that we want to reuse, then we <<include>> this functionality (e.g. see slide 32, “consult catalogue”) INCLUDE When we have complicated use cases that we want to break down into simpler use cases then we <<include>> the simpler use cases to the more general one (e.g. “Receive payment”) An “alternative path” or an “extension” is represented using the <<extend>> notation (be careful with the direction of the arrow: goes from the specific to the general) (e.g. “issue warning letter” + “telephone reminder”) EXTEND