1. Introduction and Goals

1.1. Requirements Overview

WIChat is an enhanced version of last year’s experimental game show app developed by HappySw for RTVE. The main improvement is the addition of a chatbot powered by a large language model (LLM), allowing contestants to interact and receive clues during the game. The app generates questions and images automatically using data from Wikidata, offering a diverse range of topics and visual content. It also features user registration, history tracking, and performance data, making the game more engaging and personalized. WIChat is a web-based platform designed to be scalable, flexible, and easily maintainable while providing an interactive, fun, and educational experience for users.

1.2. Essential Functional Requirements:

  • User registration and authentication:

    • Users will be able to create accounts and log in to participate in the contest.

  • Question and answer game:

    • Presentation of images to the contestants, who must guess the place or theme represented.

    • Inclusion of questions about the images in the chatbot.

    • Rewarding users for each correct answer.

  • Interactive clue functionality:

    • Users will be able to request clues about the answers conversationally.

    • The clues will be generated using an external large language model (LLM).

  • Automatic content generation:

    • Images and clues will be automatically generated from data obtained from Wikidata.

1.3. Driving Forces:

  • Improvement of user interaction:

    • The inclusion of conversational clues aims to increase user interest and engagement.

  • Content automation:

    • Automatically generating images and clues reduces manual work and helps keep the content updated and diverse.

  • Alignment with modern technologies:

    • The integration of an LLM and the use of Wikidata position the app at the forefront of technology, which is key for RTVE as an innovative public media entity.

1.4. Motivation

From the perspective of the end users, the WIChat system is created with the purpose of enhancing the user experience in the "Saber y Ganar" quiz. The modification of the system aims primarily to increase participant interaction by allowing them to obtain clues in a conversational manner through an external large language model (LLM). This enriches the gaming experience and makes it somewhat easier for users by receiving "assistance" from the chatbot.

This system is designed to improve player support through the chatbot with clues, while the quality of the game is also enhanced by integrating advanced technology to automatically generate images and clues based on Wikidata. This ensures that the content is relevant, up-to-date, and non-repetitive, which guarantees a more enriching and engaging experience for users.

1.5. Quality Goals

Quality Goal Concrete Scenario

High Availability

The system must be available 24/7 with minimal downtime.

Scalability

The architecture must support the addition of more servers without interrupting service, managing traffic spikes during peak times.

Security

The application must ensure the protection of user data, particularly during registration and access.

Performance

The response time for displaying a question and its options should be under 2 seconds.

Integration with Wikidata

Images and clues must be generated correctly from Wikidata data without errors.

Usability

The user interface must be intuitive, with clear instructions on how to participate and get clues.

1.6. WIChat System Stakeholders

  1. End Users:

    • Role: Contestants of the quiz.

    • Responsibility: They should understand the basic architecture of the game to know how to interact with the questions and hints. They do not need to be aware of technical details.

  2. Software developers:

    • Role: Frontend and Backend developers.

    • Responsibility: They need to understand the architecture in detail to implement system functionalities, such as image generation and integration with the language model for the chatbot hints.

  3. Software Architects:

    • Role: Technical architects responsible for the system’s infrastructure.

    • Responsibility: They must have a deep understanding of the architecture and make key decisions regarding the scalability, security, and modularity of the system.

  4. Testers:

    • Role: Responsible for ensuring the system’s quality.

    • Responsibility: They need to understand the architecture and work organization to ensure the game functions correctly, and the images and hints are generated properly.

Table 1. Project stakeholders
Role/Name Contact Expectations

Software developers, architects and testers

Daniel Alberto Alonso Fernández
David Álvarez Cabezas
Alejandro Fernández García
Emilio García Fernández
Mario García Prieto

Collaborate effectively across all project stages, ensuring clean, maintainable code. Focus on scalability, performance, and integration with external systems. Conduct thorough testing and automation. Document and share design decisions and best practices.

Client

Radio Televisión Española (RTVE)

Expects a stable and attractive web solution that increases user engagement and provides an entertaining and interactive gaming experience.

ChattySW (Development Company)

Internal development team at ChattySW

Deliver a robust and interactive application that integrates AI-driven hints for the game. Ensure availability, performance, and security. Maintain clear communication with RTVE and align with project deadlines.

System Administrator

IT team responsible for system maintenance

Ensure system uptime, security, and performance. Manage deployments, monitor server load, and provide technical support.

Regular User (Player)

People who register and play the game

