Chapter 5. Use Case Preconditions, Postconditions, and Invariants: What They Didn't Tell You, But You Need to Know!
With the growth in popularity of use case-driven development, in some cases being applied to product
From a black-box testing perspective, preconditions and postconditions are the quintessential elements of a use case, saying what it does without saying how. They are the ideal basis for black-box testing; what more could one need for specifying tests? And in failure analysis, preconditions play the role of specifying those conditions under which the use case is intended to work correctly, and conversely the conditions under which the system might fail. A system can then be implemented by using techniques such as design by contract or defensive programming , where routines check their preconditionscalled assertions because they assert what the routine assumes to be truebefore running. If the precondition is false, the routine can handle the exception safely (i.e., fail safe ). 
In reality, however, few use cases are produced with preconditions and postconditions of substance enough to test from. If you look at your favorite book on use cases, you are likely to find use cases with preconditions but no postconditions (the significance of which will make sense later) and postconditions with no preconditions. And even when both are present, you would likely be hard pressed to tell what a use case did based solely on the pre- and postconditions . While developers may be willing to keep use cases informal (Cockburn, 2002)  when it comes to failure analysis and test design, something a bit more concrete is needed; hence, a number of proposals for making use cases more test-ready have appeared. 
In this chapter, we look
Sanity Check Before Proceeding
Unlike the other
In this chapter, you will be looking at preconditions and postconditions of individual operations or steps that make up a use case.  This is a different perspective from that of most use case literature that talks about pre- and postconditions of the use case "as a whole." One consequence of the latter perspective is that the use case community has focused primarily on preconditions that must be satisfied before the use case can start . But from a failure analysis and test design standpoint this is not sufficient: there are usually operations (for instance, later in the use case) whose preconditions are to be satisfied by the postcondition of another operation earlier in the same use case. While such preconditions do not prevent the use case from starting , their violation can translate into system failure nevertheless.
While the presentation of pre- and postconditions in this chapter is, I believe, consistent with UML in general ( The UML Reference Manual defines preconditions and postconditions in terms of operations [Rumbaugh, Jacobson, and Booch 2005]), the chapter could be a little confusing if you read it with the mindset that the only type of use case precondition is one that must be satisfied before the use case starts.
This issue and others are discussed in more detail near the end of this chapter; if you care to read ahead, see the "Further Thoughts: Preconditions, Postconditions, and Invariants in Use Cases" section. Remember, the goal of this chapter is not to rehash what has already been said about preconditions and postconditions in the use case literature. The goal of this chapter is to think outside the box a bit and present to you a look at preconditions and postconditions and how they relate to use cases from a whole new perspective, that of model-based specification.