<Project Name> | Document Version <0.1> |
|
|
Use Case Specification | Date: |
|
|
Template Name: UseCaseSpecification | Template Version: 0.1 |
|
|
6.1.1.1 < An Alternative Subflow >
[Alternative flows can, in turn, be divided into subsections if it improves clarity. Only place subflows here if they are only applicable to a single alternative flow.]
6.1.2 < <n><b> Second Alternative Flow >
[There can be, and most likely will be, a number of alternative flows in each area of functionality. Keep each alternative flow separate to improve clarity.]
6.2 <Another Area of Functionality>
[There can be, and most likely will be, a number of areas of functionality giving rise to sets of alternative flows. Keep each set of alternative flow separate to improve clarity.]
6.2.1 < <nn><x> Another Alternative Flow >
7 Subflows
7.1 <S1 First Subflow >
[A subflow should be a segment of behavior within the use case that has a clear purpose, and is “atomic” in the sense that you do either all or none of the actions described. You might need to have several levels of
7.2 < S2 Second Subflow >
[There can be, and most likely will be, a number of subflows in a use case. Keep each sub flow separate to improve clarity. Using sub flows improves the readability of the use case, as well as preventing use cases from being decomposed into hierarchies of use cases. Keep in mind that use cases are just textual descriptions, and their main purpose is to document the behavior of a system in a clear, concise, and understandable way.]
<indicate if Confidential>
copyright <COMPANY>, 2007
Page 8 of 9
