First release

docs/src/01_introduction_and_goals.adoc

@@ -1,95 +1,148 @@
-ifndef::imagesdir[:imagesdir: ../images]
-
-[[section-introduction-and-goals]]
-== Introduction and Goals
-
-[role="arc42help"]
-****
-Describes the relevant requirements and the driving forces that software architects and development team must consider. 
-These include
-
-* underlying business goals, 
-* essential features, 
-* essential functional requirements, 
-* quality goals for the architecture and
-* relevant stakeholders and their expectations
-****
-
-=== Requirements Overview
-
-[role="arc42help"]
-****
-.Contents
-Short description of the functional requirements, driving forces, extract (or abstract)
-of requirements. Link to (hopefully existing) requirements documents
-(with version number and information where to find it).
-
-.Motivation
-From the point of view of the end users a system is created or modified to
-improve support of a business activity and/or improve the quality.
-
-.Form
-Short textual description, probably in tabular use-case format.
-If requirements documents exist this overview should refer to these documents.
-
-Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation.
-
-****
-
-=== Quality Goals
-
-[role="arc42help"]
-****
-.Contents
-The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. 
-We really mean quality goals for the architecture. Don't confuse them with project goals.
-They are not necessarily identical.
-
-Consider this overview of potential topics (based upon the ISO 25010 standard):
-
-image::01_2_iso-25010-topics-EN.drawio.png["Categories of Quality Requirements"]
-
-.Motivation
-You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. 
-Make sure to be very concrete about these qualities, avoid buzzwords.
-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
-****
-
-=== Stakeholders
-
-[role="arc42help"]
-****
-.Contents
-Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that
-
-* should know the architecture
-* have to be convinced of the architecture
-* have to work with the architecture or with code
-* need the documentation of the architecture for their work
-* have to come up with decisions about the system or its development
-
-.Motivation
-You should know all parties involved in development of the system or affected by the system.
-Otherwise, you may get nasty surprises later in the development process.
-These stakeholders determine the extent and the level of detail of your work and its results.
-
-.Form
-Table with role names, person names, and their expectations with respect to the architecture and its documentation.
-****
-
-[options="header",cols="1,2,2"]
-|===
-|Role/Name|Contact|Expectations
-| *Students* | Andrés Cadenas Blanco, Christian Fernandez Noriega , Adrián González Guadalupe and Luis Salvador Ferrero | Are the ones in charge of web development. They will work together to make the application. 
-| *Teachers* | Pablo González  | In charge of supervising the student's teamwork, ensuring the work accomplishes the goals in the best way possible and helping in the development and solving doubts.
-| *Bussineses* | RTve has hired software development company HappySw | Emphasis the SOLID part of the web and have a high understanding of this area  
-| *Users*  | Anyone that wants to use the web  | They should be able to understand how to use and move around the web with ease  
-|===
+
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-introduction-and-goals]]
+== Introduction and Goals
+
+[role="arc42help"]
+****
+Describes the relevant requirements and the driving forces that software architects and development team must consider. 
+These include
+
+* 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
+
+[role="arc42help"]
+****
+.Contents
+Short description of the functional requirements, driving forces, extract (or abstract)
+of requirements. Link to (hopefully existing) requirements documents
+(with version number and information where to find it).
+
+.Motivation
+From the point of view of the end users a system is created or modified to
+improve support of a business activity and/or improve the quality.
+
+.Form
+Short textual description, probably in tabular use-case format.
+If requirements documents exist this overview should refer to these documents.
+
+Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
+
+
+.Further Information
+
+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"]
+****
+.Contents
+The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. 
+We really mean quality goals for the architecture. Don't confuse them with project goals.
+They are not necessarily identical.
+
+Consider this overview of potential topics (based upon the ISO 25010 standard):
+
+image::01_2_iso-25010-topics-EN.drawio.png["Categories of Quality Requirements"]
+
+.Motivation
+You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. 
+Make sure to be very concrete about these qualities, avoid buzzwords.
+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
+
+[role="arc42help"]
+****
+.Contents
+Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that
+
+* should know the architecture
+* have to be convinced of the architecture
+* have to work with the architecture or with code
+* need the documentation of the architecture for their work
+* have to come up with decisions about the system or its development
+
+.Motivation
+You should know all parties involved in development of the system or affected by the system.
+Otherwise, you may get nasty surprises later in the development process.
+These stakeholders determine the extent and the level of detail of your work and its results.
+
+.Form
+Table with role names, person names, and their expectations with respect to the architecture and its documentation.
+****
+
+[options="header",cols="1,2,2"]
+|===
+|Role/Name|Contact|Expectations
+| *Students* | Andrés Cadenas Blanco, Christian Fernandez Noriega , Adrián González Guadalupe and Luis Salvador Ferrero | Are the ones in charge of web development. They will work together to make the application. 
+| *Teachers* | Pablo González  | In charge of supervising the student's teamwork, ensuring the work accomplishes the goals in the best way possible and helping in the development and solving doubts.
+| *Bussineses* | RTve has hired software development company HappySw | Emphasis the SOLID part of the web and have a high understanding of this area  
+| *Users*  | Anyone that wants to use the web  | They should be able to understand how to use and move around the web with ease  
+|===
+

