• Is Expected Outcome interchangeable with Postcondition depending on your use case structure?

  • Should Expected Outcome and Postcondition be explicitly differentiated from each other?

Say I have a snippet of the use case of withdrawing money from an ATM (agrees to issue receipt):

Description: This use case describes how a Bank Customer uses an ATM to withdraw money from their bank account
Basic Flow:
Customer inserts their bank card into the card reader of the ATM
...
System ejects the Customer's bank card; the Customer takes the bank card from the machine

Should the Expected Outcome be:

Expected Outcome: The ATM dispenses the requested amount of the Customer

or

Expected Outcome: The Customer obtains cash from the machine

with the Postcondition having

Postcondition: The Customer obtains the receipt from the machine; the system records a transaction log entry for the withdrawal

I was thinking that the Expected Outcome should be the latter since it agrees with the Description while the Postcondition enumerates the activities/conditions that the system will perform upon successful execution of the use case. Am I in the right logic here?

  • Does either of your 'Expected Outcome' examples add any 'real' value? For that matter, does either of your 'PostConditions' add any additional meaningful value beyond the description and basic flow? IMO, I'd say no for all. If you don't have a compelling reason for having a section in your template then don't bother including it in your template. It saves a lot of useless work. I'm not claiming there aren't valid reasons for having those fields, but only add them once you discover the 'compelling' reason that your specific project needs those fields. – Dunk Aug 14 at 19:01

For a case like this I would expect a pre-condition like:

  • The customer has a sufficient available funds to cover the withdrawal amount.

This would result in a post-condition like:

  • The transaction is recorded and the customer's balance reduced by the withdrawal amount.

The expected result would be:

  • The cash is dispensed.

The insertion, validation and return of the card and printing of the receipt could be part of a separate use cases. These are generally reusable actions.

  • it's more like "what the system could do", since the Customer would be withdrawing money; the system shall dispense cash provided your given pre-condition has been met. – Dee Aug 7 at 0:41

I guess you are looking for a difference between Minimal Guarantee and Success Guarantee as defined by Cockburn.


the system records a transaction log entry for the withdrawal

Is a requirement from some stakeholder to this use case. Regardless of how withdrawal went our security chief requires detailed logs of the operation. It's a Minimal Guarantee: must be fulfilled as long as use case execution started and regardless of which alternate and especially exceptional flow it went.

The ATM dispenses the requested amount of the Customer

System ejects the Customer's bank card

These are again requirements from some stakeholder to this use case. If not met then something went wrong and user goal is not achieved. It's a Success Guarantee: must be fulfilled when the use case completes successfully regardless if it went through its main success scenario or any alternative path(s). Typically not fulfilled if an exceptional flow is reached (ATM has no cash for example).

The Customer obtains the receipt from the machine

This could be a Success Guarantee of the same use case only if there is a requirement that user must always receive a receipt.

The Customer obtains cash from the machine

the Customer takes the bank card from the machine

Are neither, you don't have any control over user.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.