Engage with the game by answering image-based questions and using the conversational hint system. Provide feedback on usability and user experience.

2. Architecture Constraints

2.1. Technical constraints

Name Description

FrontEnd

The system shall have at least one frontend for user interaction.

Question Generation

Questions should be generated automatically from wikidata.

User Management

The system shall have a user management system that allows for login, registration, andhistorical consultation.

LLM

We will use an LLM for hint generation based on an image that we will send.

Deployment

We will use docker for local deployment.

2.2. Organizational constraints

Name Description

Github

We will use github to host the project repository, from which each member will work on a branch for their implementations.

Class Meetings

For the meetings we will use the classrooms to meet and discuss the work to be done and the work we have done during the week. There is also a whatsapp group where we will communicate with each other in case we need to meet outside the classroom.

2.3. Convention Constraints

Name Description

Project documentation

We will use the Arc42 template for the documentation which will be written in English in its entirety.

3. Context and Scope

3.1. Business Context

Communication Partner Inputs Outputs

Users

User requests and interactions.

Responses and hints (chatbot clues).

Web Application

Receives user inputs and data from backend services.

Updates the interface to display information to the user.

Backend Service

Takes actions from users via the web application and data returned by external APIs.

Manages calls to APIs and updates the web application view.

Chatbot

User queries (text input).

Clues and tips (text output).

Database

Stored game data.

Game state, user progress, stored results.

Wikidata

Receives queries about a theme or category.

Returns a page corresponding to the given query.

LLM (Large Language Model)

Receives relevant information about the question the user needs to answer.

Interacts or provides answers to the user in different ways, depending on the used wildcard.

3.1.1. Communication Partners:

  • Users:

    • The end-users interact with the system through the chatbot and other game features. They are provided feedback or hints within the game.

  • Web Application:

    • The web application serves as the user interface and manages the presentation of the game, including the display of questions, answers, and interactions with other components of the system.

  • Backend Service:

    • This service processes user actions, manages the game state, communicates with external services (like Wikidata and LLM), and provides necessary data to the web application.

  • Chatbot:

    • The chatbot serves as a conversational interface for user interactions. It receives inputs in the form of questions or commands and generates responses that may provide hints or extra information.

  • Database:

    • The database stores all relevant game information, such as the game state, user progress, and historical results.

  • Wikidata:

    • An external data source accessed by the backend service to retrieve knowledge and information via SPARQL queries, which helps generate trivia questions and provide context.

  • LLM (Large Language Model):

    • A complex model that processes user queries and generates responses or hints, adapting based on the wildcards used in the game.

3.2. Technical Context

Communication Partner Explanation

Web Application

The user plays the game via the internet, connecting to the system through HTTP requests.

Backend Service

Manages game data, processes user actions, communicates with LLMs to provide hints, and generates trivia questions by calling external APIs.

Database

A MongoDB database stores user data, including player profiles, scores, and game progress.

Wikidata

The backend service retrieves data from Wikidata using SPARQL queries, providing general knowledge and information for the game.

LLM (Large Language Model)

Used to process user questions and provide relevant hints, ensuring dynamic and meaningful interactions in the game.

Azure Cloud

Used for deploying the application, ensuring scalability, security, and availability of the system.

MongoDB

A NoSQL database for storing all application data, including user information and trivia questions.

Web Browsers

Allow users to access the game once it is deployed, supporting various browsers.

React, JavaScript, HTML, CSS

Technologies used for the frontend development of the game, providing an interactive and responsive user interface.

  • Web Application:

  • The game is played through the internet. Users connect to the system via HTTP requests, allowing access via web browsers.

  • Backend Service:

  • This service manages all game-related data. It processes user actions, generates trivia questions, and interacts with the Large Language Model (LLM) to offer hints. It also calls external APIs for additional game data.

  • Database:

  • The database, which is based on MongoDB, stores critical data like user profiles, scores, and game progress. It ensures persistent storage and retrieval of this information.

  • Wikidata:

  • The backend service retrieves knowledge from Wikidata using SPARQL queries, which is then used to create trivia questions and provide game context.

  • LLM (Large Language Model):

  • The LLM processes user questions and generates relevant hints or answers. It enables dynamic and intelligent interactions based on user inputs.

  • Azure Cloud:

  • Azure Cloud is used for deploying the application, ensuring the system is scalable, secure, and available.

  • MongoDB:

  • MongoDB, a NoSQL database, stores all the application’s data, including user profiles and trivia questions, making it ideal for handling large volumes of unstructured data.

  • Web Browsers:

  • Web browsers serve as the platform for accessing the game, allowing users to interact with it across a variety of devices.

  • React, JavaScript, HTML, CSS:

  • These technologies are used to develop the frontend of the game. React builds the interactive user interface, while JavaScript, HTML, and CSS manage the layout, functionality, and styling of the game’s web pages.

