Arunkumar Khannur's Software Testing Knowledge Center

11.10. Documenting a Use Case

Following are the sections of a use case
Use case Name < Use Case Name >
The name should implicitly express the user's intent or purpose of the use case, such as "Enroll Student in Seminar."
Use case Identifier (Optional) < Use Case ## >
A unique identifier, such as "UC221," that can be used in other project artifacts (such as your class model) to refer to the use case.
Risk Factors A list of possible risks that may halt the progress of scenarios
Goal in context Brief description on what is expected from the < Use Case Name >
Description Several sentences summarizing the use case.
Preconditions A list of the conditions, if any, that must be met before a use case may be invoked.
Assumptions [Optional] Any important assumptions about the domain that you have made when writing this use case. At some point you should verify these assumptions and evolve them either into decisions or simply into parts of the Primary Scenario or alternate courses of action.
Actors Primary actor:
Secondary actors:
The list of actors associated with the use case. Although this information is contained in the use case itself, it helps to increase the understandability of the use case when the diagram is unavailable.
Primary Scenario The main path of logic an actor follows through a use case. Often referred to as the happy path or the main path because it describes how the use case works when everything works as it normally should.
Steps: All interactions between actors and system that are necessary to complete the scenario
Variations or Alternate Scenario The infrequently used paths of logic in a use case, paths that are the result of an alternate way to work, an exception, or an error condition.
Post-conditions A list of the conditions, if any, that will be true after the use case finishes successfully.
Extensions/ Extended Use Cases [Optional] The use case that this use case under development extends (if any). An extend association is a generalization relationship where an extending use case continues the behavior of a primary use case. The extending use case accomplishes this by inserting additional action sequences into the base use-case sequence. This is modeled using a use-case association with the < < extend > > stereotype. Branching Action to other connected alternatives available for completing the user actions with the system.
Inclusions/ Included use cases [Optional]. A list of the use cases this use case under development includes. An include association is a generalization relationship denoting the inclusion of the behavior described by a use case within another use case. This is modeled using a use-case association with the < < include > > stereotype. Also known as a uses or a has-a relationship.
Change history [Optional] Details about when the use case was modified, why, and by whom.
Referenced GUI GUI that are referenced in the scenario
Issues [Optional] A list of issues or action items, if any, that are related to the development of this use case.
Decisions A list of critical decisions, typically made pertaining to the content of the use case. It is important to record these decisions to maintain a group memory.
Khannur's Book
Arunkumar Khannur, Software Testing - Techniques and Applications, Published by Pearson Publications, 2011 (ISBN:978-81-317-5836-6; Pages:341 + xxii)
Follow Khannur
Khannur's Company
ISQT Process & Consulting Services Pvt. Ltd., Bangalore, INDIA
Khannur's Software Testing Forum
 Contact Khannur
ISQT Process & Consulting Services Pvt. Ltd.
#732, 1st Floor, 12th Main,
3rd Block, Rajajinagar,
Bangalore - 560010, INDIA
Phone: +91 80 23012511
Skype: arun.isqt