diff --git a/Vision-Document.md b/Vision-Document.md index 6130b37..b02fa52 100644 --- a/Vision-Document.md +++ b/Vision-Document.md @@ -1,114 +1,113 @@ **Group 1** -**Asura Tournament System** +# Asura Tournament System -Vision +**Vision** -**Version 1** - -**Revision History** +**Version 1.0** +## Revision History | **Date** | **Version** | **Description** | **Author** | -| --- | --- | --- | --- | +|----------|-------------|-----------------|------------| | 06/03/22 | 0.1 | Preliminary Draft | Felix Albrigtsen,Jonas Jødestøl Haugland,Kristoffer Juelsen,Kristoffer Longva Eriksen | | 16/03/22 | 0.2 | Changes according to supervisor meeting | Jonas Jødestøl Haugland,Kristoffer Juelsen | | 18/03/2022 | 1.0 | Final Draft | Felix Albrigtsen,Jonas Jødestøl Haugland,Kristoffer Juelsen | -**Table of Contents** +## Table of Contents -[1 Introduction](#_Toc97497362) +[1 Introduction](#\_Toc97497362) -[1.1 Purpose and scope](#_Toc97497363) +[1.1 Purpose and scope](#\_Toc97497363) -[1.2 Definitions, Acronyms, and Abbreviations](#_Toc97497364) +[1.2 Definitions, Acronyms, and Abbreviations](#\_Toc97497364) -[1.3 References](#_Toc97497365) +[1.3 References](#\_Toc97497365) -[1.4 Overview](#_Toc97497366) +[1.4 Overview](#\_Toc97497366) -[2 Positioning](#_Toc97497367) +[2 Positioning](#\_Toc97497367) -[2.1 Business Opportunity](#_Toc97497368) +[2.1 Business Opportunity](#\_Toc97497368) -[2.2 Problem Statement](#_Toc97497369) +[2.2 Problem Statement](#\_Toc97497369) -[2.3 Product Position Statement](#_Toc97497370) +[2.3 Product Position Statement](#\_Toc97497370) -[3 Project goals](#_Toc97497371) +[3 Project goals](#\_Toc97497371) -[3.1 Impact goals](#_Toc97497372) +[3.1 Impact goals](#\_Toc97497372) -[3.2 Result goals](#_Toc97497373) +[3.2 Result goals](#\_Toc97497373) -[3.3 Process goals](#_Toc97497374) +[3.3 Process goals](#\_Toc97497374) -[4 Stakeholder and User Descriptions.](#_Toc97497375) +[4 Stakeholder and User Descriptions.](#\_Toc97497375) -[4.1 Market Demographics](#_Toc97497376) +[4.1 Market Demographics](#\_Toc97497376) -[4.2 Stakeholder Summary](#_Toc97497377) +[4.2 Stakeholder Summary](#\_Toc97497377) -[4.3 User Summary](#_Toc97497378) +[4.3 User Summary](#\_Toc97497378) -[4.4 User Environment](#_Toc97497379) +[4.4 User Environment](#\_Toc97497379) -[4.5 Key Stakeholder or User Needs](#_Toc97497380) +[4.5 Key Stakeholder or User Needs](#\_Toc97497380) -[4.6 Alternatives and Competition](#_Toc97497381) +[4.6 Alternatives and Competition](#\_Toc97497381) -[4.6.1 Challonge](#_Toc97497382) +[4.6.1 Challonge](#\_Toc97497382) -[5 Product Overview](#_Toc97497383) +[5 Product Overview](#\_Toc97497383) -[5.1 Product Perspective](#_Toc97497384) +[5.1 Product Perspective](#\_Toc97497384) -[5.2 Summary of Capabilities](#_Toc97497385) +[5.2 Summary of Capabilities](#\_Toc97497385) -[5.3 Assumptions and Dependencies](#_Toc97497386) +[5.3 Assumptions and Dependencies](#\_Toc97497386) -[5.4 Risk analysis](#_Toc97497387) +[5.4 Risk analysis](#\_Toc97497387) -[5.5 Installation](#_Toc97497388) +[5.5 Installation](#\_Toc97497388) -[6 Product Features](#_Toc97497389) +[6 Product Features](#\_Toc97497389) -[6.1 Intuitive web interface](#_Toc97497390) +[6.1 Intuitive web interface](#\_Toc97497390) -[6.2 User management](#_Toc97497391) +[6.2 User management](#\_Toc97497391) -[6.3 Easy Collaboration](#_Toc97497392) +[6.3 Easy Collaboration](#\_Toc97497392) -[6.4 Automatic Bracketing](#_Toc97497393) +[6.4 Automatic Bracketing](#\_Toc97497393) -[6.5 Scheduling](#_Toc97497394) +[6.5 Scheduling](#\_Toc97497394) -[7 Constraints](#_Toc97497395) +[7 Constraints](#\_Toc97497395) -[8 Quality Ranges](#_Toc97497396) +[8 Quality Ranges](#\_Toc97497396) -[9 Precedence and Priority](#_Toc97497397) +[9 Precedence and Priority](#\_Toc97497397) -[10 Other Product Requirements](#_Toc97497398) +[10 Other Product Requirements](#\_Toc97497398) -[10.1 Applicable Standards](#_Toc97497399) +[10.1 Applicable Standards](#\_Toc97497399) -[10.2 System Requirements](#_Toc97497400) +[10.2 System Requirements](#\_Toc97497400) -[10.3Performance Requirements](#_Toc97497401) +[10.3Performance Requirements](#\_Toc97497401) -[11 Documentation Requirements](#_Toc97497402) +[11 Documentation Requirements](#\_Toc97497402) -[11.1 User Manual](#_Toc97497403) +[11.1 User Manual](#\_Toc97497403) -[11.2 Internal Documentation](#_Toc97497404) +[11.2 Internal Documentation](#\_Toc97497404) -[11.3 Installation Guides, Configuration, and Readme File](#_Toc97497405) +[11.3 Installation Guides, Configuration, and Readme File](#\_Toc97497405) Vision # 1 **Introduction** -This document provides and describes the requirements and features of the "Asura Tournament System", which is the project for the course "DCST1008 – Systemutvikling". The assignment consists of developing a tournament system for a specified stakeholder. The assignment is well defined and is presented as a task to create a management system for multi-team tournaments, where the primary user should be the tournament administrator. +This document provides and describes the requirements and features of the "Asura Tournament System", which is the project for the course "DCST1008 – Systemutvikling". The assignment consists of developing a tournament system for a specified stakeholder. The assignment is well defined and is presented as a task to create a management system for multi-team tournaments, where the primary user should be the tournament administrator. The Introduction includes relevant information that will be used and referenced throughout the document. @@ -128,14 +127,13 @@ UD – Universal Design ## 1.3 References -[1] WCAG 2.1 +\[1\] WCAG 2.1 -This is the standard which we will base our development on, to include Universal Design and accommodate for anyone who wishes to use or explore our products features. -[https://www.w3.org/TR/WCAG21/](https://www.w3.org/TR/WCAG21/) +This is the standard which we will base our development on, to include Universal Design and accommodate for anyone who wishes to use or explore our products features. -Don Norman's principles of Interaction design +Don Norman's principles of Interaction design -[https://www.educative.io/edpresso/what-are-normans-design-principles](https://www.educative.io/edpresso/what-are-normans-design-principles) + ## 1.4 Overview @@ -147,29 +145,25 @@ The rest of the Vision document is organized in different sections where the inf In the ever-increasing landscape of competitions and tournaments, there is a growing need for a simple and effective system to handle many users without the need for end users to worry about the infrastructure and organization of any tournament they would want to host. With this project we wish to decrease the workload put on hosts, and let the administrators focus on the game rather than the technology. -## 2.2Problem Statement - +## 2.2 Problem Statement | The problem of | Easily hosting tournaments without the need for much manual labor | -| --- | --- | +|----------------|-------------------------------------------------------------------| | affects | The Asura gaming community | | the impact of which | Creates lots of extra work for management and moderators that wish to host a tournament or event | -| a successful solution would be | Easily managed - Have a fast-paced setup and completion - Accessible and easily implemented | - -## 2.3Product Position Statement +| a successful solution would be | Easily managed
Have a fast-paced setup and completion
Accessible and easily implemented | +## 2.3 Product Position Statement | For | The management of a large, international, gaming community that hosts events and tournaments. | -| --- | --- | +|-----|-----------------------------------------------------------------------------------------------| | Who | Wishes to more easily create online tournaments and lessen the workload for the organizers | | The (product name) | Is a web application that can be accessed by the specified user | | That | Provides a good and accessible solution that is upheld to international standards and implemented in such a way that anyone would be able to utilize the product given the right documentation and manuals. | -| Unlike | "Challonge", another tournament hosting website | +| Unlike | "Challonge", another tournament hosting website | | Our product | Should be accessible to anyone who needs to use the system and correspond to international standards regarding Universal Design, as well as being straight-forward and simple to use in addition to having smart and useful features. | -# 3Project goals +# 3 Project goals -## 3.1Impact goals +## 3.1 Impact goals - Ensure readability and maintainability of our code and project - To keep our project readable, we will use descriptive Git commit messages and peer review to ensure good quality. For our code specifically we will use descriptive variable names that are easy to understand, as well as commenting our code where necessary. @@ -178,21 +172,21 @@ In the ever-increasing landscape of competitions and tournaments, there is a gro - Improve the working environment when hosting these events by developing for helpful and creative uses - Not a thing easily measured, but by getting feedback from the customer and reviewing the success of the tournaments hosted we will secure these goals are met. By also adhering to standards and not developing for our own winnings, but rather the improvement of the community we provide the service for, we will ensure these goals are met. -## 3.2Result goals +## 3.2 Result goals - Hand in deliverables on time -- Develop a good product that meets the customers' expectations and needs -- Create a product that follows necessary standards such as UD, WCAG 2.1[1] and provides accessibility for anyone who needs to use the system +- Develop a good product that meets the customers' expectations and needs +- Create a product that follows necessary standards such as UD, WCAG 2.1\[1\] and provides accessibility for anyone who needs to use the system -## 3.3Process goals +## 3.3 Process goals - Learn the process of developing a complete system - Improve communication with other students and lectures for guidance and better development in the future - Pass the subject -# 4Stakeholder and User Descriptions. +# 4 Stakeholder and User Descriptions. -## 4.1Market Demographics +## 4.1 Market Demographics The organization is one of the biggest communities and providers of game servers in the market that it focuses on. It has a good reputation and is the only server that provides the unique style of gameplay in the game servers it hosts of its size. With well over 30,000 users that is an active part as well as being an ever-increasing place of gathering, the organization is one of the lead places in its category. With an active player base and moderation team, it is in good shape and is ever growing. @@ -200,30 +194,25 @@ We would like the market demographic to continue growing as the customer expands By creating this project, we can increase the member retention and also member engagement, resulting in increased activity and growth. This would also in some cases lead to an increase in turnover for the customer. -## 4.2Stakeholder Summary - +## 4.2 Stakeholder Summary | **Name** | **Description** | **Responsibilities** | -| --- | --- | --- | -| Community Management | End user - | Add and manage Community Moderators Approve tournaments and manage tournaments Organize and create tournaments | +|----------|-----------------|----------------------| +| Community Management | End user | Add and manage Community Moderators Approve tournaments and manage tournaments Organize and create tournaments | | Community Members | Will not be able to manage the system, only view the tournaments Is the group of people who will participate in the tournaments | None | | Community Moderators | The people who primarily organize the tournaments with approval from management End user | Organize and create tournaments | | Course Lecturer | End user | View the final product and guide the production through iterations | | Teaching Assistant | End user | View the product during production and comment on potential improvements | -| Project Developers | End user and developer of product | Create and manage the product Responsible for maintenance and further development - - Communication with the customer, lecturers, and teaching assistants | - -## 4.3User Summary +| Project Developers | End user and developer of product | Create and manage the product Responsible for maintenance and further development
Communication with the customer, lecturers, and teaching assistants | +## 4.3 User Summary | **Name** | **Description** | **Responsibilities** | **Stakeholder** | -| --- | --- | --- | --- | +|----------|-----------------|----------------------|-----------------| | Community Managers | Leaders of the customer organizations | Manage tournaments Manage tournament organizers Manage archive | Self-represented | | Community Moderators | Moderators of the community | Organize tournaments Who this is can change and it is a varied group of people | Community Managers | | Community Members | Guests | View tournaments if they wish | Self-represented | | System Managers | The creators of the project | In charge of maintenance Fix bugs and errors that might display themselves down the line | Self-represented | -## 4.4User Environment +## 4.4 User Environment Currently, there are four people who are considered managers, and 22 moderators actively pursuing the improvement of the community. The number of people in either of these positions change because of people retiring, or being hired, so it is not a set value. There is one owner, who should have some superior level of control regarding certain cases. @@ -231,28 +220,22 @@ There are no set tasks, as most of the work is voluntary coming from the moderat This is an online operation, so no environmental constraints will be liable, other than some moderators or users being unavailable due to local environmental problems. Current platforms are three different games, two of which are located on steam, the other on an individual platform. One of these games is a plan for future development but is close to being implemented. -The only other application in use that could be directly utilized by us as system developers is Discord and integrating this with either Discord to login or to be able to format messages to be sent to the communities' channels. This, however, is not a priority for us and will only be implemented by necessity. - -## 4.5Key Stakeholder or User Needs +The only other application in use that could be directly utilized by us as system developers is Discord and integrating this with either Discord to login or to be able to format messages to be sent to the communities' channels. This, however, is not a priority for us and will only be implemented by necessity. +## 4.5 Key Stakeholder or User Needs | **Need** | **Priority** | **Concerns** | **Current Solution** | **Proposed Solutions** | -| --- | --- | --- | --- | --- | -| Create a Tournament | High | - | None | Web application UI | +|----------|--------------|--------------|----------------------|------------------------| +| Create a Tournament | High | | None | Web application UI | | Manage Tournaments | High | Cooperation, multiple admins | None | Web application UI | -| View Tournaments & standings | High | - | None | Web application UI | -| Complete tournament and announce a winner | Medium | - | None | Web application and Discord | -| Archive tournaments | Low | - | None | Export summary | +| View Tournaments & standings | High | | None | Web application UI | +| Complete tournament and announce a winner | Medium | | None | Web application and Discord | +| Archive tournaments | Low | | None | Export summary | | User notifications | Medium | Integration with discord | None | Discord or Email | -| Login system for organizers | High | Security, privacy | - | Web interface with cookies/browser storage | +| Login system for organizers | High | Security, privacy | | Web interface with cookies/browser storage | -## 4.6Alternatives and Competition +## 4.6 Alternatives and Competition -### 4.6.1Challonge +### 4.6.1 Challonge Challonge is an established easy-to-use web application that is free to use for anyone. @@ -260,25 +243,25 @@ Its major strengths are that it is already in use by the customer as it is a sim A weakness it has is that it is not built for the customer specifically, but rather built for anyone who would wish to host a tournament, and therefore must provide a lot of additional elements rather than focusing on one specific customer and their needs. -# 5Product Overview +# 5 Product Overview -## 5.1Product Perspective +## 5.1 Product Perspective The product aims to be a targeted alternative to the bigger, broader, tournament hosting websites like Challonge. The larger websites are accommodated to host tournaments for a lot of different games which makes them bloated for users wanting to host infrequent tournaments for a single game. The product is a simple website aimed towards simple navigation and needing fewer clicks to create the initial tournament as well as managing them. It is a self-contained system and consists of the client interface (the Web GUI), a server running the application, and a database server which holds the team and player information. -## 5.2Summary of Capabilities +## 5.2 Summary of Capabilities The tournament management system we produce should enable all administrators in our customer group to create and manage tournament plans for their given games. The back-end of the application will host the database storing all tournament data, but this should not be directly visible to the user. Administrators should have a simple web interface where they can create, edit, and delete tournaments. Players, not just administrators, should also have access to a web link where they can see the tournament status. This ensures that the system is accessible to everyone without requiring any installation or additional tools. The management pages should be fault-tolerant and handle any conceivable input from the user and must be resilient to user mistakes. Normal usage of the application should be well documented and explained in the supplied user manual. -## 5.3Assumptions and Dependencies +## 5.3 Assumptions and Dependencies The tournament system is naturally based on the type of game being played. In the specified game, every match exists between exactly two teams or players. If this were to change, for example by requiring a match between three different teams, our requirements and build process would have to adapt. As previously stated, our product will be hosted on a web server. That means that all usage requires a web browser and an internet connection. Without access to the internet, the user will not be able to send and receive data between their computer and the web server. The server application will be hosted on one of our private servers but require little in terms of software and hardware performance. Any computer with a good internet connection and the ability to run Node.JS will suffice. -## 5.4Risk analysis +## 5.4 Risk analysis Here we have listed possible events and analyzed the probability and consequence for each. @@ -301,51 +284,155 @@ Here we have listed possible events and analyzed the probability and consequence - **Aversion:** - Configuration files will be backed up in git and locally on our personal computers. - The NTNU-IDI MySQL database seems stable, but we can easily change to any other MySQL instance. - - The installation manual will be devised for easy reinstallation if we must. + - The installation manual will be devised for easy reinstallation if we must. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + **What** + + + **Probability** + + + **Consequence** + + + **Risk factor** +
+ + Project delay + + + 3 + + + 2 + + + 6 +
+ + Late delivery + + + 2 + + + 5 + + + 10 +
+ + Delivery of unfinished product + + + 2 + + + 5 + + + 10 +
+ + Loss of work + + + 1 + + + 4 + + + 4             +
+ + Server downtime + + + 1 + + + 2 + + + 2 +
-| **What** | **Probability** | **Consequence** | **Risk factor** | -| --- | --- | --- | --- | -| Project delay | 3 | 2 | 6 | -| Late delivery | 2 | 5 | 10 | -| Delivery of unfinished product | 2 | 5 | 10 | -| Loss of work | 1 | 4 | 4 | -| Server downtime | 1 | 2 | 2 | Probability and consequence values are given on a scale of 1-5. Risk factor is probability times consequence. -## 5.5Installation +## 5.5 Installation -Because we use a cloud-like model where no work is being done on the user's computer, no special installation concerns are required. All users are only required to have a web browser and an internet connection. +Because we use a cloud-like model where no work is being done on the user's computer, no special installation concerns are required. All users are only required to have a web browser and an internet connection. The actual software will be built in JavaScript on top of the node.js and React frameworks. These tools will be required on the server for building and running the project. The basic mechanics will build on tools and techniques used in our earlier programming courses. -# 6Product Features +# 6 Product Features -## 6.1Intuitive web interface +## 6.1 Intuitive web interface The software should be accessible through a normal web browser. The user will be able to interact with all components of the system by using a mouse and keyboard in the browser. By complying with established guidelines for universal design and clean web development, the menus should be intuitive, simple, and understandable. This minimizes installation time and costs, training time and allows the software to be used by people with a disability. -## 6.2User management +## 6.2 User management -Our customer has two levels of administrator access, "Administrators" and "Management". Users in the management group should be able to access and modify all tournaments in the system, as well as creating or removing administrators. +Our customer has two levels of administrator access, "Administrators" and "Management". Users in the management group should be able to access and modify all tournaments in the system, as well as creating or removing administrators. -## 6.3Easy Collaboration +## 6.3 Easy Collaboration As opposed to smaller, simpler, tournament management systems, our product will allow multiple administrators to manage the same tournament at once. This will be important to our customers, as the administration consists of many different people in all parts of the world. Relying on single people might be a bad idea, and this system will still be fully functional if one or more administrators disappear or fail to fulfill their tasks, as a manager or other administrator can take over the project. -## 6.4Automatic Bracketing +## 6.4 Automatic Bracketing To create a new tournament bracket, an administrator can simply create an empty tournament and insert the competing teams. When the list of teams is saved, pairs of teams will be combined randomly into matches. This makes the process of creating new tournaments both simple and fair. If the administrator is not happy with the distribution, they can either manually edit the order, or randomize again. -## 6.5Scheduling +## 6.5 Scheduling Each tournament is created with a duration and starting time and date. When teams are invited, they can receive reminders about upcoming tournaments ahead of time. This can improve the workflow of the administrators, as they can prepare the tournament in advance so the games can start exactly when scheduled, without having to wait for configuration. -# 7Constraints +# 7 Constraints The project assignment constraints how much time we are able to spend on the assignment itself, as well as on what technologies that are allowed to be utilized. Knowledge could also be a constraint in some cases, as well as the need for expertise to create elements of the project. -# 8Quality Ranges +# 8 Quality Ranges We have not defined specific performance requirements in terms of numbers, but usability and a feeling of responsiveness is highly prioritized. We will not accept excessive delays and hiccups in the finished product, and the software should leave a professional impression on the user. @@ -353,26 +440,24 @@ The system should be able to handle our expected workload with an excessive marg Usability is an important aspect of modern web development. By sticking to established guidelines concerning Universal Design and availability, we will ensure that the tournament system is easy to use. This also includes the page structure being accessible to screen readers, and that the visual elements can be distinguished clearly. -# 9Precedence and Priority +# 9 Precedence and Priority Here we have listed different system features and prioritized them. - | **Feature** | **Priority** | **Precedence** | -| --- | --- | --- | +|-------------|--------------|----------------| | Intuitive Web Interface | 3 | Intuitive Web Interface is the most important feature of the program, and it precedes any other, because unless the interface is intuitive there is little reason to improve on other areas. | | User Management | 3 | User management should be one of the core features of the program to ensure easy access and usage, | | Automatic Bracketing | 2 | Automatic Bracketing is a Quality-of-Life improvement which reduces the amount of effort and clicking needed by the end user to set up a bracket. With just simple inputs of names and teams, the system will create a bracket on its own without the need of an end user moving slots around and manually assigning each slot with a name. | -| Easy Collaboration | 1 | Easy Collaboration by multiple administrators is a "nice to have" feature, but it is more important to improve the workflow of each administrator rather than allowing multiple administrators to enter the workflow. Therefore, it is preceded by scheduling. | +| Easy Collaboration | 1 | Easy Collaboration by multiple administrators is a "nice to have" feature, but it is more important to improve the workflow of each administrator rather than allowing multiple administrators to enter the workflow. Therefore, it is preceded by scheduling. | | Scheduling | 1 | Scheduling of when and where precedes easy collaboration, as its more important to have a functioning system where everyone is able to view the correct info, rather than having multiple people being able to edit and manage a single tournament. | -Priority values are given on a scale of 1-3. - Precedence compares the features with the same priority and ranks them accordingly within the priority range. +Priority values are given on a scale of 1-3. Precedence compares the features with the same priority and ranks them accordingly within the priority range. # 10 Other Product Requirements ## 10.1 Applicable Standards -WCAG 2.1[1] +WCAG 2.1\[1\] The system should work on any platform, including Windows and \*NIX-based Operating Systems @@ -384,7 +469,7 @@ The server needs to be able to run Node to present the web application. The user needs a computer with internet access to access the application. -## 10.3Performance Requirements +## 10.3 Performance Requirements The tournament system should be a fairly simple application without any specific hardware requirements. Although the system may be simple, we might expect several hundred web requests in a short period of time if all contestants are loading the dashboard to check the status of their tournaments. We will not set any hard limits on performance, like measuring response times, but we will ensure that the page is perceived as responsive and stable. The user should not have to wait for pages to load or actions to occur, but these should be integrated in a seamless web interface with little latency. Downtime is unacceptable, and the page should be perceived as smooth and professional.