Doc 10 of documentation updated.

docs/10_quality_scenarios.adoc

@@ -1,63 +1,43 @@
 [[section-quality-scenarios]]
 == Quality Requirements
 
-
-[role="arc42help"]
-****
-
-.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.
-
-.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.
-****
-
 === Quality Tree
+image:Quality-tree.png["Quality tree diagram"]
+
 
-[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:
+=== Quality Scenarios
 
-* tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root
-* a mind map with quality categories as main branches
+[options="header"]
+|===
+| Quality goal | Scenario | Approach | Priority
 
-In any case the tree should include links to the scenarios of the following section.
-****
+| Accessibility
+| Users want to be able to traverse the application easily.
+| -
+| High
 
-=== Quality Scenarios
 
-[role="arc42help"]
-****
-.Contents
-Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.
+| Privacy
+| We need to protect the user's data. The application will only take essential data from users and it will be done in a decentralized way.
+| User's data will be retrieved from the user's pod. 
+| High
 
-These scenarios describe what should happen when a stimulus arrives at the system.
 
-For architects, two kinds of scenarios are important:
+| Security
+| Our application will be developed in such a way that the user's data will be stored in a secure place. If the user doesn't trust our site, they won't use it.
+| User data wont be accessible for any third parties and it will be stored in a secure system.
+| High
 
-* 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.
 
-.Motivation
-Scenarios make quality requirements concrete and allow to
-more easily measure or decide whether they are fulfilled.
+| Usability
+| The user wants the application to be as intuitive as possible, and the maps to be easy to understand and navigate through.
+| -
+| High
 
-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.
-****
+| Decentralization 
+| Decentralization of the log in process (serverless). 
+| It is achieved by means of calling the Pod provider and delegating the process to it.
+| High