diff --git a/Anforderungen.md b/Anforderungen.md
new file mode 100644
index 0000000..e021875
--- /dev/null
+++ b/Anforderungen.md
@@ -0,0 +1,70 @@
+# Überlegungen
+
+* Typische Operationen für Vermittler auf der Wolke der Geschäftsobjekte einer Versicherung sind: Neuanlage, Update und Lesen.
+  Löschen kommt schon eher selten vor. Im Folgenden geht es um Neuanlage und um Update bzw. Änderung von Geschäftsobjekten.
+* Die Frage ist dabei, wie viel Wissen und Logik auf Clientseite vorausgesetzt werden soll, bzw. wie viel von Serverseite
+  unterstützt werden kann. 
+* Bei der OMDS Antragsstrecke setzen wir bisher stark darauf, dass der Client in der Lage ist, einen gültigen Antrag zu
+  erstellen. Dafür muss er das Metamodell kennen und bei sich abbilden. Heute erfolgt das über Programmierung z.B. auf
+  Basis einer Produkt- und Schnittstellendokumentation.
+* Bei Update könnte man auch diesen Ansatz nutzen und vom Client verlangen, dass er das Metamodell kennt und die Instanz
+  in neuer Form gültig übermittelt. 
+* Für viele Änderungen wirkt dies aber übertrieben anspruchsvoll für den Client. Wenn die Zahlungsfrequenz eines Vertrags
+  geändert werden soll, so genügt es die Polizzennummer und die neue Zahlungsfrequenz zu übermitteln. Die Kombination aus
+  Verfahren und reduziertem Objektmodell für das Verfahren erscheint zweckmäßiger.
+* Theoretisch ließen sich nicht nur Änderungen auf diese Weise abbilden, sondern auch Neuanlagen, wenn sie sich in 
+  Verfahrensschritte zerlegen lassen. Allerdings ist die Frage, wie sinnvoll das ist, da Clients oft Produkte  
+  vergleichen müssen und dabei eine sukzessive Anlage nicht in Betracht kommt. 
+* Metamodell und Instanzen können für unterschiedlichste Zwecke erstellt werden. Theoretisch ist es auch möglich,
+  sehr statische Modelle auf diese Weise zur Laufzeit zu übermitteln. Dies ist aber nicht sinnvoll. Für Zwecke, wo
+  das Modell auf absehbare Zeit konstant ist, ist es sinnvoll, das Modell traditionell statisch zu definieren.
+  Dies schließt gemeinsame, service-übergreifende Elementdefinitionen nicht aus. Beispiele hierfür sind Abfrage von
+  Dokumenten, Maklerpost, Ereignissen. 
+* Metamodelle zur Laufzeit machen Sinn für - komplizierte, zur Laufzeit veränderliche Requests. Zur Laufzeit veränderlich
+  ist insbesondere das Produktwissen, welches für Anträge, Konvertierungen und Vertragsänderungen erforderlich ist. 
+
+
+# Anforderungen
+
+## Basis
+* Es gibt _Verfahren_, diese legen fest, welche Services aufrufbar sind und welche Daten erwartet werden.
+* Ein Auskunftsservice soll das Metamodell für den eigentlichen Request zurückgeben.
+* Es soll einen Service zur probeweisen Ausführung der Modellinstanz geben (Validierung, Berechnung am Server) und 
+  einen Service zur eigentlichen Durchführung.
+* Es gibt Use-Cases, wo man vollständige Modelle übermitteln möchte, z.B. um ein neues Geschäftsobjekt anzulegen 
+  oder zu erzeugen. Ein Beispiel wäre einen Versicherungsantrag zu übermitteln. In diesem Beispiel wird das
+  Geschäftsobjekt komplett neu erzeugt.
+* Es gibt Use-Cases, wo man existierende Geschäftsobjekte referenziert und durch die Übermittlung eines kleinen 
+  Änderungsobjekts oder Teilmodells modifiziert. Aber auch für kleinere Änderungsobjekt kann die Technik angewendet werden,
+  dass es einen Auskunftsservice und Services für die Validierung und Durchführung der Instanz gibt.
+* Versionierung: Es gibt verschiedene Versionen eines Metamodells.
+
+## Versicherungsprodukte
+### Antragsverfahren
+* Das Antragsverfahren hat eine a-priori Produktauskunft, welche das Produktwissen übermittelt.
+* Es gibt spezielle Objekte für
+  * Produktbaum, bestehend aus
+    * Deckungsbaum
+      * (Produkt, Ereignis, Leistung wie bei VP/MS ?)
+      * Versicherungssummen
+      * Selbstbehalten
+      * Deckungsvarianten
+    * Versicherte Interessen (ein Objektmodell)
+  * Umschläge für Berechnung, Offerterstellung, Antrag
+    * Personendaten
+    * Sicherstellungen (Vinkulierungen...)
+    * Zahlungsinformationen
+    * Vertragsrollen
+    * Bezugsrechte
+  
+### Konvertierungsverfahren
+* Scope: Für einen bestehenden Vertrag bzw. mehrere bestehende Verträge werden die Änderungsmöglichkeiten bezüglich 
+  der Deckung angezeigt.
+* Proposal: Es wird ein Vorschlag, für eine der gewünschten Deckung entsprechenden Folgevertrag erstellt.
+* Es wird ein Antragsverfahren durchgeführt, um die Konvertierung auf den neuen Vertrag durchzuführen.
+
+### Vertragsänderungsverfahren
+* Behandelt Teilmodelle bezogen auf existierende Geschäftsobjekte (insbesondere Verträge)
+* Kennt zwei Profile:
+  * Profil 1: stateless. Services Check und Execute
+  * Profil 2: stateful. Services Create und Submit
\ No newline at end of file