SADM 7/ed CTTS CASE STUDY - Milestone 2: Problem Analysis

Page: 2-1

MILESTONE 2 PROBLEM ANALYSIS

Synopsis heres an old saying that suggests, Don't try to fix it unless you understand it. With those words of wisdom, the next milestone of our project is to study and analyze the existing system. There is always an existing system, whether computerized or manual or some of both. The problem analysis phase provides the project team with a more thorough understanding of the problems, opportunities, and/or directives that triggered the project. Indeed, the analyst frequently uncovers new problems and opportunities. The problem analysis phase may answer the questions, Are the problems worth solving? and Is a new system worth building?

The purpose of the problem analysis phase is threefold. First and foremost, the project team must gain an appropriate understanding of the business problem domain. Second, we need to answer the question, Are these problems (opportunities, and directives) worth solving? Finally, we need to determine if the system is worth developing. The problem analysis phase provides the systems analyst and project team with a more thorough understanding of the problems, opportunities, and/or directives that triggered the project. In the process, they frequently uncover new problems and opportunities. In this milestone you will perform Cause-Effect Analysis and document your findings using the Problems, Opportunities, Objectives, and Constraints Matrix. The PIECES framework, originally developed by James Wetherbe, and then adapted by the authors, can serve as a useful tool to classify the various problems, opportunities, and directives identified in Milestone 1. Second, you will develop a Context Diagram to begin to understand the proposed system and whether or not it is worth developing. A Context Diagram looks at the system as a whole and how it interacts with the world around it. The third step in this milestone moves us from the problem analysis phase into the requirements analysis phase, which will be covered more fully in Milestone 3. You will make a list of system requirements and classify them as either functional or non-functional.

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 2: Problem Analysis

Page: 2-2

Objectives After completing this milestone, you should be able to:

Perform Cause-Effect Analysis to be able to thoroughly understand a systems problems, opportunities, and/or directives that triggered the project. Use and understand the PIECES framework for classifying problems, opportunities, and directives. Complete the Problems, Opportunities, Objectives, and Constraints Matrix. Create a Context Diagram for the proposed system. List functional and non-functional requirements for the system.

Prerequisites Before starting this milestone the following topics should be covered: 1. 2. 3. 4. The problem analysis phase Chapters 3 and 5 Problem analysis techniques Chapter 6 PIECES Framework Chapter 3 and 5 Milestone 1 Solution

Assignment Now that we have completed the survey of the system and gained approval to proceed, we can attempt to gain a better understanding of the current system and to evaluate whether the proposed system is worth developing. Activities
1.

To complete the Problems, Opportunities, Objectives, and Constraints Matrix, use the interview presented in this milestone. Use the PIECES framework as a model to classify the problems, opportunities, and directives. Create a Context Diagram of the proposed system, using the interview presented in this milestone and interview from Milestone 1.

2.

3. Create a tentative list of requirements for the proposed system, classifying each as a functional or non-functional requirement. Deliverable format and software to be used are according to your instructors specifications. Deliverables should be neatly packaged in a binder, separated with a tab divider labeled Milestone 2 and optionally accompanied with a Milestone Evaluation Sheet. References: Case Background Case Study Introduction Milestone 1 Solution Provided by your instructor
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 2: Problem Analysis Transcript of Interview with Peter Charles Milestone 1, Exhibit 1.1 Transcript of Client Technology Tracking System meeting Exhibit 2.1 Templates See on-line learning center website for the textbook. Deliverables: Problems, Opportunities, Objectives, and Constraints Matrix: Due: __/__/__ Time:_______ Context Diagram: Due: __/__/__ Time:_______

Page: 2-3

