A Use Case describes the system’s behavior as it responds to a series of related requests from an actor. The Use Case should contain all system activities that have significance to the actor. A Use Case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the Use Case and goal are sometimes considered to be synonymous. The Use Case describes multiple paths that the user can follow within the use case. The basic elements that make up the Use Case are:

Name: The scenario or use case must have a unique name within the project. The use case name should describe which goal or event it will deal with, and generally includes a verb and a noun.

Actors: An actor is any person, system, or event external to the system under design that interacts with that system through a use case.

Preconditions: A precondition is any fact that the solution can assume to be true when the use case begins. This may include textual statements, such as “user must be logged in” or “Item must exist in catalogue”, or the successful completion of other use cases.

Triggers: A trigger is the initiator of a use case. It is what causes the use case to start.

Assumptions: Assumptions are influencing factors that are believed to be true but have not been confirmed to be accurate.

Flow of Events: Describes what the actor and the system do during the execution of the scenario or use case. Most use case descriptions will further break this down into a basic, or primary flow (representing the shortest successful path that accomplishes the goal of the actor) and a number of alternate flows that show more complex logic or error handling. If a circumstance still allows the actor to successfully achieve the goal of the use case, it is defined as an alternative.

Post-Condition: Any fact that must be true when the use case is complete. The post conditions must be true for all possible flows through the use case.

Business Rules: A business rule is a specific, actionable, testable directive that is under the control of an organization and that supports a business policy.
The business rules should be:

• Stated in appropriate terminology to enable domain SMEs to validate the rules. 
• Documented independently of how they will be enforced.
• Stated at the atomic level and in declarative format.
• Separated from processes that the rule supports or constrains. 
• Maintained in a manner that enables the organization to monitor and adapt the rules as the business policies change.