Documantation point 10 finnished

docs/src/10_quality_requirements.adoc

@@ -3,7 +3,6 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-quality-scenarios]]
 == Quality Requirements
 
-
 [role="arc42help"]
 ****
 
@@ -27,47 +26,27 @@ See https://docs.arc42.org/section-10/[Quality Requirements] in the arc42 docume
 
 === Quality Tree
 
-[role="arc42help"]
-****
-.Content
-The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.
-
-.Motivation
-The tree structure with priorities provides an overview for a sometimes large number of quality requirements.
-
-.Form
-The quality tree is a high-level overview of the quality goals and requirements:
-
-* tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root
-* a mind map with quality categories as main branches
+image::QualityAttributesTree.PNG["Quality Attributes Tree"]
 
-In any case the tree should include links to the scenarios of the following section.
+[Attributes]
+|===
+|Quality Category |Quality |Description |Scenario
 
-
-****
+|Usability(QG1)| Ease of use| Ease of use for the user| 
+|   |Ease of Learning| The standard functions should be as easy and intuitive to use as possible without the need for lengthy prior instruction| SC1
+|Performance(QG2)| Responsiveness| Pages shoud load at a resonable time.\n During the game the answers to the questions must be processed by the system quickly|
+|   |Robustness| The system shall work reliable under all specified environment and operating conditions.|
+|Question Generation|Compressible questions| The system shall generate compressible questions using information fomr Wikidata|SC2 
+|   |Question Variety| The system shall generate questions based on different fields of knowledge keeping the from getting repetitive|
+|Security(QG3)|Data Protection|The user’s data should be protected and not accesible by anyone else|   
+|===
 
 === Quality Scenarios
 
-[role="arc42help"]
-****
-.Contents
-Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.
-
-These scenarios describe what should happen when a stimulus arrives at the system.
-
-For architects, two kinds of scenarios are important:
-
-* 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.
+[Attributes]
+|===
+|Id |Scenario
 
-.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.
-****
+|SC1|After a small tutorial, the user shoud be able to play the game.
+|SC2|When playing a game, the player whose turn is currently playing will answer autogenerated questions.
+|===