SADM 7/ed – CASE STUDY CTTS – Milestone 2: SolutionPage: 2-1

MILESTONE 2 - PROBLEM ANALYSIS

Problems, Opportunities, Objectives, and Constraints Matrix.

T

hematrix should be completed based on the solution of Milestone 1, the case background information, and the user interviews. The students should try to identify the causes and effects of the problems identified in Milestone 1. Make sure students identify a cause and not restate the problem. Also, make sure they specify proper objectives to correct the problems. You will have a multitude of different answers. Evaluate their thought processes. The following matrix illustrates one possible solution.

Prepared by Gary B. Randolph for

Systems Analysis & Design Methods 7ed

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

SADM 7/ed – CASE STUDY CTTS – Milestone 2: SolutionPage: 2-1

PROBLEMS, OPPORTUNITIES, OBJECTIVES AND CONSTRAINTS MATRIX

Project:Client Technology Tracking System / Project Manager:Peter Charles
Created by:Anna Kelly / Last Updated by:Anna Kelly
Date Created:03/22/2006 / Date Last Updated:03/22/2006
CAUSE AND EFFECT ANALYSIS / SYSTEM IMPROVEMENT OBJECTIVES
Problem or Opportunity / Causes and Effects / System Objective / System Constraint
  1. The current system does not accurately track configuration information, leading to wasted time for technicians and clients.
/
  1. Three-ring binder that holds information is disorganized and incomplete.
  2. Three-ring binder is difficult to keep up-to-date because word processing documents cannot be updated in the field.
  3. Leads to wasted effort in the field, unbilled hours, and dissatisfied clients.
/
  1. Create a searchable database of configuration information.
  2. System should be easy to update in the field.
/
  1. Configuration information should not be accessible from the Internet for security reasons.
  2. If not online, then need to replicate data between master and copy.

  1. The current system does not accurately track installed components, leading to wasted and non-billable extra trips to the customer’s place of business.
/
  1. Three-ring binder that holds information is disorganized and incomplete.
  2. Three-ring binder is difficult to keep up-to-date because word processing documents cannot be updated in the field.
  3. Leads to wasted effort in the field, unbilled hours, and dissatisfied clients.
/
  1. Create a searchable database of configuration information.
  2. System should be easy to update in the field. One approach could be the use of barcode scanning.
/
  1. Configuration information should not be accessible from the Internet for security reasons.
  2. If use barcode scanning, would have to change inventory check-in process.
  3. If use barcode scanning, would have to make sure barcode was on every piece of equipment.
  4. If not online, then need to replicate data between master and copy.

  1. The proposed system could allow clients to enter service requests online, saving receptionist time plus providing more efficiency.
/
  1. Receptionist takes calls and route to technicians with phone transfer or e-mail.
  2. If client calls back, request can get duplicated and worked on by multiple technicians.
  3. Leads to wasted effort and dissatisfied clients.
  4. Consumes a great amount of receptionist's time.
/
  1. Create Internet application in which clients can enter their own service requests.
/
  1. Internet application must have adequate security.

  1. The proposed system could provide a customer history that would allow for better service.
/
  1. Would allow technicians to see what other technicians had done.
  2. Would lead to better customer satisfaction.
/
  1. System would allow technicians to record notes on work done on service requests.
  2. Technicians and client could see service request history.
/
  1. Internet application must have adequate security.

Prepared by Gary B. Randolph for

Systems Analysis & Design Methods 7ed

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

SADM 7/ed – CASE STUDY CTTS – Milestone 2: SolutionPage: 2-1

Context Diagram

The Context Diagram below is one possible solution based on the interviews in Milestones 1 and 2. This was drawn in Microsoft Visio. Visio cannot easily produce a Context Diagram exactly like the one shown in chapter 5. The Data Flow Model template found in the Software category can produce one that is like the sample except that the square Interface symbol must be used instead of the Actor symbol. This, of course, is DFD style.

Tentative List of Requirements

The list of requirements below is one possible solution based on the interviews in Milestones 1 and 2. Students may combine some requirements; evaluate their thought processes in building the list. Pay careful attention to the classification. In your class discussion you might point out that functional requirements show up in the context model, while generally non-functional requirements do not show up in the context model other than to specify the actors that can do send or receive certain information.

Requirement / Classification
The system should allow technicians to view and edit hardware component information in the field. / Functional
The system should allow technicians to view and edit software configuration information in the field. / Functional
The system must make it easy for technicians to update the component and configuration information. / Non-functional
If system is not always online then need to replicate data between master database and copies. / Non-functional
The system should allow clients, technicians, and the receptionist/bookkeeper to submit service requests. / Functional
The component and configuration parts of the system should not be online. / Non-functional
The service request part of the system should be online. / Non-functional
The service request part of the system should have adequate security. / Non-functional
Clients, technicians, and management should be able to view unresolved service requests and the history of work performed on them. / Functional
Techs should be able to enter work performed on a service request / Functional
Only techs should be able to enter work performed on a service request / Non-functional
Techs should be able to enter new equipment to the system. / Functional
Only techs should be able to enter new equipment to the system. / Non-functional
Techs should be able to mark a service request as resolved / Functional
The system should be able to mark as service request as resolved if nothing more is heard from the client after the passage of a set amount of time / Functional

Prepared by Gary B. Randolph for

Systems Analysis & Design Methods 7ed

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