diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 0000000..9e26dfe --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1 @@ +{} \ No newline at end of file diff --git a/README.md b/README.md index d84a1d4..f05f003 100644 --- a/README.md +++ b/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 | UO282276@uniovi.es | | Christian Fernandez Noriega | UO282650@uniovi.es | | Adrián González Guadalupe | UO287621@uniovi.es | -| Luis Salvador Ferrero | UO287841@uniovi.es | \ No newline at end of file +| Luis Salvador Ferrero | UO287841@uniovi.es | diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc index ddb2ae3..8a8206d 100644 --- a/docs/src/01_introduction_and_goals.adoc +++ b/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 diff --git a/docs/src/10_quality_requirements.adoc b/docs/src/10_quality_requirements.adoc index 68475e8..e81acbd 100644 --- a/docs/src/10_quality_requirements.adoc +++ b/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* + +|=== \ No newline at end of file