Pixel   Hero

Software Requirements and Specifications

Group 5

Shane Taylor

Melinda Rodriguez

Humerabanu Tailor

TABLE OF CONTENTS

Contents ……………………………………...………………………… …………… …. ……… 2

Introduction .…………………………………………………………………………...… ………5

Overall Description . …………………….………….………………………….....…….…... 6

Product perspective.……………………...…………………………...…..……………..…6

Product functions....…………….………………..…………………………………..……….7

User characteristic..………………………………………….………….…….…………..…..7

Constraints..……………………….………………………………..……………………….……..7

Assumptions and dependencies……………………………..……….…………….….…7

FUNCTIONAL Requirements.…………….………....…………………………….……….8

USER Requirements ….. .……………………………….……………….………...….…….…8

Registration.…...…………………………………………….……………….…….……....……..9

Login..………………………...……………………………….…………….………...………....….9

Change Password..…………………………………………………….…..……………….....10

Search Term....……………………....………………………………………….…….…….…..10

Game Detail....……………………....………………………………………….…….……...….11

Configure Game…………………....………………………………………….…………..….….11

Select Platform and Genre………………………………………………………..……..……12

View Game Titles……………………………………………………………………..……………12

Configure Searchable Games………………………….………………………..……………12

Enter Review.……………....………………………………………….………….…………..….13

Enter Star Rating………....………………………………………….………….…………..….13

View / Approve / Reject Review…....……………………………………….…………..14

Post Comments……………....………………………………………….……....……….......14

Reply to Comments..……....………………………………………….…….…….…….......15

Validate Comments………....………………………………………….………..……….......15

Opt In / Out.…………………....………………………………………….………..……….......16

Edit / View Subscribers…....………………………………………….………..……….......16

Create / Edit Newsletter Content …………………………….…………..…………..….16

Submit Question……………………….…………………………….…………...…………..….16

Response Notification……………….…………………………….…………...…………..….17

Close Support Ticket …………………………………...………….…………...…………..….17

SYSTEM Requirements ..……………………………………………...….…….……..…...…17

Registration.…...…………………………………………….……………….……...……………..17

Login..………………………...……………………………….…………….………..….……..….18

Change Password..…………………………………………………….…….……..…………....19

Search Term....……………………....…………………………………………….….…….….….20

Game Detail....……………………....………………………………………….….……….….….20

Configure Game…………………....………………………………………….……….…..….….21

Select Platform and Genre……………………………………………………...…..…………22

View Game Titles……………………………………………………………….……..…..….……23

Configure Searchable Games………………………….…………………….………………23

Enter Review.……………....………………………………………….…………..……….…..…24

Enter Star Rating………....………………………………………….……….….…..….…..….24

View / Approve / Reject Review…....………………………………………..….………..25

Post Comments……………....………………………………………….………..…….….......26

Reply to Comments..……....………………………………………….……….….……........26

Validate Comments………....………………………………………….………….....….......27

Opt In / Out.…………………....………………………………………….…………...…….......28

Edit / View Subscribers…....………………………………………….…….……..…….......29

Create / Edit Newsletter Content …………………………….………….…..………..….29

Submit Question……………………….…………………………….………….…..………..….30

Response Notification……………….…………………………….…...……..…….……..….31

Close Support Ticket …………………………………...…………..…..…….…….……..….32

System Models ..……………………………….……………………....…………...…..……...32

Registration.…...…………………………………………….……………….…….….…………..32

Login..………………………...……………………………….…………….…….…….……...….34

Change Password..…………………………………………………….…..……...…………....36

Domain Analysis………………………………………………………………………...…………39

Search Term....……………………....………………………………………….…….….…….….41

Game Detail....……………………....…………………………………………..……….…….….42

Configure Game…………………....………………………………………….….……..….….44

Domain Analysis……………………………………………………………………….….………46

Select Platform and Genre……………………………………………………….…..………47

View Game Titles……………………………………………………………………….…………49

Configure Game Catalog…….………………………….………………………….…………51

Domain Analysis……………………………………………………………………..……………54

Enter Review.……………....………………………………………….………….……..………..55

Enter Star Rating………....………………………………………….………….…..………..….57

View / Approve / Reject Review…....…………………………………………….………..59

Domain Analysis……………………………………………………………………….……………60

Post Comments……………....………………………………………….…………..……….......62

Reply to Comments..……....………………………………………….…………...…..….......63

Validate Comments………....………………………………………….…………..……….......66

Domain Analysis………………………………………………………………………………………68

Opt In / Out.…………………....………………………………………….…………..……….......69

Edit / View Subscribers…....………………………………………….…………..……….......70

Create / Edit Newsletter Content …………………………….………….…….………..….72

Domain Analysis……. …………………………………...………….………….…….………..….75

Submit Question……………………….…………………………….…………..……………..….76

Response Notification……………….…………………………….………….….…………..….78

Close Support TIcket …………………………………...………….…………..……………..….80

Domain Analysis……. …………………………………...………….………….…..……….83

NON-functional Requirements ..……………………………………………..…………….….84

Appendix ..………………………………………………....……………..…………...………...84

Index ..………………………………………………………………………...……..………......86

INTRODUCTION

  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.  

OVERALL DESCRIPTION

PRODUCT PERSPECTIVE

Pixel Hero is an independent product  focused on the Nintendo platform but is under an umbrella of Pixel World. Pixel World has current web applications for other gaming systems.

PRODUCT FUNCTIONS

Pixel Hero will provide the following functions for users:

  1. Account creation and login.
  2. Search for specific game titles and or platforms.
  3. View user reviews of specific game titles and or platforms.
  4. Add their own review of specific game titles and or platforms.
  5. Sign up for regular newsletters.

USER CHARACTERISTICS

The users of Pixel Hero should have at least a passing knowledge on the Nintendo platform.  The intended audience ranges from the age of 15 to 65 and can be anywhere from a novice to an expert that has some knowledge about Nintendo products.

CONSTRAINTS

The following constraints will limit the development of Pixel Hero

  1. Copyright restrictions concerning the use of official Nintendo images and logos.
  2. Some original content.
  3. An internet connection is required to access use.
  4. Users must be able to read.
  5. Outsourcing of data storage services.
  6. User generated content is key component and is dependant on user volume.
  7. Users personal data is a security liability.

 ASSUMPTIONS AND DEPENDENCIES

Pixel Hero HTML coding will conform to HTML5 and XML standards to better future proof the product and provide an extended life cycle.  

There will be considerably more traffic to PH during the holidays and release dates for popular titles.

