Use Case Assumptions versus Pre-Conditions

Within the Oracle Unified Method (OUM) we define the following in relation to Use Cases:

 

  • Assumptions: Facts we assume to be true, but may later prove to be untrue
  • Pre-Conditions: That which must be true before the Use Case can start

 

Seems pretty clear at this point! But in practice, when would it be appropriate to use an Assumption versus a Pre-Condition within a Use Case?

Let’s look at a hypothetical Use Case which represents the creation of an On-Line Sales Order (Internet shopping). For the sake of this example, we will name the Use Case – Create On-Line Sales Order

If a Business Analyst were writing such a Use Case, one question that might come up is…..”How should we deal with the possibility of the Credit Card Payment Gateway being unavailable during the on-line order creation process?”

One option would be to use a Use Case “Pre-Condition”. In other words, we will not let the Use Case “start” unless the Payment Gateway is actually available. This would force the software developer into creating some logic that checks the Payment Gateway Status prior to the user beginning the shopping process, and if the Gateway was “down” then the user would not be allowed to even begin the shopping process, i.e. a Pre-Condition allows us to define “what must be true before the Use Case can begin”.

Nothing wrong with that option you might think?

Well……another option would be to use a Use Case “Assumption”. In other words, we will assume that the Credit Card Payment Gateway is available, and allow the Use Case to “start” without actually verifying its availability. The implication for this, in terms of software development, is that the developer will not check the Payment Gateway status when the user begins the “shopping” process, and if at the point of checkout, the Gateway is in fact “down”, then we would describe how that should be handled through a Use Case Exception Scenario.

At this point we really need to step back from the semantics of the Use Case framework and think about how the business would prefer to handle this process, and specifically, what sort of user experience do they ideally want to provide to their on-line shoppers?

If you were the on-line shopper, you would be pretty un-happy if you had just spent 30 minutes choosing a range of items, including size/color/style, only to find that you could not checkout due to a problem with the Payment Gateway. You might not want to come back and shop there again!

So…..Pre-Condition sounds like the best option for this scenario?

Perhaps not……Let’s put the shopper experience at the forefront of our approach. If we apply this type of thinking, then another option would be to allow the customer to go through the product selection process, and at the point of selecting the checkout option, we would only then check the status of the Payment Gateway. If it was “up” then the customer would checkout as normal. It the Payment Gateway was not available, an option would be provided for the customer to either abort the checkout, or save their items in the shopping cart, and the business would notify them as soon as the Payment Gateway was available.

This latter option has many advantages, particularly in the area of analytics in terms of quantifying the number of customers who were not able to checkout due to a Payment Gateway issue, and the value of any lost business for those customer who do not return, even if they had previously saved items in their shopping cart.

Let’s now return to our Use Case. If we assume the business decides to take the latter option, should we use a Pre-Condition or an Assumption? The preferred option would be as follows:

  • Make the availability of the Payment Gateway a Use Case Assumption
  • Create an independent (<<include>>) Use Case called “Verify Payment Gateway Status” and reference this in the main success scenario of the “Create On-Line Sales Order” Use Case at the point the user selects the Checkout option.
  • If the Payment Gateway is available, then Use Case continues through the checkout process
  • If the Payment Gateway is unavailable, then the User is presented with an option to either:
    1. “abort shopping” whereby an Exception Scenario would describe the subsequent steps
    2. “save items, pay later” whereby an Alternate Scenario would describe the subsequent steps before returning to the main success scenario

In summary, on the face of things the difference between a Use Case Assumption and a Pre-Condition seems a little arbitrary. However these, along with other elements of a Use Case approach encourages an essential level of dialog between the Analyst and the Business; and it is this level of analytical rigor which makes a Use Case approach such a powerful approach to understanding complex requirements, and/or describing functional requirements prior to a potentially costly software development cycle.

In short.....time invested in the structured analysis of requirements, is more efficient that leaving the Software Developer to "fill in the blanks".

Comments:

Another option is to have a step where in the payment gateway availability status is notified to the customer, for information only without hard stopping him while choosing the goods.

The same can be extended to pole the availablity continuously and show the status to the customer.