4. Solution Strategy

4.1. Technology Decisions

For the implementation of WIChat, we have selected the following technologies based on their ease of development, scalability, and compatibility with the project requirements:

  • Frontend: React with TypeScript for an interactive and modular user interface.

  • Backend: Node.js with Express to manage business logic, authentication, and data operations.

  • Database: MongoDB Atlas, a cloud-based NoSQL database optimized for flexible and scalable storage.

  • Authentication: JSON Web Tokens (JWT) for secure authentication without third-party dependencies.

  • Question Generation: Use of queries to Wikidata via the backend to retrieve images and data.

  • Deployment: Netlify for frontend hosting and a cloud-based platform (such as Render or AWS) for the backend.

4.2. Top-Level System Decomposition

The system follows a frontend + dedicated backend architecture, where all business logic is handled by a Node.js backend instead of serverless functions.

  1. Presentation Layer (Frontend - React)

    • Implemented in React with TypeScript, providing an interactive experience.

    • Communicates with the backend via HTTP requests to the Node.js API.

  2. Business Logic Layer (Backend - Node.js & Express)

    • Manages question generation, answer validation, and data storage.

    • Connects to Wikidata to retrieve questions and answers.

    • Handles user authentication with JWT, generating and validating tokens.

  3. Data Layer (MongoDB Atlas)

    • Stores information about users, generated questions, and game statistics.

    • Optimized for flexible storage and efficient queries.

4.3. Architectural Patterns

  • Monolithic Backend Architecture: The backend is implemented as a single Node.js application managing all API requests.

  • API Gateway: The backend acts as a centralized API that receives requests from the frontend and processes the corresponding logic.

  • Event-Driven Architecture: MongoDB enables real-time updates through triggers and change streams.

4.4. Design Patterns

  • Façade: Centralizes calls to MongoDB Atlas and Wikidata within the backend API.

  • Observer: MongoDB allows real-time subscriptions to data changes.

  • Lazy Loading: Loads data progressively to optimize frontend performance.

4.5. Decisions for Achieving Quality Goals

To ensure system quality, the following strategic decisions have been made:

Quality Goal Decision Taken

Scalability

Use of MongoDB Atlas and Node.js backend, ensuring efficient request handling.

Availability

Deployment in a cloud-based environment with automatic scaling.

Security

Implementation of JWT-based authentication for secure access control without third-party dependencies.

Maintainability

Use of Express framework for a structured and maintainable backend.

Usability

Intuitive web interface with React and automatic question generation to enhance user experience.

Mitigation of LLM Errors

Use of specifically designed prompts to reduce incorrect responses and pre-filter generated hints.

4.6. Organizational Decisions

Third Party Product Reason

Git

Easy to use distributed version control system.

GitHub

Web-based platform for hosting and managing Git repositories, including features like issues tracking, pull requests, and GitHub Actions.

Netlify

Cloud service used for deploying the frontend with built-in support for continuous integration.

MongoDB Atlas

Scalable and flexible cloud-based NoSQL database solution.

JSON Web Tokens (JWT)

Secure and stateless authentication mechanism used to handle user sessions.

Render / AWS

Cloud-based hosting service for the Node.js backend, ensuring scalability and reliability.

4.7. Motivation

The architectural decisions in this system are based on the need for an agile and efficient development approach within a 10-week academic environment. A Node.js backend with Express was chosen to ensure greater control over business logic while maintaining scalability and ease of integration with React and MongoDB.

5. Building Block View

Content

The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, data structures, …​) as well as their dependencies (relationships, associations, …​)

This view is mandatory for every architecture documentation. In analogy to a house this is the floor plan.

Motivation

Maintain an overview of your source code by making its structure understandable through abstraction.

This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details.

Form

The building block view is a hierarchical collection of black boxes and white boxes (see figure below) and their descriptions.

Hierarchy of building blocks

Level 1 is the white box description of the overall system together with black box descriptions of all contained building blocks.

Level 2 zooms into some building blocks of level 1. Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks.

