Requirements Analysis

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