Furthermore, 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.  

   

FUNCTIONAL REQUIREMENTS

Pixel Hero will provide the following functional requirements for its users:

USER REQUIREMENTS

ACCOUNT CREATION AND LOG IN

 

Image

REGISTRATION

Any visitor should be able to self-register as a user at Pixel Hero.  Registration is a one time event per user and a user can only register themselves.  Registration gives users abilities that unregistered users do not possess, such as the ability to create new reviews for game titles and platforms and sign up for newsletters.  An administrator can register a user and can change their password.

The “registration” use case contains the following basic steps:  

  1. Pixel Hero user fills in and submits data  
  2. Pixel Hero System validates data  
  3. Pixel Hero System creates user’s profile/account
  4. Pixel Hero System enables the activated account to log into the system

LOGIN

Any registered user should be able to log into the Pixel Hero Web application. To successfully log into the system, the user must be already registered with the Pixel Hero. The login screen should be accessible from any place with access to the internet, and should work with all kinds of browsers. After successfully authenticating, the user will be redirected to the home page and be granted access to any sections of the Pixel Hero Web app for his/her role. Both customers and administrators should use the same Login screen.

The “Login” use case contains the following basic steps:  

  1. Registered user inputs credentials
  2. Pixel Hero System validates data against stored registered users
  3. If credentials match current user, then the Pixel Hero System will grant access and redirect user to home page
  4. If credentials are incorrect, the Pixel Hero System will return an error message to user for retry

CHANGE PASSWORD

Any registered user should be able to access a page of the Pixel Hero Web app to change their current password for a new one. To be able to submit a password change, the user must also submit the current password. The new password should be input twice and both fields should match, to ensure the user typed the desired password. All password fields will be masked as to prevent any accidental discovery of the password while the registered user is using the Web app.

The “change password” use case contains the following basic steps:  

  1. Logged in user access Change Password page
  2. User enters current password and new password, then submits the input
  3. Pixel Hero System validates current password
  4. Pixel Hero System validates new password meets security policy
  5. If current password is valid, then PH System changes the password stored for the new one submitted
  6. If current password fails or the new password does not meet security policy rules, then an errors is sent back to the user to correct

GAME SEARCH

Humera

SRS DocPHSRS.png

SEARCH TERM

Any user, both registered and non-registered and the admin, will have access to search for a game title/platform in Pixel Hero's database. Once the user has submitted a search, the system will compare it  to PH's database and a result list will appear for the visitor to make a selection for the detail description.

The "search term" use case contains the following basic steps:

  1. PH user inputs a game title/platform in the search field.
  2. The search module validates the input and searches the database for a match.
  3. The PH system will either display a results list or an error message to enter a new inquiry.

GAME DETAIL

Once the system validates the search and the list is generated for the result to view the details, the user will be able to select any game from the list and get the detailed description of that particular game. In this use case the PH user:  

  1. Will be able to use the list as a medium to go get the details regarding the particular game.
  2.  PH user will be able to view details such as Game Title, Platform, Main Characters, Game plot, etc.

CONFIGURE GAME

The configuration of the Game list can be done only by the Admin. In this use case admin will be able to:

  1. Admin can add new games as per new changes in the environment, holidays or occasions.
  2. Admin can also delete or rearrange the games from the list as per needed by the changing environment of the system.

CATALOG GENRE SEARCH

Melinda

SELECT PLATFORM AND GENRE

A PH user, registered or not, will be able to look for a particular game by searching the type of platform of choice. Then, a drop down menu of genres will be displayed so the user will select the genre of choice.  A list of games will be displayed pertaining to the particular genre chosen.  In this instance, the admin will have the same functionality as the user.

The “select platform and genre” use case contains the following basic steps:

1.        PH user and/or admin clicks platform type

2.        PH user and/or admin clicks genre preference

3.         List of games are displayed

VIEW GAME TITLES

A list of games will be displayed based on the platform and genre chosen by either a  PH user or admin. The user and admin will have the capability to look over the list of games that were displayed and make a selection.

The “view game titles” use case contains the following basic steps:

1.        PH user and/or views list of games        

2.        PH user and/or admin selects the game of choice

CONFIGURE SEARCHABLE GAMES

The PH admin will have access to add or delete a title, the description, the MSRP, and the release date of games in the database for PH users to view.  The admin must validate whether or not entry is already in the database before adding a new game. The admin will have the authority to delete games.

The “configure searchable games” use case contains the following basic steps:

        1.        PH admin searches for a title against database to avoid duplicates

        2.        If no duplicates are registered, the admin will add all information

        3.        Admin can delete games from the database

REVIEWS

Melinda

PH ReviewPHSRS.png

ENTER REVIEW

A PH user should be able to write a review on any given game that is in the PH game catalog. The user of the PH site must be a registered user in order to enter a review. The title and review text will be entered within the page of a particular game.

The “enter review” use case contains the following basic steps:

1.        PH user searches for game title in catalog or search

2.         PH user clicks review button

3.         PH user will enter a subject of their review

4.         PH user will enter content of their review

ENTER STAR RATING

A PH user should be able to rate any given game that is in the PH game catalog. The user of the PH site must be a registered user in order to rate a game. A five star rating system will be used to show the satisfaction of a game.

The “enter star ratings” use case contains the following basic steps:

1.        PH user searches for game title in catalog or search

2.         PH user clicks review button

3.        PH user will select how many stars to rate game

VIEW/ APPROVE/REJECT REVIEW

The PH admin will be able to view all reviews posted by any PH user.  Before displaying it on the site, the admin will view each review and decide whether or not to approve or reject the review before submitting it to be displayed.

The “view/approve/reject review” use case contains the following basic steps:

1.        Admin will receive notification of new review

2.        Admin will view a PH user’s review posting

2.        Admin will approve or reject the submission

FORUMS/DISCUSSIONS

Humera

SRS Doc (2)PHSRS.png

POST COMMENTS

Here in this use case both admin and the regular users will be able to post questions regarding the game issues and comment regarding the game. This use case has the basic steps like:

  1. User posts the comments/questions.
  2. Admin comments on the threads created by users.

REPLY TO COMMENTS

Both user and Admin can reply to the comments done by the other users. A user can reply by commenting to solve the issue regarding any level of the game. Also admin can reply to the comments where it is necessary to help users to solve an issue regarding game etc.

VALIDATE COMMENTS

