Pixel   Hero

Analysis and Design Document

Group 5

Shane Taylor - Customer Support Interface

Melinda Rodriguez - Game Catalog

Humerabanu Tailor - Forums/Discussions

Table of Contents

Contents

1

Introduction

3

System Architecture

4

     System Overview

5

     Architectural Design

5

     Decomposition Description

6

     Design Rationale

7

Human Interface Design

7

      Account Creation and Login

7

         Registration    

7

         Login

9

          Change Password

11

        Game Catalog

13

          Select Platform and Genre

13

          View Game Titles

14

          Configure Searchable Games

16

      Forums/Discussions

18

          Post Comment

18

          Reply to Comments

20

          Validate Comments

22

      Customer Support Interface

24

          Submit Question

24

          Response Notification

26

          Close Support Ticket

29

Component Design

31

      Account Creation and Login

31

      Game Catalog

32

      Forums/Discussions

33

      Customer Support Interface

34

Data Design

35

      Account Creation and Login

35

      Game Catalog

36

     Forums/Discussions

37

     Customer Support Interface

38

Database  Dictionary / Schema

39

       Account Creation and Login

39

       Game Catalog

40

      Forums/Discussions

41

      Customer Support Interface

42

Full Database Model

43

Requirements Matrix

43

Appendices

45

INTRODUCTION

         This software  design  document describes the architecture and system design of Pixel Hero . It is suppose to help the user to understand which parts of the project are developed and how they will be able to interact with the system. This system design document is intended for the audience age from 10 to 60 years. The user of any age must be able to find information regarding the game here will be the goal of this SDD.

           The scope of Pixel hero ADD will entail the following:  

  1. Search for games manually for all systems Nintendo has produced from past to current.
  2. Go through a game catalog to get specific information on a particular Nintendo game, which will be categorized by system then genre.
  3. Get reviews from fellow Nintendo enthusiasts.  
  4. Register for a newsletter.
  5. Have a forum to post discussions and get comments from other users.
  6. Get support from the administrator by posting a comment and getting a response.

        Pixel Hero will not include any type of video tutorials to assist with game play,    dialogue between users will be the source for that particular inquiry. This site will not provide a news section.  

The three modules that are included in the design are Game Catalog, Forums/Discussions and Customer support Interface respectively.  

SYSTEM ARCHITECTURE

ADD Diagrams (1)ADD.png  

A layered system architecture was chosen to better accommodate the relatively short lifecycle of the presentation or user interface layer.  With the goal of a long term existence, PH will better be able to keep up with the latest in user interface design without affecting the business logic, database access, or the database itself.

        The user interface will employ Bootstrap to ensure that all platforms have uniform access to PH.  While at the same time easily allowing PH to change the interface at any time.
        Business logic will be well defined and separated from any other component in the system.  They will implemented using the server-based scripting language php.  Security will be drafted to determine which features are accessible to each type of user.
        The data access layer will use the ASP.net framework and C# language.  Smart Report Maker will be used as an open source solution for auto generating MySQL reports based on tables, views or SQL queries . Smart Report Maker can be installed easily in shared hosting servers, It supports many advanced features such as data filters , multiple grouping levels, labeling , and members login.  With this we can track the growth rate of new registered users, the most visited pages, and the most popular platforms and titles.

        The  database character set to be used is UTF-8 in order to easily implement Japanese characters in the event that Pixel Hero expands to Nintendo’s home country.

SYSTEM OVERVIEW

PH will be a platform for fans of Nintendo games to rate games and tell the world why their favorite game should be in every gamers catalog.  Users will get the latest news in the weekly PH newsletter.  And share their knowledge and passion of Nintendo products.   In a marketplace that is devoid of Nintendo specific, PH will be a standout destination.  The layered and compartmental design allows for flexibility and and rapid response to an ever evolving online environment.

ARCHITECTURAL DESIGN

