Lets see how we can apply this methodology to our example system under development. From the system description we identify the actors. We can identify two actors, the user and the librarian, and if we consider that we shall use a database management system to store the information stated in the description, then this database shall be a third actor.

The next step is to find out how our actors interact with the system. This will help us identify a first cut of use cases. We can do this by going through the description again. The first statement states:

“There is a need for an automated library system that permits the registration of books, magazines, documents, electronic data storage software (CD, floppy, zip etc.) etc.”

There must be a way to insert (register) all these items with the library. This is the responsibility of the librarian even though it is not stated in the description. Hence, we can create a use case Registers item for this case.

            The next statement:

“A user must be able to browse a library catalogue and be able to do a search to the catalogue (by author, by title, by ISBN and/or by keyword).”

notifies us that there should be a use case Search for item that contains also another use case Browse library catalogue. But for now, lets assume only the use case Search for item.

“The user will be able to make an application electronically to borrow a book and after approval, a token will be returned to him/her and s/he will be able to borrow the item from its physical location in the library.”

From the above statement, another use case will be Borrow item.

“If the item is not available, s/he will be able to make a reservation on the item. Reservations will be stored in a FIFO list for the users.”

The user can also interact with the system with the use case Reserve item.

Continuing the same way we have produced the use case diagram of Figure 7 .

Figure 7 A first cut use case diagram for the example system

Next, we must register each actor and use case using the formula described in §4.1. For example, a short documentation for the actor user would be: “A user can be anyone who has rights to use the system to search for and borrow an item”. 

The documentation for a use case will be:

We see that some fields are empty in the above use case documentation. These fields will be completed later during the analysis phase.

Once we have documented all use cases, we can now proceed further with our analysis by rectifying our use case diagram. First, we can analyse more the relation between the user and the librarian. We can assume that the librarian can also be a normal user of the system, i.e. be able to borrow items, make reservations etc. However, a librarian has additional responsibilities such as to register new items or users, receive fine payment etc. Or, we may decide that the librarian cannot perform what a normal user can do. In this case if the librarian wishes to borrow items too, then s/he must have a second id with the library, that of a normal user. In our system, we decide for the first case. Hence, we have to provide a generalization relationship between the librarian and the user as is shown in the following diagram:

Figure 8 A generalisation relationship among actors

This relationship means that the librarian can perform all the use cases the user can perform, plus additional ones, but not the other way round.

We are now in a position to further rectify out use case diagram by use of associations. We saw in our previous analysis that Search for item use case also includes a use case Browse items which is not shown in the use case diagram. The basic flow of action for Search for item use case is:

1.

^{1 In a real system a use case ID will be of the form: #13. Similarly, requirements come will some sort of numbering, so in the "Requirements tracing" row, instead of a description of the requirement we would have something like: #906, #45, #34 etc. if the use case refers to more than one requirement statements.}