![\"\"](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab3860058dc8.png\")
<\/p>\n
Dieser Leitfaden erl\u00e4utert die Kernideen hinter NotesKeep, die Dokumentationsprobleme, die es adressiert, und praktische Anwendungsm\u00f6glichkeiten f\u00fcr verschiedene Teams.<\/p>\n
Die Dokumentationsherausforderung<\/h2>\n
Moderne Software- und Systementwicklungsprojekte erzeugen Informationen in vielen Formaten:<\/p>\n
- \n
- \n
Anforderungsdokumente<\/p>\n<\/li>\n
- \n
Technische Spezifikationen<\/p>\n<\/li>\n
- \n
Architekturdiagramme<\/p>\n<\/li>\n
- \n
API-Definitionen<\/p>\n<\/li>\n
- \n
Datenbank-Skripte<\/p>\n<\/li>\n
- \n
Protokolle von Besprechungen<\/p>\n<\/li>\n
- \n
Produkt\u00fcbersichten<\/p>\n<\/li>\n
- \n
Testpl\u00e4ne<\/p>\n<\/li>\n
- \n
Whiteboard-Skizzen<\/p>\n<\/li>\n
- \n
E-Mails und Chat-Diskussionen<\/p>\n<\/li>\n
- \n
\u00c4nderungsantr\u00e4ge und Designentscheidungen<\/p>\n<\/li>\n<\/ul>\n
Diese Quellen werden oft voneinander getrennt. Ein Produktmanager kann eine Anforderung in einem Dokument aktualisieren, w\u00e4hrend ein Architekt ein Diagramm \u00e4ndert und ein Entwickler die \u00c4nderung \u00fcber eine Chat-Nachricht erh\u00e4lt. Wenn die Informationen nicht konsolidiert und chronologisch verfolgt werden, k\u00f6nnen verschiedene Teammitglieder mit widerspr\u00fcchlichen Versionen arbeiten.<\/p>\n
Drei wiederkehrende Probleme sind besonders sch\u00e4dlich.<\/p>\n
Anforderungsdrift<\/h3>\n
Anforderungen \u00e4ndern sich kontinuierlich. Eine statische Spezifikation kann das System zum Zeitpunkt seiner Erstellung korrekt beschreiben, aber nach mehreren Designbesprechungen oder Kundenanfragen veraltet sein.<\/p>\n
Zum Beispiel:<\/p>\n
- \n
- \n
Eine Produkt\u00fcbersicht verlangt, dass Benutzer Transaktionen manuell genehmigen.<\/p>\n<\/li>\n
- \n
Ein sp\u00e4teres Stakeholder-Meeting \u00e4ndert die Anforderung auf automatische Genehmigung unterhalb eines definierten Schwellenwerts.<\/p>\n<\/li>\n
- \n
Die aktualisierte Entscheidung wird in den Besprechungsprotokollen festgehalten, aber nicht in die Hauptspezifikation aufgenommen.<\/p>\n<\/li>\n
- \n
Entwickler setzen weiterhin die urspr\u00fcngliche Arbeitsablaufumsetzung fort.<\/p>\n<\/li>\n<\/ol>\n
Dies ist Anforderungsdrift: Das implementierte System weicht schrittweise von der aktuellen Gesch\u00e4ftsabsicht ab.<\/p>\n
Spezifikations-Silos<\/h3>\n
Wichtige Informationen k\u00f6nnen auf verschiedene Formate und Standorte verteilt sein. Ein Anforderungsdokument k\u00f6nnte in Word vorliegen, Interface-Details in einer Tabellenkalkulation, Datenbankdefinitionen in SQL und Architekturentscheidungen in einem Whiteboard-Bild.<\/p>\n
Wenn diese Quellen nicht verbunden sind, verbringen Teams Zeit mit:<\/p>\n
- \n
- \n
Suche nach der neuesten Version<\/p>\n<\/li>\n
- \n
Manuelles Kopieren von Informationen<\/p>\n<\/li>\n
- \n
Neuzeichnen von Diagrammen<\/p>\n<\/li>\n
- \n
Vergleichen inkonsistenter Dokumente<\/p>\n<\/li>\n
- \n
Wiederholtes Erkl\u00e4ren des Kontexts f\u00fcr neue Teammitglieder<\/p>\n<\/li>\n<\/ul>\n
KI-Kontext und Genauigkeitsrisiken<\/h3>\n
Allgemeine KI-Tools k\u00f6nnen Antworten basierend auf allgemeinen Mustern statt auf der genehmigten Projektdokumentation erzeugen. Dies kann zu Vorschl\u00e4gen f\u00fchren, die technisch plausibel sind, aber mit dem tats\u00e4chlichen System unvereinbar sind.<\/p>\n
Ein KI-Assistent, der auf ausgew\u00e4hlte Projektnotizen oder Tags beschr\u00e4nkt ist, kann eine gezieltere Unterst\u00fctzung bieten. Anstatt aus nicht verwandten Informationen zu antworten, kann er innerhalb eines definierten Projektkontexts arbeiten.<\/p>\n
Was NotesKeep tut<\/h2>\n
NotesKeep wurde entwickelt, um Notizen, Quelldokumente, Anforderungen und visuelle Modelle in einem einzigen Dokumentationsworkflow zu verbinden. Sein zentrales Ziel ist es, rohes Projektmaterial in strukturiertes Wissen zu verwandeln, das Teams aktualisieren und wiederverwenden k\u00f6nnen.<\/p>\n
Der Workflow umfasst im Allgemeinen vier Phasen:<\/p>\n
- \n
- \n
Informationen importieren<\/strong>aus unterst\u00fctzten Dateien, Websites oder Bildern.<\/p>\n<\/li>\n
- \n
Inhalte in bearbeitbare Notizen umwandeln<\/strong>die organisiert und getaggt werden k\u00f6nnen.<\/p>\n<\/li>\n
- \n
Notizen mit Anforderungen und Designentscheidungen verkn\u00fcpfen<\/strong>im Laufe der Zeit.<\/p>\n<\/li>\n
- \n
Die strukturierten Informationen nutzen, um visuelle Modelle und Spezifikationen zu erstellen oder zu aktualisieren.<\/strong><\/p>\n<\/li>\n<\/ol>\n
Dieser Ansatz schafft eine Br\u00fccke zwischen unstrukturierten Informationen und formaler Systemtechnik.<\/p>\n
Schl\u00fcsselkonzepte<\/h2>\n
1. Lebende Spezifikationen<\/h3>\n
Eine lebende Spezifikation ist Dokumentation, die sich mit dem Projekt ver\u00e4ndert, anstatt nach ihrer Erstver\u00f6ffentlichung veraltet zu werden.<\/p>\n
Sie sollte bewahren:<\/p>\n
- \n
- \n
Die aktuelle Anforderung<\/p>\n<\/li>\n
- \n
Fr\u00fchere Versionen oder Entscheidungen<\/p>\n<\/li>\n
- \n
Der Grund f\u00fcr jede wesentliche \u00c4nderung<\/p>\n<\/li>\n
- \n
Die beteiligten Personen oder Teams<\/p>\n<\/li>\n
- \n
Zugeh\u00f6rige Diagramme und Implementierungsdetails<\/p>\n<\/li>\n
- \n
Offene Fragen und ungel\u00f6ste Konflikte<\/p>\n<\/li>\n<\/ul>\n
Beispielsweise k\u00f6nnte eine Spezifikation f\u00fcr ein Zahlungssystem Folgendes festhalten:<\/p>\n
- \n
- \n
Version 1 erforderte eine manuelle Pr\u00fcfung aller Transaktionen mit hohem Wert.<\/p>\n<\/li>\n
- \n
Version 2 f\u00fchrte eine automatische Genehmigung f\u00fcr vertrauensw\u00fcrdige Kunden ein.<\/p>\n<\/li>\n
- \n
Version 3 f\u00fcgte zus\u00e4tzliche Betrugspr\u00fcfungen nach einer Compliance-Pr\u00fcfung hinzu.<\/p>\n<\/li>\n<\/ul>\n
Dieser chronologische Kontext hilft Teams zu verstehen, nicht nur was das System tun sollte, sondern auch, warum es so funktioniert.<\/p>\n
2. Chronologische Notizen<\/h3>\n
Chronologische Notizen bieten einen Zeitstrahl des Projektverst\u00e4ndnisses. Sie k\u00f6nnen Entscheidungen, \u00c4nderungen, Diskussionen und Kl\u00e4rungen erfassen, sobald sie eintreten.<\/p>\n
Eine n\u00fctzliche chronologische Notiz k\u00f6nnte Folgendes enthalten:<\/p>\n
- \n
- \n
Datum der Entscheidung<\/p>\n<\/li>\n
- \n
Teilnehmer<\/p>\n<\/li>\n
- \n
Betroffene Anforderung<\/p>\n<\/li>\n
- \n
Bisheriges Verhalten<\/p>\n<\/li>\n
- \n
Neues Verhalten<\/p>\n<\/li>\n
- \n
Grund f\u00fcr die \u00c4nderung<\/p>\n<\/li>\n
- \n
Zugeh\u00f6rige Artefakte<\/p>\n<\/li>\n
- \n
Nachfolgende Aufgaben<\/p>\n<\/li>\n<\/ul>\n
Dies erleichtert die Aufl\u00f6sung von Konflikten zwischen \u00e4lteren Dokumenten und neueren Entscheidungen.<\/p>\n
3. Begrenzter KI-Kontext<\/h3>\n
Begrenzte KI bedeutet die Einschr\u00e4nkung eines KI-Assistenten auf ausgew\u00e4hlte Notizen, Projekte oder Tags.<\/p>\n
Beispielsweise k\u00f6nnte ein Team Tags wie folgende erstellen:<\/p>\n
- \n
- \n
billing-platform<\/code><\/p>\n<\/li>\n- \n
mobile-app<\/code><\/p>\n<\/li>\n- \n
security-requirements<\/code><\/p>\n<\/li>\n- \n
customer-onboarding<\/code><\/p>\n<\/li>\n- \n
release-2026-q3<\/code><\/p>\n<\/li>\n<\/ul>\nEin KI-Chatbot, der mit dem
billing-platform<\/code> Tag w\u00fcrde sich auf die Notizen und Dokumente konzentrieren, die mit diesem Projekt verbunden sind, und nicht auf nicht verwandtes organisatorisches Material.<\/p>\nDies kann Teams helfen:<\/p>\n
- \n
- \n
Relevante Anforderungen lokalisieren<\/p>\n<\/li>\n
- \n
Einen Projektbereich zusammenfassen<\/p>\n<\/li>\n
- \n
Widerspr\u00fcche identifizieren<\/p>\n<\/li>\n
- \n
Akzeptanzkriterien entwerfen<\/p>\n<\/li>\n
- \n
Architekturentscheidungen erl\u00e4utern<\/p>\n<\/li>\n
- \n
Diagramme aus genehmigten Informationen erstellen<\/p>\n<\/li>\n<\/ul>\n
4. Multi-Format-Informationsextraktion<\/h3>\n
Projektwissen wird selten in einem einzigen Format erstellt. NotesKeep soll mehrere g\u00e4ngige Formate in bearbeitbare Notizen umwandeln, darunter:<\/p>\n
- \n
- \n
Microsoft Word-Dokumente<\/p>\n<\/li>\n
- \n
PDF-Dateien<\/p>\n<\/li>\n
- \n
HTML-Seiten<\/p>\n<\/li>\n
- \n
Rich-Text-Format-Dateien<\/p>\n<\/li>\n
- \n
Markdown<\/p>\n<\/li>\n
- \n
Klartext<\/p>\n<\/li>\n
- \n
Excel-Tabellen<\/p>\n<\/li>\n
- \n
CSV-Dateien<\/p>\n<\/li>\n
- \n
PowerPoint-Pr\u00e4sentationen<\/p>\n<\/li>\n
- \n
PNG-, JPG- und SVG-Bilder<\/p>\n<\/li>\n<\/ul>\n
Die bereitgestellten Produktinformationen zeigen, dass PDF-Importe bis zu 10 Seiten enthalten k\u00f6nnen. Bild-Importe k\u00f6nnen besonders n\u00fctzlich sein, um Whiteboard-Skizzen, Workshop-Diagramme und fotografierte Designnotizen festzuhalten.<\/p>\n
5. Visuelles Systemengineering<\/h3>\n
Text allein reicht nicht immer aus, um ein System zu verstehen. Visuelle Modelle helfen Teams dabei, Struktur, Verhalten, Abh\u00e4ngigkeiten und Datenbeziehungen darzustellen.<\/p>\n
NotesKeep kann Workflows unterst\u00fctzen, die Folgendes beinhalten:<\/p>\n
- \n
- \n
UML-Diagramme<\/p>\n<\/li>\n
- \n
Entity-Relationship-Diagramme<\/p>\n<\/li>\n
- \n
Flussdiagramme<\/p>\n<\/li>\n
- \n
Systemarchitekturdiagramme<\/p>\n<\/li>\n
- \n
Datenbankmodelle<\/p>\n<\/li>\n
- \n
Story Maps<\/p>\n<\/li>\n
- \n
Server-Topologie-Diagramme<\/p>\n<\/li>\n<\/ul>\n
Es kann auch mit Diagrammformaten wie Mermaid, PlantUML und DBML arbeiten und erm\u00f6glicht es Teams, von konversationellen Beschreibungen zu bearbeitbaren technischen Modellen \u00fcberzugehen.<\/p>\n
6. Audit-Trails und architektonische Entscheidungen<\/h3>\n
Architecture Decision Records, allgemein als ADRs bezeichnet, dokumentieren wichtige technische Entscheidungen.<\/p>\n
Ein ADR dokumentiert typischerweise:<\/p>\n
- \n
- \n
Die Entscheidung<\/p>\n<\/li>\n
- \n
Der Kontext<\/p>\n<\/li>\n
- \n
Gepr\u00fcfte Alternativen<\/p>\n<\/li>\n
- \n
Der ausgew\u00e4hlte Ansatz<\/p>\n<\/li>\n
- \n
Die Konsequenzen<\/p>\n<\/li>\n
- \n
Datum und Status<\/p>\n<\/li>\n<\/ul>\n
Zum Beispiel:<\/p>\n
\n
Das Team w\u00e4hlte eine ereignisgesteuerte Integration anstelle direkter synchroner Aufrufe, da mehrere nachgelagerte Systeme w\u00e4hrend Spitzenlastzeiten m\u00f6glicherweise nicht verf\u00fcgbar sind. Der Kompromiss besteht in einer erh\u00f6hten operativen Komplexit\u00e4t und der Notwendigkeit zur Ereignis\u00fcberwachung.<\/p>\n<\/blockquote>\n
Die Pflege von ADRs zusammen mit Projektnotizen erleichtert das Verst\u00e4ndnis daf\u00fcr, warum ein System auf eine bestimmte Weise entworfen wurde.<\/p>\n
Ein praktischer NotesKeep-Arbeitsablauf<\/h2>\n
![\"Visual](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/visual-paradigm-noteskeep-main-screen.jpg\"\/)
<\/p>\nSchritt 1: Vorhandenes Projektmaterial sammeln<\/h3>\n
Beginnen Sie damit, die Dokumente zu sammeln, die den aktuellen Status des Projekts darstellen:<\/p>\n
- \n
- \n
Produktanforderungen<\/p>\n<\/li>\n
- \n
Technische Spezifikationen<\/p>\n<\/li>\n
- \n
Vorhandene Diagramme<\/p>\n<\/li>\n
- \n
Sitzungsniederschriften<\/p>\n<\/li>\n
- \n
Tabellenkalkulationen<\/p>\n<\/li>\n
- \n
API-Dokumentation<\/p>\n<\/li>\n
- \n
Datenbankdefinitionen<\/p>\n<\/li>\n
- \n
Testpl\u00e4ne<\/p>\n<\/li>\n
- \n
Compliance-Dokumente<\/p>\n<\/li>\n
- \n
Whiteboard-Bilder<\/p>\n<\/li>\n<\/ul>\n
Beschr\u00e4nken Sie die Sammlung nicht auf ausgearbeitete Dokumente. Informelle Notizen enthalten h\u00e4ufig die Erkl\u00e4rung f\u00fcr sp\u00e4tere \u00c4nderungen.<\/p>\n
Schritt 2: Inhalt importieren und konvertieren<\/h3>\n
Importieren Sie die relevanten Dateien in NotesKeep und konvertieren Sie sie in bearbeitbare Notizen. Dies schafft einen gemeinsamen Arbeitsbereich f\u00fcr Informationen, die zuvor in verschiedenen Formaten existierten.<\/p>\n
Zum Beispiel:<\/p>\n
- \n
- \n
Ein Word-Anforderungsdokument wird zu einer bearbeitbaren Projektnotiz.<\/p>\n<\/li>\n
- \n
Eine Excel-Funktionsmatrix wird zu strukturiertem Referenzmaterial.<\/p>\n<\/li>\n
- \n
Ein fotografiertes Whiteboard wird zur Quelle zur Extraktion von Designelementen.<\/p>\n<\/li>\n
- \n
Eine PDF-Compliance-Checkliste wird zu durchsuchbarer Projektdokumentation.<\/p>\n<\/li>\n<\/ul>\n
Schritt 3: Notizen mit Projekten und Tags organisieren<\/h3>\n
Erstellen Sie vor dem Hinzuf\u00fcgen gro\u00dfer Mengen an Inhalten ein logisches Organisationssystem.<\/p>\n
Ein Projekt kann in Tags wie folgende unterteilt werden:<\/p>\n
- \n
- \n
Gesch\u00e4ftsanforderungen<\/code><\/p>\n<\/li>\n- \n
Technische Architektur<\/code><\/p>\n<\/li>\n- \n
Datenbank<\/code><\/p>\n<\/li>\n- \n
API<\/code><\/p>\n<\/li>\n- \n
Sicherheit<\/code><\/p>\n<\/li>\n- \n
Testing<\/code><\/p>\n<\/li>\n- \n
Entscheidungen<\/code><\/p>\n<\/li>\n- \n
Release-Planung<\/code><\/p>\n<\/li>\n<\/ul>\nTags sollten das Thema, den Produktbereich oder den Zweck einer Notiz beschreiben. Eine konsistente Tagging-Praxis erleichtert es, KI-Abfragen auf den richtigen Kontext zu beschr\u00e4nken.<\/p>\n
Schritt 4: \u00c4nderungen chronologisch erfassen<\/h3>\n
Wenn sich eine Anforderung \u00e4ndert, erfassen Sie die \u00c4nderung als neue Notiz oder als Update, das mit dem relevanten Projektbereich verkn\u00fcpft ist.<\/p>\n
Ein n\u00fctzlicher \u00c4nderungs-Eintrag k\u00f6nnte wie folgt aussehen:<\/p>\n
\u00c4nderung: Kundenidentit\u00e4tspr\u00fcfung\n\nBisherige Anforderung:\nAlle neuen Kunden m\u00fcssen eine manuelle Identit\u00e4tspr\u00fcfung durchf\u00fchren.\n\nAktualisierte Anforderung:\nKunden mit niedrigem Risiko k\u00f6nnen eine automatisierte Pr\u00fcfung durchf\u00fchren. Kunden mit hohem Risiko m\u00fcssen weiterhin einer manuellen Pr\u00fcfung unterzogen werden.\n\nGrund:\nOnboarding-Verz\u00f6gerungen reduzieren, w\u00e4hrend eine verst\u00e4rkte Pr\u00fcfung f\u00fcr F\u00e4lle mit h\u00f6herem Risiko beibehalten wird.\n\nBetroffene Bereiche:\n- Kunden-Onboarding-Prozess\n- Risikobewertungsdienst\n- Compliance-Berichterstattung\n- QA-Testf\u00e4lle\n<\/code><\/pre>\nDieses Format hilft Entwicklern, Testern, Pr\u00fcfern und Produktmanagern, die Auswirkungen der \u00c4nderung zu verstehen.<\/p>\n
Schritt 5: Stellen Sie KI-Fragen innerhalb eines definierten Kontexts<\/h3>\n
Stellen Sie statt breiter Fragen zur gesamten Organisation die KI-Assistenz auf die relevanten Projekt- oder Notiz-Tags ein.<\/p>\n
Beispiele hierf\u00fcr sind:<\/p>\n
- \n
- \n
\u201eFassen Sie die aktuellen Onboarding-Anforderungen zusammen.\u201c<\/p>\n<\/li>\n
- \n
\u201eWelche Anforderungen haben sich im letzten Release-Zyklus ge\u00e4ndert?\u201c<\/p>\n<\/li>\n
- \n
\u201eIdentifizieren Sie Konflikte zwischen den API-Notizen und dem Datenbankmodell.\u201c<\/p>\n<\/li>\n
- \n
\u201eListen Sie alle Sicherheitsanforderungen im Zusammenhang mit der Kundenauthentifizierung auf.\u201c<\/p>\n<\/li>\n
- \n
\u201eErstellen Sie Akzeptanzkriterien f\u00fcr den aktualisierten Zahlungsprozess.\u201c<\/p>\n<\/li>\n
- \n
\u201eErkl\u00e4ren Sie den Grund f\u00fcr die Wahl der asynchronen Integration.\u201c<\/p>\n<\/li>\n<\/ul>\n
Die Qualit\u00e4t der Antwort h\u00e4ngt stark von der Klarheit und Vollst\u00e4ndigkeit des Ausgangsmaterials ab.<\/p>\n
Schritt 6: Visuelle Modelle erstellen oder aktualisieren<\/h3>\n
Sobald die Anforderungen strukturiert sind, verwenden Sie sie, um visuelle Darstellungen zu erstellen.<\/p>\n
Zum Beispiel eine Beschreibung wie:<\/p>\n
\n
Ein Kunde reicht einen Antrag ein. Der Onboarding-Service validiert die Daten, sendet sie an die Risikoverarbeitungsengine und genehmigt den Kunden entweder automatisch oder leitet den Antrag an einen Compliance-Beauftragten weiter.<\/p>\n<\/blockquote>\n
K\u00f6nnte als Flussdiagramm mit folgenden Schritten dargestellt werden:<\/p>\n
- \n
- \n
Antragseinreichung<\/p>\n<\/li>\n
- \n
Datenvalidierung<\/p>\n<\/li>\n
- \n
Risikobewertung<\/p>\n<\/li>\n
- \n
Automatische Genehmigung<\/p>\n<\/li>\n
- \n
Manuelle Compliance-Pr\u00fcfung<\/p>\n<\/li>\n
- \n
Benutzerbenachrichtigung<\/p>\n<\/li>\n<\/ol>\n
Das daraus resultierende Modell kann anschlie\u00dfend von Architekten und Stakeholdern \u00fcberpr\u00fcft und bearbeitet werden.<\/p>\n
Schritt 7: Modelle wieder mit Anforderungen verkn\u00fcpfen<\/h3>\n
Ein Diagramm ist am wertvollsten, wenn seine Elemente auf Anforderungen und Entscheidungen zur\u00fcckverfolgt werden k\u00f6nnen.<\/p>\n
Zum Beispiel:<\/p>\n
- \n
- \n
Ein Prozess \u201eRisikobewertung\u201c verkn\u00fcpft sich mit der Anforderung zur Betrugserkennung.<\/p>\n<\/li>\n
- \n
Ein Schritt \u201eCompliance-Pr\u00fcfung\u201c verkn\u00fcpft sich mit einer ADR.<\/p>\n<\/li>\n
- \n
Eine Datenbankentit\u00e4t verkn\u00fcpft sich mit Regeln zur Datenspeicherung.<\/p>\n<\/li>\n
- \n
Eine API-Interaktion verkn\u00fcpft sich mit einer Integrationspezifikation.<\/p>\n<\/li>\n<\/ul>\n
Dies schafft Nachverfolgbarkeit zwischen Gesch\u00e4ftszielen, Systemverhalten und technischer Umsetzung.<\/p>\n
Beispiele nach Teamrolle<\/h2>\n
Produktmanager<\/h3>\n
Produktmanager k\u00f6nnen NotesKeep nutzen, um hochlevelige Ideen in detaillierte Spezifikationen zu verwandeln.<\/p>\n
Eine Produktkurzfassung k\u00f6nnte lauten:<\/p>\n
\n
Kunden sollten in der Lage sein, ein Abonnement zu pausieren und sp\u00e4ter fortzusetzen, ohne ihre Kontoverlauf zu verlieren.<\/p>\n<\/blockquote>\n
Dies kann erweitert werden zu:<\/p>\n
- \n
- \n
Funktionale Anforderungen<\/p>\n<\/li>\n
- \n
Benutzerstories<\/p>\n<\/li>\n
- \n
Akzeptanzkriterien<\/p>\n<\/li>\n
- \n
Randf\u00e4lle<\/p>\n<\/li>\n
- \n
Gherkin-Szenarien<\/p>\n<\/li>\n
- \n
Zugeh\u00f6rige Abrechnungsregeln<\/p>\n<\/li>\n
- \n
Anforderungen an Kundenbenachrichtigungen<\/p>\n<\/li>\n<\/ul>\n
Beispiel f\u00fcr Akzeptanzkriterien:<\/p>\n
Gegeben sei ein aktives Abonnement\nWenn der Kunde \u201eAbonnement pausieren\u201c ausw\u00e4hlt\nDann \u00e4ndert sich der Abonnementstatus in \u201ePausiert\"\nUnd der Kunde beh\u00e4lt den Zugriff auf historische Rechnungen\nUnd das System zeigt das geplante Wiederaufnahmedatum an<\/code><\/pre>\nSoftware-Architekten<\/h3>\n
Architekten k\u00f6nnen Projektnotizen verwenden, um Systemkomponenten zu vergleichen und visuelle Modelle zu erstellen.<\/p>\n
Angenommen, das Projekt umfasst:<\/p>\n
- \n
- \n
Eine mobile Anwendung<\/p>\n<\/li>\n
- \n
Ein API-Gateway<\/p>\n<\/li>\n
- \n
Ein Kontodienst<\/p>\n<\/li>\n
- \n
Ein Zahlungsdienst<\/p>\n<\/li>\n
- \n
Ein Benachrichtigungsdienst<\/p>\n<\/li>\n
- \n
Eine Berichtsdatenbank<\/p>\n<\/li>\n<\/ul>\n
NotesKeep kann helfen, Beziehungen zu organisieren und diese durch Architekturdiagramme oder Formate wie Mermaid, PlantUML und DBML auszudr\u00fccken.<\/p>\n
Ein vereinfachtes Mermaid-Flussdiagramm k\u00f6nnte so aussehen:<\/p>\n
\n\nMermaid<\/span>
\n
\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n