Creating the Use Case Diagram

Creating the Use Case Diagram

For drawing use case diagrams, you need to use any tool that supports use case diagrams. We will be using the Poseidon Community Edition tool for drawing the use case diagram, as shown in Figure 3.7. You can use any tool that you are comfortable with. A use case modeling tool provides a palette of options to draw actors and use cases and to define relationships between the use cases.

Click here for a larger image.

Figure 3.7: a screen shot of the Poseidon tool

Take a look at the screen shot of the Poseidon tool. You can see the different options it provides to draw the use case diagram elements. In addition to drawing the use case diagram elements such as actors and use cases, you also can define relationships between use cases. Apart from this, the tool also provides capability to document the different elements that we draw. This documentation can be viewed as a consolidated report for future reference.

An additional feature that you can check in your modeling tool is support for generating test scripts from the use case diagram. A comprehensive use case diagram provides a good foundation for basing test cases for the system that you model.

Writing a Use Case Specification

A use case diagram, as we have seen, is a visual depiction of the different scenarios of interaction between an actor and a use case. The usefulness of use case diagrams is more as a tool of communication between the requirements capture team and the user group. The next step after finalizing of use case diagrams is to document the business functionality into clear-cut and detailed use case specifications. Because use cases are used as an input to the other project phases such as design, development, and testing, we need to ensure that the visual depiction of the business requirements is translated into clear and well-defined requirements in the form of use case specifications. Elaborate use case specifications are used as an input for design and development and for writing test cases (unit, system, and regression tests, as the case may be).

A use case specification document should enable us to easily document the business flow. Information that you document in a use case specification includes what actors are involved, the steps that the use case performs, business rules, and so forth. 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.

   

You can download a template for a use case specification document and customize it for your use here.