This use case is operated just by the admin. Here the admin can control the flow of the comments/questions. Also admin can view which user is commenting what kind of comment and can delete any inappropriate comments. This use case basically has following steps:

  1. Admin can control the flow of the comments or questions as such if a comment/question surpasses certain amount of time, that comment is locked.
  2. Admin can also validate a comment by deleting it if it is not appropriate.

NEWSLETTER

Shane

Any registered user of Pixel Hero should be able to receive the regular newsletter.  A registered user should be able to opt in and opt out as many times as desired.  The newsletter delivers textual and graphical information on new games and platforms as well as any trending older games or platforms related to the Nintendo brand.  An administrator can remove any user from newsletter mailing list.

The newsletter use case contains the following basic steps:

1.      Registered users can opt in or out of receiving the newsletter

2.      Administrators can view and edit subscribers

3.      Administrators can create and edit the newsletter content.

OPT IN / OUT

As a registered user of Pixel Hero, a user can choose to receive the regularly delivered email newsletter.  To opt into the newsletter, a user must first login and navigate to their “My Account”.  Once there, the user will use check boxes with clearly defined text to indicate if they wish to receive emailed newsletters or not.

EDIT / VIEW SUBSCRIBERS

Administrative users can view the current list of registered users who are receiving the emailed newsletter.  This list includes the subscriber’s first name, last name, and email address.  Admin users also have the ability to remove a user from that list, and add a user to that list.

CREATE / EDIT NEWSLETTER CONTENT

An admin user should have the ability to create and edit the content of the newsletter.  This gives the admin user final say over the content of the newsletter before it is mailed out to the subscriber list.  

CUSTOMER SUPPORT INTERFACE

Shane

SUBMIT QUESTION

At the “Contact Us” support page, the customer can send their questions or comments related to the site to Pixel Hero staff.  First the user must be logged in to the site as a registered user to post a question.  Once logged in the user navigates to the “Customer Support” page, they can select from a dropdown list of pre-populated topics that describe various support scenarios.  The customer selects from this list the topic most appropriate for their question or comment.  Below the drop down list, a large text input area is provided for the user to input text and ask their question or post their comment.  Once finished, the user hits a submit button to send their question to PH staff.

RESPONSE NOTIFICATION

Once a PH admin user is logged into the CSI, a list of PH registered user questions with the open status is displayed in the Support Queue.  The PH admin user will click on a specific question to display its details.  Here a textbox is displayed for the admin user to write a response.  Once the user has been responded to by a PH admin, an alert notification is posted to the user’s home page indicating that a response from PH support staff has been generated.

CLOSE SUPPORT TICKET

When receiving contact from a registered user, the PH support system generates a unique support ticket number that is used to reference the customer’s issue.  All new issues are marked as status open.  After responding to the customer, the PH admin changes the support ticket from open to closed.  Changing the status from open to closed removes the support ticket from the Support Queue.

SYSTEM REQUIREMENTS

ACCOUNT CREATION AND LOG IN

REGISTRATION

The following table outlines the details of use case # 1: Registration

Use Case ID:1

Registration

Description

There are two types of users who can register within the PH Web site, customers and administrators. Customers must register to be allowed to create reviews.  Administrators are registered by other administrators and navigate the administrator view of the site.

To register with the system, a user must fill in a list of required fields before submitting the form. If the transaction is successful the user account will be created within the system.  

Input

  • First Name
  • Last Name
  • Email/Username
  • Password

Output

If transaction was successful, then the system will return a Thank You message back to the user. If the transaction failed, the system will return the appropriate error message

Preconditions

The Email/Username does not exists within the system at the time the user submits the form.

Postconditions

If succeeded, the user account will be created and stored within the system.

Actions

PH System will validate the following rules before creating the user account:

  • All fields have values
  • Username is unique within the system and does not exist at the time the user submits the registration
  • Password meets the security policy rules

LOGIN

The following table outlines the details of use case # 2: Login

Use Case ID:2

Login

Description

A customer or an administrator will enter their correspondent credentials to get access granted to the site.

The system will present the same window to either type of user, and should recognize the user type once authentication is successful, to grant the user different access types based on the predefined role.

Input

Email and Password

Output

User should see the Home page upon successful login.  

Preconditions

User has been previously registered successfully with the system. In addition, the user account must be active and should have not expired.

Postconditions

User is redirected to the correspondent page based on the assigned role.

Actions

The user submits the credentials (username/email and password). The system will verify that the user email already exists within the system, and will evaluate the posted password to see if it matches the one stored.

CHANGE PASSWORD

The following table outlines the details of use case # 3: Change password

Use Case ID:3

Change Password

Description

A user (customer or administrator) should be able to change their account password by providing the current credentials. Since the client browser does not show the values of the password input field, it is important that the system requires two values for the new password to ensure the user has typed the desired value.  

In addition, the system will require the user’s current credentials to authenticate him or her before updating the account with the new specified password. If the username/email is already stored in memory, then the system will only require the user to specify the current password. If the system uses a “stateless” environment, it will require both username and current password for the authentication.

Input

Old password and new password. Optionally the username/email

Output

If the transaction succeeds, the system will send a “Success” message, but if the transaction fails, the system will send back an “error” message.

Preconditions

The user is already registered with the system, and his or her account is active.  

Frequency of use

Many times a day

GAME SEARCH

SEARCH TERM

The following table outlines the details of use case # 4:Search Term

Use Case ID:1

Search Term

Description

User will enter title of the game that the user wants to search and the system will generate a list of possible matches.

Input

Title of the game.

Output

If the query is successful a list of possible matches that are related to the user's input will be displayed. If the query fails, a message is returned to the user that no results were found.

Preconditions

The user must enter at least a single alphanumeric character. Non-alphanumeric characters will be stripped from the term before querying the database to protect against sql injections.

Post Conditions

The list of query results are clickable and take the user to that individual title’s page.

Action

The user will input a search term. The database is searched for possible matches.  If matches are found, they are returned to the user’s screen.

GAME DETAIL

The following table outlines the details of use case # 2: Game Detail

Use Case ID:2

Details of Games.

Description

From the given list generated by the system user will be able to select any game and get the details regarding that particular game.

Input

Particular game selected by the PH user to get the details.

Output

User will get details of selected game such as: Game title, Platform, Main Characters, Game Plot, Game levels.

Preconditions

There should be a list of games for user to select to get the details.

Post Conditions

If succeeded user will be transferred to the next page where user will be able to view the game detailed description.

Action

A detailed description of the selected game by the user will be prompted up on the user's screen.

CONFIGURE GAME

The following table outlines the details of use case # 3: Configure the game list

Use Case ID:3

Configure the games of the list.

Description