The PH system is predicated on having a robust and functional catalog.  The catalog content will be the motivating factor that drives users to the site.  Once at the site, the registration system will allow users to access the forums and customer support interface.  Admin users will administrate the user functionality of the forums and respond to PH users through the customer support interface.

DECOMPOSITION DESCRIPTION  

ADD Diagrams (1)ADD.png

        The game catalog, forums, and support interface modules all derive from navigation.  Each module has well defined use cases that support it and derive from it.  

The game catalog provides the data our users are seeking.  By using a dynamic genre search, PH users are able to view the titles they desire and PH admins are able to add to that catalog as the need arises.

The forums provide functionality for PH users to communicate with the larger PH community while also giving PH admins the ability to approve or remove comments as needed.

The customer support interface provides PH users an efficient method of communication with PH admin.  Allowing for response notification and a support ticket system that tracks ticket status.

DESIGN RATIONALE

Discuss the rationale for selecting the architecture described in 3.1 including critical issues and trade/offs that were considered. You may discuss other  architectures that were considered, provided that you explain why you didn’t choose them.

HUMAN INTERFACE DESIGN

The following mock ups are based on two color schemes.  The PH user interfaces are grey and red to reflect the theme of the client side of the system.  The PH admin interfaces are blue and white.  This is done in effort to more easily differentiate between client facing and admin facing interfaces.

ACCOUNT CREATION AND LOGIN

REGISTRATION

RegistrationADD.png

The registration page will allow new users to register with the system. The user must enter all fields before submitting the form.

____________________________________________________________________________

INPUT & OUTPUT

____________________________________________________________________________

INPUT  

•        First Name: String representing the first name of user. Minimum of 1 and maximum of

        50 characters.

•        Last Name: String representing last name of user. Min 1 and maximum 50 characters

•        Email: User’s email address used for communication and verification. Should match

        standard email pattern “name@server.com”. Minimum of 10 characters, maximum of 50

        Characters.

•        Username: string representing the username can be a minimum of 6 characters and a

        maximum length of 20.

•        Password: Also a string. Must be a minimum of 8 characters and a maximum of 20. Must

        contain one capital letter and one number.

•        Re-enter Password: matches Password field. Used only for verification of password.

____________________________________________________________________________

OUTPUT

Upon successful creation of user, the system will display a welcome message or a warning message. In addition, if the data entered is not valid, the system will show a list of the fields with invalid data in red font.

Possible messages:  // Must be exact language messages

Successful: “Welcome [First Name] [Last Name]. Thank you for registering with us!”

Failed: “There is an error with your information. Please review the fields highlighted in red and re-enter the information”

____________________________________________________________________________

ACTIONS

Upon submitting the form, the system will validate that all required fields have input, and that each field matches the required data in the required format.

If the validation is successful, the system will run a query to store the user’s information in the database.

If the validation failed, the system will abort transaction and return an error message for each invalid field.

____________________________________________________________________________

PRE & POST CONDITIONS

Pre-conditions: User has not registered with the system already. The system should validate that the email and username are unique within the stored user values.

Post-conditions: User record is stored successfully. A user session is created.

____________________________________________________________________________

VALIDATION

The following validations will be performed on the submitted data:

•        First Name, Last Name: fields must be at least the minimum specified length and

        no more than the maximum length.

•        Username: must be unique

•        Email: must be unique and must meet standard email address format

•        Password: Must meet standard strong password policy. The password must be

        stored using a secure mechanism that will prevent unauthorized access. All

        passwords will be hashed and stored as such in the database.

LOGIN

LoginADD.png

The login page will allow students/faculty to access the system’s features. They can also rest their password or unlock their account.

____________________________________________________________________________

INPUT & OUTPUT

____________________________________________________________________________

INPUT

•        Username: string representing the username can be a minimum of 6 characters

        and a maximum length of 20.

        

•        Password: Also a string. Must be a minimum of 8 characters and a maximum of

        20. Must contain one capital letter and one number.

__________________________________________________________________________

