1.1 1.2 and 10 Documentation

1.1, 1.2 and 10. Documentation

.vscode/settings.json

@@ -0,0 +1 @@
+{}

README.md

@@ -1,9 +1,11 @@
 # wiq_en1a
-
+[![Deploy on release](https://github.com/Arquisoft/wiq_en1a/actions/workflows/release.yml/badge.svg)](https://github.com/Arquisoft/wiq_en1a/actions/workflows/release.yml)
+[![Quality Gate Status](https://sonarcloud.io/api/project_badges/measure?project=Arquisoft_wiq_en1a&metric=alert_status)](https://sonarcloud.io/summary/new_code?id=Arquisoft_wiq_en1a)
+[![Coverage](https://sonarcloud.io/api/project_badges/measure?project=Arquisoft_wiq_en1a&metric=coverage)](https://sonarcloud.io/summary/new_code?id=Arquisoft_wiq_en1a)
 ### Members
 | Name                        | Email              |
 |-----------------------------|--------------------|
 | Andrés Cadenas Blanco       | [email protected] |
 | Christian Fernandez Noriega | [email protected] |
 | Adrián González Guadalupe   | [email protected] |
-| Luis Salvador Ferrero       | [email protected] |
+| Luis Salvador Ferrero       | [email protected] |

docs/src/01_introduction_and_goals.adoc

@@ -8,12 +8,13 @@ ifndef::imagesdir[:imagesdir: ../images]
 Describes the relevant requirements and the driving forces that software architects and development team must consider. 
 These include
 
-* underlying business goals, 
+* underlying business goals,
 * essential features, 
 * essential functional requirements, 
 * quality goals for the architecture and
 * relevant stakeholders and their expectations
 ****
+In these points, the main goals and functional requirements will be explained. In order to give context on how the webapp will be developed.
 
 === Requirements Overview
 
@@ -40,7 +41,43 @@ Keep these excerpts as short as possible. Balance readability of this document w
 See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation.
 
 ****
-
+The functional requirements have been grouped into the different microservices the web application will have.
+==== User and Authorization Services
+[decimal]
+. The User service allows the user to
+[arabic]
+.. Register.
+.. Delete the account.
+.. Update the account.
+.. Recover the password.
+. The authorization service allows the user to 
+[arabic]
+.. Log in.
+.. Log out.
+. A user can retrieve the following information from the User service
+[arabic]
+.. Name.
+.. Email.
+.. Profile picture.
+.. Questions answered.
+. The system must be able to manage the user's access to the system.
+
+==== Question Service
+[decimal, start=5]
+. The Question service retrieves questions generated from wikidata.
+. A user can retrieve the following information from the Question service
+[arabic]
+.. Select a category.
+.. Select a difficulty.
+.. Select a question.
+.. Select an answer.
+. Questions must be stored in a database.
+. The database used is MongoDB.
+. Questions are classified by
+[arabic]
+.. Category.
+.. Difficulty.
+. The questions should be selected randomly.
 === Quality Goals
 
 [role="arc42help"]
@@ -62,6 +99,20 @@ If you as an architect do not know how the quality of your work will be judged..
 .Form
 A table with quality goals and concrete scenarios, ordered by priorities
 ****
+[options="header", cols="1,1"]
+|===
+| Goal | Description
+| Testability |Test will be developed, so the application has a good quality.
+
+| Usability | The application has to be intuitive for its users.
+
+| Portability | The application works in different devices and browsers. With different screen sizes.
+
+| Performance | The application can handle a big number of users and give good response times.
+
+
+
+|===
 
 === Stakeholders
 

docs/src/10_quality_requirements.adoc

@@ -45,7 +45,13 @@ In any case the tree should include links to the scenarios of the following sect
 
 
 ****
-
+@startmindmap
+* Quality
+** Testability
+** Usability
+** Portability
+** Performance
+@endmindmap
 === Quality Scenarios
 
 [role="arc42help"]
@@ -71,3 +77,46 @@ more precisely down to a level of scenarios that can be discussed and evaluated.
 .Form
 Tabular or free form text.
 ****
+==== Usage Scenarios
+[options="header", cols="1,1,1,1"]
+|===
+| Quality goal | Motivation | Usage scenario | Priority
+
+| *Testability* 
+| Test will be developed, so the application has a good quality.
+| The coverage should be higher than 70% and SonarCloud should give a pass in unit tests
+| *High*
+
+| *Usability* 
+| The application has to be intuitive for its users.
+| Users don't like to spend a lot of time trying to understand how to use an application. Therefore when they want to do something, they want to know where to go and what to do.
+| *Very high*
+
+| *Portability*
+| The application works in different devices and browsers. With different screen sizes.
+| Users connect from different devices and browsers, we should ensure that the application works in all of them.
+| *Medium*
+
+| *Performance*
+| The application can handle a big number of users and give good response times.
+| The application should be able to stand at least 10 users simultaneously and give a response time of less than 20 seconds.
+| *High*
+
+|===
+
+==== Change Scenarios
+
+[options="header", cols="1,1,1,1"]
+|===
+| Quality goal | Motivation | Change scenario | Priority
+| *Maintainability*
+| An application should be easy to update and maintain by the dev team. Respecting the architecture of the web application and the continuous integration.
+| If a developer wants to add a feauture or include a hotfix, he should be able to do it without major consequences on the system, always respecting the architecture of the web application.
+| *High*
+
+| *Maintainability*
+|An application should be easy to update and maintain by the dev team. Respecting the architecture of the web application.
+| As there is continuous integration, when fixing a bug or adding a feature, if an error is found, the application won't be affected as changes won't be applied.
+| *Very High*
+
+|===