forked from Arquisoft/wiq_0
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Apartado 10 de la documentación V0.1
- Loading branch information
1 parent
d7b2ee9
commit cd24984
Showing
1 changed file
with
59 additions
and
46 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 |
---|---|---|
@@ -1,73 +1,86 @@ | ||
ifndef::imagesdir[:imagesdir: ../images] | ||
|
||
[[section-quality-scenarios]] | ||
== Quality Requirements | ||
== Requisitos de calidad | ||
|
||
|
||
[role="arc42help"] | ||
**** | ||
=== Árbol de calidad | ||
|
||
.Content | ||
This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals) | ||
|
||
Here you can also capture quality requirements with lesser priority, | ||
which will not create high risks when they are not fully achieved. | ||
[cols="1,1,1,1"] | ||
|=== | ||
|Categoría |Calidad |Descripción |Escenario | ||
|
||
.Motivation | ||
Since quality requirements will have a lot of influence on architectural | ||
decisions you should know for every stakeholder what is really important to them, | ||
concrete and measurable. | ||
|Adecuación funcional | ||
|Corrección funcional | ||
|El sistema deberá marcar que las respuestas correctas a las preguntas se corresponden con wikidata | ||
|SC1 | ||
|
||
|Eficiencia de desempeño | ||
|Comportamiento temporal | ||
|El sistema deberá responder a las acciones de los usuarios en menos de 5 segundos bajo condiciones normales | ||
|SC2 | ||
|
||
.Further Information | ||
| | ||
|Utilización de recursos | ||
|El sistema deberá usar recursos inferiores a los establecidos por Azure | ||
| | ||
|
||
See https://docs.arc42.org/section-10/[Quality Requirements] in the arc42 documentation. | ||
|Seguridad | ||
|Integridad | ||
|El sistema deberá proteger los datos del usuario contra accesos y modificaciones no autorizados | ||
| | ||
|
||
**** | ||
|Usabilidad | ||
|Reconocibilidad de la adecuación | ||
|El sistema deberá ser fácil de usar para un usuario que conozca "Saber y ganar" | ||
|SC3 | ||
|
||
=== Quality Tree | ||
| | ||
|Estética de la interfaz de usuario | ||
|El sistema deberá tener una interfaz que facilite al usuario jugar correctamente | ||
| | ||
|
||
[role="arc42help"] | ||
**** | ||
.Content | ||
The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs. | ||
|Mantenibilidad | ||
|Capacidad para ser modificado | ||
|La capa de interfaz deberá estar separada de la lógica de negocio | ||
| | ||
|
||
.Motivation | ||
The tree structure with priorities provides an overview for a sometimes large number of quality requirements. | ||
| | ||
|Capacidad para ser probado | ||
|Se deberán poder crear pruebas unitarias | ||
| | ||
|
||
.Form | ||
The quality tree is a high-level overview of the quality goals and requirements: | ||
|Portabilidad | ||
|Adaptabilidad | ||
|El sistema deberá porder usarse en las últimas versiones de Chrome y Firefox | ||
| | ||
|
||
* tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root | ||
* a mind map with quality categories as main branches | ||
|Fiabilidad | ||
|Disponibilidad | ||
|El sistema deberá registrar un fallo cuando no sea posible obtener datos de la API de wikidata correctamente | ||
|SC4 | ||
|
||
In any case the tree should include links to the scenarios of the following section. | ||
|=== | ||
|
||
|
||
**** | ||
=== Escenarios de calidad | ||
|
||
=== Quality Scenarios | ||
[cols="1,1"] | ||
|=== | ||
|ID |Escenario | ||
|
||
[role="arc42help"] | ||
**** | ||
.Contents | ||
Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios. | ||
|SC1 | ||
|Un usuario puede comprobar que la respuesta correcta a su pregunta coincide con Wikidata | ||
|
||
These scenarios describe what should happen when a stimulus arrives at the system. | ||
|SC2 | ||
|Al responder una pregunta, el sistema muestra si es correcta o falsa en menos de 5 segundos | ||
|
||
For architects, two kinds of scenarios are important: | ||
|SC3 | ||
|Un nuevo usuario que conozca "Saber y ganar" puede aprender a jugar en menos de 5 minutos | ||
|
||
* Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second. | ||
* Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change. | ||
|SC4 | ||
|Si no se puedan obtener datos de Wikidata, se le mostrará un mensaje de error al usuario al generar la pregunta | ||
|
||
.Motivation | ||
Scenarios make quality requirements concrete and allow to | ||
more easily measure or decide whether they are fulfilled. | ||
|=== | ||
|
||
Especially when you want to assess your architecture using methods like | ||
ATAM you need to describe your quality goals (from section 1.2) | ||
more precisely down to a level of scenarios that can be discussed and evaluated. | ||
.Form | ||
Tabular or free form text. | ||
**** |