OUTPUT

A session is created for the successful logged in user to access information granted to the specific user role. Also a message welcoming the user or an error (depending on the credentials provided)

_______________________________________________________________________

ACTIONS

Once the user has entered their username and password, the “Login” button will prompt the site to authenticate the user. Their role will be determined and they will be granted access to the modules available to that class of user. Based on the assigned role, the user might be re-routed to the faculty page or the student page.

____________________________________________________________________________

PRE & POST CONDITIONS

Pre-conditions:  Faculty and students both require a valid username and password, the user name will be assigned upon acceptance or employment to the institution.

Post-conditions:  Successful entry of credentials will result in a portal page. Unsuccessful entry of credentials will result in an error page, where the user is required to re-submit credentials.

____________________________________________________________________________

VALIDATION

Both the username and password will be validated by comparing them to the specific user credentials stored in the database.

Password Security:  The password must be stored using a secure mechanism that will prevent unauthorized access. All passwords will be hashed and stored as such in the database.

CHANGE PASSWORD

ChangePWADD.png

The Change Password page will allow the user to change their password by entering the current one, and the new password.

____________________________________________________________________________

INPUT & OUTPUT

____________________________________________________________________________

INPUT

•        Current Password: String. Must be a minimum of 8 characters and a maximum of

        20. Must contain one capital letter and one number.

•        New Password: Also a string. Must be a minimum of 8 characters and a maximum

        of 20. Must contain one capital letter and one number.

•        Re-type Password: Same requirements as New Password

____________________________________________________________________________

OUTPUT

If the user enter the correct “current password”, the system will store the new password and return a “Successfully change of password” message.

____________________________________________________________________________

ACTIONS

Upon submission of the form, the system will validate the user has entered the correct password. To do so, the system will use the current session username and retrieve the current password from the database. The “Current Password” entered will be verified against the stored password and if successful, it will also validate both “New Password” and “Re-type Password” values are identical.

If all validation passes, then the system will update the user account with the new password entered.

____________________________________________________________________________

PRE & POST CONDITIONS

Pre-conditions:  User is already registered and the account is active.

Post-conditions:  Successful transaction will update the user’s password to the specified new values

______________________________________________________________________  ______

VALIDATION

Must meet standard strong password policy.  The password must be stored using a secure mechanism that will prevent unauthorized access.  All passwords must be hashed and stored as such in the database

GAME CATALOG

SELECT GAME PLATFORM AND GENRE

Platform-Genre (1)ADD.png

____________________________________________________________________________

INPUT & OUTPUT

____________________________________________________________________________

INPUT

•        Name of platform: String. Contains no more than 10 characters.

•        Name of game: String. Contains anywhere from 10-20 characters.

____________________________________________________________________________

OUTPUT

Once the user enters into the system  a row in the form of a navigation bar will be placed at the top of the page listing the different platforms Nintendo has ever produced. Dropdown list with every platform listing the genres offered.

____________________________________________________________________________

ACTIONS

        

Upon entering the system, the user will go to the navigation bar at the top of the page and select a platform type. Once a type has been chosen a genre drop down list will appear and the user will select the genre of choice.

____________________________________________________________________________

PRE & POST CONDITIONS

The user must have Nintendo knowledge to navigate through system.  An intended search is necessary as well. The platform and genre types must be clickable.

____________________________________________________________________________

VALIDATION

All strings representing the various platforms must be a valid Nintendo game system from the past or present.  All genre categories must be present to give the user proper usability of the system.

VIEW GAME TITLES

viewGamesADD.png

GameADD.png

____________________________________________________________________________

INPUT & OUTPUT

____________________________________________________________________________

INPUT  

•        Game title selection: String. Contains anywhere from 10 - 20 characters.

____________________________________________________________________________

OUTPUT

        Once the user selects a game title, the displayed information will include:

•        Game title

•        Game description

•        MSRP

•        Rating

•        Reviews

__________________________________________________________________________

