SADM 7/ed – CASE STUDY CTTS – Milestone 2: Solution
Page: 2-1
MILESTONE 2 - PROBLEM ANALYSIS
 Problems, Opportunities, Objectives, and Constraints Matrix.
he matrix 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.
T
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 – CASE STUDY CTTS – Milestone 2: Solution
Page: 2-2
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
Problem or Opportunity
1.
2.
The current system does not
accurately track configuration
information, leading to wasted time
for technicians and clients.
The current system does not
accurately track installed
components, leading to wasted and
non-billable extra trips to the
customer’s place of business.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 7ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
SYSTEM IMPROVEMENT OBJECTIVES
Causes and Effects
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.
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.
System Objective
1.
Create a searchable database of
configuration information.
2.
System should be easy to update in
the field.
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.
System Constraint
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.
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.
Copyright Irwin/McGraw-Hill 2007
SADM 7/ed – CASE STUDY CTTS – Milestone 2: Solution
Page: 2-3
CAUSE AND EFFECT ANALYSIS
Problem or Opportunity
3.
4.
The proposed system could allow
clients to enter service requests
online, saving receptionist time plus
providing more efficiency.
The proposed system could provide
a customer history that would allow
for better service.
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 7ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
SYSTEM IMPROVEMENT OBJECTIVES
Causes and Effects
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.
Would allow technicians to see
what other technicians had done.
2.
Would lead to better customer
satisfaction.
System Objective
System Constraint
1.
Create Internet application in which
clients can enter their own service
requests.
1.
Internet application must have
adequate security.
1.
System would allow technicians to
record notes on work done on
service requests.
1.
Internet application must have
adequate security.
2.
Technicians and client could see
service request history.
Copyright Irwin/McGraw-Hill 2007
SADM 7/ed – CASE STUDY CTTS – Milestone 2: Solution
Page: 2-4
 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.
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 – CASE STUDY CTTS – Milestone 2: Solution
Page: 2-5
 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
The system should allow technicians to view and edit hardware component
information in the field.
The system should allow technicians to view and edit software configuration
information in the field.
The system must make it easy for technicians to update the component and
configuration information.
If system is not always online then need to replicate data between master database
and copies.
The system should allow clients, technicians, and the receptionist/bookkeeper to
submit service requests.
The component and configuration parts of the system should not be online.
The service request part of the system should be online.
The service request part of the system should have adequate security.
Clients, technicians, and management should be able to view unresolved service
requests and the history of work performed on them.
Techs should be able to enter work performed on a service request
Only techs should be able to enter work performed on a service request
Techs should be able to enter new equipment to the system.
Only techs should be able to enter new equipment to the system.
Techs should be able to mark a service request as resolved
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
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 7ed
by J. L. Whitten, L. D. Bentley, & K.C. Dittman
Classification
Functional
Functional
Non-functional
Non-functional
Functional
Non-functional
Non-functional
Non-functional
Functional
Functional
Non-functional
Functional
Non-functional
Functional
Functional
Copyright Irwin/McGraw-Hill 2007