Admin User will be able to add delete or modify the given list of the games as per the change in environment or holidays or particular seasons. Regular users will not be able to operate this section of the game.

Input

The selected game to be deleted or modified from the list of games or any new game that is supposed to be added in the list.

Output

A whole new list of game after the modification made by the Admin user.

Preconditions

 User must be Admin only and should be logged in to make changes.

Post Conditions

If succeeded, Admin user will be able to modify the given list of games.

Action

Admin user will make the changes in the list of the games as per need of holidays, seasons or changes in game environment.

GAME CATALOG

SELECT PLATFORM AND GENRE

The following table outlines the details of use case # 1:Select Platform and Genre

Use Case ID:1

Select Platform and Genre

Description

A user will select a game by first viewing the platform being used then the genre the title would be categorized as, then the system will generate a list of titles. The user will then select a game.

Input

The platform and genre user selected.

Output

User should see a navigation bar with platform titles and a drop down list of genres within the platform.

Preconditions

The user must have an intended platform to view.

Post Conditions

The sublist of genres are clickable and display another sublist of games within that genre.

Action

The user will select a platform to search by clicking the name of the system. The system will display the given genres for the specific platform.  The user will select the genre.

VIEW GAME TITLES

The following table outlines the details of use case # 2:View Game Titles

Use Case ID:2

View Game titles

Description

Once the user selects the platform and genre, a list of games will be displayed

Input

Game id user selected

Output

  • Game Title
  • Game Description
  • MSRP
  • Rating

Preconditions

The user must know what genre

Post Conditions

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

Action

Once the user selects a platform to search by clicking the name of the system. The system will display the given genres for the specific platform.  The user will select the genre then a drop down menu of games will be displayed. The user then selects a game title.

CONFIGURE SEARCHABLE GAMES

The following table outlines the details of use case # 3:Configure Searchable Games

Use Case ID:3

Configure Searchable Games

Description

An admin will have access to add and/or delete any game titles that will be displayed in PH’s game catalog.

Input

Game id

Output

A list of game titles within a certain platform and genre  

Preconditions

The user must know what genre a game can be categorized as.

Post Conditions

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

Action

The admin will add any new titles released to the stored information in PH’s database

REVIEWS

ENTER REVIEW

The following table outlines the details of use case # 1:Enter Review

Use Case ID:1

Enter Review

Description

A game review can be given on any title in the PH game catalog.  The registered PH user will be able to review as many games as they desire but will be submitted for review.

Input

The text review from the user

Output

The approved review of any game  

Preconditions

The user must be logged in and must have basic knowledge on the game that is being reviewed.

Post Conditions

If approved the user’s review will appear on the page of the specific game chosen.

Action

The user will select a title from the game catalog to review.  The user will type the content into a text box on all aspects of a particular title.  Then once the review is complete the user will hit the submit button.

ENTER STAR RATING

The following table outlines the details of use case # 2:Enter Star Rating

Use Case ID:2

Enter Star Rating

Description

Once the user selects the platform and genre, a list of games will be displayed

Input

The amount of stars based on likeability

Output

Stars given to a particular game

Preconditions

The user must be logged in.  Each title must have stars that are clickable.

Post Conditions

The login name of the user will appear on the title’s page with the amount of stars chosen.

Action

The user will select a title from the game catalog to give a star rating to. Once they have selected how many stars to rate the game title, the user will hit submit.

VIEW/APPROVE/REJECT REVIEW

The following table outlines the details of use case # 3:View/Approve/Reject Review

Use Case ID:3

View/Approve/Reject Review

Description

The system will allow PH users the ability to write a review on any particular game title, the submission will go to the PH admin to view the text and decide at that point whether it gets approved or rejected to be then displayed on the PH site.

Input

  • Game id
  • Text review

Output

If the review is accepted the user will be able to view his/her entry on the site of the game title but if it is rejected the PH user will get an email from the PH admin as to why the review was rejected.  

Preconditions

There must be reviews submitted by PH users.

Post Conditions

The approved review will be stored in PH’s database and will be viewable to anyone visiting the site

Action

The admin will get a notification every time a new review is submitted  by a PH user.  The admin will decide at that point if the content submitted is acceptable to be on the PH site.  

FORUMS/DISCUSSION

POST COMMENTS

Use Case ID:1

Posting comments

Description

Admin and user both can post comments in this section regarding the game. User can also ask question on this use case regarding the game or any issues related to game.

Input

Title of the comment if it's a first commenter and the description of the comment in detail.

Output

User's comment will be now shown as a thread on the forums/discussions section as a new thread .

Preconditions

The user must enter at least title and description for a comment to be posted.

Post Conditions

If succeeded the user's comment will be posted on the forums/discussions section of the site.

Action

A thread is created in form of user's comments in forums section.

REPLY TO COMMENTS

The following table outlines the details of use case # 2: Reply to Comments

Use Case ID:2

Reply to comments

Description

Both user and admin will be able to reply to the other comments related to game

Input

Written text by user and admin as comments for games.

Output

Thread is created in form of user/admin comment on forums section of the website.

Preconditions

User must reply to related comments on forums in appropriate way.

Post Conditions

If succeeded comment will be posted on forums/discussion section.

Action

User will be able to reply to another comments.

VALIDATE COMMENTS                                                                                                        

The following table outlines the details of use case # 3: Configure Comments

Use Case ID: 3

Validate comments

Description

This action will be in charge of admin. It will be admin who will be able to control the flow of the comments, add comment, delete any comment if it is inappropriate, in short admin validates the comments posted on the forums.  

Input

The query by admin to configure any comment on forums/discussion section.

Output

Modified forums section after being validated and configured by admin.

Preconditions

It should be an admin user to able to do any changes in this section.

Post Conditions

If user is admin, user can configure and validate or access this section of website.

Action

Unnecessary and inappropriate comments related to game will be removed and old comments will be locked by the admin.

NEWSLETTER

OPT IN / OUT

The following table outlines the details of use case # 1 of the Newsletter: Opt in / out

Use Case ID:1

Opt in / out

Description

The system will provide users with the ability to subscribe and unsubscribe from newsletter emails at will.

Input

The system will provide two checkboxes at the “my account” page.  One box indicating the user is subscribed and the other indicating the user is not subscribed.  The user will only be able to choose one box to indicate their preference.

Output

If the user is subscribed the message, “Thank you for subscribing”  is displayed.  If the user is unsubscribed the message, “You are not subscribed to the newsletter” is displayed.

Preconditions

The user must be registered, logged in, and at their “my account” page.

Post Conditions