ACTIONS

Upon selecting the platform and genre, a list of games will be displayed for the user to select from.  Once the user selects the desired genre, a detailed list of games will be displayed. The user will be able to scroll through the categorized list and click on the desired game to view complete details.  

____________________________________________________________________________

PRE & POST CONDITIONS

The user must know what genre the game they are searching for is under. The sublist of game titles are clickable and take the user to that individual title’s page.

____________________________________________________________________________

VALIDATION

        Games represented must be valid game titles of any of the Nintendo platforms.

CONFIGURE SEARCHABLE GAMES

ConfigGamesADD.png

  ADD.png  

SuccessADD.png DeleteADD.png

____________________________________________________________________________

INPUT & OUTPUT

____________________________________________________________________________

INPUT  

•        Game ID: String.  Contains exactly 6 characters.

•        Game Title: String.  Contains anywhere from 1 to 30 characters.

•        MSRP: String.  Contains exactly 6 characters.

•        Genre: String.  Can contain from 1 character to 20 characters .

•        Platform: String.  Can contain from 1 character to 20 characters .

•        Description: String. Must be minimum of 1 character and up to 150 characters .

_________________________________________________________________________

OUTPUT

When the admin selects to “Add New”, a box will pop up.  Admin will add all information needed to add entry to PH’s site.  Once submitted, a dialog box will appear stating the game was successfully added.  When the admin wants to delete a game, he/she will highlight the game and then hit “delete” and a confirmation box will appear and the admin will click ok or cancel.          

____________________________________________________________________________

ACTIONS

Add :

The admin will have the capability to add new games to the system, delete games from the system and modify games.  For adding a game, the admin will first check to see if the game already exists in the PH database.  If it does a list will appear.  If it does not the admin will click on the “add new” clickable button and will be taken to a separate screen to add the values needed.  

Delete :

To delete a game the admin will enter a search for the game.   Then the admin will highlight the game title/id and click the delete button. A confirmation box that says “are you sure?” will appear and then admin is to select “yes” or “no”.  

Modify :

To modify a game the admin will enter a search for the game. Then the admin will highlight the game title/id and then click the modify button.  The system will take it to another screen to modify values.

____________________________________________________________________________

PRE & POST CONDITIONS

The sublist of game titles are clickable and take the user to that individual title’s page.

_____________________________________________________________________________

VALIDATION

Game ID will be validated that there is not another game title with the same ID.

FORUMS / DISCUSSIONS

POST COMMENTS

Untitled Diagram (12)ADD.png

____________________________________________________________________________

INPUT & OUTPUT

____________________________________________________________________________

INPUT [a]  

•        Author: String representing the name of the PH user willing to comment in forums. It should be minimum 1 and maximum 20 characters.

•         Title: String representing the title of the comment or question the user is going to post regarding the game. It should be minimum of 1 and maximum of 50 characters.        

•        Description: String representing the description of the comment that explains in detail what the user want to comment about the game or what is the question that the user want to ask related to game. The description should be of minimum 1 and maximum of 100 characters.

____________________________________________________________________________

OUTPUT

Upon successful submission of the comment to be posted on forums section a new thread will be created of user’s comment on the Forums/Discussion section of the game.

____________________________________________________________________________

ACTIONS

A new thread is been created on Forums/Discussion section of the gaming website in the form of user’s comment along with the user’s name for who’s commenting, comment title, description of the comment along with the date on which it is posted.

____________________________________________________________________________

PRE & POST CONDITIONS

Pre-conditions: The user trying to post a comment on this section of website must at least enter a proper title and description of the comment as a first commenter.

Post-conditions: If successfully submitted, user’s comment will be posted on the Forums/discussion ection of the gaming website.

____________________________________________________________________________

VALIDATION

The validations that will be applied to the Title and description of the comment will be that it should be at least of minimum specified length and should not exceed than the maximum length mentioned.

REPLY TO COMMENTS

