Trade-In Portal - PHP Based

Functional Requirement Specification Introduction This specification contains the functional requirement for the IT BuyBack portal. IT BuyBack is an internet portal where customers can sell their used IT equipment to us. Normally we will only buy larger quantities, but that all depends on what kind of products the customer wants to sell and at what price. We want to establish a portal where customers can get all the necessary information about our BuyBack and Donation programs so they fell prepared and save when they are going to hand over their used equipment. The customer must be able to submit product information by selecting predefined values online in an easy and straightforward manner, and then get a fixed price from us when we have processed the inquiry(so we don’t want any automatically evaluation in the first phase). Some of the keywords that define the IT BuyBack concept are: § Environmental responsibility § Donation § Financial benefit § Easy disposal § Secure data erase Functional Requirements General 1.1 We need full legal rights and ownership to all source code, prototypes, documentation and other material created, which must be delivered as part of this project. If the source code for any program or binary file can not be delivered, expressively notice must be given as part of the proposal. 1.2 Any source code developed as part of this project may not be used by the vendor in any circumstances or situations than in this project without written permission from GI. 1.3 If a runtime error occurs during production based on a user’s action, then the user must see a “user-friendly” error page and not a detailed technical page. Full stack-trace and any necessary information in order to reproduce the error must be stored so the error can be fixed based on this information. 1.4 The client must support IE v. 5 and NS v. 4.6, with the default settings. It must also be supported on a computer running Windows XP SP2 with maximum security level. 1.5 All system requirements must be part of the proposal. 1.6 The proposal must contain a complete reference to which technology, architecture and platform that will be used for the project. All standard software that might be part of the project must also be specified in the proposal. Content Management System (CMS) 2.1 The site must either be build around a CMS system or have CMS functionality to administer web-pages, “menu structure”, leading text(“field” captions), etc. 2.2 The CMS must support multilingual sites and the following must be supported as a minimum: 1) Pages can be translated by the user 2) Menu items can be translated by the user 3) Leading text(“field” captions) in dynamic pages can be translated The default language is English. If a page/menu item/leading text, etc., is not translated it must be possible to mark the items that the English version should be shared and used if the user selects another language. If the item is not marked then the item is not displayed to the user. 2.3 The content on the site must be editable by us in a WYSIWYG editor. We must be able to edit all the languages that is activated (it is not required that we can activate a new language our self. Though this need to be possible without programming). 2.4 We must be able to upload pictures and other files (as PDF documents etc.) so they can be used in the WYSIWYG editor. When we select the button for “Insert picture” in the WYSIWYG editor we must be able to upload pictures and other files. 2.5 We must have a description on the functionality available in the WYSIWYG editor 2.6 If the CMS contains any publication flows we must have a description on the flows or functionality available. 2.7 If the CMS contains any templates we must have a description/demo of the functionality available. 2.8 We must be able to add new menu items in the menu structure that is implemented on the site. 2.9 When a page is created in the CMS it must be possible to enter a page title that must be show on top of the page in the “title area” and with a predefined style. This page title field must not be mixed with the actual content field of the page. The page title field must be multilingual. Pages and Navigation 3.1 The site must contain a basis navigation bar in a predefined area of the screen. From this bar the following menu items must exists: 1) Login (dynamic section) 2) Register (dynamic section) 3) Get a free quote (dynamic section) 4) Donate (static page) 5) How it all works (static page) 6) FAQs (static page) 7) Contact (static page) 8) Terms and conditions (static page) The above structure may change as the design is not fixed yet. All the web forms that user interact to input data must be validated for > Data Types > Data Length > And any the business rules that can be validated at client side. 3.2 The “Login” page/section When the user accesses this page or section he can login with a username and a password. If the login is successful one of the following happens: 1) If the user was transferred to the login page as part of some process (ex. maybe he choose to login instead of creating a new account when he was submitting his inquiry), the process must continue without the need of re-entering any data. 2) If the user pushed the Login button in the login section/box then he must be sent to the front page of the site No matter which of the above, the user complete name must be written in the top-left login-section of the screen as seen on Figure 2. In order to login, the user must enter his login name and password which must be validated through the database. 3.3 The “Register” page/section This page allows the user to create a new company account. When he creates an account he can fill out the following fields: Fieldname Length Required Comment First Name 30 Yes Middle initials 3 No Sur Name 30 Yes Title 20 No E-mail 80 Yes The e-mail must be validated for a correct format. This is also the loginname on the site. Password 20 Name 30 Yes In the company section Address 30 Yes In the company section Address 2 30 Yes In the company section Post Code / ZIP 10 Yes In the company section City 30 Yes In the company section State 10 No In the company section Country XXX Yes In the company section. This must be a drop down. If the current language is Danish then this must be defaulted to Denmark. VAT No. 20 Yes In the company section Phone No. 20 Yes In the company section Fax No. 20 No In the company section Home Page 80 No Subscribe to Newsletter 1 No Boolean field If one of the required fields is not filled out the user is notified about which fields that is missing, and he must fill the fields before the registration is complete. When the user is successfully registered he is directed to a page that says that the registration was successful. At the same time he is logged in. This page is a static and the content must be maintainable from the CMS. Every field must have a caption that is multilingual and is maintained in the CMS. All customer registrations must be sent to a predefined e-mail address at GI, and they must be stored in a database that has an admin. GUI that GI can access and view the customers. 3.4 The “Get a free quote” page/section This section is described in the Inquiry section later in this document. When the products are submitted all the values etc. must be stored in the database. Inquiry 4.1 When the user want to inquiry one or more products, he must submit all details regarding these products to us and whatever he want to ship the products or want us to pickup the products. All inquiries must be sent to a predefined e-mail address at GI, and they must be stored in a database that has an admin. GUI that we can access and view the inquiries. The Main inquiry flow is illustrated in Figure 3 The process of the customer creating a new inquiry is described in the following: 4.2 The user is presented with a page that is part dynamic and part static. The top part of the page is static and maintained in the CMS. Below this part a list of available product types that we do offer to buy back (this must look like this page [login to view URL] under the headline “Trade-In Estimators”. See Figure 2. When the user clicks on one of the products then following page is displayed. 4.3 The user is requested to enter the information about the product that he wants to sell. Like the previous page, this page has a static top part and a dynamic part thereafter. The top part of the page must be maintained in the CMS. The dynamic part has the following fields: Fieldname Length Required Comment Product Description 100 Yes Quantity 5 Yes Between the two fields above, a list of user specified fields are displayed based on the product type that the user selected on the previous page. These fields are all specified by the administrator and can have the following type: 1) Text 2) Dropdown 3) Checkbox Through the admin. GUI the administrator will specify which fields that the user needs to input with information on which product category. This page is illustrated in “Figure 1”, but must only be treated as a design draft and therefore not the final design. When the user submits this page the following page is displayed. 4.4 A new page that is static in the top and dynamic in the bottom is displayed. The static part of the page is maintained in the CMS and the dynamic shows all the product information just entered. From this page the user can either push a button to enter a new product which brings him to step one, or he can choose to send the inquiry to us. If he selected to send the inquiry to us and he is not logged in, then he can either choose to login or to register for a new account. After that he the following page is displayed. 4.5 A new page that is static in the top and dynamic in the bottom is displayed. The static part of the page is maintained in the CMS and the dynamic contains the following: 1) A bottom and text that says something like “I want to handle the shipment of all the products”. 2) A list of pickup addresses where the user can select the address where he want us to pickup the products. The user must also be able to edit or delete these addresses. He must also be able to add a new address. The functionality of this list of addresses etc. is best illustrated on Amazon ([login to view URL]) when you select your shipment address. After this is completed the following page is displayed. A pickup address must contain the following fields which is editable when the user creates a new or edit a pickup address, and must also be shown in the page where the user can select the pickup address: Fieldname Length Required Comment Name 30 Yes Address 30 Yes Address 2 30 Yes Post Code / ZIP 10 Yes City 30 Yes State 10 No Country XXX Yes This must be a drop down. It must be defaulted to the language that the have already been selected for the company. Phone No. 20 Yes Fax No. 20 No Contact Person 30 Yes 4.6 A new page that is static in the top and dynamic in the bottom is displayed. The static part of the page is maintained in the CMS and the dynamic contains all the products that the user has added and the information about wheatear he will ship the products to us or if we needs to pick them us and if so from which address. The user must submit just one button that sends the inquiry to us. After this the following page is shown. 4.7 A new static page is show that is maintained in the CMS. This page will just confirm that the products have been submitted to us. 4.8 When the user has added one or more products to inquiry but not yet send the final inquiry to us, there should be a fixed area on the screen where the user can see his inquiry. This should be done by showing the last product he added to his inquiry and then with a link to see all inquiries. This should work similarly to Amazon when you have more items in your shopping card. This is also illustrated in a simple manner in “Figure 1”. The products that the user has added to his inquiry basket must be stored in his session variable. When the user want to see all the products that he currently have in his “Inquiry basket” the following page is displayed. 4.9 The “Inquiry basket” page that is static in the top and dynamic in the bottom is displayed. The static part of the page is maintained in the CMS and the dynamic shows all the products that are currently being inquired. The dynamic part must be a list of these products and display the “Product Description” and Quantity. It must be possible to delete a product inquiry (the user need to confirm the deletion by pressing OK on a dialog (the text in the dialog must be maintained in the CMS), before the deletion is executed), and edit the inquiry. When the user edits a product inquiry the page in Req. # 4.3 is used, but with the saved values pre-filled. Administration 5.1 Inquiry: Product category The administrator must be able to define which product categories that the users can inquiry. See figure 2 for 8 product categories. For each product category he must be able to enter a description (ex. “PC DESKTOP”, MONITOR, etc.) and select a picture that is displayed above the description (the design is not yet fixed so changes may occur to this). For each product categories the administrator must define which product information (attributes/properties) that the user need to enter when he submits an inquiry. The administrator must be able to define an unlimited number of attributes/properties and the associated values for each product category. The administrator must be able to edit and delete these attributes/properties and the associates values as well. Examples: Product information for “PC DESKTOP” Code Description Sort Order Type Values MFG Manufacturer 1 Dropdown IBM, HP, SIEMENS, DELL, (etc.) CPU Processor 2 Dropdown Pentium II, Pentium III, Pentium 4, Celeron, Xeon, Other… CPU_SPEED Processor Speed 3 Dropdown 1.0 – 1.5, 1.6 – 2.0, 2.0 – 2.5, 2.6 – 3.0, 3.1 – 3.5 MEM RAM 4 Dropdown 128MB, 256MB, 512MB, 768MB, 1024MB, 1280MB, 1536MB, 1792MB, 2048MB HDD Total HDD Size 6 Dropdown 5GB – 10GB, 11GB – 20GB, 21GB – 30GB, 31GB – 40GB, 41GB – 50GB, 51GB – 60GB, 61GB – 70GB, 71GB – 80GB, 80GB – 100GB, 101GB – 120GB, 121GB – 160GB, 160GB – 200GB, 201GB – 250GB, 251GB – 300GB, 300GB – 400GB, More FIREWIRE Firewire installed 7 Checkbox (the user checks this field if firewire is installed in the computer) NIC Network adapter 8 Checkbox (the user checks this field if a network adapter is installed in the computer) WIN Certificate of Authenticity 9 Checkbox (the user checks this field if the computer has a “Certificate of Authenticity” label (a license for Windows comes with the system)) COMMENT Comments 10 Text (the user can input plain text) 5.2 Inquiry: Submitted inquiries The administrator must be able to select if he wants to see all inquiries. This list must contain the following fields: Inquiry Number, Customer Name, Customer Country, Number product he wants to inquiry. All inquiries must be sorted descending by the date they were created. When the administrator select an inquiry from the lists above he will see the actual inquiry with all its information. 5.3 Customer The administrator must be able to select if he wants to see all customers. This list must contain the following fields: Customer Number, Customer Name, Customer Country and Number of products he has inquired. All customers must be sorted descending by the date they were created. When the administrator select a customer from the lists above he will see the actual customer with all its information. He will also see a list of all inquiries this customer has made. 5.4 Content Blocks Content Blocks are small information “blocks” that can appear on every page on the site (ex. “Figure 2”: “Worried about your data?” and “Red Cross brings the technology”). Each can be related to the main page(ex. the page “Register”, “Home”, “Contact”, when the user fills the product attributes/properties, etc.). The blocks must be displayed on a fixed screen area (in Figure 2 it is on the left but this will properly change when the design is completed). We must be able to create unlimited number of blocks for every page. Each block must have the following: • Title: “Red Cross brings the technology”? • Picture: The truck in Figure 2 • Small text: “In the last 2 month Red Cross has been donated 250…” • Content: The content appears when the user push the “read more” bottom and the content is edited in a WYSIWYG editor. Each block must be multilingual. All blocks must be maintained in one place – in a “block list”. On every CMS page it must be possible to select which blocks that shall be displayed and at what time. Even on a block content page (the page that appears when you push the “read more” of a block), it must be possible to add new blocks that are displayed. Also on every dynamic or part dynamic page is must be possible to select which blocks to display. Figure 1 – “Get a free quote” Figure 2 – “Get a free quote” Figure 3 – “Main Inquiry Flow”