felixalb/asura-tmdb
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Update Vision Document

Felix Albrigtsen 2022-04-28 16:08:41 +02:00 committed by Felix Albrigtsen
parent f6caf83baf
commit f25409b653
1 changed files with 511 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

513
Vision-Document.md

@ -1,3 +1,512 @@
#### Link to the Vision Document PDF
+------------+-------------+-------------------+-------------------+
| **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 | Jonas Jødestøl |
| | | to supervisor | Haugland, |
| | | meeting | |
| | | | Kristoffer |
| | | | Juelsen |
+------------+-------------+-------------------+-------------------+
| 18/03/2022 | 1.0 | Final Draft | Felix Albrigtsen, |
| | | | |
| | | | Jonas Jødestøl |
| | | | Haugland, |
| | | | |
| | | | Kristoffer |
| | | | Juelsen |
+------------+-------------+-------------------+-------------------+
Table of Contents
[Vision_Document_Group1.pdf](uploads/384489412485ae10ad11222ddae0ce20/Vision_Document_Group1.pdf)
[**_1_** **_Introduction_** 5](#positioning)
[1.1 Purpose and scope 5](#business-opportunity)
[1.2 Definitions, Acronyms, and Abbreviations 6](#problem-statement)
[1.3 References 6](#product-position-statement)
[1.4 Overview 6](#project-goals)
[2 Positioning 6](#impact-goals)
[2.1 Business Opportunity 7](#result-goals)
[2.2 Problem Statement 7](#process-goals)
[2.3 Product Position Statement 7](#stakeholder-and-user-descriptions.)
[3 Project goals 7](#market-demographics)
[3.1 Impact goals 7](#stakeholder-summary)
[3.2 Result goals 9](#\_Toc452813584)
[3.3 Process goals 9](#user-environment)
[4 Stakeholder and User Descriptions. 10](#key-stakeholder-or-user-needs)
[4.1 Market Demographics 10](#alternatives-and-competition)
[4.2 Stakeholder Summary 10](#challonge)
[4.3 User Summary 10](#product-overview)
[4.4 User Environment 10](#product-perspective)
[4.5 Key Stakeholder or User Needs 10](#summary-of-capabilities)
[4.6 Alternatives and Competition 11](#assumptions-and-dependencies)
[4.6.1 Challonge 11](#risk-analysis)
[5 Product Overview 12](#installation)
[5.1 Product Perspective 12](#product-features)
[5.2 Summary of Capabilities 12](#intuitive-web-interface)
[5.3 Assumptions and Dependencies 12](#user-management)
[5.4 Risk analysis 12](#easy-collaboration)
[5.5 Installation 12](#automatic-bracketing)
[6 Product Features 12](#scheduling)
[6.1 Intuitive web interface 13](#constraints)
[6.2 User management 13](#quality-ranges)
[6.3 Easy Collaboration 13](#precedence-and-priority)
[6.4 Automatic Bracketing 14](#other-product-requirements)
[6.5 Scheduling 14](#applicable-standards)
[7 Constraints 14](#system-requirements)
[8 Quality Ranges 14](#performance-requirements)
[9 Precedence and Priority 14](#documentation-requirements.)
[10 Other Product Requirements 14](#user-manual)
[10.1 Applicable Standards 14](#internal-documentation)
[10.2 System Requirements 14](#installation-guides-configuration-and-readme-file)
[10.3 Performance Requirements 14](#performance-requirements)
[11 Documentation Requirements. 14](#documentation-requirements.)
[11.1 User Manual 14](#user-manual)
[11.2 Internal Documentation 14](#internal-documentation)
[11.3 Installation Guides, Configuration, and Readme File 14](#installation-guides-configuration-and-readme-file)
Vision
# **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.
The Introduction includes relevant information that will be used and referenced throughout the document.
## Purpose and scope
The purpose of the document is to define these needs and features, as well as focusing on the capabilities required by the stakeholders and target users, including why these exist. Further explanations of each feature and design goal is described in their corresponding sections in the document.
The scope of the document includes only the specifications for the tournament system previously described, and does not include any other projects, there are no external dependencies. Any supplemental information not directly regarding the project will be clearly marked
## Definitions, Acronyms, and Abbreviations
The Isle -- The Isle is the game that will be played in our tournaments, and is intended to be a gritty, open-world survival horror game. It is a game where you go through the life cycles of a Dinosaur and grow up, fight, hunt and survive. Upon dying you need to start over, making it quite competitive for some people to become the best.
Asura -- A European based gaming community that hosts game servers for The Isle, as well as other games, and regularly hosts tournaments and events for its members. This group will serve as our customer.
UD -- Universal Design
## References
\[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/>
Don Norman's principles of Interaction design
<https://www.educative.io/edpresso/what-are-normans-design-principles>
## Overview
The rest of the Vision document is organized in different sections where the information within those sections mostly correlate to each other, but also is used to define features for the rest of the document, and some sections are elaborated later in the document. The first section includes positioning in regard to business opportunities and different statements. The second section describes the project goals, and the next thereafter includes stakeholder and user descriptions. The rest of the document includes Product Overview, Product Features, Constraints, Quality Ranges, Precedence and Priority as well as other product requirements, such as standards. Finally, it includes documentation requirements. The document is organized in these sections to provide an easier reading experience and to be able to quickly navigate through the document.
# Positioning
## Business Opportunity
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.
## 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 |
+----------------------------------+----------------------------------+
## 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 |
+----------------------+----------------------------------------------+
| > 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. |
+----------------------+----------------------------------------------+
# Project goals
## 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._
- _Reduce the efforts needed to host a tournament_
- _We will measure this by measuring the time it takes for the customer currently and aiming for a set amount of time needed to have a successful setup of a tournament that is shorter than the current time._
- _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._
## 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
## 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
# Stakeholder and User Descriptions.
## 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.
We would like the market demographic to continue growing as the customer expands and extends its services to other platforms and markets. It is already a very large market in comparison to other potential smaller, local customers, so we are happy with servicing the established environment.
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.
## Stakeholder Summary
+----------------------+----------------------+----------------------+
| **Name** | **Description** | **Responsibilities** |
+----------------------+----------------------+----------------------+
| 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 | None |
| | manage the system, | |
| | only view the | |
| | tournaments | |
| | | |
| | Is the group of | |
| | people who will | |
| | participate in the | |
| | tournaments | |
+----------------------+----------------------+----------------------+
| Community Moderators | The people who | Organize and create |
| | primarily organize | tournaments |
| | the tournaments with | |
| | approval from | |
| | management | |
| | | |
| | End user | |
+----------------------+----------------------+----------------------+
| 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 | Create and manage |
| | developer of product | the product |
| | | |
| | | Responsible for |
| | | maintenance and |
| | | further development |
| | | |
| | | Communication with |
| | | the customer, |
| | | lecturers, and |
| | | teaching assistants |
+----------------------+----------------------+----------------------+
\[\]{#\_Toc452813584 .anchor}
## User Summary
+----------------+----------------+----------------+----------------+
| **Name** | * | **Resp | * |
| | *Description** | onsibilities** | *Stakeholder** |
+----------------+----------------+----------------+----------------+
| Community | Leaders of the | Manage | Se |
| Managers | customer | tournaments | lf-represented |
| | organizations | | |
| | | *Manage | |
| | | tournament | |
| | | organizers* | |
| | | | |
| | | *Manage | |
| | | archive* | |
+----------------+----------------+----------------+----------------+
| Community | Moderators of | Organize | Community |
| Moderators | the community | tournaments | Managers |
| | | | |
| | | *Who this is | |
| | | can change and | |
| | | it is a varied | |
| | | group of | |
| | | people* | |
+----------------+----------------+----------------+----------------+
| Community | Guests | View | Se |
| Members | | tournaments if | lf-represented |
| | | they wish | |
+----------------+----------------+----------------+----------------+
| System | The creators | In charge of | Se |
| Managers | of the project | maintenance | lf-represented |
| | | | |
| | | *Fix bugs and | |
| | | errors that | |
| | | might display | |
| | | themselves | |
| | | down the line* | |
+----------------+----------------+----------------+----------------+
## 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.
There are no set tasks, as most of the work is voluntary coming from the moderators. The things that have a set schedule are the events (tournaments), but the time slot of these vary depending on the organizer and content.
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.
## Key Stakeholder or User Needs
---
**Need** **Priority** **Concerns** **Current Solution** **Proposed Solutions** 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 User notifications Medium Integration with discord None Discord or Email Login system for organizers High Security, privacy Web interface with cookies/browser storage
---
## Alternatives and Competition
### Challonge
Challonge is an established easy-to-use web application that is free to use for anyone.
Its major strengths are that it is already in use by the customer as it is a simple solution and straightforward in most cases.
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.
# Product Overview
## 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.
## 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.
## 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.
## Risk analysis
Here we have listed possible events and analyzed the probability and consequence for each.
- Project delays
- The project could at any time become delayed due to illness or other unforeseen events.
- **Aversion:**
- Team communication: The entire team is kept updated, and workloads can be shifted to other team members if someone is unable to participate, for example when ill.
- Late delivery or delivery of unfinished product
- The project could be delivered late or in an unfinished state due to underestimation of work hours needed to finish the product.
- **Aversion**:
- Active use of the Gantt-diagram and GitLab-board ensures that we stay with the pre-defined plan. By keeping eye on these diagrams, deviations can be easily spotted and corrected.
- Loss of work
- Program code or documentation that has not yet been committed or saved otherwise may be lost due to a power outage, application crash or other unforeseen events.
- **Aversion:**
- All team members will follow a policy of working directly in the git repository, with separate commits for each feature or issue.
- We will keep daily backups of our git repository on a personal server.
- Text documents and similar work not included in our git will be stored in Microsoft OneDrive.
- Server downtime
- The server hosting the tournament system may experience internal or external issues regarding uptime and availability, making the product become temporarily unavailable.
- **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.
**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.
## 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.
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.
# Product Features
## 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.
## 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.
## 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.
## 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.
## 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.
# 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.
# 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.
The system should be able to handle our expected workload with an excessive margin. This is a part of robustness, which also includes proper error handling when something goes wrong at runtime. By writing efficient back-end code with little resource overhead, and by logging important actions, we can ensure that the system is robust.
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.
# 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. 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.
# Other Product Requirements
## Applicable Standards
WCAG 2.1\[1\]
The system should work on any platform, including Windows and \*NIX-based Operating Systems
TCP/IP standard is the basis for our web communication
## System Requirements
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.
## 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.
# Documentation Requirements.
## User Manual
The user manual includes a basic guide on how to use the system and will also include an email address to contact the system developers if the need arises. It should be relatively short, no more than two A4 pages so that it can be printed on a single, double-sided A4 paper if necessary.
## Internal Documentation
To aid in team collaboration, planning, maintenance and documentation for the subject assignment, all code, models, and internal structures must be documented and presented on our wiki page hosted on GitLab. Source code should be written as clearly, readable, and concisely as possible, and be commented inline where appropriate. Documentation will be done in parallel with development, and not afterwards.
## Installation Guides, Configuration, and Readme File
The product will be hosted by us, the developers, and maintained by us in a web-based environment, so there is no need for any installation guides for this specific project. Should be need arise for others to host this environment themselves installation guides can be procured.