Untitled Diagram (13)ADD.png

____________________________________________________________________________

INPUT & OUTPUT

____________________________________________________________________________

INPUT  

•        Author: String representing the name of the PH user willing to reply to the comment in forums. It should be minimum 1 and maximum 20 characters.

•        Title(optional): String representing the comment title which will be the reply to another user’s comment. Minimum of 1 character and maximum of 50 characters.

•        Description: String representing the detailed description of the comment that the user want to reply on another user’s comment. Minimum of 1 character and maximum 50 characters.

____________________________________________________________________________

OUTPUT

A new thread is created upon the successful submission of the user’s comment on another user’s comment as it's subsection.

____________________________________________________________________________

ACTIONS

If the user is able to go through pre-conditions than the user will be able to reply on another user’s comment in that comment subsection along with the date.

____________________________________________________________________________

PRE & POST CONDITIONS

Pre-Conditions: The user who want to reply on another user’s comment must reply to it an appropriate way in related to game only.

Post-Conditions: If succeeded, user’s response to another user’s comment as its reply will be posted in forums/discussions section of the gaming website.

____________________________________________________________________________

VALIDATION

The validations here will be applied to on user’s response to another user’s comment, must be related to the game and it should be in appropriate way, also it should not be less than minimum length and should not exceed maximum length characters.

VALIDATE COMMENTS

Untitled Diagram (14)ADD.png

____________________________________________________________________________

INPUT & OUTPUT

____________________________________________________________________________

INPUT  

•        Query: String query written by admin user only to configure and validate the comments posted on the forums/discussion section of the gaming website.

____________________________________________________________________________

OUTPUT

The modified forums/discussion section of the website after being configured and validated by the admin user.

____________________________________________________________________________

ACTIONS

The admin user will be able to delete all inappropriate comments that are related to game. Admin will also be able to control the the flow of the comments and hence configure and validate the comments. Also he can suppress the old comments by discarding them.

____________________________________________________________________________

PRE & POST CONDITIONS

Pre-conditions: The user trying to access this section of the gaming section should be admin only, all the other users will not be able to access this section.

Post-conditions: If the user is admin, admin will have access to this section and hence will be able to configure and validate the comments posted on this section related to games.

____________________________________________________________________________

VALIDATION

The validation here will be to verify whether the user trying to access this particular section of the gaming website is admin or not. If it is admin than only the user will be able to access it. All the other PH user will not have an access to this section of the website.

CUSTOMER SUPPORT INTERFACE

SUBMIT QUESTION

The submit question page will allow registered users to send questions and comments to PH admin. The user must enter all fields before submitting the form. ____________________________________________________________________________

INPUT & OUTPUT

____________________________________________________________________________

INPUT  

____________________________________________________________________________

OUTPUT

____________________________________________________________________________

ACTIONS

____________________________________________________________________________

PRE & POST CONDITIONS

____________________________________________________________________________

VALIDATION

RESPONSE NOTIFICATION

____________________________________________________________________________

INPUT & OUTPUT

____________________________________________________________________________

INPUT  

The PH admin user replies to the customer’s issue.

____________________________________________________________________________

OUTPUT

The user’s home page displays a notification.  Once the user clicks on the notification, the complete PH admin user response is displayed.

____________________________________________________________________________

ACTIONS

The user can click on the notification to view the PH staff response.

____________________________________________________________________________

PRE & POST CONDITIONS

The PH user is registered and logged in.  There is an open support ticket for the admin user to respond to.  The PH user can view the PH admin response.

____________________________________________________________________________

VALIDATION

The PH admin user has entered a text response.

CLOSE SUPPORT TICKET

____________________________________________________________________________

INPUT & OUTPUT

____________________________________________________________________________

INPUT

The PH admin user selects from a drop down a list of available support ticket statuses and chooses closed.

____________________________________________________________________________

OUTPUT

A message is display to the admin user, “This support ticket has now been closed”.

____________________________________________________________________________