The user will be added or removed from the system’s list of current subscribers.

Action

The system will send the newsletter via email the list of subscribers.

EDIT / VIEW SUBSCRIBERS

The following table outlines the details of use case # 2 of the Newsletter: Edit / View Subscribers

Use Case ID:2

Edit / View Subscribers

Description

The admin user also has the ability to view the current list of subscribers and both add or remove users from the list.

Input

The admin user can input a new user’s email to the current subscription list.

Output

The list of subscribers with the user’s email, first name, and last name.

Preconditions

The admin user must be registered as an admin user.

Post Conditions

The edits to the subscription list reflects any changes the admin made.

Action

The system stores the edited list of subscribers.

CREATE / EDIT NEWSLETTER CONTENT

The following table outlines the details of use case # 3 of the Newsletter: Create / Edit Newsletter Content

Use Case ID:3

Create / Edit Newsletter Content

Description

An admin user has the ability to create,  preview, and edit the newsletter content before it is mailed to subscribers.

Input

The admin user generates content for the newsletter using the newsletter template, or edits generated content and approves the newsletter for mailing.

  • Text
  • Images
  • Hyperlinks

Output

The upcoming newsletter is displayed.  If there is no content currently created for the upcoming newsletter, a newsletter template is displayed.

Preconditions

The admin user must be logged in.

Post Conditions

The edited and approved newsletter is submitted to the system for storage where the mailing system will later distribute it.

Action

The newsletter content has been approved and is ready for mailing.

CUSTOMER SUPPORT INTERFACE

SUBMIT QUESTION

The following table outlines the details of use case # 1 of the Support Interface: Enter Question

Use Case ID:1

Enter Question

Description

The CSI will allow registered users to post PH related questions to the PH site and receive answers provided by PH staff.

Once a user fills out the various input fields, the question is submitted to the Support Queue and a support ticket is created by the CSI.  The ticket remains open until the issue is marked resolved by PH staff.

Input

  • Question or comment topic - the customer selects from a drop down list the most appropriate topic related to their question or comment.
  • Question Description - A large blank text box for the customer to input their specific question or comment.
  • Submit - a “submit” button is clicked by the user to send the question to the PH system.

Output

After submission, the system responds to the user with,

  •  “Thank you, your question has been received.”
  •  A unique support ticket number to reference their issue.
  •  “A notification will be sent to your home page once a response has been generated.”

Preconditions

The user must be a registered and logged in.

Post Conditions

The support ticket is forwarded to PH support staff with a status of open.

Action

The PH System accepts the user generated data, issues a unique support ticket number, and marks the ticket as open.

RESPONSE NOTIFICATION

The following table outlines the details of use case #2 of the Support Interface: Response Notification

Use Case ID:2

Response Notification

Description

A PH admin user accesses the Support Queue where a list of open status support tickets is displayed.  The admin selects a support ticket to respond to.  The admin uses the provided text field to respond to the customer.  Once the response has been sent, the customer is notified that a response has been generated and is ready to view.

Input

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

  • Text
  • Hyperlink

Output

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

Preconditions

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

Post Conditions

The PH user can view the PH admin response.

Action

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

CLOSE SUPPORT TICKET

The following table outlines the details of use case #3 of the Support Interface: Close Support Ticket

Use Case ID:3

Close Support Ticket

Description

After responding to the customer’s issue, the admin user changes the status of the support ticket to closed.

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”.

Preconditions

A registered user question or comment must first be generated and in the open status.

Post Conditions

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.

Action

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

System Models

ACCOUNT CREATION AND LOG IN

REGISTRATION

The diagram on the following page describes the process that takes place as part of the registration transaction. The user access the registration page and fills out all required fields. Once the user submits the form, the system begins the processing by first validating each submitted input value.

If any of the fields contains invalid data or is a required field that was left blank, the transaction is aborted and the system returns an error message to the user. Once the user corrects the error and re-submits the process, the input values are once again validated until all fields are validated successfully.

At this point, the system will create and store the new user account within the system repository. If saving the data was successful, then the system will return a “welcome” or “thank you” message to the user.

 

The same process can be seen in the sequence diagram below. The proposed design defines a middle-tier component (Accounts) that will be responsible for all business rules and processing of the input data. The Web site component just routes all calls to the business logic layer, which in turn retrieves or posts data to the database layer.

The diagram also describes an alternative path for successful and failed transactions. If the transaction fails, then the user will receive a message outlining which input fields did not pass validation as to allow the user to correct the data and re-submit.

 

LOGIN

The steps included in the Login transaction are described in the activity diagram below. The transaction begins with the user submitting his or hers username and password. Once the server receives the input, it validates that the username is already registered with the system. If no matching value is found, then the system will return an error message to the user to retype the credentials.

If the username is found in the system, then the stored password is retrieved and evaluated against the one submitted by the user. If both passwords match, then the user is granted access and a successful message is returned. If the passwords do not match, then the system will return an error message to correct the credentials and retry again.

The Accounts component processes the request, access the data repository and evaluates any business rules required for the transaction. The first task is to retrieve the user account with a matching email/username from the request. If the account is found, the data layer will return a user account back to the Accounts component.

The system will then evaluate, if the account was found, that both passwords match. If so, the system will inform the Web Site component to grant access to the user. The Web Site component will then redirect the user to the appropriate page.

If the credentials did not pass validation, the system will return an error message to the user. This is depicted in the “alternative” flow of the sequence diagram below.

CHANGE PASSWORD

To change the password, the user must submit the old credentials as well as the new ones. This is done to ensure that the user requesting a change of password is authentic. The activity diagram below shows the steps required to process the “change password” transaction.

The first step in the activity diagram represents the system receiving the input values from the user. If the system already has stored the username or email, then only the old password would be required. If the system does not have the current logged in username in memory, then both username/email and password will be required to authenticate the user before updating the account with the new password.

The system validates the user credentials and if they match, it proceeds to update the account with the new password. The new password will be submitted through two fields to ensure that the user has typed the desired value.

The sequence diagram shown on the next page describes the responsibilities for each component. As shown, most of the work is done at the middle-tier layer. The Accounts component is responsible for evaluating the input values, querying the database and updating the user account.

The Web Site component is only in charge of routing the requests to the middle-tier component and returning a transaction result message back to the user.

Not shown in the diagram is the evaluation of both “new password values” entered by the user. This evaluation could be done at the client browser to provide faster feedback.

DOMAIN ANALYSIS

Domain RegisPHSRS.png

The class diagram above identifies the main entities for the Registration/Authentication module.

