Filter
Top Products
190 Model Driven Systems Development with Rational Products
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 sub-flows, but if you can you
should avoid this as it makes the text more complex and harder to understand.]
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.]
<Project Name> <Sub-Project Name> Document Version <0.1>
Use Case Specification Date: 20-Oct-07
Template Name: UseCaseSpecification Template Version: 0.1
<indicate if Confidential> copyright <COMPANY>, 2007 Page 8 of 9