Changes to point 2 -> Arquitecture constraints

docs/src/02_architecture_constraints.adoc

@@ -3,6 +3,34 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-architecture-constraints]]
 == Architecture Constraints
 
+When designing the WIQ application, there are several constraints that must be taken into consideration, as they will have a significant impact on the overall design of the application and the architectural decisions. These constraints must be considered in order to ensure that the final product meets the needs and expectations of the users and stakeholders. The following table summarizes these constraints and provides a brief explanation for each one divided into technical, organizational and political constraints.
+
+=== Technical constraints
+|===
+|Constraint|Explanation
+| WikiData | Our application must generate questions automatically getting data from WikiData 
+| Docker | We are using docker for the deployment.It's a platform that allows you to package Our application and its dependencies into a standardized unit called a container. 
+| Azure | Azure is a cloud computing platform where we are going to host our WIQ application
+| Version control and monitoring (GitHub) | For the WIQ application, GitHub is a useful tool for version control and collaboration among the team members working on the project. It allows easier coordination and organization of the development process, as well as keeping track of changes and contributions made by each team member. 
+| User Experience | The design of the application must make its use friendly and easy 
+| Test coverage | Code must meet a good test quality and coverage to ensure the expected outcome.
+|===
+
+=== Organizational constraints
+|===
+|Constraint|Explanation
+| Team | The project will be done in a team composed of 7 students, so work must be assigned accordingly.
+| Git-based development | The project will be built around the Git workflow, so all tools used must be able to closely interact with this system. 
+| Meetings |  The project’s development process must be reflected in the minutes of each meeting that happens. 
+| Delivery deadlines | There are 4 deliverables every 3 weeks that should be followed accordingly before the deployment of the application 
+|===
+
+=== Political constraints
+|===
+|Constraint|Explanation
+| Documentation | We are going to use AsciiDoc and follow the Arc42 template. 
+| Language | The documentation and application will be developed in English. 
+|===
 
 [role="arc42help"]
 ****

docs/src/09_architecture_decisions.adoc

@@ -3,6 +3,28 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-design-decisions]]
 == Architecture Decisions
 
+Along the process of developing the application, decisions had to be taken as problems arise.
+These are the initial decicision that we have made but they change during the course of the project
+The following table contains some of the design decisions that were imposed to us due to the architectural constraints:
+
+.Imposed decisions
+|===
+|Code|Decision|Advantages|Disadvantages
+|ID1| React.js or Svelte | Quite easy to learn in comparison to other front-end libraries. Increasingly popular in the web.|Not all of us know about its usage
+|ID2| MongoDB | It does not need to be started manually. Free and easy to understand|We are quite new with MongoDB.
+|ID3| Docker | Fast deployment, ease of moving/maintaining your applications. Easy as we already have DockerFiles example|We do not have much experience using Docker
+|ID4| PlantUML | Allows drawing diagrams very easily, with a simple syntax.|Does not allow as much control over the exact layout of the elements in the diagram as other tools.
+|===
+
+.Architectural Records
+|===
+|Code |Context |Record
+
+|ADR1 | TBD | TBD
+
+|ADR2 | TBD | TBD
+
+|===
 
 [role="arc42help"]
 ****