<Project Name> <Sub-Project Name> | Document Version <0.1> |
| |
Use Case Specification | Date: 20-Oct-07 |
| |
Template Name: UseCaseSpecification | Template Version: 0.1 |
| |
Complex flows of events should be further structured into sub-flows. In doing this, the main goal should be improving the readability of the text. Subflows can be re-used in many places. Remember that the use case can perform subflows in optional sequences or in loops or even several at the same time.
A picture is sometimes worth a thousand words, though there is no substitute for clean, clear prose. If it improves clarity, feel free to paste flow charts, activity diagrams or other figures into the use case. If a flow chart is useful to present a complex decision process, by all means use it! Similarly for state-dependent behavior, a state-transition diagram often clarifies the behavior of a system better than pages upon pages of text. Use the right presentation medium for your problem, but be wary of using terminology, notations or figures that your audience might not understand. Remember that your purpose is to clarify, not obscure.
Flow of Event Formats
There are two possible formats for flows of events. A basic numbered list can be used, such as:
1.The use case begins when…
2.…
3.…
4.… and the use case ends.
If the use case comes from a system-of-systems operation handed down from the level above, for example, and enterprise operation handed down to become a system level use case, then the flow of events should be expressed as an operation specification, including both white and black box perspectives, using the following table format:
<indicate if Confidential>
copyright <COMPANY>, 2007
Appendix A. MDSD use case specification template 187
