SADM 7/ed – CTTS CASE STUDY - Milestone 3: Solution Page: 3-1

MILESTONE 3 – MODELING SYSTEM REQUIREMENTS

:  Activity 1 – Use-Case Glossary

T

he following use cases and their descriptions and actors can be determined from the interview. Some students may identify other use cases based on standard maintenance functions. These are not incorrect, but have been left out of the glossary for the sake of simplicity. We have chosen to focus only on the use cases that will be most used.

A few notes on the use cases included in the glossary:

·  Manually Resolve Service Request was made a separate use case from Automatically Resolve Service Request because the steps that each follow are very different.

·  An abstract use case called Resolve Service Request was added to encapsulate the logic that actually marks a service request as resolved. This will be used by Manually Resolve Service Request and Automatically Resolve Service Request.

·  From the interview we could easily add another abstract use case for logon. But since every other use case would use logon, this was left out solely to keep the use case diagram that follows from becoming messy.

·  An Employee role was added for two use cases that could be accessed by any employee.

Use-Case Glossary
Use-Case Name / Use-Case Description / Participating
Actors and Roles
Enter Service Request / This use case describes the event of creating a new service request. / Client
Technician
Receptionist/Bookkeeper
Enter Work Record / This use case describes the event of a technician entering work done related to a service request, including time to be used for time-and-billing. / Technician
Enter Component Information / This use case describes the event of a technician entering a new component that has been added to a PC or other kind of equipment. / Technician
Check In Inventory / This use case describes the event of checking in new purchased components. / Receptionist/Bookkeeper
Enter Configuration Information / This use case describes the event of a technician entering software configuration information. / Technician
Enter New Client / This use case describes the event of entering a new client. / Receptionist/Bookkeeper
View Unresolved Requests/History / This use case describes the event of viewing a list of unresolved requests. A client can view only the unresolved requests for that client. A technician can view all of his or her unresolved requests. Management will view all unresolved requests that have been open for more than 72 hours. A complete history of all the work done on a service request can also be viewed. / Client
Technician
Management
Manually Resolve Service Request / This use case describes the event of marking an unresolved service request as resolved. / Technician
Automatically Resolve Service Request / This use case describes the event of automatically marking a service request as resolved. / Time
Resolve Service Request / This is an abstract use case that holds the functionality for actually marking a service request as resolved. It will be used by Manually Resolve Service Request and by Automatically Resolve Service Request.
View Installed Components / This use case describes the event of viewing the list of components installed in a piece of equipment. / Technician
Enter New Equipment / This use case describes the event of a technician creating an equipment record for a client. / Technician
Enter/Edit Component Type / This use case describes the event of a technician creating a new component type or editing an existing one. / Employee
Enter/Edit Equip Type / This use case describes the event of a technician creating a new type of equipment or editing an existing one. / Employee
View Software Configuration Info / This use case describes the event of a technician viewing software configuration information. / Technician

Activity 2 – Use-Case Model Diagram

T

his model should be constructed based on the use cases identified in Activity 1. The selection of subsystems will vary depending on the assumptions of the student. Most students should be able to correctly identify the Uses relationships shown below. In our solution a Uses relationship was established from View Unresolved Requests to Resolve Service Request because the interview suggested that the user interface might work that way.

:  Activity 3 – Fully-documented Use-Case Narrative

T

he narrative shown here is one possible answer. Students will need to make assumptions about the sequence of events as well as numbering and other minor issues. Grade based on the logic of the student’s approach to the problem and consistency of implementation.


Prepared by Gary B. Randolph for

Systems Analysis & Design Methods 7ed

by J. L. Whitten, L. D. Bentley, & K.C. Dittman Copyright Irwin/McGraw-Hill 2007