From deead76a8757d82eb512d38129157aed0d7d32c1 Mon Sep 17 00:00:00 2001 From: didierrc Date: Mon, 12 Feb 2024 19:44:51 +0100 Subject: [PATCH 1/3] Created Doc01 branch and added all sub-sections except QualityGoals --- docs/src/01_introduction_and_goals.adoc | 97 ++++++++++++------------- 1 file changed, 47 insertions(+), 50 deletions(-) diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc index ddb2ae3d..2496dd88 100644 --- a/docs/src/01_introduction_and_goals.adoc +++ b/docs/src/01_introduction_and_goals.adoc @@ -2,21 +2,41 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-introduction-and-goals]] == Introduction and Goals +RTVE wants to offer a web application based on the famous Spanish TV show +https://es.wikipedia.org/wiki/Saber_y_ganar["Saber y Ganar"] +to its users in commemoration of the 28th anniversary of the show. This show consisted on +answering a number of questions with different types and subjects obtaining a prize for +each question well answered. + +The expected goal is to offer a well-desgined game that maintains all the quality standards +that the company offers like maintainability, security, etc...; while trying to fulfill the +user's needs to provide a positive UX. [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 +Notes: +The shown requirements may increase if during the development +of the project more features are included. Please, refer to +https://github.com/Arquisoft/wiq_en3b/wiki/Lab-Assignment-Overview#optional-features[Optional features] for more info. **** === Requirements Overview +The web application must meet the following requirements: + +[options="header",cols="1,2" ] +|=== +| Requirement | Description +| Accesibility | It must be taken care of the different HTML standards so Screen-readers users can also play the game. Also, take care of features like coloring. +| Availability | The system must always be available so users can play at any time. +| User Registration and Login | Users must be able to register into game so its data is stored for later consult. +| WikiData | The questions and answer options must be generated using the WikiData API. +| Timer | All the questions must have a time to answer. +| APIs | The game must expose two APIs that retrieves information about 1. Users and 2. Questions generated. +|=== + + + [role="arc42help"] **** .Contents @@ -43,51 +63,28 @@ See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 docum === 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"] +[options="header",cols="1,2a,2" ] |=== |Role/Name|Contact|Expectations -| __ | __ | __ -| __ | __ | __ +| RTVE | rtve.dircom@rtve.es | A web application that emulates the functionality of the famous Spanish TV show "Saber y Ganar". +| HappySw | contact_projects@happysw.es | An application that meets all the requirements asked by RTVE mantaining the quality that offers the company. +| Professors +| +* Pablo González: gonzalezgpablo@uniovi.es +* Jose Labra: labra@uniovi.es +| A well-designed web application that fulfills the functional requirements for the game to work, as well as, the quality requirements. +| Users | | A "Saber y Ganar" web game to test their knowdlege on different fields. The game must be easy to use and must record all of their past games. +| Development team +| +* Carlos Menéndez González (UO288056@uniovi.es) +* Didier Yamil Reyes Castro (UO287866@uniovi.es) +* Iyán Robles Suárez (UO288780@uniovi.es) +* Raúl Mera Soto (UO287827@uniovi.es) +* Mateo Rico Iglesias (UO277172@uniovi.es) +* Anna Kutova (UO305098@uniovi.es) +* Diego Murias Suárez (UO290009@uniovi.es) +| A good documented and clean code that fulfills the expected requirements. Also, a well implemented System that makes it easier for maintenance and extension. |=== From 5f41625cf40fea60877e3ed489699b31bacff483 Mon Sep 17 00:00:00 2001 From: Murias10 Date: Wed, 14 Feb 2024 23:04:32 +0100 Subject: [PATCH 2/3] Quality Goals done and Requirements Overview completed --- docs/src/01_introduction_and_goals.adoc | 53 +++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc index 2496dd88..ce6ddfcd 100644 --- a/docs/src/01_introduction_and_goals.adoc +++ b/docs/src/01_introduction_and_goals.adoc @@ -33,6 +33,17 @@ The web application must meet the following requirements: | WikiData | The questions and answer options must be generated using the WikiData API. | Timer | All the questions must have a time to answer. | APIs | The game must expose two APIs that retrieves information about 1. Users and 2. Questions generated. +| Game History +| Maintain a record of users' participation in the game, including the number of games played, questions passed and failed, and times played. + +| Question Generation +| Questions will be automatically generated from data available in Wikidata, and users must answer them within a specific time limit. + +| Question Options +| Each question will have one correct answer and several automatically generated incorrect options or distractors. + +| API Access +| The system will provide access to user information and information about the generated questions through APIs. |=== @@ -63,6 +74,48 @@ See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 docum === Quality Goals +[cols="1,1,1,1",options="header"] +|=== +| Priority | Quality Goal | Description | Considerations + +| 1 +| Usability +| As with any application, response time, learning curve, and navigability of the application should meet standards and expected minimums. The system should be easy to use and not require specific or complex knowledge. | Consider incorporating user feedback and usability testing to refine the user interface. + +| 2 +| Availability +| The application must be accessible 24 hours a day. While complete availability may be impossible over extended periods, minimizing downtime and making interruptions imperceptible to users is key. | Implementing redundancy and failover mechanisms can help ensure continuous availability. + +| 3 +| Security +| The application should adhere to industry best practices for security to protect against unauthorized access, data breaches, and other threats. | Regular security audits and implementing basic security controls are essential. + +| 4 +| Maintainability +| The application should demonstrate good architecture and design to showcase the team's capabilities and ensure easy maintenance. | Documenting code and following best practices contribute to maintainability. + +| 5 +| Privacy +| Users must be assured that their personal information is protected when using the application. | Implementing basic data protection measures and ensuring compliance with relevant regulations enhance privacy. + +| 6 +| Performance +| The software should have acceptable response time to provide a smooth user experience. | Basic optimization techniques can improve performance. + +| 7 +| Efficiency +| Application functionalities should be efficient for users to accomplish their tasks effectively. | Streamlining workflows and minimizing redundant processes contribute to efficiency. + +| 8 +| Testability +| The application must be designed to facilitate testing across various scenarios to ensure robustness and reliability. | Implementing basic testing frameworks and writing unit tests support testability. + +| 9 +| Adaptability +| The application should adapt seamlessly to different devices and screen sizes. While primarily developed for desktops, it should also provide a satisfactory user experience on mobile devices. | Utilizing responsive design principles and conducting compatibility testing across devices can enhance adaptability. + +|=== + === Stakeholders From a97e2d04914ccc3efc7010229340aa9f9a8c383b Mon Sep 17 00:00:00 2001 From: didierrc Date: Fri, 16 Feb 2024 19:12:34 +0100 Subject: [PATCH 3/3] Resolved duplication on documentation. --- docs/src/01_introduction_and_goals.adoc | 46 +++---------------------- 1 file changed, 5 insertions(+), 41 deletions(-) diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc index ce6ddfcd..fa910ba8 100644 --- a/docs/src/01_introduction_and_goals.adoc +++ b/docs/src/01_introduction_and_goals.adoc @@ -29,49 +29,13 @@ The web application must meet the following requirements: | Requirement | Description | Accesibility | It must be taken care of the different HTML standards so Screen-readers users can also play the game. Also, take care of features like coloring. | Availability | The system must always be available so users can play at any time. -| User Registration and Login | Users must be able to register into game so its data is stored for later consult. -| WikiData | The questions and answer options must be generated using the WikiData API. +| User Registration and Login | Users must be able to register into game or login into the game. +| WikiData | The questions and answer options (a correct one and three distractors) must be generated using the WikiData API. | Timer | All the questions must have a time to answer. | APIs | The game must expose two APIs that retrieves information about 1. Users and 2. Questions generated. -| Game History -| Maintain a record of users' participation in the game, including the number of games played, questions passed and failed, and times played. - -| Question Generation -| Questions will be automatically generated from data available in Wikidata, and users must answer them within a specific time limit. - -| Question Options -| Each question will have one correct answer and several automatically generated incorrect options or distractors. - -| API Access -| The system will provide access to user information and information about the generated questions through APIs. +| User History | Maintain a record of users' participation in the game, including the number of games played, questions passed and failed, and times played. |=== - - -[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 [cols="1,1,1,1",options="header"] @@ -88,7 +52,7 @@ See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 docum | 3 | Security -| The application should adhere to industry best practices for security to protect against unauthorized access, data breaches, and other threats. | Regular security audits and implementing basic security controls are essential. +| The application should stick to industry best practices for security to protect against unauthorized access, data breaches, and other threats. | Regular security audits and implementing basic security controls are essential. | 4 | Maintainability @@ -112,7 +76,7 @@ See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 docum | 9 | Adaptability -| The application should adapt seamlessly to different devices and screen sizes. While primarily developed for desktops, it should also provide a satisfactory user experience on mobile devices. | Utilizing responsive design principles and conducting compatibility testing across devices can enhance adaptability. +| The application should adapt seamlessly to different devices and screen sizes. While primarily developed for desktops, it should also provide a satisfactory user experience on mobile devices. | Utilising responsive design principles and conducting compatibility testing across devices can enhance adaptability. |===