Tentative List of Functional and Non-Functional Requirements: Due: __/__/__ Time:_______ ADVANCED OPTIONS Write a detailed study report for the phase. This deliverable was not discussed in the narrative because students need to be exposed to modeling (data, process, and interface) before this report can be completed. For those ambitious individuals who are familiar with those skills and wish to be challenged, use the detailed study report outline found in Chapter 5 of the textbook as a guideline. Another advanced option is to develop one or more fishbone diagrams for problems outlined in the case. To complete this advanced option, you may need to make some assumptions about causes and effects. Study Report: Fishbone Diagrams: Due: __/__/__ Time:_______ Due: __/__/__ Time:_______ ____

Milestones Point Value:

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 2: Problem Analysis

Page: 2-4

The following is a transcript of a meeting of Anna Kelly (analyst/programmer), Kathy Grey (receptionist/bookkeeper), Doug Drake (system integrator), and Ben Logan (IT consultant). Exhibit 2.1 Scene: The meeting room at Coastline Systems Consulting. Anna Kelly has just greeted the other participants. Anna: OK. I feel a little funny being the most junior member of the team and leading this meeting. But Peter has asked me to lead a design project for a proposed customer technology tracking system. By technology tracking, I mean a system that would track each of the components installed in each of the computers and other devices at a client's business as well as track all configuration information. The system would do some other things also, such as allow clients to submit service requests and problems and track the progress of the request until it is resolved. I need your input to design the system correctly. I need you to help me (1) more fully understand the current system, (2) understand what we need in the new system and (3) document any constraints for designing the new system things that it either must do or must not do. Each of you has received a copy of the Request for System Services and the Problem Statement Matrix. Id like to start with problems in the current system. How does the present system work? Here's how it's supposed to work. We keep a three-ring binder on each client and place in it papers with all the configuration information. But it doesn't work very well. For one thing, the papers are disorganized so it is hard to find anything in it. But the information is never really complete anyway. By the time you finish a job, you don't have time to update the paperwork because another job is demanding your attention. Sometimes I make pencil corrections in the binder while I'm on-site. But after a while that just looks like chicken scratches. The word processing document never gets updated. And yet, without updated information at hand we end up spinning our wheels the next time we go out to that client. It's frustrating. It frustrates the clients, too. They see us out there not being prepared. They complain about the time it takes to fix problems. I can think of a couple of clients we may have lost because of it. What we need is a searchable database. A database system could solve the disorganization. But if we don't solve the updating problem, we still won't have a solution. Do you have any ideas on that? For the component tracking, I would suggest barcode scanning. Nearly every component we buy already has a barcode on it. Well, when we put a component into inventory, we would have to scan the barcode and manually record what kind of component it is a NIC, a video card, whatever.

Ben:

Doug: Ben: Doug:

Ben: Doug: Anna: Ben:

Kathy: How would that work? Doug:

Kathy: Checking things into inventory is my job. Would scanning be difficult?

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 2: Problem Analysis Anna: Ben: Doug:

Page: 2-5

It shouldn't be. It would probably save you time because of less typing. But it would be a small change in the check-in process. Then out in the field we could scan the barcode when we install the component. The system could pick up the system date automatically. Of course, you'd also need a barcode on the computer that it was being installed in. We would need to make sure we used barcoding on every piece of equipment. It would be as easy as select "install component" from a menu, then scan the computer's barcode, then scan the component's barcode, and "Bob's-your-uncle" you're done. Slow down, boys. Let's not write the code yet. But I think we're onto something at least for the component tracking. What about the configuration information? Peter talked about tracking usernames, passwords, IP addresses and port numbers, and web addresses. How does that system work now? That stuff is supposed to be in the notebook, too. But that has the same problems with completeness and accuracy. And the consequences are sometimes worse. If we lose a password, we may have to completely reset a router. That's a big time waster, and Peter doesn't want us to bill a client for things that are really our fault. So how do we fix that? Configuration information should be in the same searchable database. Well, we're a small company. We should be able to convince everyone that it is in their interest to invest the time in updating it. But, let's design the system so it is easy to update. For instance? For instance, we should have to wait until we get back into the office. The longer we wait the more likely it is that something else will take precedence. So we have a web-enabled database we can update from the client's place of business. Jack has already nixed the idea of having configuration and component information on the Internet for security reasons. Besides, some of that information we need while we are standing in a wiring closet or sitting under a client's desk or other places where the Internet isn't accessible. As Peter told me, we can't jump into implantation yet. But by way of an example, I was thinking about having an intranet application. In our office, it would run on our in-house web server and connect to a master database. In the field we would run in on our laptops with a web server running on the laptop and connecting to a copy of the database. Intriguing. You'd have to work out replicating, or updating, the data back and forth between the copies and the master. Maybe we could switch to tablet PCs to make data entry even easier. That's a possibility. What about the service request part of the system? What is the present system?