Level 3 zooms into selected building blocks of level 2, and so on.

Further Information

See Building Block View in the arc42 documentation.

5.1. Whitebox Overall System

Here you describe the decomposition of the overall system using the following white box template. It contains

  • an overview diagram

  • a motivation for the decomposition

  • black box descriptions of the contained building blocks. For these we offer you alternatives:

    • use one table for a short and pragmatic overview of all contained building blocks and their interfaces

    • use a list of black box descriptions of the building blocks according to the black box template (see below). Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modeling tool).

  • (optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box. Since there are so many ways to specify interfaces why do not provide a specific template for them. In the worst case you have to specify and describe syntax, semantics, protocols, error handling, restrictions, versions, qualities, necessary compatibilities and many things more. In the best case you will get away with examples or simple signatures.

05 building block view EN
Motivation

The main goal of the diagram above is to provide an overall view of the structure of the system, dividing it into separate modules with defined responsibilities.

Contained Building Blocks
Building Block Description

GUI

The user interface application that allows users to log in, start a game, answer questions, and view rankings.

Game

The core service responsible for managing game logic, including question generation and answer processing.

Ranking

A service dedicated to managing player scores and rankings.

Authentication

A service responsible for handling user authentication and session management.

Database

Data storage system that keeps info about players, statistics, games and rankings.
Important Interfaces
Interface Description

GUI - Game

Allows the GUI to request a new game, retrieve questions, and submit user answers.

Game - Ranking

Allows the GameManager to store player results and retrieve rankings to show them in the GUI.

GUI - Authentication

Responsible for validating user credentials via forms and managing sessions.

6. Runtime View

Contents

The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:

  • important use cases or features: how do building blocks execute them?

  • interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems?

  • operation and administration: launch, start-up, stop

  • error and exception scenarios

Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their architectural relevance. It is not important to describe a large number of scenarios. You should rather document a representative selection.

Motivation

You should understand how (instances of) building blocks of your system perform their job and communicate at runtime. You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view).

Form

There are many notations for describing scenarios, e.g.

  • numbered list of steps (in natural language)

  • activity diagrams or flow charts

  • sequence diagrams

  • BPMN or EPCs (event process chains)

  • state machines

  • …​

Further Information

See Runtime View in the arc42 documentation.

6.1. Runtime Scenario 1 - Playing a game

The following diagram depicts the interaction between the user and the most notable modules of the application.

06 runtime view EN

The interaction can be divided into these steps:

  • Logging in: The user logs into the application. If they don’t have an account created, it will be necessary to sign up.

  • Starting the game: Once logged in, the user will start a new game, choosing a mode among all the options.

  • Answering the questions: For each question, the four ellegible answers will be generated. Once per question, its info (question, image and possible answers) will be presented to the user via the GUI, and it will wait for their input. After the user inputs their answer, the score will be increased (or not) accordingly to the choosen answer.

  • Ending the game: Once all the questions have been answered, the GUI will display the final score of the game. Then, the user will have the opportunity to upload this score to the leaderboard. In any case, a shortened ranking of the highest scores will be shown afterwards.

Additional considerations:

  • Once the game is finished, the user will be asked whether they’d like to start a new game. This diagram only portrays one game.

  • In spite of simplicity, this diagram assumes the user already has an account.

7. Deployment View

Content

The deployment view describes:

  1. technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and

  2. mapping of (software) building blocks to that infrastructure elements.

Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.

Especially document a deployment view if your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips.

From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture.

Motivation

Software does not run without hardware. This underlying infrastructure can and will influence a system and/or some cross-cutting concepts. Therefore, there is a need to know the infrastructure.

Form

Maybe a highest level deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. In this section one can zoom into this black box using additional deployment diagrams:

  • UML offers deployment diagrams to express that view. Use it, probably with nested diagrams, when your infrastructure is more complex.

  • When your (hardware) stakeholders prefer other kinds of diagrams rather than a deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.

Further Information

See Deployment View in the arc42 documentation.

7.1. Infrastructure Level 1

Describe (usually in a combination of diagrams, tables, and text):

  • distribution of a system to multiple locations, environments, computers, processors, .., as well as physical connections between them

  • important justifications or motivations for this deployment structure

  • quality and/or performance features of this infrastructure

  • mapping of software artifacts to elements of this infrastructure

For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments.

07 deployment view EN
Motivation

