Use Case Assumptions versus Pre-Conditions

Within the Oracle Unified Method (OUM) we define the

• 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 (<>)
  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".