Anna:

Ben:

Anna: Ben:

Doug: Anna: Doug:

Anna: Ben: Anna:

Doug: Ben: Anna:

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 2: Problem Analysis

Page: 2-6

Kathy: Clients call in with reports of problems. Sometimes I can transfer the call to a consultant. Generally I have to send an e-mail. If the consultant is out on a call, it may be hours before the client gets a response. Sometimes the client calls back and I'll transfer them to whoever is available just so they feel that something is happening. That's when the confusion starts. Ben: Yeah, I can't tell you how many times I've come in and found an e-mail from Kathy on a problem but found out that Jeff or Doug or even Dane was already working on it. So as it is, before I start working on a problem, I need to ask around and make sure no one else is working on it. That sounds like a time waster. We need to eliminate that. Can this part of the system be on the Internet? Yes, Peter suggested it. He even wants clients to be able to enter their own requests.

Anna: Ben: Anna:

Kathy: Without calling in? That would be wonderful. But if they do call in, I'll still need a way to enter service request for them. Ben: Anna: Ben: And the techs should be able to enter service requests, too. Sometimes when we're on-site, clients tell us about other problems. Sounds good. The Problem Statement Matrix said something about maintaining the history of service on a problem. That would be great. I often follow-up on things Jeff worked on. I need to know what he did. That would make me more efficient. Good. That's what I need to cost justify this system. I have a suggestion on that. We really want the next available tech to take each service request unless there is a compelling reason to assign it to a specific tech. So let's just have all the techs view the open list, and they can take the next one. And they can view the history for any request from that list of unresolved request. Integrate the two functions together. Sure. I'll give it some thought. Sounds good. I'm sure Peter, as management, would want to view the open requests and their history, too. And clients should be able to view their own requests and history. And that brings up a point that the service requests part of the system will need security, too. We don't want someone flooding us with bogus requests. Or worse, what if someone hacked our database and messed up our data. I want this system to solve problems, not create more. Right. Make sure that only techs can enter work records and new equipment. And only techs should be able to mark a service request as resolved. Techs get so busy on new requests, they might forget to mark a request as resolved or to do the follow-up with the client to make sure it is resolved. Maybe we need a way for the system to automatically mark a service request as resolved if we don't hear anything more from the client after so much time.
Copyright Irwin/McGraw-Hill 2007

Anna: Ben:

Kathy: How are the techs going to know what service requests are assigned to them?

Anna: Ben: Anna: Doug:

Ben: Doug:

Prepared by Gary B. Randolph for Systems Analysis & Design Methods 7ed by J. L. Whitten, L. D. Bentley, & K. C. Dittman

SADM 7/ed CTTS CASE STUDY - Milestone 2: Problem Analysis Anna: Anna:

Page: 2-7

That's a good point. Let me give that some thought. Anything else we need to discuss? I know it would help me. Well that gives me plenty to work on. Id like to thank each of you for your time. I will be sending you a copy of my problems, opportunities, objectives, and constraints matrix, a tentative list of system requirements, and a context diagram fro the proposed system. Let me know if you have any comments or questions.

Kathy: If you can do all this, it would be great!

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