3: MODELLING SYSTEM REQUIREMENTS MILESTONE

3: MODELLING SYSTEM REQUIREMENTS MILESTONE

ACTIVITY 1. USE CASE GLOSSARY

The following table describes the use case glossary for CTTS:

NAME DESCRIPTION ACTORS

View Software Configuration Information

This use case refers to the system user interaction where the user is looking at the information pertaining to software configuration.

Technician

Enter Service Request

This use case refers to the system user interaction where a new service request is being entered in the system.

Client Receptionist or Bookkeeper Technician

Check Inventory This use case refers to the system user interaction where the new components which have been purchased are being checked into the inventory.

Receptionist or Bookkeeper

Enter Work Record This use case refers to the system user interaction where the user files in the details of work done in order to service a particular request.

Technician

View Unresolved Requests or History

This use case refers to the system user interaction where the list of unresolved requests currently in the system are being viewed. For a client, only the list of unresolved requests for the client would be displayed. For a technician, the list of all unresolved requests under his name will be displayed. For management, all the requests which have been in the system for more than 3 days and are yet unresolved will be displayed. Entire history related to the event can also be seen.

Client Management Technician

Enter New Client This use case refers to the system user interaction where a new client is being registered in the system.

Receptionist or Bookkeeper

Enter New Equipment

This use case refers to the system user interaction where a new equipment record for a client is being created.

Technician


 Table 1. Use Case Glossary

The following assumptions have been made while designing the above use case glossary:

1. Employee was added as an actor in the system, so that the use cases which are accessible to all the employees can be handled using this role.
2. Manually Resolve Service Request and Automatically Resolve Service Request have been differentiated from each other because the system would follow different course of action in each of these cases.
3. In order to cover the fact that a service request is eventually marked as resolved, an abstract use case can be added which would account for both the manual as well as automatic request resolution.
4. From the discussion in the exhibit from question document, it is clear that login should be another use case. However, login has to be used by each and every use case and hence it has been intentionally left out from the cases above by implicitly assuming that all the users using the system are authenticated.

Enter Component Information

This use case refers to the system user interaction where the user adds the details of a new component that has been added while processing a service request.

Technician

Automatically Resolve Service Request

This use case refers to the system user interaction where a service request is marked as resolved by the system.

Time

Enter Configuration Information

This use case refers to the system user interaction where the user enters the details corresponding to a software configuration done.

Technician

Enter or edit Equipment Type

This use case refers to the system user interaction where the user creates a record for a new equipment in the system or modifies an existing record.

Employee

Manually Resolve Service Request

This use case refers to the system user interaction where a service request is marked as resolved by a user.

Technician

Enter or edit Component Type

This use case refers to the system user interaction where the user creates a record for a new component type in the system or modifies an existing record.

Employee

View Installed Components

This use case refers to the system user interaction which displays the list of all the components which have been installed in an equipment

Technician