RecordTrader Requirements Analysis and Specifications - Deliverable C
1.1 Objectives

RecordTrader is an online marketplace focusing on the buying and selling of new and used records. Focusing on niche and specialty music genres, RecordTrader will give vintage and specialty record stores a platform to expand from their current local customer bases to an online global marketplace. Online shoppers can then search through all seller music listings on the RecordTrader site, communicate with sellers as well as discuss music interests and opinions with other buyers.

Goals
  • Aiding in sellers reaching a wider customer base.
  • Make rare items easy to find.
  • Easy access to product information.
  • Earn profit from each post that sellers list.
  • Reach customers that are in search of specialty and hard to find records.
Message
  • RecordTrader is the largest online marketplace to buy and sell your specialty and hard to find vintage music.
1.1.2 Content
  • Content for each listing will be submitted from the sellers. Information entered will be formatted to a formal listing on the website so it can be correctly accessed.
  • Home page
  • Wish list
  • Product details
  • Seller promotions
  • Blog
  • Forum
  • FAQs
  • Shopping cart
  • Registered user information
  • Delivery status
1.1.3 Structure and Interpretation
  • Buyers and sellers will find RecordTrader while searching for vintage records.
  • Customers can list their products for sale or purchases other products listed on the website.
  • Users can search the product listing in multiple ways.
  • Customers can register so they are recognized as a returning user. This will allow for the creation of a wish list and a quicker checkout process.
  • Users can join the online chat room or forum to discuss music or specific products.
  • Buyers can have an online chat with sellers that are available.
  • Buyers can view promotional information from sellers.
  • Buyers can view delivery status of their purchased items.
  • Buyers and sellers can interact with the site in a variety of levels to meet their specific needs.
1.1.4 Sensorial Design
  • RecordTrader will have a typical web layout with multiple search abilities.
  • The site overall will appeal to a wide variety of users and be easy to read with no dramatic color differences.
  • Patient buyers will be able to easily view prices and details of each product; even contact sellers if needed.
  • Product descriptions will be entered by sellers but will have a maximum length so the aesthetic is not taken away from the product pages.
  • There will not be much programming upkeep needed for this site once it is fully running though monitoring will always be needed.
1.1.5 Market Testing

RecordTrader will bring together buyers and sellers but the largest competitor for RecordTrader will be eBay. There are a variety of other online competitors but most lack the necessary user-centered features that will retain buyers and sellers for the long term.

1.1.6 Potential Challenges
  • Current competition
  • Reaching the needed niche demographic
  • Gaining trust of buyers and sellers
1.1.7 Strengths
  • Single site bringing together a wide variety of vintage records.
  • Large inventory due to having multiple sellers.
  • Contact current sellers to expand upon their listings.
  • Ability of buyers to contact sellers to get detailed information.
  • Chat room and forum for users to discuss music and specific items.
  • Ease of purchases and delivery tracking.
1.1.8 Opportunities
  • Expand upon quantity and quality of sellers.
  • Build strong loyalty base of buyers and sellers.
  • Connect to seller inventory database systems to allow for immediate information to be shown to browsers.
  • Market to a specialized set of buyers.
1.19 Target Demographics
  • Most users are expected to be from North America, Europe and Japan.
  • Buyers are expected be to be mostly male between the ages of 20 and 60.
  • Somewhat affluent buyers earning between 50k and 80k per year.
  • Sellers will be specialty music stores looking to gain or expand upon an online presence.
2 Impact Assessment
2.1 Impact Assessment
  • Registering name www.recordtrader.com
  • Maintain and build database that will hold data including customer info, order, seller info, buyer info.
  • Set up security for login, orders, customer data, seller info, and all other data’s.
  • Employee will have to meet the customer’s needs.
  • A social networking engine will be implemented.
  • The site will generate reports.
  • Secure payment systems.
  • Technical Support.
3 Implementation Strategy
3.1 Panning March 24 - April 29
  • Assigning team roles and their responsibility.
  • Create Project.
  • Develop Business Plan.
3.2 Analysis April 10 - April 25
  • Documenting user requirements.
  • Indentify test plans.
  • Indentify process flows.
  • Create wireframes.
  • Establish site structure.
3.3 Design April 25 - May 25
  • Create database design.
  • Establish the layout of the web design.
  • Create site prototype.
  • Testing application.
  • Integrate mobile ordering and chat features.
  • Modify site based on user testing results.
  • Revise and design.
