Each use case should represent a discrete unit of work. Each unit has a specific role within the overall functionality of the system.
To define the unique role for each use case, you must document the relationship of the use case to the other behaviors of the system.
Three additions to the use case template can help properly position each use case in relation to the other use cases:
Each use case is only one part of a complete system. When certain behaviors must be handled by another use case prior to allowing anyone to access this use case, specify these conditions as assumptions. For example, verify that the user has permission to access this feature.
Good design requires that processes clean up after themselves so that subsequent processes are not corrupted. Post-conditions identify the items that the use case must handle before terminating.
Sometimes these activities may be part of the normal and exceptional event flows. Other times they must be added. For example, after you complete a transaction, it is often useful to add the transaction to a history file so that it can be audited and/or reversed at a later date.
1) Start with our earlier example and add the new narrative elements
2) Add the assumptions, conditions that must be tested outside of this use case and before this use case may be executed.
3) Add the pre-conditions, conditions that are tested by this use case that must prove true
4) Add the post-conditions, condition that are tested by this use case and that must prove true before