The diagram portrays an overview of the distrubution of each element in the infraestructure, offering details about relationships between devices and communications. Understanding this diagram will help with identifying potential points of failure in the future.

Quality and/or Performance Features

This design has been made taking in consideration potential performance and availability issues. Accessing data from the Wikidata servers, as well as the LLM, will ensure that their failure won’t be fatal to the entire app. On the other hand, hosting the database in the same server as the game will help in reducing response time when accessing the database.

Mapping of Building Blocks to Infrastructure
Device/Node Deployed Artifacts

WIChat server

Game app - Frontend (React), Backend (node.js), database (MongoDB)

Wikidata server

Wikidata API to fetch data via SPARQL queries to dynamically generate questions

OpenLLM server

Open LLM (AI) designed to give hints during the game

8. Cross-cutting Concepts

Content

This section describes overall, principal regulations and solution ideas that are relevant in multiple parts (= cross-cutting) of your system. Such concepts are often related to multiple building blocks. They can include many different topics, such as

  • models, especially domain models

  • architecture or design patterns

  • rules for using specific technology

  • principal, often technical decisions of an overarching (= cross-cutting) nature

  • implementation rules

Motivation

Concepts form the basis for conceptual integrity (consistency, homogeneity) of the architecture. Thus, they are an important contribution to achieve inner qualities of your system.

Some of these concepts cannot be assigned to individual building blocks, e.g. security or safety.

Form

The form can be varied:

  • concept papers with any kind of structure

  • cross-cutting model excerpts or scenarios using notations of the architecture views

  • sample implementations, especially for technical concepts

  • reference to typical usage of standard frameworks (e.g. using Hibernate for object/relational mapping)

Structure

A potential (but not mandatory) structure for this section could be:

  • Domain concepts

  • User Experience concepts (UX)

  • Safety and security concepts

  • Architecture and design patterns

  • "Under-the-hood"

  • development concepts

  • operational concepts

Note: it might be difficult to assign individual concepts to one specific topic on this list.

Possible topics for crosscutting concepts
Further Information

See Concepts in the arc42 documentation.

8.1. Domain Concepts

8.1.1. Introduction

This section covers fundamental principles that influence various aspects of the system, ensuring consistency and proper functionality. It includes domain models, design principles, technologies used, and key architectural decisions.

8.1.2. Motivation

The use of cross-cutting concepts ensures the system’s coherence, optimizing development and maintenance while enhancing security, scalability, and user experience.

8.1.3. Categories of Concepts

  • Domain Models

  • User Experience (UX)

  • Operational Concepts

  • Architecture and Design Patterns

  • Security and Data Protection

  • Development Strategies

Each of these is detailed below.

8.2. Domain Models

8.2.1. Domain Structure

  • User: An individual interacting with the application, capable of handling multiple concurrent sessions.

  • Game: A feature allowing users to engage in individual or multiplayer challenges with different formats.

  • Stats: A section displaying user performance, including total games, accuracy, and average scores.

  • Ranking: Displays user rankings based on scores, correct answers, and playtime.

Domain Entity Diagram

8.3. User Experience (UX)

  • Intuitive Design: A clear and accessible interface for easy navigation.

  • Multilingual Support: Available in multiple languages, with English as the default.

  • Accessibility Features: Visual aids such as icons and colors to improve understanding.

8.4. Operational Concepts

  • Ease of Use: User testing conducted to enhance usability.

  • Enhanced Accessibility: Adjustments made to improve the experience for all users.

8.5. Security

  • Access Control: Restriction of certain sections to authenticated users.

  • Password Security: Minimum 8-character passwords with letters, numbers, and special characters.

  • Data Protection: Encrypted credentials to prevent unauthorized access.

8.6. Architecture and Design Patterns

  • Microservices Architecture: The application is segmented into independent modules such as user management, question generation, and graphical interface.

  • Scalability: The modular structure enables system expansion without compromising performance.

8.7. Development Strategies

  • Automated Testing: Implementation of unit and integration tests to validate system functionality.

  • Continuous Deployment: Use of CI/CD pipelines to ensure active development and deployment processes.

9. Architecture Decisions

9.1. Overview

This section outlines the key architectural decisions made during the development of WIChat. These decisions have been carefully evaluated based on technical feasibility, project constraints, scalability, and maintainability. The rationale for each decision is provided to ensure transparency and traceability for all stakeholders.

9.2. Key Architectural Decisions

