Skip to content

Latest commit

 

History

History
101 lines (79 loc) · 7.53 KB

srs.md

File metadata and controls

101 lines (79 loc) · 7.53 KB
Raw

srs2shine

Software Requirements Specification

This template is a simplified version based on the documentation templates from IBM Rational Unified Process (RUP).

1. Introduction

1.1 Overview

A game hub where players can play and enjoy multiple different online games of different styles directly in their browsers, whitout having to install any software.

1.2 Scope

This document covers our whole project, in the future however we might split it up into two sections (probably frontend and backend).

1.3 Definitions, Acronyms and Abbreviations

  • API: Application Programming Interface
  • Java: The programming language we use in our backend
  • Pixi.JS: OpenGL Renderer we use for building the games in our frontend
  • REST: Representational State Transfer (a paradigm for API architecture)
  • Spring Boot: Our backend framework (RESTful API)
  • tbd: To be done
  • t2s: Abbrevation for "time2shine"

1.4 References

Until now, there are now external documents used in our SRS

2. Functional requirements

This section will explain the different Use Cases we want to implement. It describes the individual pre- and post-conditions and gives a brief idea of what we want to accomplish.

2.1 Overview

A brief description of the functionality of your application.
Include one or more UML use case diagram(s) and necessary description to specify the major use cases of your application.

Link to our UML diagram (draw.io format, not human-readable) image

Link to our UI-Template (draw.io format, not human-readable) image

2.2 Account Management

Highscore Activity Diagram

image

Logout Activity Diagram

image

Account Management Activity Diagram

image

  • Relevant account stories: Issue #20
  • UI mockup: Should look like the account view in the picture (see our UI Mockup)
  • UML behavior diagram: see further up the page or here
  • Preconditions: We need a functioning backend that is able to hold account accounts.
  • Postconditions: Users can now login. When they are logged in, some kind of token is stored in the account's browser session. This means he can now access his account page and play games...
  • Estimated effort: high

2.2 Playing Games

  • Relevant account stories: Issue #18 and Issue #19
  • UI mockup: Should look like the account view in the picture (see our UI Mockup)
  • UML behavior diagram: see further up the page or here
  • Preconditions: The account system has to be implemented and working.
  • Postconditions: Users can now login and play games.
  • Estimated effort: high

2.3 Highscore Tracking

  • Relevant account stories: Issue #17
  • UI mockup: Should look like the account view in the picture (see our UI Mockup)
  • UML behavior diagram: see further up the page or here
  • Preconditions: The account account system needs to be setup. Also, players have to be able to play games, and the results have to be stored.
  • Postconditions: Based on the stored game results, the leaderboards are now being calculated and published on the website.
  • Estimated effort: low

2.3 Game Tutorials

  • Relevant account stories: Issue #21
  • UI mockup: There is no UI mockup yet, because this feature can't be implemented before we have everything else running.
  • UML behavior diagram: see further up the page or here
  • Preconditions: The whole game portal has to be running already.
  • Postconditions: When a new account creates an account, he is prompted if he wants to get an introduction to our portal.
  • Estimated effort: ?medium?

3. Nonfunctional requirements

This section shows the nonfunctional requirements which we want to provide. This includes functionalities to let the account feel as comfortable as possible while having all of his data secured.

3.1 Utility Tree

3.2 Maintainability and Modifiability

Since we plan on separating our project into dedicated frontend and backend, we dont't end up with a giant, unmaintainable monolithic construct, but rather a Services-based architecture. This means that the two parts are independant from each other and can e. g. be replaced if a used framework etc. is discontinued. Also, this approach makes us flexible in terms of scaling. In theory,we should be able to easily power on multiple instances of our backend for example.

3.3 Performance

Players want the game platform to work fast and responsive, everything else would be a bad experience. Therefore, our whole system (Application, Backend, Database) has to be designed in a performant yet secure way to make sure to meet the users requirements.

3.4 Availability

Our application should be always reachable so that users can play whenever they like.

3.5 Security

We plan on using OAuth2 to secure our application, meaning that we use a current up-to-date technology that is used by most serious companies from all over the world. It makes communication between the different parts of our application secure. Also, scanning for cheaters is an important thing for keeping the account experience good.

3.6 Testability

The code we write has to be testable in order to meet our quality requirements.

4. Technical constraints

  • Backend: A RESTful API build with Spring Boot in Kotlin
  • Database: PostgreSQL Database
  • Frontend: Based on the Pixi.JS OpenGL Renderer that we will use to build our games
  • Deployment: As students, we can each get a 200 $ credit at Digital Ocean, a web hosting provider. We will spend them on running a Debian 12 instance there. We chose Digital Ocean over bwCloud due to the way better performance (we can choose from different server configurations there). We chose a VPS with 2 AMD EPYC cores and 4 GB of memory which will be sufficient for our use, but still a lot more performant than the offered bwCloud instance. On this server, we will run our Backend, the database and our frontend, each of them being a dedicated Docker Container.