diff --git a/docs/src/10_quality_requirements.adoc b/docs/src/10_quality_requirements.adoc
index 68475e80..f9bc58f1 100644
--- a/docs/src/10_quality_requirements.adoc
+++ b/docs/src/10_quality_requirements.adoc
@@ -1,73 +1,86 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-quality-scenarios]]
-== Quality Requirements
+== Requisitos de calidad
 
 
-[role="arc42help"]
-****
+=== Árbol de calidad
 
-.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.
+[cols="1,1,1,1"]
+|===
+|Categoría |Calidad |Descripción |Escenario
 
-.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.
+|Adecuación funcional
+|Corrección funcional
+|El sistema deberá marcar que las respuestas correctas a las preguntas se corresponden con wikidata
+|SC1
 
+|Eficiencia de desempeño
+|Comportamiento temporal
+|El sistema deberá responder a las acciones de los usuarios en menos de 5 segundos bajo condiciones normales
+|SC2
 
-.Further Information
+|
+|Utilización de recursos
+|El sistema deberá usar recursos inferiores a los establecidos por Azure
+|
 
-See https://docs.arc42.org/section-10/[Quality Requirements] in the arc42 documentation.
+|Seguridad
+|Integridad
+|El sistema deberá proteger los datos del usuario contra accesos y modificaciones no autorizados
+|
 
-****
+|Usabilidad
+|Reconocibilidad de la adecuación
+|El sistema deberá ser fácil de usar para un usuario que conozca "Saber y ganar"
+|SC3
 
-=== Quality Tree
+|
+|Estética de la interfaz de usuario
+|El sistema deberá tener una interfaz que facilite al usuario jugar correctamente
+|
 
-[role="arc42help"]
-****
-.Content
-The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.
+|Mantenibilidad
+|Capacidad para ser modificado
+|La capa de interfaz deberá estar separada de la lógica de negocio
+|
 
-.Motivation
-The tree structure with priorities provides an overview for a sometimes large number of quality requirements.
+|
+|Capacidad para ser probado
+|Se deberán poder crear pruebas unitarias
+|
 
-.Form
-The quality tree is a high-level overview of the quality goals and requirements:
+|Portabilidad
+|Adaptabilidad
+|El sistema deberá porder usarse en las últimas versiones de Chrome y Firefox
+|
 
-* tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root
-* a mind map with quality categories as main branches
+|Fiabilidad
+|Disponibilidad
+|El sistema deberá registrar un fallo cuando no sea posible obtener datos de la API de wikidata correctamente
+|SC4
 
-In any case the tree should include links to the scenarios of the following section.
+|===
 
 
-****
+=== Escenarios de calidad
 
-=== Quality Scenarios
+[cols="1,1"]
+|===
+|ID |Escenario
 
-[role="arc42help"]
-****
-.Contents
-Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.
+|SC1
+|Un usuario puede comprobar que la respuesta correcta a su pregunta coincide con Wikidata
 
-These scenarios describe what should happen when a stimulus arrives at the system.
+|SC2
+|Al responder una pregunta, el sistema muestra si es correcta o falsa en menos de 5 segundos
 
-For architects, two kinds of scenarios are important:
+|SC3
+|Un nuevo usuario que conozca "Saber y ganar" puede aprender a jugar en menos de 5 minutos
 
-* 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.
+|SC4
+|Si no se puedan obtener datos de Wikidata, se le mostrará un mensaje de error al usuario al generar la pregunta
 
-.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.
-****