Countertop Estimator Requirements Analysis, Design & Testing Plan Northwest Fabricators Gig Harbor, Washington July 24, 2003 Table of Contents Requirements Analysis ................................................................................................................... 1 Use Case.......................................................................................................................................... 3 Design ............................................................................................................................................. 5 Conceptual Implementation Design ............................................................................................ 5 Conceptual Database Design ...................................................................................................... 6 Extended Implementation Design ............................................................................................... 7 Testing Plan .................................................................................................................................... 8 ii Requirements Analysis The following text depicts the requirements that the system must meet for completion. These requirements represent both a collection of requirements set forth in initial requirements gathering and suggestions made to date. The requirements set forth in no way are to be added to nor taken away from. The application will function under a drag-and-drop premise. Any combination of the 4 Basic countertop shapes will be provided for estimation, which are as follows… Rectangle U-Shape L-Shape G-Shape System will rely on outside variable information read in from a structured database. Items found in the database will include the following o Product lines o Colors for corresponding product lines o Color Category Pricing o Edge treatments o Sinks for corresponding product lines o Ranges o Company information o Miscellaneous variables such as Labor Cost, Retail Margin, Tax, etc. o Comparable Color selection System color scheme will be dependent upon variables read from the database; this will additionally include various company logos to be used both on the screen and for printing. In this way the application can adapt itself to the look and feel of the company that is currently using it. 1 Estimate different prices based upon color from within 5 different product brands which are as follows o Staron o Corian o Avontite o Gibralter o Formica Application will have the capacity to add and estimate sinks to the job based upon the product line of the currently selected color. In the event that sinks have already been added and the user switches product brands the current sinks within the canvas will be deleted and new sinks dependent upon the currently selected product brand will need to chosen. Estimate different prices dependent upon back splash type. Estimate different prices dependent upon varying edge profile treatments. The user will be presented with a toggle button that allows them to select edges that are to be profiled. The application will color the newly selected edges to indicate that they have been chosen as such. Edges not selected will be treated as the currently selected back splash type. The algorithm for estimation of the new countertop will be based upon the following A - Material Cost sq/ft B – Labor Cost sq/ft C – sq ft per width D – Number of linear feet ( A B) C D The user interface will have a “snap to” characteristic in some increment not yet determined to potentially ease the resizing feature of the application. There will be a button provided which will clear the current canvases of all shapes and allow the user to begin the process over again. The ability to remove a single object will be provided by first selecting the object to be removed and then pressing a delete single item button. A timer for inactivity whose firing length will be determined from a value in the database will clear all the canvases. If the timer is set to a value of 0 or less it will be interpreted as the application not desiring to take advantage of this feature. A Boolean variable will be provided within the database to determine whether or not the application is to be used in a kiosk setting or rather a dealer setting. The primary difference will dictate whether or not the user will be allowed to close the program and slight differences in the features that are allowed to either such as changing color outside of the default product line, etc. A Boolean variable will be provided in the database to dictate whether or not a keyboard will be present to the user. The only difference this will change is whether or not a Keyboard interface will be presented for textual input. The system will have the ability to print itself in a pre-formatted fashion. No printing options will be allowed. Printing will only occur after specific user information has been filled out. The system will have the ability to save its current state in a unique file format that can later be opened by a similar system in a read only manner. 2 Use Case Primary Actor: User/ potential client and or Dealer with application experience Scope: Accurate retail estimate of countertop installation. Stakeholders and Interests: Owner of the software-wants to review layout of client’s countertop and follow-up with appropriate action. Preconditions: Dimensions of the finished drawing are accurate, edges to be profiled have been selected, and color has been selected Success Guarantee: The countertop estimate will be accurate and will include… Total cost of the job. Total cost of the current canvas All applicable information to each canvas, namely color, edge type etc. Main Success Scenario: In any order the following can happen User touches one of the predetermined countertop shapes o System updates the canvas to include new countertop layout User modifies current canvas pieces to desired dimensions, using a drag-and drop style interface o System updates dimensions of new layout based upon user motion along with estimated cost for the current state. User changes the color of the current canvas o System responds by changing the current canvas’s color and appropriately updates the estimated cost. If the color is changed outside of the current product line and there are sinks present on the canvas the system will delete the sinks on the current canvas and prompt the user with a reason for doing so. User changes the back splash of the current canvas o System responds by changing the current canvas’s back splash and appropriately updates the estimated cost. User changes the type of edge profile that the current canvas is to receive o System responds by changing the current canvas’s edge type profile and appropriately updates the estimated cost. User decides to select edge profile treatments; first they press the toggle button labeled something to the effect of “Select Profile Edges” o System responds by locking the current canvas into a state in which pieces cannot be moved or resized. For every edge the user touches the system colors the edge a different color to indicate that it has been selected as an edge that is to receive profiling. Should an already selected edge again be selected it will be unselected. In edge selecting event during this locked phase the system will update the estimated cost appropriately User decides to add a sink to the current canvas o System responds by placing an image representing the selected sink and waits for the user to move and or resize it. Additionally the system updates the cost of the canvas appropriately. 3 User decides to add a range to the current canvas o System responds by placing an image representing the selected range and waits for the user to move and or resize it. Additionally the system updates the cost of the canvas appropriately. User decides to delete the currently selected item o System responds by deleting the currently selected item and updates the estimated cost appropriately. If no item is currently selected then the system will take no action. User decides to delete the entire estimate and begin entirely new o System responds by first confirming the desire to delete the content from all of the canvases. Should the user still desire to proceed all canvases are cleared of their content, otherwise the confirmation disappears and the state of the canvases remains unchanged. User decides to enter contact information o System responds by capturing stored information User decides to print the estimate o System responds by printing the estimate in a pre-formatted fashion if and only if certain fields of the contact information have be filled out. If these fields are not filled out the screen from which to enter the information will appear. User decides to leave the system o If the system is left idle for a determined length of time the system will clear all canvases and wait for a new user. Special cases not pertaining to a kiosk Application User closes the program o System responds by closing, no information is stored 4 Design The following items depict the conceptual design from which the system will be constructed. It includes the following elements Conceptual Implementation Design Conceptual Database Design Extended Implementation Design Conceptual Implementation Design The following image is a UML representation of how the system will be constructed. It includes only class relationships, for a more comprehensive version of this Conceptual Implementation please refer to the Extended Implementation Design image. Estimator NotesCollector KeyboardGUI (f rom CountertopEstimator) (f rom CountertopEstimator) (f rom CountertopEstimator) PrintUtilities SaveUtilities (f rom CountertopEstimator) (f rom CountertopEstimator) CompanyInfo InfoCollector (f rom CountertopEstimator) (f rom CountertopEstimator) UserInfoCollector (f rom CountertopEstimator) RangeChooser DrawingObjectPainter (f rom CountertopEstimator) (f rom CountertopEstimator) Sink DrawingObject (f rom CountertopEstimator) (from CountertopEstimator) Range (f rom CountertopEstimator) EdgeChooser (f rom CountertopEstimator) UserInfo (f rom CountertopEstimator) BackSplashChooser (f rom CountertopEstimator) ColorChooser CountertopCanvas (f rom CountertopEstimator) (f rom CountertopEstimator) CostGenerator FeatureComponent (f rom CountertopEstimator) (f rom CountertopEstimator) Top (from CountertopEstimator) ProductBrand (f rom CountertopEstimator) ComperableChooser (f rom CountertopEstimator) ImageComponent (f rom CountertopEstimator) Perimeter (f rom CountertopEstimator) EdgeDimension (f rom CountertopEstimator) LShape UShape GShape RShape (f rom CountertopEstimator) (f rom CountertopEstimator) (f rom CountertopEstimator) (f rom CountertopEstimator) 5 Conceptual Database Design The following image depicts the structure of the “Products” database to be used in the system. This database will be used extensively to read in variables and images that will be used throughout the system. 6 Extended Implementation Design The following image depicts an extended form of the “Conceptual Implementation.” In addition to class relationships, the image includes the methods associated with each class. 7 Testing Plan Upon completion of the implementation phase the system will undergo an extensive testing period. This testing period is to last one week in duration beginning on August 8, 2003. The testing period is to be conducted by both key decision makers who are familiar with the estimating algorithm, as well as myself. At the beginning of the testing period the system will have already been installed on the clients computers so that they may test it from within their own working environment. During the testing period the following elements will take place: From a randomly selected countertop layout, one that takes into consideration the limits of the application (i.e. the countertop estimate cannot include a feature the application does not estimate such as rounded corners, lobbed edges etc.) the user will first estimate the countertop layout using the currently existing spreadsheet. The user will then progress by drawing the same countertop layout using the application to within a 1-inch precision of the desired layout. The user will note the following during this process: o Countertop layout being estimated o Estimate based upon spreadsheet o Estimate generated by the application o Difference of the two estimates to within a ± tolerance of some amount determined to be insignificant, should one exist. If this difference is considerably large a possible suggestion as to the cause will accompany. In the event of a system error or malfunction the error will be recorded, along will an accompanying description of the steps taken to arrive at it. This includes all Exceptions thrown and printed to the Command screen. Additionally all those involved in the testing period will scrutinize the User interface for possible areas of improvement. Notes will be taken to assist in the ease of use while operating the system. Suggestion will include: o Clarification of Button Text o Button Layout o Clarity of Message/Error Dialogs presented o Etc. Upon conclusion of the testing week a formal document will be generated depicting errors found within the system along with user interface improvement suggestions. Furthermore a document will be generated that outlines what changes the system will undergo according to both the errors found and suggestions made. This document will receive the signatures from both of the key decision makers as well as myself, affirming the project will conclude as soon as the items within the document have been completed. 8
© Copyright 2026 Paperzz