ACTIONS

The admin user changes the support ticket status from open to closed which removes it from the Support Queue.

____________________________________________________________________________

PRE & POST CONDITIONS

A registered user question or comment must first be generated and in the open status.  The response has been sent and the open status of the support ticket has been changed to closed. A list of new open support tickets is generated for the PH admin user to respond to.

____________________________________________________________________________

VALIDATION

The PH admin has responded fully to the user’s concern.  The admin user must change the status of the support ticket to closed.

COMPONENT DESIGN

Account Creation and Login

Account Creation and Login Entities

User: The User class represents both customer and staff entities. It is the base class for all user information. This class is responsible for managing the user personal information as well as defining the formatting of names.

User Attributes/Fields:

•        User ID: unique identifier for a single User instance

•        FirstName: The first name of the user

•        LastName: The last name of the user

•        Email: a string representing a valid email address in the form of [account]@[domain].[suffix]

•        Username: a unique string chosen by the user to gain access to the system

•        Password: a string representing the password selected by the user to gain access to the Web site. It should be no less than 8 chararcters

•        UserType: An association to the UserType entity. It defines the type of the current user instance

Relationships:

•        UserType: Each user has a one to one relationship with a type entity.

•        HashingProvider: The User object will depend on the HashingProvider entity which will hash the passwords for the current user object.

UserType: Entity that identifies one of the possible types of users. Possible options might be “customer”, “admin”, “guest”

HashingProvider: This object will be responsible for hashing the user passwords using one of the standard algorithm. The “provider” will depend on a third party library for the hashing algorithm.

HashingAlgorithms: This package is TBD based on hashing requirements.

Game Catalog

DataDesignRevisionADD.png

Game  Catalog Entities

Game: The game class represents represents all game entities

Game Attributes:

•        ID: unique identifier for a single Game instance

•        Title: The name of the game title

•        Description: A brief description of the game

•        Reviews: User input of the efficiency and likeability of games

•        MSRP: Represents the cost of the game

•        Rating: Representation of efficiency and likeability of games with the use of star ratings

•        GenreID: Represents the id associated with the genre the game will categorized under

•        PlatformType: Represents the cost of the game

User: The User class represents both customer and admin entities that will have access to Game entity.

User Attributes:

•        UserID: unique identifier for a single User instance

•        UserType: identifier for type admin or PH user

Genre: The Game entity will use the Genre class to organize all the games into categories.

Genre Attributes:

•        GenreID: unique identifier for a single Genre instance

•        GenreType: identifier for different types of genre to classify games

•        GenreDescription: identifier for an explanation of the different genre types.

 

Forums / Discussions

Untitled Diagram (10)ADD.png

Forums/Discussions Entities

User: The User class represents both customer and staff entities. It is the base class for all user information. This class is responsible for managing the user personal information as well as defining the formatting of names.

User Attributes/Fields:

•        User_id: unique identifier for a single User instance

•        Name: The name that PH user uses to post their comments.

•        UserType: An association to the UserType entity. It defines the type of the current user instance

Comments: The comments class represents the comments posted by the PH user. This class basically has all the attributes regarding user’s comment.

Comment Attributes:

•        Cmmnt_id: unique identifier for each comment posted on forums.

         Title: The title of the comment of the user if the user is first commenter.

•        Description: Detailed explanation of the comment that is going to be posted.

•        Date: The date on which the comment was posted.

Validation: The validation class represents the configurations and changes that admin is going to make in the comments of the forums section.

Validation attributes:

•        User_id: Unique identifier of the admin user who is going to access this section and going to configure the comments.

•        Query_id: unique identifier for the query that will be written by the admin user only for configuring the comments in forums section.

•        Authorisation: The boolean value assigned by admin to the comments whether they are authorized to be posted on the forums section or not.

Customer Support Interface

Customer Support Interface Entities

