Skip to content

Software Requirements Specification

Oliver Saar edited this page Jun 19, 2023 · 16 revisions

Table of contents

1. Introduction

1.1 Purpose

This Software Requirements Specification (SRS) describes all specifications for the application "Decksterous". It includes an overview of this project and its vision, detailed information about the planned features and boundary conditions of the development process.

1.2 Scope

The game is going to be realized as a Web application.

Planned Subsystems are:

  • Account System:
    Users can create accounts so sessions can be connected to a person as well as join requests. User data must be stored alongside the posting data.
  • Storing Data:
    User data for accounts and possibly profiles have to be stored. The data storage will form the foundation for the visualization, account system, search and gameplay feature.
  • Game Lobbys:
    For players to find and join a game, there is a lobby system. Every possible game will be listed.
  • Authentication Page:
    The authentication page is our initial landing page for new users. There is an option to signup and sign in, as well as reset your forgotten password. It contains only minimal information to not confuse any user. Any navigation to unauthorized sites will lead to the redirection of this page.
  • Navigation Page:
    This is a collection of more subsystem/-pages for users to easily navigate to. It contains a sorted and grouped navigation menu on the left-hand side of the screen.
  • Profile Page:
    All information about a user itself is displayed here. This contains level, ranking, inventory/items, etc.

1.3 References

Title Date Publishing organization
Decksterous Blog 06.04.2023 Decksterous
GitHub 06.04.2023 Decksterous
Software Requirements Specification 06.04.2023 Decksterous
Create new Decks (Use-Case) 06.04.2023 Decksterous
Trade Items (Use-Case) 06.04.2023 Decksterous
Invite Friend (Use-Case) 06.04.2023 Decksterous
Show Rankings (Use-Case) 10.06.2023 Decksterous
Buy Shop Items (Use-Case) 10.06.2023 Decksterous

2. Overall Description

The following chapter provides an overview of this project with a vision and Overall Use Case Diagram.

2.1 Vision

Our idea is to make a battle and collection card game with fully customisable rules. Players will be able to challenge others and compete against them in different game modes. Before a battle, players can pick their cards for their deck to play with. Each game can have different rules that are even customisable by players themselves. In certain modes it is even possible to lose cards permanently, so choose wisely with what cards you want to play! There will also be an option to upgrade your cards.

2.2 Use Case Diagram

Diagram

2.3 Technology Stack

Stack

Backend

Decksterous is a web application realized with Node.js as a backend service. It will be powered with Express.js for web capability (like HTTP) and Socket.io for WebSocket handling. We are going to use MariaDB as our database for all data that needs to be stored.

  • Node.js which will be powered by:
  • Express.js for web capability
  • Socket.io for WebSocket handling
  • Seqeuelize as ORM (Object Relation Model) adapter for database connection
  • JWT (JSON Web Token) for authentication
  • MariaDB for storing data

Frontend

The frontend is going to be designed in TypeScript with the Angular and Material framework. The whole art design of our game will be created with the help of an image generation AI such as Stable Diffusion. Our gameplay will be run with Three.js as a renderer.

  • TypeScript with:
  • Angular framework
  • Material Design framework
  • Socket.IO Client for WebSocket

IDE

Two members of our team use IntelliJ and one uses Visual Studio Code as their IDE.

  • IntelliJ
  • Visual Studio Code

Project Management

For our project we make use of GitHub for version control and YouTrack for time tracking.

  • YouTrack
  • GitHub
  • Discord

Tools

For code formatting we use Prettier for a standard format style.

Deployment

  • tbd

3. Specific Requirements

This chapter (Requirements Specification) delivers more details about the specific requirements in terms of functionality, usability and design parameters.

3.1 Functionality

This section will explain the different use cases, you could see in the Use Case Diagram, and their functionality.

Until December we plan to implement:

  • 3.1.1 Login & Account
  • 3.1.2 Picking cards for your deck
  • 3.1.3 Challenging other players
  • 3.1.4 Competing in tournaments
  • 3.1.5 Levelling up
  • 3.1.6 Unlocking achievements

3.1.1 Login & Account

Our first milestone is that everyone can log in or if they have no account yet, can register. After that, we need to make sure every player has all unlocked cards available to select.

3.1.2 Picking cards for your deck

Since the player has their cards available, they should be able to create different decks with these cards.

3.1.3 Challenging other players

Once the deck is created, there will be an option to challenge other players. It will be a round based 1v1 game, where each player can choose his actions (e.g. play a card, attack with an already played card, ...)

3.1.4 Competing in tournaments

There is a tournament function planned, where players can get rewards for competing and especially placing well.

3.1.5 Levelling up

The possibility to level up your cards is planned, but we are not sure yet how this will be implemented.

3.1.6 Unlocking achievements

There will be achievements to unlock through playing the game.

3.2 Usability

We plan on designing the user interface as intuitive and self-explanatory as possible to make the user feel as comfortable as possible using the game. Another big point is the fun factor, which should be always given.

3.2.1 Familiar Feeling

We want to implement a web app with familiar designs and functions. This way users can interact in familiar ways with the application without having to learn new interfaces. The plan is to make everything as easy as possible for the players.

3.3 Reliability

3.3.1 Availability

The server should be available 95% of the time. This also means we have to figure out the "rush hours" of our game because the downtime of the server is only tolerable when as few as possible players want to play.

3.3.2 Defect Rate

Our goal is that we have no loss of any data. This is important so that the game sessions can carry on, even after one player disconnects.

3.4 Perfomance

3.4.1 Capacity

The system should be able to manage thousands of requests. It should be possible to register as many players as necessary as well.

3.4.3 App perfomance / Response time

To provide the best performance we aim to keep the response time as low as possible, which will make the user experience much better. This is given because we only put out requests if we need a component, so nothing gets loaded unnecessarily.

3.5 Supportability

3.5.1 Coding Standards

We are going to write the code by using all of the most common clean code standards. For example, we will name our variables and methods by their functionalities. This will keep the code easy to read for everyone and make further development much easier. Our code formatting is going to be handled by 'Prettier', which is a tool that allows all developers to have the same formatting.

3.6 Design Constraints

We are trying to provide a modern and easy-to-handle design for the UI as well as for the architecture of our application. All functionalities will be kept as modular as possible, to achieve that goal.

3.7 Purchasable Components

We don't have any purchased components yet (tbd). If there will be purchased components in the future we will list them here ( e.g Card packs).

3.8 Interfaces

3.8.1 User Interfaces

The User interfaces which are going to be implemented are:

  • Login - page to log in
  • Register - form to signup
  • Forgot password - form to reset a forgotten password
  • Dashboard - summary of many different things, such as short user information, last games played etc.
  • Profile - contains all player information such as level, ranking, inventory/items
  • Friend List - lists all friends of a player
  • Lobbies - lists all available game lobbies a player can join, as well as create a new lobby
  • Market - a marketplace for players to exchange items
  • Story - this page is for single-player games
  • Settings - shows different settings (page display etc.)

3.9 Applicable Standards

The development will follow the common clean code standards and naming conventions.

4. Supporting Information

The Team Members are:

  • Mats Fischer
  • Benedikt Müll
  • Oliver Saar
Clone this wiki locally