Why Postconditions Matter in Use Cases: Knowing the Outcome

If preconditions are the rules for starting a use case, then postconditions are the results when it’s all over. A postcondition is a specific, observable change that occurs after a use case has been completed successfully or with an error. It tells you exactly what the state of the system should be once the process is finished.

A Simple Tip for Writing Your Own

Think about sending a text message.

The precondition is that you have service and a recipient.

The postcondition is what happens after you hit “send.”

Postconditions for Different Outcomes

A use case can have different outcomes, each with its own postcondition. It’s important to define both the successful and the failed results.

Successful Postcondition

The text message is successfully sent and the message log is updated to show a “Delivered” status. The message is now visible to the recipient.

Failed Postcondition

A network error occurs. The message is not delivered. The system displays an “Error Sending Message” alert to the user and the message remains in the outbox.

Why Postconditions Are So Important

Defining postconditions is a crucial part of system design because they:

• Ensure System Integrity: They confirm that the system’s state has changed correctly and as expected (e.g., a balance has been updated).
• Meet User Expectations: They describe the final result the user is looking for, ensuring the software delivers on its promise.
• Simplify Testing: Postconditions provide a clear way for testers to verify the final outcome of a use case. They are the “expected result” of a test case.

A Simple Tip for Writing Postconditions

When you write a postcondition, focus on the change.

Instead of “The use case is finished,” write “The user’s account balance has been debited by the transaction amount.” This makes it specific and verifiable, which is exactly what a tester needs.