Support Ticket: The support ticket class represents represents all customer support inquiries and their responses.  It is dependent on the user class, due to the PH user needing to be registered before submitting a question and the PH admin is required to submit a response.  

Support Ticket Attributes:

•        Ticket_ID: unique identifier for a single customer inquiry.

•        Ticket_Status: The current status of the customer inquiry. Open, Pending, or Resolved.

•        User_ID:  The unique user ID of the PH user that initiated the inquiry.

•        Subject: The option chosen by the PH user from a prepopulated list of possible appropriate reasons for the correspondence.

•        Question: The textual question or comment submitted by the PH user.

•        Response: If a response has been generated, the textual response submitted by the PH admin.

User: The User class represents both customer and admin entities.

User Attributes:

•        UserID: unique identifier for a single User instance

•        UserType: identifier for type admin or PH user

DATA DESIG N

ACCOUNT CREATION AND LOGIN

From the below diagram, we identified a relationship between a user and his/her type. The possible types will be Administrator and Customer. The relationship “IsType” does not include any specific attributes.

Another relationship for the user is the Game Reviews. In this particular relationship, we have unique attributes that are not part of the user and neither are they part of the game. Those attributes are only related to the user review of a game. For example, the Review Description and the When Reviewed attributes are not part of the user, but they do describe the relationship of the user and game through a review.

Please include in the diagram a numeric quantity on the relationships.

GAME CATALOG

The below diagram demonstrates the relationship between the user and the game catalog.  In this particular relationship, there are unique identifiers that are not part of either entity.  This shows how a user will have access to the Game Catalog, whether it is an admin or client.  

The shared attributes for Game and Genre demonstrate the relationship and how Genre is a type of game.  They have several different attributes between the two entities.  The primary key for the game will be the unique identifier for that class.

The relationship between the Game Catalog and Game entity shows that there is a dependency of games for the Game catalog to exist.  

ERADD.png

FORUMS/DISCUSSIONS

The below diagram shows the relation between the entity user and comments. Both the user and admin share the same attributes. As of actions to be taking place, user and admin both are able to post and reply to comments, but it is admin that takes the action of validating those comments.

The comments entity has attributes like cmmnt_id, title, description, date.

Untitled Diagram (11)ADD.png

SUPPORT INTERFACE

The diagram below represents the relationship between the PH user entity, PH admin entity, and the customer support interface.  The PH user and the PH admin are related through the customer support interface.  Once a PH user submits a question, a unique support ticket number is automatically generated and becomes the relation between the two user types.

Both users have the same set of attributes, User_id, username, password, and email and they derive from the user type.  WHich has the attributes User_type_ID, User_Type_Name, and Type_Description.

The support ticket entity has the following attributes:Support_Ticket_ID, Subject, Status, Question, and Response.

DATABASE DICTIONARY / SCHEMA

REGISTRATION / AUTHENTICATION

The following tables are defined for the Registration/Authentication module

User Table

 Entity

Type

Value

Description

user_id  

INT

Not null

PK. Unique identifier of a user.

user_type_id

INT

Not null

FK. Relationship key to the User_Types table

user_pw

varchar(50)

Not null

User’s password HASH

first_name

varchar(30)

 

Not null

User’s first name

last_name

varchar(30)

 

Not null

User’s last name

Email

varchar(50)

 

Not null

User’s E-mail address

User_Types Table

Entity

 

Type

Value

Description

user_type_id

INT

Not Null

PK. Unique identifier of a user.

type_name

 

varchar(50)

Not null

The name of the user type

type_description

 

varchar(50)

Not null

Description of the user type and its uses

GAME CATALOG

GAME

 Entity

Type

Value

Description

game_id  

INT

Not null

PK. Unique identifier of a game.

game_title

varchar(50)

Not null

Name of the game.

game_description

varchar(200)

Not null

Description of the game

game_review

varchar(200)

 

Not null

User’s review on game

game_msrp

INT

 

Not null

Game’s representation of cost

game_rating

INT

 

Not null

User’s star ra ting