The following entities have been identified:

User :

This entity is responsible for authenticating any user and grant access to the system. The User serves as the base class for all different types of clients, such as Customer and Administrator. The User entity has a dependency on the HashingProvider entity. This utility class is used to hash any password required to authenticate the user.

Customer :

This entity represents a single customer and inherits from the User class. It contains a unique attribute of “CustomerSince” which defines how long a customer has been a client of our system.

Administrator :

This entity also inherits all attributes from the User class. It has the ability to create other Administrator type of users. (only administrators can create other admins).

HashingProvider :

This entity is responsible for hashing any string based on the defined algorithm. It is used by the User entity to hash the password strings.

GAME SEARCH

Humera

SEARCH TERM

The diagram here shows how to get the information about any Nintendo game from PH's database.

 

First user must enter the game title in the search field of the website.

 

The system will check whether user has entered valid characters, if no, the system will prompt an error message.

 

If it is a valid search title, the search term will be matched from the database entries until similar match found.

 

If no matches are found the system will generate message " no results for that search term."

 

If the database has that game or similar game, the results will be generated for the user.

Image

The sequence diagram shown above describes the responsibilities for each component. As shown, most of the work is done at the middle-tier layer. The Search Module is responsible for validating the search, querying the database and displaying the results to the website for the user to view.

The Web Site component is only in charge of routing the requests to the middle-tier component and returning a transaction result message back to the user.

GAME DETAIL

The diagram here shows how the user has to select a game from a given list of games to get the details about it.

 

The system will then verify whether user is selecting a game for details before clicking to submit button for details about the game.

 

If user has selected the game system will display the details of the game like: game title, platform, genre, main characters, different levels of the game, and the story line up.

 

If there is no selection done by the user an error message by the system will be prompted saying " please select  a game."

Untitled Diagram (2)PHSRS.png

As shown in the sequence diagram above most of the work is done in the detail module of game. It is responsible for validating the selected game by user, queering the database and also displaying the details to the website. Website will be only the medium to send the requests to the module and returning the result generated by the detail module to the user.

CONFIGURE GAME

 

The diagram here describes how system requires only admin to be the one who will be able to access this section.

 

As, for the first step system will ask user to login, it will then check if the user is admin or not.

 

If the user is not an admin it will prompt an error message for user informing " user must be admin."

 

If the user is admin, system will allow the user to configure the game.

 

If the admin is trying to make any changes that cannot be made it will show an error message and if changes are accepted by the system, the new changes will be displayed in game list.  

Untitled Diagram (3)PHSRS.png

As shown above in the sequence diagram, the configuration module will handle most of the work related to admin's query of making changes in the game list depending on holiday seasons, system changes etc. Websites helps to transfer the message the message to the admin whether the changes can be done or not.

DOMAIN ANALYSIS

Game Search Domain (1)PHSRS.png

The class diagram above identifies the main entities for the Game Search module.

The following entities have been identified:

User: This entity represents a single visitor, registered user or not, that can visit the site to search for games.

Database: This entity also inherits all attributes from the Results class.  It has the capability to store game titles by platform and genre with descriptions and release dates.

Game: This entity is responsible for validating the search based on the criteria that is within the database.

GAME CATALOG    

Melinda

SELECT PLATFORM & GENRE

Game Catelog 1PHSRS.png

The diagram on the left will describe how a user can search through different menus to view reviews, ratings, and price for any given Nintendo game.  To access the game catalog database, the user will select the option on the site for the game catalog.  Before being able to select the actual game, the options are filtered by system of preference then genre of games.  A list of results will then be displayed in alphabetical order.

GC SDPHSRS.png

The sequence diagram above demonstrates how a user will look for a game title using the game catalog.  The user will select a particular Nintendo gaming platform and the genre of interest on the PH site.  Then the search component will query the database for desired game ids to get a list of games under the two parameters of platform and genre.  The database will then display the list of games on the PH website.

VIEW GAME TITLES

Game Catalog 2 (2)PHSRS.png

The activity diagram to the left demonstrates how a user views game titles on the PH site using the game catalog.  The user will select which platform they are using then a list of genres will be displayed. Game titles are categorized under the specific genre.  If there title is not in the game catalog they’ll have to perform another search but if it is displayed then the user will select the desired title.  The system will then display the page of the game chosen.

The sequence diagram on the next page shows how the user can view games on a list.  After the database is queried for the list of games under the genre chosen, the user will see if the desired game is in the list or not.  If it is the page for the game will be displayed. If the game is not on the list then the user will not see the game and will be forced to look for another game.

GC SD#2PHSRS.png

CONFIGURE GAME CATALOG

The activity diagram below demonstrates how the admin can configure the games that are in the system’s database.  First, the admin will search for the game and if the game exists in the database the game info will be displayed.  Once it is displayed the admin will be able to edit the details or delete the game tag altogether.  But, if it does not exist the admin will be able to add a new game tag. They can enter all the information such as the game title, description, MSRP, and rating.  In both scenarios, at the end of the transaction the information will be saved to the database.

AD GC #3PHSRS.png

        The sequence diagram below demonstrates the process of how an admin will configure the game catalog.  Initially, the admin will search for a title and the search component validates the entered search.  If it is an acceptable search the database will be queried.  If search is successful the admin will be able to use the configuration component to edit the info and will be saved to the database. If the search fails then the admin will proceed to add a new game to the database.  Once the information is saved the game catalog will be updated and users will be able to look for new games and view edited info on existing titles.

SD GC#3PHSRS.png

DOMAIN ANALYSIS

Domain Game (2)PHSRS.png

The class diagram above identifies the main entities for Game Catalog.

The following entities have been identified:

Platform: This entity is has a dependency on the genre entity to access the database .  It contains a unique attribute of “Platform Name” which defines the different Nintendo gaming systems.

Genre: This entity has a unique attribute of “Genre Name” that will describe the type of category the games will be listed under.

Game: This entity will have a unique attribute of “Game id” which will give each game a specific identifier that cannot be replicated.

User:  This entity represents the user viewing the catalog and it can be anonymous because a non-registered user can view the PH site.

Database: This entity inherits attributes from genre, game and platform to categorize them when a search of the catalog is called.  It holds all the necessary attributes needed to then have content displayed on the site.

SUBMIT USER REVIEW

Melinda

ENTER REVIEW

Review#2PHSRS.png

The diagram on the left describes the process that takes place as part of the user review transaction. The user searches for the desired game title either in the game catalog or by entering the game.  There the user clicks the review button and begins to write content in the text box.  Once complete, the user submits the review for approval.

