diff --git a/chapters/analyse/analyse.tex b/chapters/analyse/analyse.tex
index 21300c7..3cfc222 100644
--- a/chapters/analyse/analyse.tex
+++ b/chapters/analyse/analyse.tex
@@ -42,15 +42,75 @@ Wenn man nun die allgemeinen und spezifischen Anforderungen zusammenfasst, erhä
 
 \begin{itemize}
     \item Änderbarkeit / Skalierbarkeit
-    \item Testbarkeit / Wartbarkeit
+    \item Testbarkeit
     \item Effizienz
-    \item Komplexität
+    \item Komplexität / Wartbarkeit
     \item Verständlichkeit
     \item Dokumentierung
     \item Strukturbestimmung
 \end{itemize}
 
-% Lesbarkeit
+\section{Bewertungskriterien}
+
+Da nun die Anforderungen an Zustandsverwaltungssysteme feststehen, können jetzt Kriterien für die Bewertung der Systeme beziehungsweise der Umsetzung mit diesen Systemen definiert werden. Ziel dabei ist es, möglichst aussagekräftige, objektive Bewertungskriterien zu definieren. Die Kriterien sollen auf die jeweiligen Anforderungen einzahlen.
+
+\subsection{Änderbarkeit/Skalierbarkeit}
+
+Um zu untersuchen, ob ein Zustandsverwaltungssystem skalierbar oder nicht aufwendig änderbar ist, muss untersucht werden, wie dieses mit einer wachsenden Größe des Zustands umgeht. Dabei ist ein entscheidendes Kriterium, wie effektiv sich diverse Zustände sich untereinander verknüpfen lassen. Es ist nämlich damit zu rechnen, dass bei einer größer werdenden Anwendung auch die Koppelung zwischen den einzelnen Zuständen zunimmt. 
+
+Für dieses Bewertungskriterium wird eine qualitative Bewertungsskala verwendet, welche die Änderbarkeit/Skalierbarkeit mit den Werten \textquote{nicht erfüllt}, \textquote{teilweise erfüllt} und \textquote{vollständig erfüllt} bewertet.
+
+\subsection{Testbarkeit}
+
+Für die Testbarkeit sind diverse Blickpunkte von Relevanz. Zuerst sollte geprüft werden, inwiefern sich die mit dem Zustandsverwaltungssystem abgebildete Geschäftslogik testen lässt. Hier kann beispielsweise geprüft werden, ob es ohne Veränderung am Ausgangsquelltext möglich ist, einzelne Funktionen zu testen, die den Zustand verändern. Grundlage dafür sollten automatisierte Unit-Tests sein.
+
+Ein anderer Blickpunkt ist die Testbarkeit von Widgets, die auf geteilte Zustände zugreifen. Hier sollte zum einen geprüft werden, ob sich die Widgets vom Zustandsverwaltungssystem entkoppeln lassen und so eigenständig getestet werden können, und zum anderen sollte geprüft werden, ob die Zustände zum Test von Widgets einfach durch Platzhalter (engl. mocks) ausgetauscht werden können.
+
+Ausgehend von der Prüfung dieser Eigenschaften, wird eine Bewertung von einer Skala von 0/3 bis 3/3 vorgenommen, wobei die Ziffer die Anzahl der erfüllten Prüfungen darstellt.
+
+\subsection{Effizienz}
+
+Erfolgt das neu-bauen von Widgets nur, wenn dies wirklich notwendig ist
+
+\subsection{Komplexität / Wartbarkeit}
+
+Kombination mit quantitativer Bewertung
+https://dartcodemetrics.dev/docs/metrics/maintainability-index
+
+\subsection{Verständlichkeit / Lesbarkeit}
+
+begründete qualitative Bewertung
+
+\subsection{Dokumentierung}
+
+Gibt es eine Dokumentation? Sind die Grundkonzepte dokumentiert? Gibt es umfangreiche Beispiele?
+
+\subsection{Strukturbestimmung}
+
+Qualitative Bewertung; Inwiefern macht das System Vorgaben an die Struktur der Anwendung? Werden diese forciert?
+
+% Änderbarkeit/Skalierbarkeit:
+% - Wie gut lassen sich diverse Stores verknüpfen?
+% - Wie geht das System mit wachsender Größe des Zustands um?
+
+% Testbarkeit / Wartbarkeit
+% - Lässt sich die Geschäftslogik einfach automatisiert testen?
+% - Lassen sich Widgets, die auf den State zugreifen decoupled testen? (mocking z.B.)
+% -> Qualitative Bewertung jeweils
+
+% Effizienz
+% -
+
+% Komplexität / Wartbarkeit
+
+
+% Verständlichkeit / Lesbarkeit
+% - 
+
+% Dokumentierung
+% - 
+
+% Strukturbestimmung
 
 
 % https://learning.oreilly.com/library/view/fundamentals-of-software/9781492043447/ch04.xhtml#idm46005305800936
@@ -61,4 +121,5 @@ Wenn man nun die allgemeinen und spezifischen Anforderungen zusammenfasst, erhä
 % Klare Strukturvorgaben
 % Kommunikation zwischen States
 % Dokumentation
-% Performance -> Neubau nur bei related Changes
\ No newline at end of file
+% Performance -> Neubau nur bei related Changes
+% Bedienbarkeit
\ No newline at end of file