Software Requirements Specification (SRS)
This Software Requirements Specification (SRS) describes all specifications for the application "Vigad". It includes an overview about this project and its vision, detailed information about the planned features and boundary conditions of the development process.
The project is going to be realized as an Desktop Application.
Actors of this application can be users.
Planned Subsystems are:
- Capturing Desktop/Screen: The capturing of a specific part of the screen is the most important part for our project. This is also the first thing you will do with the application. With our user interface it should be easy to setup your capturing. It should be responsive and intuitive to use.
- Data Processing: The captured data in its raw form will not be usable. Thats why we will implement a regex subsystem to filter out the garbage of the raw data. The user should then be able to define his/her own regex for an individual usage.
- Session for sharing the data: The user can host a session to share his captured data with other players. It should also be possible to collect the captured data from all players and summarize, e.g. to create a map from the location of all players.
- Storing the data: To store the shared data we will create a database.
| Abbreviation | Explanation |
|---|---|
| SRS | Software Requirements Specification |
| UC | Use Case |
| n/a | not applicable |
| tbd | to be determined |
| UCD | overall Use Case Diagram |
| FAQ | Frequently asked Questions |
| Title | Date | Publishing organization |
|---|---|---|
| Vigad Blog | 18.10.2022 | Vigad Team |
| Vigad GitHub | 17.11.2022 | Vigad Team |
| Vigad GitHub Board | 21.04.2023 | Vigad Team |
| Vigad Zenhub outdated | 17.11.2022 | Vigad Team |
The following chapter provides an overview of this project with vision and overall Use Case Diagram. The third chapter (Requirements Specification) delivers more details about the specific requirements in terms of functionality, usability, and design parameters. Finally, there is a chapter with supporting information.
The vision of Vigad is to build an application, that can read written information on your screen like your game-characters coordinates, health points, or basically anything and convert it to processable data using image(video) to text technologies.
This information can then be used to develop visuals like statistics, ingame-maps and vice versa. We have this application in mind to act as a kind of “framework” providing this live-data for other developers to use. This can not only be used for games, but for any closed application that displays data to you, but does not provide you a way to fetch and use this data in an external program.
For example, did you ever play Minecraft with your friends and everybody of you didn’t know where you are? The only thing you can do is to tell them your coordinates. But wouldn’t be a map more useful? With Vigad it could be possible to build a map website or something similar on top of the streamed information which Vigad provides.
- Blue & Green: Planned till end of the 3. Semester
- Red & Yellow: Planned till end of the 4. Semester
The technology we use is:
Backend:
- Regex definition in Typescript
- RedisDB
Frontend:
- Electron.js
- Vue.js
- Vite
IDE:
- Visual Studio Code
Project Management:
- Azure DevOps (first weeks)
- Zenhub (not anymore after the 3st Semester because of a paywall)
- GitHub Projects (currently)
Deployment:
- Github Actions
Design Iterations:
- Figma
Testing:
- Vitest for Unit and Component Testing
Metrics Reports:
- Codacy
This section will explain the different use cases, you could see in the Use Case Diagram, and their functionality.
Until the end of the 3. Semester we plan to implement:
- Screen Capturing Use Case
- Capture Area Definition Use Case
- Regex Definition Use Case
- Data Processing
Until the end of the 4. Semester, we want to implement:
We want to create an intuitive User Interface with with a good overview on things the user should interact with. The app will also have a FAQ document, but it shouldn't be necessary.
The overall workflow with the application should be very easy and every step from installation to the final usage should not require any previous experience.
The design will not be a completely new approach, so the user will feel like working in a familiar environment. This is part of our self explaining UI.
Once installed the app should run for itself. The planned Service for sharing the data should be available at least 95% of the time. To ensure the downtime for maintaining the server affect as few users as possible we have to figure out at which time we have the least amount of active users.
Our goal is that we have no loss of any data. Even at maintenance the data should not be lost.
tbd
Database
tbd
To provide the best desktop application performance, we aim to keep the response time as low as possible. This will make the user experience much better. The processing of the data through regex should be very quick to ensure the viewed data is always up-to-date.
We are going to write the code by using all 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 by everyone and make further development much easier.
Developing an effective testing approach for our desktop application, which is built using web development tools and programming languages, poses a challenge. However, we have found a promising solution that leverages Vitest for unit testing and component/composable testing. This choice aligns well with our web technology stack and has proven to be highly beneficial.
Furthermore, we have implemented a GitHub Actions pipeline that incorporates the command "npm run test-coverage" to execute comprehensive testing. This pipeline ensures that all tests are run, and if any of them fail, the pull request cannot be merged. This approach guarantees that only high-quality and fully functional code is integrated into the project.
We are trying to provide a modern and easy to handle design for the UI as well as for the architecture of our application. To achieve that, the functionalities will be kept as modular as possible.
Because we are programming a Desktop Application there were many options on how to implement it, but we decided to use Electron.js therefore we chose JavaScript/TypeScript as our programming language. For the regex processing we also use typescript.
The usage of the desktop application should be as intuitive as possible, so it won't need any further documentation.
We don't have any purchased components yet. If there will be purchased components in the future, we will list them here.
See our design iterations for UI
The User interfaces that will be implemented are:
Capturing: A view where the user can start the capturing process.
Source: The user should select either a screen or an application as his source for the capture area.
Regex: The user will be able to define capture areas on his selected source and then define regexes to process the data.
Settings: A Popover which lets you setup and start a session to share data.
The Desktop Application will be runnable on any common PC or Laptop.
The Desktop Application will be runnable on Windows, Linux and macOS.
The server and hardware will communicate using the http protocol.
The logo is licensed to the Vigad Team and is only allowed to use for the application. We do not take responsibility for any incorrect data or errors in the application.
The development will follow the common clean code standards and naming conventions. Also, we will create a definition of done which will be added here as soon as it's complete.
For any further information you can contact the Common Playground Team or check our Vigad Team.
The Team Members are:
- Timo
- Kevin
- Roman
- Florian (sadly deceased)
- Erik (newly onboarded)