•Make the availability of the Payment Gateway a Use Case Assumption

Create a independent User Case called "Verify Payment Status" and reference this (<<extend>>)in the main scenario of the "Create On-Line Sales Order" Use Case at the point just after start of the use case

• During check out reference (<<include>>) Use Case called “Verify Payment Gateway Status” and reference this in the main success scenario of the “Create On-Line Sales Order”

Posted by guest on March 13, 2012 at 07:42 PM GMT+05:00 #

Another option is to use <<extend>> “Verify Payment Gateway Status” during the initation of the order process to notify the customer, keeping the status as assumption rather than a pre-condition

Posted by Murugan on March 13, 2012 at 08:20 PM GMT+05:00 #

Good comments!

As always, there are many ways to "skin a cat"! or as Alistair Cockburn once wrote "my Use Case, it not your Use Case".

In other words, when you write a Use Case (or any description of how you'd like software to work), there are often several potential options.

I guess the main point of my Blog entry was to emphasize the importance of openly, and creatively discussing these options with the client. And of course the Use Case framework, is, at the end of the day, simply a vehicle to encourage that discussion and encourage an appropriate level of resulting documentation.

Posted by guest on March 14, 2012 at 05:00 AM GMT+05:00 #

Thanks for your comments.

Here are my thoughts (in CAPITALS)

Another option is to have a step where in the payment gateway availability status is notified to the customer, for information only without hard stopping him while choosing the goods.
YOU COULD CERTAINLY DO THIS, MY ONLY CONCERN OR QUESTION WOULD BE WHETHER THE BUSINESS WOULD WANT TO NOTIFY THE CUSTOMER THAT EARLY ON DURING THE SHOPPING PROCESS THAT A PROBLEM EXISTED WITH THE PAYMENT GATEWAY, I.E. YOU MIGHT NOT WANT TO SCARE THE CUSTOMER AWAY, ESPECIALLY IF THE GATEWAY MIGHT BE AVAILABLE AGAIN IN A FEW MINUTES

The same can be extended to pole the availablity continuously and show the status to the customer.
TOTALLY AGREE, AND IT THE BUSINESS WANTS THAT, THEN IT IS SPELLED OUT CLEARLY IN THE USE CASE, AND NOT LEFT TO THE DEVELOPER TO “2ND GUESS” THAT OPTION

Create a independent User Case called "Verify Payment Status" and reference this (<<extend>>)in the main scenario of the "Create On-Line Sales Order" Use Case at the point just after start of the use case
THE ONLY PROBLEM WITH USING AN <<EXTEND>> USE CASE IS, BY DEFINITION, AN EXTENSION USE CASE DESCRIBES “OPTIONAL BEHAVIOR” AS OPPOSED TO THE MANDATORY BEHAVIOR OF AN <<INCLUDE>> USE CASE, AND I WOULD THINK THE VERIFICATION OF THE PAYMENT GATEWAY STATUS IS MANDATORY BEHAVIOR, EVEN IF IT’S HIDDEN FROM THE USER.

Posted by David Burke on March 14, 2012 at 05:09 AM GMT+05:00 #

Another way to look at this is that Assumptions are actually risks that you capture during the development of the use case header and details. Ideally, those "risks" would be transferred onto the overall risk log for the project and should be prioritized and addressed with all of the other risks. In the best case, all of the assumptions would be removed from the use cases details (or at least from the risk log) as the project progresses.

Posted by Tom Spitz on March 14, 2012 at 08:56 PM GMT+05:00 #

I agree with David Burke on the <<extend>> vs <<include>>.

You would want it to be mandatory, so it should be <<include>>.

Posted by Shannon on April 04, 2014 at 01:20 PM GMT+05:00 #

Post a Comment:
  • HTML Syntax: NOT allowed
About

OUM Logo
The Oracle® Unified Method (OUM) is Oracle’s standards-based method that enables the entire Enterprise Information Technology (IT) lifecycle.

Read:

· Brief

· White Paper

· Customer Program Data Sheet

Connect:

· OUM on Twitter

· OUM on LinkedIn

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds