diff --git a/docs/images/BusinessContext1.1.png b/docs/images/BusinessContext1.1.png new file mode 100644 index 0000000..fc39dda Binary files /dev/null and b/docs/images/BusinessContext1.1.png differ diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc index ddb2ae3..4121005 100644 --- a/docs/src/01_introduction_and_goals.adoc +++ b/docs/src/01_introduction_and_goals.adoc @@ -2,42 +2,25 @@ 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. **** @@ -45,49 +28,34 @@ See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 docum [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 -| __ | __ | __ -| __ | __ | __ +| _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_ | _jelabra@gmail.com_ | _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_ |=== diff --git a/docs/src/03_system_scope_and_context.adoc b/docs/src/03_system_scope_and_context.adoc index c528e90..b3e1185 100644 --- a/docs/src/03_system_scope_and_context.adoc +++ b/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] ****