docs/src/03_system_scope_and_context.adoc

@@ -48,28 +48,44 @@ The title of the table is the name of your system, the three columns contain the
 
 ****
 
-**<Diagram or Table>**
-
-**<optionally: Explanation of external domain interfaces>**
-
-=== Technical Context
-
-[role="arc42help"]
-****
-.Contents
-Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation which I/O uses which channel.
-
-.Motivation
-Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces.
-
-.Form
-E.g. UML deployment diagram describing channels to neighboring systems,
-together with a mapping table showing the relationships between channels and input/output.
-
-****
-
-**<Diagram or Table>**
-
-**<optionally: Explanation of technical interfaces>**
-
-**<Mapping Input/Output to Channels>**
+[plantuml,"Context diagram",png]
+----
+actor Player
+actor Client
+[Wikidata] <<external>>
+
+[WIQ Game] <<system>>
+[UsersAPI] <<internal>>
+[GeneratedQuestionsAPI] <<internal>>
+Player ..> (WIQ Game) : register/login
+Client ..> (WIQ Game) : view data
+[GeneratedQuestionsAPI] ..> Wikidata
+[WIQ Game] ..> UsersAPI
+[WIQ Game] ..> GeneratedQuestionsAPI
+----
+
+[cols="e,2e" options="header"]
+|===
+|Element |Description
+
+|Player
+|Plays the game and can consult past scores
+
+|Client
+|Can access the data about players and generated questions
+
+|WIQ Game
+|Main system in which generated questions are shown and can be answered by players
+
+|Wikidata
+|External data repository from which questions are generated using the WikidataAPI
+
+|MongoDB
+|Database for storing generated questions, players' info and scores
+
+|Users Info API
+|Allows clients to see the info about players stored in the database
+
+|Generated Questions API
+|Allows clients to see the info about generated questions stored in the database
+|===

docs/src/04_solution_strategy.adoc

@@ -2,7 +2,17 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-solution-strategy]]
 == Solution Strategy
+The system will follow *MERN Stack* as they key technologies for its development. MERN Stack is composed of four technologies: MongoDB, Express, 
+React and Node.
 
+* *MongoDB:* chosen technology for the persistance of the system, that provides a non-relational database approach.
+* *Express and Node:* they make up the middle tier of the application, providing a powerful server platform.
+* *React:* front-end framework that will solve the client interfaces of the application.
+
+Regarding the deployment of the application, the strategy chosen is a *cloud-based* system. This decision was motivated because of the nature of
+the project, since a web application needs to be live and accesible at any moment.
+The server will be an ARM *Linux VM on Oracle*, where some *containers* for different charasteristics of the system will be *deployed with
+Docker* (MongoDB database for example)
 
 [role="arc42help"]
 ****