The sequence diagram below demonstrates the process of submitting a review from a registered PH user.  The user will enter title and  content of the review onto the website.  Then it will be sent to the admin for determination of approval or rejection.

SD Review#1PHSRS.png

ENTER STAR RATING

Review#2PHSRS.png

The diagram on the left describes the process that takes place as part of the user star rating transaction. The user searches for the desired game title either in the game catalog or by entering the game.  There the user clicks the review button and begins to write content in the text box.  Once complete, the user submits the review for approval.

SD StarPHSRS.png

The sequence diagram above demonstrates the process of how to complete a star rating.  The PH user must be registered to take advantage of this function.  After they have chosen the desired game they will click a button for review then they will have access to click on the amount of stars to rate the particular game.  There is no need for admin controls.  The rating will be saved to the database then displayed on the game’s info page.

VIEW / APPROVE / REJECT REVIEWS

Review#3PHSRS.png

Once the review is received, an administrator then has the ability to either accept or reject the review based on stipulated review guidelines.

If the review is acceptable, the administrator submits the review to the database where it will then be live on the site and a message is displayed on the user’s homepage notifying them that their review has been approved.

If the review is rejected, the administrator does not submit it to the database and instead deletes it.  Deletion of a pending review generates a message displayed on the user’s homepage notifying them that the review violated review guidelines.

SD Review #3PHSRS.png

The sequence diagram shown above describes the responsibilities for each component. As shown, most of the work is done by the admin. The admin is responsible for managing the reviews, accessing the database, and replying back to the user.

The Web Site component is only in charge of routing the requests to the admin and returning a transaction result message back to the user on whether their review was denied or requested.

DOMAIN ANALYSIS

Domain StarPHSRS.png

The class diagram above identifies the main entities for Reviews.

The following entities have been identified:

Review: This entity represents the entire review a user submits, it contains a unique attribute of “review title” that gives the name of the review.  It inherits attributes from game.  The utility class allows the review to be saved into the database  

Game: This entity is responsible for all attributes that pertains to the each game.  It will be categorized under a specific genre and platform.  The review itself and the star ratings are unique to each game.

 

User: This entity represents a registered PH user with unique attributes of the specific user id and names.  

GameSave: This utility class allows for the “review” entity to be saved to the database.

FORUMS / DISCUSSIONS

Humera

POST COMMENTS

The diagram here describes the way how both user and admin will be able to add comments in forums section.

 

The system will first validate whether the first commenter has title and proper description for the comment or not.  

 

If the comment does not have it, system will generate an error message prompting" please enter title and description for the comment."

 

If the comment is valid it will be displayed on the forums section as a new thread.

Untitled Diagram (4)PHSRS.png

The sequence diagram above shows clearly that most of the responsibilities of comments section is handled by second tier layer. It validates whether the first commenter has title and description in its comment.

The website component will only work as the in charge medium of transferring message and returning it back to the user and admin.

REPLY TO COMMENTS

The diagram shows how both User and Admin will reply to the comments already displayed on the forums section.

 

As soon as the user or admin is done writing the response to the comment on discussion section and hits to respond to the comment a new thread as a response to that comment is displayed on the comments section.

 

Untitled Diagram (5)PHSRS.png

In this sequence diagram of response section, response module works as the medium to post the replies posted by both user and admin and notify it to the website and both user and admin.

VALIDATE COMMENTS

The diagram here describes how it will be only admin who will be to have an access to this section of the website. As soon as user logs in, it will check whether user is admin or not, if user is not an admin, the system will prompt an error message for user saying " User must be admin."

 

If the user is admin, then he will be able to access this section and will be able to validate the comments, manage flow of the comments also admin can delete any such comment that looks in appropriate for the website.

 

Also if for some reason admin is not able to configure comments it will take back  the admin to the login step to start over again.

If the admin is able to make changes in the forums section, new changes will now be displayed on the forums section.

Untitled Diagram (6)PHSRS.png

The sequence diagram shows that the second tier that is configure comments section will be responsible to check whether the user is admin, if user is admin changes can be made by admin. also there will be some cases when admin too cannot make any changes.

Website component will be charge of routing messages to second tier and returning it back to admin.

DOMAIN ANALYSIS

Untitled Diagram (7)PHSRS.png

The class diagram above identifies the main entities for the Forums/Discussion module.

The following entities have been identified:

PH User: This entity represents a single visitor, registered user that can add comments in forums.

Admin User: This entity represents the user that can edit the forums section by deleting and editing comments. It inherits all properties of user.

Forums Posts: This entity represents the first comments done by user and admin.

Forum Reply: This entity represents the responses given by user on the other comments posted by other PH users.

Database Access: This entity is both accessed by Forum posts and reply to store comments and modify it. Inherits all attributes of Result class.

NEWSLETTER

Shane

OPT IN / OUT

The diagram on the left depicts the PH user process of opting in or out of receiving the regularly mailed newsletter.  Once the user has logged in they navigate to the “My Account” page where they can select user preferences.  Here they are supplied two check boxes that indicate if they are currently subscribed or not.  If they are not subscribed the box labeled “Opt out” is checked.  If the user wishes to change their subscription and receive the newsletter, they should be able to select the “Opt in” box.  A user cannot select both boxes, nor should they be able to have neither box selected.  The newsletter subscription is a binary either or choice.  If the user chooses to receive the newsletter, the system sends a message thanking them.  If they choose not not receive the newsletter, the system responds with a message alerting them that they are no longer subscribed.

EDIT / VIEW SUBSCRIBERS

     The flow chart diagram on the left depicts the process of an admin user viewing and editing the current list of subscribers.  One an admin user logs in, they are able to retrieve the current list of subscriber information including first name, last name, and email address.  The admin user has the ability to both add and delete specific PH users to and from this list.  Once any edits have been made to this list, the admin users submits the updated list to the database.

     The sequence diagram below also outlines this process.  The proposed design defines the subscription list which exists as a table within the database that holds the first name, last name, and user ID of all subscribers to the newsletter.

CREATE / EDIT NEWSLETTER CONTENT

     The flow chart to the left depicts the process an admin user executes to create and or edit the newsletter content.  Once the admin user is logged in, they should be able to receive a list of past, current, and upcoming newsletters.  After selecting the upcoming newsletter, a detailed page of the newsletter is displayed.  If no content has yet been added to the newsletter, a newsletter template is displayed.  This template is the starting point for all newsletters.  At this detailed view, the admin user can add or edit content such as text, graphics, and hyperlinks.  Once the admin has finished, the newsletter is submitted to the database where it will later be mailed out to the subscriber list.

     The sequence chart below defines the middle-tier component, Newsletter Editor Module.  The newsletter editor module provides a template for all newsletters to follow.  While the content changes with each newsletter edition, the overall look should remain consistent.

