Within the Oracle Unified Method (OUM) we define the following in relation to Use Cases:
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:
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".