Identifying the Problem Domain

The first step in designing an application is determining the needs of the application. This starts by identifying the boundaries or domain of the problem the application will solve. The better the domain of the problem is understood , the more accurate the class design will be. A frequently encountered problem is when developers dive into coding an application before they fully understand what needs to be done. This, invariably, leads to more time being spent modifying and refactoring the application. To properly understand the domain, we need to begin by understanding the business requirements.

N OTE

As was discussed in Chapter 8, refactoring is the process of revising parts of the plans, designs, or code to address new needs not earlier known. As we will see throughout this chapter, it is inherently cheaper/faster/easier to refactor the application while still in the planning and design phases than it is after the code has been written.

Business Requirements of the Application

XYZ Subscriptions is a magazine subscription wholesaler that has been in business since 1990. When they first opened, they used a Visual Basic Application tied to an MSSQL server to enable their call center representatives to take orders over the phone. In the late 1990s, seeking to reduce costs of deploying updates and fixes to the system, they decided to invest in an HTML/ColdFusion, browser-based intranet. They did this so that the software would be distributed and there would be no need to have a desktop support person constantly installing updates on all the PCs.

For each magazine, there are one or more subscription offers available. Each offer consists of a magazine for a particular duration. Subscriptions with a longer duration will have greater discounts over the single issue price (the price a reader would pay at the news stand).

In addition to facilitating customers signing up for a subscription, a few other features have been requested :

• A Data Entry Representative (DER) needs to be able to enter information about new magazines XYZ Subscriptions will be selling.

• A Subscription Manager (SM) needs to be able to create new subscription offers, associating a magazine, a number of issues, and a price.

• A Phone Center Manager (PCM) needs to be able to monitor and review transactions of each call center representative to determine the effectiveness of the rep's performance. The performance will be judged based on the number of calls a rep handles per day, as well as how successfully each call is handled.

With these loose requirements in mind, a use case diagram and domain model can begin to be assembled to begin determining how to best solve the challenges.

Before a solution can be defined, we need to understand what problem is being solved . In the case of XYZ Subscriptions, they have an existing application. The fact that they are looking to replace it indicates the existing application does not meet their needs.

Understanding the Failing of the Current System

With the upgrade of their system from a VB-based, client/server application to a browser-based intranet system, XYZ Subscriptions was able to save significantly on the cost of keeping the most current software installed on all the employees ' machines. However, along with this savings came a new liability: the productivity of the Call Center Rep (CCRs) has dropped significantly with the browser-based system compared to their productivity with the client/server application.

On further analysis, it seems the loss in productivity is largely due to the page-based nature of the application. The reps type in a bit of information, submit it to the server, and wait for a new page to be sent down to them. While the wait times for the pages are not large, the fact that they are forced to stop all entry and wait until the next screen loads has cut into their productivity.

With the client/server application, as some data was being sent to the server, reps were still free to continue entering data into the interface. With that original system, the average call time for a CCR entering a new subscription was 150 seconds. With the browser-based system, the average call now takes 210 seconds.

While an extra 60 seconds may not seem significant, the average number of calls handled by a CCR has dropped from 20 an hour to 14 an hour . While each CCR is handling fewer calls, the overall call volume to XYZ Subscriptions has not diminished. Therefore, XYZ Subscriptions has had to incur the additional expense of bringing in more CCRs and training them.

Further exacerbating the situation is the fact that the executives of XYZ Subscriptions have a business plan to increase the business (and therefore the number of calls) by an additional 20 percent. The fear is that the extra costs needed to hire and train additional CCRs, combined with the marketing efforts that will drive the increase in business, might outweigh the added revenue.

Enhancing Productivity of the Application

The chief technical officer of XYZ Subscriptions has been reading about Rich Internet Applications (RIAs) and believes they may be able to solve the problems of XYZ Subscriptions. By migrating the existing browser-based application to an RIA, he believes that the delays seen by the page-based nature of the Hypertext Markup Language (HTML) solution can be mitigated. They will no longer need to wait for a page to load. The client and server can exchange data seamlessly, without interrupting the CCR's ability to continue entering details about the transaction for a customer.

The intention is to return to the productivity the CCRs had with the client/server application, yet not add back the costs associated with the distribution of that software.

Challenges of a Call Center

The call center application needs to be multi- faceted . The requirements previously stated define a system with four distinct types of users, each of which is likely to require a different set of interfaces. However, there are likely to be some commonalities across the interfaces. For example, consider the following requirements:

• If a caller asks the CCR a question about a particular magazine, the CCR needs to be able to look up details of the magazine to relate the information to the customer.

• The DER will also need an interface to look up and review the details of a magazine so that he or she can determine if it was entered correctly and make modifications if it was not.

• The SM will also need an interface to review magazines, which can be useful as he or she assembles offers.

So, while these three users of the system will each have different ways to reach the magazine lookup screen, they will all access the same screen. Equally, both the CCR and the Call Center Manager (CCM) will need to be able to look up customer records. The CCR will need this to add new subscriptions to existing customers, while the CCM will do this as part of the auditing process. Should they find that several customers cancel their subscriptions after talking to a particular CCR, they may need to look deeper into the CCR's overall performance.

While the two screens described ”the Magazine lookup screen and the Customer lookup screen ”are not the only places where different users will access the same screens, they certainly give the impression that this will be best built as a single unified application, as opposed to four discrete applications.