3.4 Implementation May 25 - June 2
  • Create test environment.
  • Functional testing.
  • System testing of the entire site.
  • Beta testing with select target demographic.
  • Conduct load and performance testing.
  • Revise and retest site.
  • Ensure site development is brought to proper completion.
  • Final renew within the team.
  • Full implementation and launch the website.
4.1 Functional Requirements
  • The system shall permit a user to search all products by artist, genre, year-of-release, seller(s), condition, and price range.
  • The system shall allow provide sellers with an interface to add new inventory listings to the site using an html form.
  • The system shall provide sellers with an interface to make manual changes to inventory using an html form. For example, the seller wishes to increase the price of one or two items or withdraw a single item which is no longer for sale.
  • The system shall allow, but not require, customers to register and record personal information in a "profile" to speed checkout and record preferences.
  • The system shall allow a user to add, update and delete items in a shopping cart while on the site.
  • The system shall allow customers and sellers to record reviews of any individual product. Reviews shall be readily identified as either customer or seller generated.
  • The system shall protect user data such as password and credit card numbers using encryption.
  • The system shall display customer specific recommendations both on demand in a format similar to a search result and, one at a time, on each web page within a dedicated area on a rotating basis.
  • The system shall evaluate a registered customer's preferences, if any, and record of completed sales, if any, to tailor specific, relevant product recommendations to that customer.
  • The system shall provide sellers with on-demand reports for reviewing current inventory, reviewing sales for an arbitrary period, and reviewing audit trail of inventory changes.
  • The system shall store customer shopping cart data for both completed and abandoned sales. Cart data for registered users shall be attributable to the specific user. Cart data for unregistered users shall be attributed to an unspecified user known as "N/A"
5 Information Architecture

5.1.1 High level Site Map
High Level Site Map


5.2 High level Process Flows

5.2.1 Use Case Diagram
Use Case

5.2.2 Flow Diagram – Add New Seller Listing Add New Listing

5.2.3 Flow Diagram – Add Item to Shopping Cart Add Item

5.2.4 Flow Diagram – Advanced Search Add Item

5.2.5 Flow Diagram – Create New Account Create New Account

5.2.6 Flow Diagram - Edit/Update Item Listing Update

6 Interface Requirements/Specifications
6.1 User Interface

Our site has two main audiences, each with very different needs. Buyers are focused on browsing and buying and sellers are focused on presenting their wares for sale and determining what is selling and who is buying.

  • To support the disparate needs of the buyer and seller, the system should guide buyers to a buyer page and sellers to a seller page where each group’s needs are best fulfilled.
  • Music fans as buyers generally gravitate to one specific type of music. Therefore, the site will employ a product based marketing strategy displaying links to the most popular music genres. An “Advanced Search” capability will support search for these popular genres plus additional, less popular, genres as a means to broaden appeal.
  • Web pages shall be developed according to strict standards including the use of XHTML 1.0 compliant HTML and CSS to maintain a common look and feel across all pages.
Common navigation and layout throughout the RecordTrader site: Common

Buyers’ primary interaction with the site uses the following page: Buyer

Sellers’ primary interaction with the site uses the following page: Seller

Note the following toggling behavior for selected links:

  • The “Login” link toggles to “Logout” when a user logs in and the “Logout” link toggles to “Login” when the user logs out. Initial state is “Login”.
  • Similarly, the “Register” link toggles to “Your Account” upon log in.
6.2 Hardware Interfaces

Buyers will obviously demand acceptable response times to all of their requests. Sellers will appreciate 24x7 selling. Fulfilling these needs, in turns, helps maximize our profits as well as those of our seller partners. Consequently, our hardware must support 24x7 selling year round with acceptable response times even in the face of heavy loads.

  • Purchase robust, scalable servers for web, application, mail, and database servers.
  • Traffic to web server should be managed by load balancer.
  • Hardware architecture should support failover for web, application, mail, and database servers.
6.3 Software Interfaces

Software components such as a DBMS are essential. However, building a DBMS from scratch for internal use is not an option. Other components, such as sales tax management, are likewise essential but there is a choice. The choice is to build or buy. For the time being, we will assume that the buy option is preferable.

  • Connect to Microsoft Access. However, to facilitate any future migration to a more robust database and to support a more robust software architecture, all communication with the database shall use the Model-View-Controller design pattern.
  • Use web services to obtain shipping costs from vendors.
  • Use web services for sales tax calculation within the US.
  • Use web services to obtain payment approval for customer purchases.
  • Use web services to remit sales tax proceeds to a third party who will handle payments to various jurisdictions.
