Merge branch 'master' of https://github.com/Arquisoft/wiq_en2a

docs/src/01_introduction_and_goals.adoc

@@ -2,92 +2,60 @@ 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
+The project is a quizz game based on the Spanish TV show "Saber y ganar", the users will be able to test their knowledge with questions from different categories and difficulties. Users will autenticate themselves into the system or create an account first.
 ****
-
 === 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.
 
+* Users will be able to create an account and log in
+* Each question must have a prize associated to it
+* Accesible through the web
+* Historical data of a user will be saved on that user's account
+* Questions have a time limit to be answered
+* Possible answer will be given to the user, only one of them being correct
+* Information about users and questions will be obtained through API's
+* Modo multijugador y modo individual
+* Se habilitarán salas de juego en tiempo real para el modo multijugador
 
-.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.
+ 
+//This table is just a placeholder, replace it with real quality goals once discussed !!!
+
 
-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...
+(based upon the ISO 25010 standard):
+[options="header",cols="1,2,2"]
+|===
+|Code|Quality Goal|Scenario
+|QG1|Usability|The user can easily navigate through the app and find the information they need
+|QG2|Performance|The app should be able to handle a large amount of users at the same time
+|QG3|Security|The user's data should be protected and not accesible by anyone else
 
-.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
-| _<Role-1>_ | _<Contact-1>_ | _<Expectation-1>_
-| _<Role-2>_ | _<Contact-2>_ | _<Expectation-2>_
+| _Wikidata_ | _Wikidata.org_ | _Public exposure by the use of their services deriving in a greater demand of said services_
+| _Uniovi's Software Architecture Teacher council_ | [email protected]_ | _Provide their students (development team) with a practical experience about the use of Software architecture in projects and making sure the have understood the concepts of it_
+|_Development Team_||_Acquire experience in the development process of Software Architecture and pass the subject to complete their studies_
+|_Users_|_Anyone who uses the app_|_Test their knowledge on a functional and easy to use quizz game app_
 |===

docs/src/03_system_scope_and_context.adoc

@@ -4,47 +4,16 @@ ifndef::imagesdir[:imagesdir: ../images]
 == System Scope and Context
 
 
-[role="arc42help"]
-****
-.Contents
-System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners
-(neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces.
 
-If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).
 
-.Motivation
-The domain interfaces and technical interfaces to communication partners are among your system's most critical aspects. Make sure that you completely understand them.
 
-.Form
-Various options:
-
-* Context diagrams
-* Lists of communication partners and their interfaces.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentation.
-
-****
 
 
 === Business Context
 
 [role="arc42help"]
 ****
-.Contents
-Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces.
-Optionally you can add domain specific formats or communication protocols.
-
-.Motivation
-All stakeholders should understand which data are exchanged with the environment of the system.
-
-.Form
-All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners.
-
-Alternatively (or additionally) you can use a table.
-The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.
+image::business-context.png[Business Context Diagram, 600, 400]
 
 ****