-
Notifications
You must be signed in to change notification settings - Fork 0
Requirements Document
v.2 - February 5, 2016
- Introduction
- Organization Requirements
- General Description
- User Requirements
- Specific Requirements
- Appendix
The purpose behind this Requirements Document is provide a succinct specification of the Party Game Platform project, summary of expected features, and desired user experience. It aims to provide the documentation to convey all necessary information for building and implementing the project to completion. Many parts of this document, particularly the section headings and overall layout, are based on the concepts and specifications given in the IEEE guide for software requirements specifications [1].
The intended audience for this document includes:
- Developers who will be designing and implementing the project
- Stakeholders who have a vest interested in the success of the project
This project will result in a web application called the Party Game Platform. The application will provide a web accessible platform for playing games designed for a casual setting that are interacted with via mobile devices. By utilizing a common device that a most Americans have access to, the platform can provide accessible, easily used entertainment in a variety of locations and scenarios [2].
While it may be used across multiple locations, the intended use of the application is with multiple individuals playing in the same location to allow for a social element of entertainment.
The remainder of this document is split into sections that detail various aspects of the project. The Organization Requirements outline the aims of the development group in regards to the project. The General Description provides a high level description of the factors that affect the product. The User Requirements outlines the product from a user's perspective. The Specific Requirements layout the functional and nonfunctional requirements for the product in detail. Finally, the Appendix contains supplementary information needed for this document.
The Minimum Viable Product (MVP) will consist of a working version of the server platform as well as one functioning game. To provide further expectations for our MVP, each of those components will have the following features:
| Feature Description | Related Requirements |
|---|---|
| Be accessible from a public URL or IP address | B.A.1-5 |
| Accept connections from any device with a modern Web browser | B.A.1-5 |
| Host a working game | B.H.1-4 |
| Feature Description | Related Requirements |
|---|---|
| Allow a user to connect to the platform | F.A.1-5 |
| Allow a user to create a game | F.C.1-5 |
| Allow other users to join a created game | F.C.6-15 |
| Allow for a group of users to play completely through a game together | F.P.1-9 |
| Be intuitive and performs well enough for most individuals to begin playing a game within 30 seconds | F.R.1-3, B.R.1-3 |
The goal for this semester is to complete the Minimum Viable Product, as described in 2.1 Minimum Viable Product.
Pending the successful completion of a Minimum Viable Product to serve as a prototype and demonstration platform, this product can be continued in a couple of ways:
- The product remains open-sourced to allow anyone else to continue development on the platform for personal and/or commercial use.
- The product continues to be developed and improved for a production environment. It can then be hosted for the general public to utilize at their discretion and for their entertainment. The product could be sold in sessions or in a subscription model to pay for the hosting costs and future development work. An alternative is to setup a donation fund while allowing games to be played at no cost.
The determination of which of these paths, if any, is taken will need to be determined by the parent organization as the Minimum Viable Product reaches completion. Other issues that will need to be resolved at that time will include the license under which the software is released as well as equity / ownership of the product if it becomes commercially viable.
As a whole, the project will result in a standalone web application without any external dependencies for it's complete functionality.
The web application will be publicly reachable from a hosted location with any Internet capable device. It will permit parties of people to join created games and interact with them via the previously mentioned Internet devices. Through the interactions, the games will be played and will provide social entertainment in an accessible and easily used manner. If the event that more than one game is developed for the platform, the users will have the option to select from a list of games and choose one to play together.
The first fundamental assumption of this platform is that the users will each have a device capable of loading a website designed with the ReactJS framework [3]. Research has shown that a large majority of Americans own some form of mobile computing device, so the development organization feels that this it is an acceptably safe to make the assumption that enough devices will be present at a normal social gathering to play a game [2] [4].
The second fundamental assumption this project makes is that the users will have access to a publicly available server hosting the platform, either through private cellular data plans or wifi internet access. Research from the Pew Research Center indicates that 80% of Americans have internet access either through a home broadband connection (67%) or through a smart phone (13%) [5]. Again, the team feels comfortable that internet access is prevalent for a large portion of Americans to have access to the project.
The third assumption made is that a server capable of running Scala, serving ReactJS, and handling internet requests will be available to host the platform and respond to requests made to the service.
The target audience for this platform are individuals of any gender or nationality who are older than 13 years of age and own or can access a mobile device with Internet access. The ideal situation is at informal social gatherings where groups of individuals wish to play a social game as a means of entertainment. One aim of the platform is to not restrict its use to only persons with medium to high levels of technical knowledge. By using common technologies that most American adults and teenagers are familiar with, the product is designed to be welcoming to individuals with any amount of technical or gaming experience. By focusing on the content provided via the game rather than the mechanics of the game itself, persons with no prior experience with the platform should be able to intuitively understand how to play with 15 seconds.
The following list describes potential attributes of users that may need to be taken into account for designing the product:
- Have access to a mobile device with access to the Internet
- Have enough understanding to access a website with said device
- Understand the mechanics of enter text into simple input fields and pressing buttons within a webpage
This section will encompass the detailed requirements that describe what is needed to be implemented for the product. The functional requirements outline key points of behavior and the user experience, while the nonfunctional requirements describe other requirements that will factor into the success of the project, such as user security, reliability, and performance. Within this section, there are features that are critical for the minimum viable product, features that are a priority but are not critical, and finally features that would enhance the product but are ultimately optional. They are denoted through the following symbols:
| Symbol | Meaning |
|---|---|
| 🔵 | Critical feature |
| ⚫ | Preferred feature |
| 🔴 | Optional feature |
The following requirements are separated into function and nonfunctional, as described above, then segregated into their technical domains (the client-side, or "front end", and the server-side, or "back end" of the application), followed by a final division into feature summaries. The tasks are ordered first by priority as indicated by the previously mentioned symbols and then by logical order of appearance or use within the product. In addition, each requirement is given a unique identifier so that each requirement can be traced across the development of the project.
| Priority | Identifier | Requirement Description |
|---|---|---|
| 🔵 | F.A.1 | Given the URL of the service, be able to load it in a web browser |
| 🔵 | F.A.2 | Upon accessing the service, be presented with a list of possible games to play |
| 🔵 | F.A.3 | Clicking the icon or name of any shown game will lead to a screen allowing a new game to be created or to join an existing game. |
| 🔵 | F.A.4 | Allow the user to back or cancel out of a selected game screen back into the game selection screen |
| 🔵 | F.A.5 | In the selected game screen, allow a user to create a new game or to join a new game |
| Priority | Identifier | Requirement Description |
|---|---|---|
| 🔵 | F.C.1 | When the option to create a game is selected, proceed to show a waiting room screen |
| 🔵 | F.C.2 | The waiting screen will show 4-8 alphanumeric characters that function as the game code |
| 🔵 | F.C.3 | The waiting screen will show the usernames and colors of every player who has joined the game and will update to remove any players that leave or disconnect from the game |
| 🔵 | F.C.4 | The waiting screen will show an input that will allow a user to leave the current game |
| 🔵 | F.C.5 | The waiting screen will show an input that will allow a user to indicate that all players have joined which will start the game with the current party |
| 🔵 | F.C.6 | When the option to join a game is selected, the user will be shown a join game screen |
| 🔵 | F.C.7 | In the join game screen, a user will be given an input to enter a game code, which determines which game to join |
| 🔵 | F.C.8 | In the event that a game code is not valid, notify the user and remain at the join game screen |
| 🔵 | F.C.9 | If an inputted game code is valid, proceed to allow the user to input a username and to select a color. Do not permit the user to proceed until both inputs are satisfied |
| 🔵 | F.C.10 | If a user tries to join with a username which has already been taken, the user is notified, and must enter an alternative username to join |
| 🔵 | F.C.11 | After a user has selected a username and color, allow the user to indicate completion and show the previously mentioned waiting room screen |
| 🔵 | F.C.12 | When any user in the waiting room selects to start the game, show a timer of 5 seconds in order to allow any user to cancel the start |
| 🔵 | F.C.13 | If the start timer of the waiting room is canceled, simply continue to show the waiting room as stated in requirements F.C.2-5 |
| 🔵 | F.C.14 | If the start timer completes without cancellation, proceed to load the game for all players |
| ⚫ | F.C.15 | Allow the device responsible for creating the game to have the option of also functioning as a controllable device |
| Priority | Identifier | Requirement Description |
|---|---|---|
| 🔵 | F.P.1 | According to the logic of the game started, allow a party of players to proceed through the game together until completion |
| 🔵 | F.P.2 | In the event that a player disconnects, allow them to rejoin using the game code that was previously entered for this particular game |
| 🔵 | F.P.3 | If a player disconnects, the game should allow for continuing without a player |
| 🔵 | F.P.4 | The game should continue to show the game code in a non-obtrusive manner so as to allow disconnected players to see it |
| 🔵 | F.P.5 | The device that created the game should show general information at the individual game developer's discretion |
| 🔵 | F.P.6 | Player devices should show enough information to be able to play the game even without a main display device |
| 🔵 | F.P.7 | When a game is completed, the player devices should be shown an option to either end the game or to restart the selected game with the current party |
| 🔵 | F.P.8 | If the option to close a completed game is selected, all devices should be directed back to the game list screen detailed in F.A.2 |
| 🔵 | F.P.9 | If the option to restart a completed game is selected, all devices should be set to restart the game as described in F.C.14 and F.P.1 |
| ⚫ | F.P.10 | Allow the main display device to close or restart the current game |
| 🔴 | F.P.11 | Allow players that are not part of the original game party to join the game in a spectator mode |
| Priority | Identifier | Requirement Description |
|---|---|---|
| ⚫ | F.U.1 | Provide a portal to allow other developers to upload games (see B.A.6) |
| ⚫ | F.U.2 | Provide documentation outlining the API for developing a valid game that is supported by the server |
| ⚫ | F.U.3 | Enable moderation of games to prevent obscene games on the platform |
| 🔴 | F.U.4 | Provide a listing of other third-party games |
| Priority | Identifier | Requirement Description |
|---|---|---|
| 🔵 | B.A.1 | Maintain a publicly accessible endpoint from a URL that serves the platform to any received requests |
| 🔵 | B.A.2 | Allow clients to query for all available games to be played |
| 🔵 | B.A.3 | Allow clients to query for information and resources pertaining to a specific game |
| 🔵 | B.A.4 | Allow clients to create a game round with a specific game, and designating this client as the master client for a game round |
| 🔵 | B.A.5 | Allow clients to join a game using a supplied game code. This will have the client join a game party |
| ⚫ | B.A.6 | Accept submissions for third-party developed games from the front-end client (see F.U.1) |
| 🔴 | B.A.7 | Analyze uploaded, third-party games for malicious content |
| Priority | Identifier | Requirement Description |
|---|---|---|
| 🔵 | B.H.1 | Relay information from a master client to other clients as indicated by the master client |
| 🔵 | B.H.2 | As directed by a master client, or if a game becomes inactive, terminate a game round or restart one |
| 🔵 | B.H.3 | As indicated by the master client, track the actions of a game round and store the actions until the game round ceases to exist or is restarted |
| 🔵 | B.H.4 | Upon request, return the actions of a game round in order to facilitate a synchronization of clients that become disconnected or are out of sync |
| Priority | Identifier | Requirement Description |
|---|---|---|
| 🔵 | F.R.1 | Ensure the loading time of any given game screen is less than 2 seconds |
| 🔵 | F.R.2 | Allow any game to be created and be in a waiting room within 30 seconds |
| 🔵 | F.R.3 | Have all screens within the product to be responsive to device display width |
| Priority | Identifier | Requirement Description |
|---|---|---|
| 🔵 | B.R.1 | Max response times of less than 500 ms, even under substantial load |
| 🔵 | B.R.2 | Average response times of less than 250 ms, even under substantial load |
| 🔵 | B.R.3 | In the event of server failure or error, enable the saving of the server state to disk, allowing for the continuation of active games upon reset |
| Priority | Identifier | Requirement Description |
|---|---|---|
| ⚫ | F.S.1 | Ensure the all inputs are secure against any form of injection attacks |
| ⚫ | F.S.2 | Ensure that no data is leaked between clients within a game party |
| ⚫ | F.S.3 | Ensure that no data is leaked between game parties on the same server |
| ⚫ | F.S.4 | Synchronize actions across clients within a party to prevent cheating or general malfeasance |
| Priority | Identifier | Requirement Description |
|---|---|---|
| ⚫ | B.S.1 | Ensure that the API does not leak any user information given |
| ⚫ | B.S.2 | Maintain a secure connection between the application server and the back-end data store |
6.1.1 IEEE guide for software requirements specifications (1984). doi:10.1109/IEEESTD.1984.119205
6.1.2 U.S. Smartphone Use in 2015
6.1.3 ReactJS
6.1.4 The Demographics of Device Ownership
6.1.5 Home Broadband 2015
#teambitshift