An up-to-date list of all architecture decisions taken can be found in this link: https://github.com/Arquisoft/wichat_es1c/wiki

9.3. Motivation

The above decisions were made to ensure that WIChat is scalable, maintainable, and easy to deploy within the constraints of a university project. By selecting a dedicated backend with Node.js and Express, we gain better control over the application’s logic while ensuring flexibility in handling authentication, database interactions, and API management.

9.4. Conclusion

These architectural choices align with the project’s goals of rapid development, minimal operational overhead, and scalability. Future iterations of the system can refine these choices based on usage patterns and performance considerations.

10. Quality Requirements

Content

This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals)

Here you can also capture quality requirements with lesser priority, which will not create high risks when they are not fully achieved.

Motivation

Since quality requirements will have a lot of influence on architectural decisions you should know for every stakeholder what is really important to them, concrete and measurable.

Further Information

See Quality Requirements in the arc42 documentation.

10.1. Quality Tree

10 árbol
Content

The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.

Motivation

The tree structure with priorities provides an overview for a sometimes large number of quality requirements.

Form

The quality tree is a high-level overview of the quality goals and requirements:

  • tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root

  • a mind map with quality categories as main branches

In any case the tree should include links to the scenarios of the following section.

10.2. Quality Scenarios

Contents

Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.

These scenarios describe what should happen when a stimulus arrives at the system.

For architects, two kinds of scenarios are important:

  • Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second.

  • Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change.

Motivation

Scenarios make quality requirements concrete and allow to more easily measure or decide whether they are fulfilled.

Especially when you want to assess your architecture using methods like ATAM you need to describe your quality goals (from section 1.2) more precisely down to a level of scenarios that can be discussed and evaluated.

Form

Tabular or free form text.

Description Quality Attribute Scenario

El sistema debe estar disponible 24/7 con un tiempo de inactividad mínimo.

Alta Disponibilidad

Los usuarios pueden acceder al sistema en cualquier momento sin interrupciones.

La arquitectura debe permitir la adición de más servidores sin interrumpir el servicio.

Escalabilidad

Durante las horas pico, el sistema distribuye el tráfico entre múltiples servidores sin degradar el rendimiento.

La aplicación debe garantizar la protección de los datos de los usuarios, especialmente durante el registro y acceso.

Seguridad

Las credenciales y datos personales de los usuarios están cifrados y almacenados de forma segura para evitar accesos no autorizados.

El tiempo de respuesta para mostrar una pregunta y sus opciones debe ser menor a 2 segundos.

Rendimiento

Un concursante solicita una nueva pregunta y el sistema la presenta casi instantáneamente.

Las preguntas deben generarse correctamente a partir de los datos de Wikidata sin errores.

Integración con Wikidata

El sistema extrae información de Wikidata para generar preguntas de manera precisa y sin inconsistencias.

El chatbot debe proporcionar pistas relevantes y coherentes basadas en la API de LLM.

Precisión de Pistas

Cuando un usuario solicita una pista, el chatbot la genera correctamente utilizando la API de LLM.

La interfaz de usuario debe ser intuitiva, con instrucciones claras sobre cómo participar y obtener pistas.

Usabilidad

Un nuevo usuario puede navegar en la aplicación sin instrucciones previas y entender cómo interactuar con el juego.

11. Risks and Technical Debts

Risks and problems may occur during project development.

11.1. Risks

Name Description Priority

Time

The available time for the project is limited due to each dev in the team having other subjects and projects to work on.

Medium

Version Control (GitHub)

Github is a version control tool in which if we do a bad management we could lose some functionality when it comes to manage the conflicts occurred.

Low

11.2. Technical Debts

Name Description Priority

React

React is a new technology for almost everyone in the team, so they should help each other to learn how to use it, as well as watch some tutorials to understand it better.

High

12. Glossary

Term Definition

Risks

Risks are something bad that could happen but has not yet happened.

Technical Debt

Debt acquired by consciously or unconsciously making the wrong design decisions.

LLM

A large language model is a type of machine learning model designed for natural language processing tasks such as language generation.

Skateholders

Person who affects, is affected or can contribute to the system and its architecture

Wikidata

Wikidata is a free and open knowledge base that can be read and edited by both humans and machines.

About arc42

arc42, the template for documentation of software and system architecture.

Template Version 8.2 EN. (based upon AsciiDoc version), January 2023

Created, maintained and © by Dr. Peter Hruschka, Dr. Gernot Starke and contributors. See https://arc42.org.