generated from Arquisoft/wiq_0
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #15 from Arquisoft/Doc01
Doc01 First Version
- Loading branch information
Showing
1 changed file
with
77 additions
and
63 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,92 +2,106 @@ 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 | ||
|
|
||
| [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). | ||
| The web application must meet the following requirements: | ||
|
|
||
| .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. | ||
| [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 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. | ||
| | User History | Maintain a record of users' participation in the game, including the number of games played, questions passed and failed, and times played. | ||
| |=== | ||
|
|
||
| .Form | ||
| Short textual description, probably in tabular use-case format. | ||
| If requirements documents exist this overview should refer to these documents. | ||
| === Quality Goals | ||
|
|
||
| Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents. | ||
| [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. | ||
|
|
||
| .Further Information | ||
| | 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. | ||
|
|
||
| See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation. | ||
| | 3 | ||
| | Security | ||
| | 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 | ||
| | 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. | ||
|
|
||
| === Quality Goals | ||
| | 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. | ||
|
|
||
| [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. | ||
| | 6 | ||
| | Performance | ||
| | The software should have acceptable response time to provide a smooth user experience. | Basic optimization techniques can improve performance. | ||
|
|
||
| Consider this overview of potential topics (based upon the ISO 25010 standard): | ||
| | 7 | ||
| | Efficiency | ||
| | Application functionalities should be efficient for users to accomplish their tasks effectively. | Streamlining workflows and minimizing redundant processes contribute to efficiency. | ||
|
|
||
| image::01_2_iso-25010-topics-EN.drawio.png["Categories of Quality Requirements"] | ||
| | 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. | ||
|
|
||
| .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... | ||
| | 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. | Utilising responsive design principles and conducting compatibility testing across devices can enhance adaptability. | ||
|
|
||
| .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. | ||
| **** | ||
| === Stakeholders | ||
|
|
||
| [options="header",cols="1,2,2"] | ||
| [options="header",cols="1,2a,2" ] | ||
| |=== | ||
| |Role/Name|Contact|Expectations | ||
| | _<Role-1>_ | _<Contact-1>_ | _<Expectation-1>_ | ||
| | _<Role-2>_ | _<Contact-2>_ | _<Expectation-2>_ | ||
| | RTVE | [email protected] | A web application that emulates the functionality of the famous Spanish TV show "Saber y Ganar". | ||
| | HappySw | [email protected] | An application that meets all the requirements asked by RTVE mantaining the quality that offers the company. | ||
| | Professors | ||
| | | ||
| * Pablo González: [email protected] | ||
| * Jose Labra: [email protected] | ||
| | 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 ([email protected]) | ||
| * Didier Yamil Reyes Castro ([email protected]) | ||
| * Iyán Robles Suárez ([email protected]) | ||
| * Raúl Mera Soto ([email protected]) | ||
| * Mateo Rico Iglesias ([email protected]) | ||
| * Anna Kutova ([email protected]) | ||
| * Diego Murias Suárez ([email protected]) | ||
| | A good documented and clean code that fulfills the expected requirements. Also, a well implemented System that makes it easier for maintenance and extension. | ||
| |=== | ||