6.4 Communications Interfaces

All intra and intersystem communications shall be supported by products based on proven standards

  • Email server and software shall support standards such as SMTP and must include support of international character sets.
  • Web services interfaces must be based on one and only one standard such as J2EE or Microsoft .NET. We cannot risk using multiple standards. Furthermore, web services will be based on SOAP and XML.
7 Data Requirements

A survey of the business domain and functional requirements yields the following preliminary data stores. See the companion word document for Deliverable C for details of table columns.

  • SELLER_ESTAB – Seller Establishment
  • COUNTRY_TBL – Countries in which we do business
  • STATE_TBL – States in which we do business
  • SELLER_CONTACT – Contacts at Seller’s Business.
  • SYS_SECUITY_QSTN – Questions used to authenticate password reset requests.
  • SELLER_PHONE - Phone numbers at seller
  • SELLER_INFO – HTML authored by SELLER for display on our site
  • SELLER_SHIP_VENDOR - Shipping vendors and modes used by seller
  • SELLER_PROMO - Promotions
  • INVENTORY - Product Inventory
  • PRODUCT_TYPE - Type of product
  • SHIP_PROFILE - Shipping profile used to determine shipping costs
  • CUSTOMER - Base info for registered customers
  • CUST_ADDR - Customer Addresses
  • CUST_PYMNT_TYPE – Customer Payment Instruments
  • CUST_PREFERENCE – Customer Product Preferences
  • CUST_PROMO_LOG – Log email promos sent to customer and online promos clicked by customer
  • CUST_PURCHASE_HIST – Customer Purchase History for Analysis
  • CUST_ORDER - Customer Order
  • CUST_ORDER_ITEMS – Individual items in an Order
  • CUST_ORDER_ADDR - Customer Order Addresses
  • REVIEW – Reviews of products and sellers
  • CART – Shopping Cart
8 Non-Functional and Support Requirements
8.1 Operational Requirements
8.1.1 Availability
  • RecordTrader.com will be available 365 days a year, 24 hours a day.
  • We will determine acceptable web server up-time, determine acceptable cost per our financial position, and determine acceptable customer service level and response time. With this information, we will determine our best suited Hosting Provider.
8.1.2 Capacity Requirements
  • We will perform Load Balance Testing to ensure RecordTrader.com can handle heavy usage and peak times.
  • We will develop RecordTrader.com ensuring best coding standards and practices are used (i.e. OOP best practices and standards, optimized Stored Procedure and database calls, acceptable hardware on Web Server).
8.1.3 Maintenance and Production Support
  • Web Server patch dates and times will be determined by Hosting Provider. However, we will ensure patch times and downtimes happen during non-peak times.
  • Web Site changes will be handled by our team of Web Developers.
  • We will follow a SCRUM software development life cycle paradigm.
8.2 Security Requirements
  • RecordTrader.com will secure the checkout and login/registration pages. These pages transmit sensitive customer data (i.e. credit card information, username, and password).
  • RecordTrader.com will purchase a SSL Certificate through VeriSign to be used on the checkout and login/registration page.
  • Web Server will be configured to use HTTPS Protocol on the secured pages.
  • VeriSign logo will be displayed on the site, so customers are aware the site is protected.
  • Site and database will be developed to protect against SQL Injection and XSS (Cross Site Scripting).
  • Validation on pages will take place both client side and server side.
  • Sensitive data on configuration pages (i.e. database connection information), the site uses, will be encrypted to protect against events where the server is compromised.
8.3 Approval of Technical Requirements

ParticipantRoleApproval Date
Tyler WassellProject Lead April 25, 2010
Mo OnaneyeMedia/Graphics Designer April 25, 2010
Oscar BautistaProgrammer/Analyst April 25, 2010
Jeff GroveProgrammer/DBA April 25, 2010
Kelly MorrisAnalyst April 25, 2010
Team Contributions for Deliverable C

Kelly Morris

  • Section 1 Objectives

Mo Onaneye

  • Section 2 Impact Assessment
  • Section 3 Implementation Strategy

Tyler Wassell

  • Section 4 Functional Requirements
  • Section 5 Functional Requirements
  • Compilation of all group member sections into one word document, creation of HTML document and posted to server.

Jeff Grove

  • Section 4 Functional Requirements
  • Section 6 Interface Requirements Specifications
  • Section 7 Data Requirements

Oscar Bautista

  • Section 8 Non-Functional and Support Requirements