DOMAIN ANALYSIS

Domain NewsPHSRS.png

The class diagram above identifies the main entities for the Newsletter module.

The following entities have been identified:

Newsletter:

The newsletter entity is conveys information to PH users about PH and contains textual and graphical data known as description, an issue number and the date of publication.   The newsletter entity has a dependency on the database entity where the data for the newsletter is stored.

PH User:

This entity represents a single customer and inherits from the User class. It contains a unique attributes of customer ID which is the unique identifier for the customer, along with the customer name and email address.

Administrator:

This entity also inherits all attributes from the User class. It has the ability to create and edit newsletter content.

CUSTOMER SUPPORT INTERFACE

Shane

SUBMIT QUESTION

     The flow chart on the left depicts the process of a PH user submitting a question or comment to the Support Interface for review and response by PH admin.  Once a registered user logs in, they navigate to the Customer Support page where they can address PH admin staff.  The user is presented with a drop down menu to select the topic that best describes their reason for contacting.  After selecting the appropriate topic, the user can enter text into the provided large area text box.  Once the user has finished typing their correspondence, they click the submit button which sends their communication to the Support Interface where it awaits a PH admin user response.

   The below sequence chart represents the PH user’s steps required for submitting a comment or question to PH.  The CSI is a middle-tier component that facilitates communication between the PH user and PH admin.  It manages the open tickets and stores them in the Support Queue.  All new PH user correspondence is submitted to the system with an open status.  Any open status item is added to the Support Queue by the CSI.

RESPONSE NOTIFICATION

   The flow chart on the left depicts the process of the admin user responding to the registered user’s question or comment.  Once logged in, the admin user navigates to the CSI.  There the user selects an open support ticket from the Support Queue.  At this detailed view of the individual support ticket, the admin user is given a large text area with which to respond to the PH user’s communication.  Once the admin generated response is submitted to the CSI a notification is sent to the PH user’s account page notifying them that a response to their issue is available for them to view.

     The sequence chart below describes the sequence of events and the relation of the CSI and the Support Queue.

CLOSE SUPPORT TICKET

     The diagram to the left depicts the process of an admin user changing the status of a support ticket to closed.  Once a support ticket is changed to the closed status, the customer’s issue is considered reconciled and the support ticket is removed from the pool of open status support tickets in the Support Queue.  After closing the support ticket, a new list of open status support tickets is generated by the Support Queue to help ensure that only one support ticket is being worked on by one admin user at a time.

     The below sequence chart depicts the process of an admin user changing the status of a support ticket to closed and the CSI then delivering a new open status support ticket from the Support Queue to the admin user for response.

DOMAIN ANALYSIS

Domain SupportPHSRS.png

The class diagram above identifies the main entities for the Customer Support module.

The following entities have been identified:

CSI:

The customer support interface entity is responsible for managing the messaging transactions between the customer and the admin.   The CSI entity has a dependency on the database entity where the data for customer correspondence is stored.

PH User:

This entity represents a single customer and inherits from the User class. It contains a unique attributes of customer ID which is the unique identifier for the customer, along with the customer name and email address.

Administrator:

This entity also inherits all attributes from the User class. It has the ability to create responses within the CSI for customers to view.

NON-FUNCTIONAL REQUIREMENTS

Category

Non-Functional Requirements

Reliability

The site should be available to all users with a maximum downtime of 10 hours per calendar year.  At the time of delivery the system should function 100%.  No issues or malfunctions should be found in account creation, navigation, user reviews, the discussion board, customer support interface, and displaying data to the user.

Availability

The system should be available to all users with an internet connection using any common browser both mobile or desktop.  With a minimum of response time of 4 page loads in 5 seconds.  Should the database require a restart or an unexpected outage, all data should be recoverable.

Maintainability

Admin users and site administrators should have the ability to add new user information in bulk to the database.  The system should also allow for the expandability of user attributes and game platforms.

Security

SSL connections and SSL Certificates shall be provided to secure client and system data.  Every user should be forced to develop a strong password when registering, consisting of at least one capital letter, one number, and a minimum of 8 characters.

 

APPENDIX

Hardware

Database System

        

INDEX

Non-Functional Requirements

85

Overall Description

Assumptions and Dependencies

Constraints

Product Perspective

Product Functions

User Characteristics

7

8

7

7

7

7

System Models

Change Password

Close support Ticket

Configure Game

Configure game catalog  

Create/Edit Newsletter Content

Domain Analysis(Account Creation and Login)

Domain Analysis(Customer Support Interface)

Domain Analysis(Forums/Discussions)

Domain Analysis(Game Catalog)  

Domain Analysis(Game Search)

Domain Analysis(Newsletter)

Domain Analysis(Review)  

Edit/View Subscribers

Enter Review  

Enter star rating

Game detail

Login

Opt in/Opt out

Post Comments

Registration  

Reply to Comments

Response Notification

Search term

Select platform and genre

Submit questions

Validate comments

View game titles  

View/approve/reject review

33

36

80

44

51

72

39

83

68

54

46

75

60

70

55

57

42

34

69

62

32

63

78

41

47

76

66

49

59

System Requirements

Change Password

Close Support Ticket

Configure Games

Configure Searchable Games

Create/Edit Newsletter Content

Edit/View Subscribers

Enter Review

Enter Star Rating

Game Detail

Login

Opt in/out

Post Comments

Registration

Reply to Comments

Response Notification

Search Term

Select Platform and Genre

Submit Question

Validate Comments

View Game Titles

View/Approve/Reject Review

17

19

32

21

23

29

29

24

24

20

18

28

26

17

26

31

20

22

30

27

23

25

User Requirements

Account Creation and Login

Catalog Search

Change Password

Close Support Ticket

Configure Game

Configure Searchable games

Create/Edit newsletter content

Customer Support Interface

Edit/View Subscriber

Enter Review

Enter Star Rating

Forums/Discussions

Game Detail

Game Search

Login

Newsletter

Opt in/out

Post Comments

Registration

Reply to Comments

Response Notification

Reviews

Search Term

Select Platform and Genre

Submit Question

Validate Comments

View Game Titles

View/Approve/Reject Review

9

8

11

10

17

11

12

16

16

16

13

13

14

11

10

9

15

16

14

9

15

17

12

10

12

16

15

12

14