Detailed
Design Document Department of Computer
Science Page maintainer: Terrence
Asgar-Deen |
This section addresses the concerns that the customer group expressed in the document titled "Overall Design Document". The concerns are listed below along with dHACs Software responses and clarification. Any questions that concerned the written content of the the document are not listed here. All the corrections have been made in the document. These responses detail information on higher level questions and concerns in the system. For example, missing elements in the data dictionary have been corrected.
1. An order without a product on it wouldn't be an order at all.
Orders are now correctly defined to have one or more products associated with it.
2. As was said earlier, the administrator also enters a password to get into the system. The process above only deals with salespeople. How does the administrator get its password?
This problem has been clarified in the Detailed Design Document. For more information, see the section entitled The User.
3. Office phone number is used here. But in the description under the entity relationship diagrams, home phone number is listed. Which one can be expected?
This was a mistake in the original specification. Office phone number is now used consistently throughout the document.
4. For the input of a new customer, how is a unique customer ID number generated? Should it be generated by the system record rather than input by the Administrator?
All unique IDs are generated by the system.
5. Will the company name be a second search key?
All fields in the system will be searchable.
6. Can only the company name be input to delete customer? (If there is a duplicate name then prompt the user to enter the customer ID).
Sort of. In most cases, deletion of a customer, or any data item, will be completed though a list of customers. This will remove the ambiguity of deleting a customer that does not have a unique company name. dHACs has found that one of the deficiencies with this design specification technique is that it does not clearly define user interaction with the system in a graphical user interface.
7. Shouldn't the datastore, "Order" be checked to see if there are outstanding orders for a customer before deletion?
Yes. This has been updated for other deletions as well.
8. Security dictates that this is available to administration and other top level people only and not the general user. (Exit)
This issue has been corrected. Any user may logout of the system. Only administrators can exit the program.
9. What is the default listing when the screen appears? Preferably it should be a listing of all customers for the Administrator, and the route listing for the Salesperson.
This is the current scheme.
10. Does the Full Customer listing display the Salesperson that handles that customer, or do you need to list by Salesperson to get that? Again, preferably it should contain the Salesperson in the listing.
The customer listing always displays the salesperson that handles that customer.
11. When "prompted for a Salesperson", does it bring up a list of the salespersons for you to pick from, or does the user need to remember the salesperson's ID or Name? And which is entered? ID or Name?
The user is required to select the name from a list of salespeople or enter the salesperson's user ID.
12. Also, an inactivity timer logout would be useful.
This was consider, however, due to time constraints, this functionality will be implemented in a future release.