game_platformtype

varchar(20)

Not Null

Name of platform the game will be under.

GENRE

 Entity

Type

Value

Description

genre_id  

INT

Not null

PK. Unique identifier of a game.

genre_title

varchar(50)

Not null

Name of the game.

FORUMS/DISCUSSIONS

COMMENTS

 Entity

Type

Value

Description

user_id  

INT

Not null

FK. Unique identifier of a user.

user_type_id

INT

Not null

 Relationship key to the User_Types table

name

VarChar(20)

Not null

Name of the user posting comments

cmmnt_id

INT

Not null

PK. Unique Identifier of a comment

cmmnt_title

varchar(50)

Not null

User’s comment title

cmmnt_description

varchar(100)

 

Not null

Description of the comments

qry_id

INT

 

Not null

Admin user’s identifier for the query

qry_description

varchar(100)

Not null

Description of the query that the admin will be making modification in the comments

Abhuthorization

boolean

Not null

Whether comment is authorised to be posted or not by the user

SUPPORT INTERFACE

Support ticket

Entity

 

Type

Value

Description

ticket_ID

INT

Not Null

PK. Unique identifier of a user.

user_id

 

varchar(50)

Not null

FK.  The name of the user type

ticket_status

 

varchar(50)

Not null

The current status of the support ticket

topic

varchar(20)

Not null

The topic selected by PH user as most appropriate for their question or concern.

question

varchar(500)

Not null

The text question or comment entered by the PH user.

response

varchar(500)

Not null

The text question or comment entered by the PH user.

FULL DATABASE MODEL

REQUIREMENTS MATRIX

Module

Use Case

Design Component

Registration Module

Registration

User Interface: Registration

ERD Diagram page 33 of SRS

Component Model: Account Creation and Login

DB Schema page 31 of ADD

Login

User Interface: Login

ERD Diagram page 35 of SRS

Component Model: Account Creation and Login

DB Schema section page 31 of ADD

Change Password

User Interface: Change Password.

ERD Diagram page 37 of SRS.

Component Model: Account Creation and Login.

DB Schema section page 31 of ADD.

Game Catalog

Select Game Platform and Genre

User Interface: Select Game Platform and Genre.

ERD Diagram page 48 of SRS.

Component Model: Game Catalog.

DB Schema section page 32 of ADD.

View Game Titles

User Interface: View Game Titles.

ERD Diagram page 50 of SRS.

Component Model: Game Catalog.

DB Schema section page 32 of ADD.

Configure Searchable Games

User Interface: Configure Searchable Games.

ERD Diagram page 52 of SRS.

Component Model: Game Catalog.

DB Schema section page 32 of ADD.

Forums / Discussions

Post Comments

User Interface: Post Comments.

ERD Diagram page 62 of SRS.

Component Model: Forums / Discussions

DB Schema section page 33  of ADD.

Reply to Comments

User Interface: Reply to Comments.

ERD Diagram page 64 of SRS.

Component Model: Forums / Discussions

DB Schema section page 33  of ADD.

Validate Comments

User Interface: Validate Comments.

ERD Diagram page 66 of SRS.

Component Model: Forums / Discussions

DB Schema section page 33  of ADD.

Customer Support Interface

Submit Question

User Interface: Submit Question.

ERD Diagram page 77 of SRS.

Component Model: Customer Support Interface

DB Schema section page 34  of ADD.

Response Notification

User Interface: Response Notification.

ERD Diagram page 79 of SRS.

Component Model: Customer Support Interface

DB Schema section page 34 of ADD.

Close Support Ticket

User Interface: Close Support Ticket.

ERD Diagram page 81 of SRS.

Component Model: Customer Support Interface

DB Schema section page 34 of ADD.

APPENDICES

Hardware

Database System

[a] When a user posts a comment a date or time is automatically assigned to it and posted alongside with it on forums section.

so, "Date" won't be an input right?

it will be generated automotically by the system?