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

Page: 3-1

MILESTONE 3 MODELING SYSTEM REQUIREMENTS

Activity 1 Use-Case Glossary

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.

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

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

Page: 3-2

Use-Case Glossary
Use-Case Name
Enter Service Request

Use-Case Description
This use case describes the event of creating a new service request. 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. 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. This use case describes the event of checking in new purchased components. This use case describes the event of a technician entering software configuration information. This use case describes the event of entering a new client. 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. This use case describes the event of marking an unresolved service request as resolved. This use case describes the event of automatically marking a service request as resolved. 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. This use case describes the event of viewing the list of components installed in a piece of equipment. This use case describes the event of a technician creating an equipment record for a client. This use case describes the event of a technician creating a new component type or editing an existing one. This use case describes the event of a technician creating a new type of equipment or editing an existing one. This use case describes the event of a technician viewing software configuration information.

Participating Actors and Roles

Client Technician Receptionist/Bookkeeper Technician

Enter Work Record

Enter Component Information Check In Inventory Enter Configuration Information Enter New Client View Unresolved Requests/History

Technician

Receptionist/Bookkeeper Technician Receptionist/Bookkeeper Client Technician Management

Manually Resolve Service Request Automatically Resolve Service Request Resolve Service Request

Technician Time

View Installed Components Enter New Equipment Enter/Edit Component Type Enter/Edit Equip Type

Technician

Technician Employee

Employee

View Software Configuration Info

Technician

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

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

Page: 3-3

Activity 2 Use-Case Model Diagram

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 our solution a Uses relationship was established from VIEW UNRESOLVED REQUESTS to to RESOLVE SERVICE REQUEST because the interview suggested that the user interface might work that way.

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

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

Page: 3-4

Activity 3 Fully-documented Use-Case Narrative

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 students 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

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

Customer Technology Tracking System
Author:__Anna Kelly Use-Case Name: Use-Case ID: Priority: Source: Primary System Actor: Primary Business Actor: Other Participating Actors: Other Interested Stakeholders: Description: View Unresolved Requests/History CTTS-006 High Requirement MSS-R1.00 Client, Technician, Management Client Client, Technician, Management

Page: 3-5

Date:__03/29/06_ Use Case Type Business Requirements

Precondition: Trigger: Typical Course Of Events:

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. The user must have previously logged on so that the system can identify the user as a particular client, technician, or management user. The use case is initiated when the user selects this option from the user interface. Actor Action System Response Step 1: This use case is initiated when a user selects the option to view unresolved requests. Step 3: The user may request to view the detailed history for one of the unresolved requests. Step 2: The system responds by displaying a list of the unresolved request related to that client or technician. Step 4: The system displays detailed information about the original request and all work that has been done on it. This display will include an option for returning to the original list. Step 6: The system will verify that this user has the right to mark a request as resolved and then branch to use case MANUALLY RESOLVE SERVICE REQUEST.

Step 5: Technician or management users may request to mark a request as resolved.

Alternate Courses:

Alt Step 2a: If the user is management then the system displays all unresolved requests that have been open for more than 72 hours. Alt Step 2b: If there are no unresolved requests to display, the system will display an appropriate message. Alt Step 6: If the user does not have the right to mark a request as resolved. The system will display an error message. Or the system may be designed so that the resolve request is never given as an option to a user lacking that right. This use case concludes when the user exits the unresolved request list screen None None Web programming to be used so clients can have easy remote access.

Conclusion: Postcondition: Business Rules: Implementation Constraints and Specifications: Assumptions: Open Issues:

None 1. Need to determine whether or not a client can mark a request as resolved.

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