1. Brief Description
[The description briefly conveys the role and purpose of the use case. A single paragraph will suffice for this description.]
2. Basic Flow of Events
Software user finds bugs of that software. He wants vendor to fix these bugs, so he tell description and snapshot about these bugs to vendor’s customer service (CS). He also tells that some of these bugs must be fixed at once; some are not so urgent, as well as some are just his suggestions which are nice to have. At last, He asks CS to notify him by email when the bugs are fixed.
CS records when user tells these bugs, code each of these bugs, and then reports these bugs to project manager of that software in papers. Start each alternative flow with an initial line clearly stating where the alternative flow can occur and the conditions under which it is performed.
3. Alternative Flows
[More complex alternatives are described in a separate section, referred to in the Basic Flow subsection of Flow of Events section. Think of the Alternative Flow subsections like alternative behavior¾ each alternative flow represents alternative behavior usually due to exceptions that occur in the main flow. They may be as long as necessary to describe the events associated with the alternative behavior.
Start each alternative flow with an initial line clearly stating where the alternative flow can occur and the conditions under which it is performed.
End each alternative flow with a line that clearly states where the events of the main flow of events are resumed. This must be explicitly stated.
Using alternative flows improves the readability of the use case. 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.]