Design Specifications

You learned in Chapter 1 and again in Chapter 13 that before you ever write a single line of code, you should carefully plan your application on paper. After detailed fact-finding regarding the purpose of the customer service application, you come up with a list of requirements. The application will be designed for use by customer service agents who receive incoming calls from customers. The application will allow the agent to retrieve the customer’s account information quickly based on one or more pieces of information provided by the customer. For example, the customer may provide all or part of a home phone number, a first and last name, and/or a customer number. The Search screen will allow the agent to retrieve the customer’s account record. The Search screen will implement ad hoc queries against the SQL Server database based upon the search criteria input by the agent. After the customer record is located and selected, it will be displayed containing such information as customer contact information, current service plan, and transaction history. Users also need the capability to open the View/Manage Customers screen independently of the search screen for all customers, not just for the selected customer.

Three use cases are shown in Figure 14-1. Users can execute a search to locate a particular customer (U.C. 1.1). Users can also clear the search results (U.C. 1.2). In addition, the application enables the user to open the View/Manage Customer Details screen for a selected customer (U.C. 1.3).

Figure 14-1

From the View/Manage Customer Details screen, you determine that the user should be able to view and manage customers using record navigation and update capabilities. However, users should not have the ability to delete user accounts, so we will not make that part of our use cases. Figure 14-2 shows these features represented in a Use Case Diagram.

Figure 14-2

Five use cases are shown in Figure 14-2. Users can open the View/Manage Customer screen for a selected customer (U.C. 2.1). In addition, the application will enable the user to update existing (U.C. 2.2) and add new (U.C. 2.3) records. Navigation buttons are provided (U.C. 2.4) to allow the user to navigate among the records. These buttons are useful when the screen has been opened to view and manage all customer records (U.C. 2.5).

As you learned in Chapter 1 and again in Chapter 13, you have other ways to document the application, including activity diagrams, flow charts, network diagrams, and object diagrams. When you analyzed the requirements previously discussed, you determined that two main screens seem to make sense: a Customer Search screen and a View/Manage Customer Accounts screen. These designs are illustrated in Figures 14-3 and 14-4.

Figure 14-3

Figure 14-4

Figure 14-3 is a prototype screen for Customer Search. Notice how various data elements related to the customer are included, as well as Search and Clear buttons. The Search button allows a user to search the database for customer records that match the criteria specified in one or more fields. The matching is based on both partial and exact matches to make it quicker for the customer service representative to locate the correct record. The matching customer records are displayed in the Search Results list. If the user double-clicks a record in the Search Results list, the View/Manage Customer Accounts screen will appear for that selected customer.

Figure 14-4 is a prototype screen for View/Manage Customer Accounts. Various data elements related to the customer are included, such as name, address, and contact information. Navigation buttons plus buttons for saving changes to records are also included. Now that you have documented what you want the application to do, you can move on to creating the database and the code.