Databases Reference
In-Depth Information
Chapter 3
Identifying the Problem
and Designing the Solution
Every computer system is (or at least should be) the result of solving some type of problem. Although “Hello World”
apps are great, we firmly believe that the best way to learn any technology is to apply it to a real problem and see how
things actually work.
We adhere to that principle throughout this topic. This chapter discusses a very common problem in most
organizations that can be solved technically. You also look at some of the detailed things you need to consider when
designing web-based systems in general and APEX specifically.
Identifying System Requirements
Almost every company, no matter the size, will at some point need to implement some sort of help desk. Whether it's
an internal one to track employee questions and problems or an external one to track client issues with commercial
software or hardware, the basics of a help-desk system are fairly standard.
Most help-desk systems are driven by the notion of a
trouble ticket
or
ticket
. This term is a leftover from the
days before computers: most problems were reported over the phone, and troubleshooters used a physical paper
ticket to log a call. The information contained on that paper ticket included a description of the problem, the person
having the problem, when the problem was logged, and so on. Then, throughout the process of troubleshooting and,
hopefully, solving the problem, the engineers wrote down each step of the process and included any documentation
of the problem they gathered along the way. Today, it would be very surprising to see a help-desk system that wasn't
computerized, even if it's only a spreadsheet of issues with notes and statuses.
In this chapter, you attack the help-desk system with APEX. Before you dive in, you need to clearly understand
the problems you're trying to solve. If nothing else, you need to review the current system.
Never a Clean Slate
Almost no computer system written today starts from scratch. There is almost always something in place, even if it's
just some loose guidelines or ideas.
For this example, let's say your company has a very basic system in place, but it's no longer meeting the needs
of your growing user community. Your goal is to create a new system that will make the logging of issues and their
solutions much easier for everyone involved; however, to do that, you must understand the needs of the users and the
functionality of the system that is in place now.
