Within the Oracle Unified Method (OUM) we define the
Seems pretty clear at this point! But in practice, when
would it be appropriate to use an Assumption versus a Pre-Condition within a
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
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
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".