The use case narrative, part 1
A common question about use cases is "How do I show workflow or screen flow?"
The short answer is that you don't. A more appropriate question would be,
"How do I use the use case model to determine screen and workflow requirements?"
Although you can go directly to describing features, many people find it helpful to develop use cases first and then generate a list of features.
A feature may be a whole use case, a scenario in a use case, a step in a use case, or some variant behavior, such as adding yet another depreciation method for your asset valuations, that does not show up in a use case narrative.
Usually, features end up being more fine grained than use cases.
Check out the pre-conditions and assumptions. If one use case requires the user to provide data that belongs to another use case, or do something that another use case is responsible for, then logically the other use case must come first.
Quite often, screen and workflows are far more flexible than we think. Let the use case constraints tell you what the flow options are. Then design the flow or flows that are possible, letting the users make the final choice as to which flow is best in the current task.