Use Case Specification

The next step after finalizing of use case diagrams is to document the business functionality into clear-cut and detailed use case specifications.

A use case specification document should cover the following areas:

* Actors: List the actors that interact and participate in this use case.
* Pre-conditions: Pre-conditions that need to be satisfied for the use case to perform.
* Post-conditions: Define the different states in which you expect the system to be in, after the use case executes.
* Basic Flow: List the basic events that will occur when this use case is executed. Include all the primary activities that the use case will perform. Be fairly descriptive when defining the actions performed by the actor and the response of the use case to those actions. This description of actions and responses are your functional requirements. These will form the basis for writing the test case scenarios for the system.
* Alternative flows: Any subsidiary events that can occur in the use case should be listed separately. Each such event should be completed in itself to be listed as an alternative flow. A use case can have as many alternative flows as required. But remember, if there are too many alternative flows, you need to revisit your use case design to make it simpler and, if required, break the use case into smaller discrete units.
* Special Requirements: Business rules for the basic and alternative flows should be listed as special requirements in the use case narration. These business rules will also be used for writing test cases. Both success and failure scenarios should be described here.
* Use case relationships: For complex systems, it is recommended that you document the relationships between use cases. If this use case extends from other use cases or includes the functionality of other use cases, these relationships should be listed here. Listing the relationships between use cases also provides a mechanism for traceability.

Generalization Relationship

The child use case in the generalization relationship has the underlying business process meaning, but is an enhancement of the parent use case.

Extend Relationship

In an extend relationship between two use cases, the child use case optionally adds to the existing functionality of the parent use case.

Include Relationship

In an include relationship, a use case includes the functionality described in the another use case as a part of its business process flow.

Use Case Relationships (dependency)

A relationship between two use cases is a dependency between the two use cases.

System boundary

A system boundary of a use case diagram defines the limits of the system.

UML Actor

An actor portrays an entity that performs certain roles in a given system.

An actor in a use case diagram interacts with a use case.

UML Use Case

A use case in a use case diagram is a visual representation of a distinct business functionality in a system.