Lösungsdesign

Dokument (SDD)

Projektname: [Vollständiger Name]

Projektnummer: [8-stelliger Code]
Ausführung: XX
Autor: [Ihr Name]
Position: [Dein Standpunkt]
Telefon: [Deine Telefonnummer]

1. Email: [Ihre E-Mail-Adresse]

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

Dokumentenverlauf

Ausführung Verantwortlich Datum Anmerkungen

1.0

*** Ende der

Revisionslist
e ***
Tabelle 1Dokumentverlauf

1. Kontakt für Anfragen und vorgeschlagene Änderungen

Wenn Sie Fragen zu diesem Dokument haben, wenden Sie sich an:
Name: Marc Dimmick
Bezeichnung: Systemgeschäftsanalyse
Telefon: (08) 6216 6335
Email: Marc.dimmick@dcp.wa.gov.au

Wenn Sie einen Verbesserungsvorschlag für dieses Dokument haben, füllen Sie bitte eine Kopie
davon aus und leiten Sie sie weiter Vorschläge für Verbesserungen Zu Dokumentation .

2. Aufzeichnung der Probleme

Die Problemliste spiegelt Überarbeitungen dieser Vorlage wider. Diese Informationen sollten aus
Ihrem Dokument gelöscht werden.
Ver Datum Art der Änderung
1.0 12. April 2006 Erstes Dokument
1.1 8. Juni Layout und Stylesheet aktualisieren
1.2 23. Nov. 06 Aktualisieren Sie Layout und Stil
1.3 19. Juli 2007 Unternehmenslogo aktualisieren

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

2. Richtlinien zum Ausfüllen dieses Dokuments:
Berater sind verpflichtet, Anforderungen in Absprache mit den Projektbeteiligten zu sammeln und zu
dokumentieren. Die Gesamtverantwortung hierfür liegt beim Projektleiter.
Diese Vorlage stellt sicher, dass die wesentlichen Details zu diesen Anforderungen eine klare und
eindeutige Darstellung der funktionalen und nichtfunktionalen Anforderungen dokumentieren.
Dieses Dokument wird in den Bereichen Entwicklung, Test, Qualitätssicherung, Projektmanagement und
damit verbundene Projektfunktionen verwendet.
Elemente in eckigen Klammern sind durch entsprechende Inhalte zu ersetzen. Beispielsweise sollte
[Projektmanager] durch den Namen des Projektmanagers ersetzt werden.
Diese Vorlage bietet eine empfohlene Struktur und ein empfohlenes Format sowie Beispielinhalte,
erläuternde Anmerkungen und Fragen, um den Autor anzuleiten und anzuregen.
Bitte löschen Sie diese Hinweise und andere Richtlinien aus dem eigentlichen Dokument. Sie dienen
ausschließlich Ihrer Information. Diese sind in dieser Farbe und Schriftart angegeben.
Wenn ein Abschnitt/Unterabschnitt nicht anwendbar ist, löschen Sie ihn nicht. Erwähnen Sie es
stattdessen als solches und erklären Sie, warum es nicht anwendbar ist. Denken Sie daran, eine
Rechtschreibprüfung durchzuführen.
Es ist vorzuziehen, das Datum mit dem Monatsnamen anstelle der Monatsnummer zu verwenden, um
Verwechslungen zu vermeiden (verwenden Sie den 2. Januar 2006 oder den 2. Januar 2006 anstelle von
1.2.2006 oder 2.1.2006).
Dieses Dokument enthält vorformatierte Stile für Überschriften. Um eine Zeile in eine Überschrift
umzuwandeln, wählen Sie die Zeile aus und wählen Sie „BS-Überschrift 1“, „BS-Überschrift 2“ usw. aus
der Dropdown-Liste „Stil“ neben dem Dropdown-Feld „Schriftart“ aus

Inhaltsverzeichnis
1 Dokumentenverlauf 2
1.1 Kontakt für Anfragen und vorgeschlagene Änderungen 2
1.2 Aufzeichnung der Probleme 2

2 Richtlinien zum Ausfüllen dieses Dokuments: 3

3 [Kunde / Projekt] 6
3.1 Zweck 6
3.2 Projektübersicht und Status 6
3.3 Projektziele/Problemstellung 6

4 Projektumfang 7
4.1.1 Einschlüsse 7
4.1.2 Ausschlüsse 7
4.1.3 Phasenweise, falls erforderlich 7
4.2 Wichtige Stakeholder 7
4.3 Projektbezogene und andere Referenzdokumente 7

5 Architekturüberblick 8
5.1 Zielschnittstellen 8

6 Architektonische Entscheidungen 9
6.1 Wichtige architektonische Probleme 9
6.2 Architektonische Risiken und Annahmen 9

7 Lösungsbeschreibung 10

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 7.1 Komponentenmodell 10
7.2 Wiederverwendung von Komponenten 10
7.3 Informationsmodell 10
7.3.1 Informations- und Datenmerkmale 11
7.4 Infrastrukturmodell 11
7.5 Integration und Netzwerkdesign 11
7.6 Sicherheitsarchitektur 11
7.6.1 Anwendungssicherheit 11
7.6.2 Betriebssicherheit 12

8 System Anforderungen 13
8.1 [System-/Komponentenname] 13
8.1.1 Relevantes Flussdiagramm 13
8.1.2 Anforderungen an die Lösungsarchitektur 13
8.1.3 Design Beschreibung 13

9 Implementierung und Migration 14

9.1 Architekturmigrationsplan 14
9.1.1 Migrationsplan 14
9.1.2 Abhängigkeiten auflisten 14
9.2 GLOSSAR 14

10 funktionale Anforderungen 15
10.1 Anforderung – [Funktion 1 Titel] 15
10.2 Ausgänge 15
10.3 Bildschirme 15
10.4 Berichte 15
10.5 Anforderung – [Funktion 2 Titel] 15
10.6 Ausgänge 16
10.7 Bildschirme 16
10.8 Berichte 16

11 Eingaben 17
11.1 Daten 17
11.2 Anwendungen 17
11.3 Dritte Seite 17

12 Design 18
12.1 Farben 18
12.2 Schauen und fühlen 18
12.3 Probleme mit der Benutzerfreundlichkeit 18
12.4 Publikum 18

13 Leistung 19
14 Datenmigration und -konvertierung 20
15 ANHÄNGE 21
15.1 Definitionen 21
15.2 Anhänge 21

16 Abmeldeliste 22
Tische

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

Tabelle 1Dokumentverlauf 2
Tabelle 2 – Projektziele/Problemstellungen 6
Tabelle 3 – Hauptakteure 7
Tabelle 4 – Projektbezogene und andere Referenzdokumente 7
Tabelle 5 – Architekturentscheidungen 9
Tabelle 6 – Wichtige architektonische Probleme 9
Tabelle 7 – Architekturrisiken und Annahmen 9
Tabelle 8 – Relevante Flussdiagramme 13
Tabelle 9 – Glossar 14
Tabelle 10 – Funktionale Anforderungen 15
Tabelle 11 – Funktionale Anforderungen 16
Tabelle 12 – Definitionen 21
Tabelle 13 – Anhänge 21

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

3. [Kunde / Projekt]
1. Zweck
Der Hauptzweck dieses Dokuments besteht darin, die wesentlichen Elemente der Gesamtlösung zu
kommunizieren, damit die geschäftlichen Auswirkungen bewertet und verstanden werden können und
damit die Designaktivitäten in Build/Acquire fortgesetzt werden können, wenn die Initiative genehmigt
wird.
Fügen Sie eine Beschreibung der technischen Entwicklung und der Ergebnisse ein, die bei erfolgreicher
Implementierung der in diesem Dokument beschriebenen Lösung erreicht werden.

2. Projektübersicht und Status

Geben Sie den Hintergrund und Kontext der Initiative sowie ihren aktuellen Status aus Projektperspektive
an.
Der aktuelle Status sollte auch alle wesentlichen Risiken oder Probleme umfassen, die für den Entwurf
relevant sein könnten.

3. Projektziele/Problemstellung
Geben Sie einen kurzen Überblick über die Ziele des Projekts, z. B. einen Überblick über ein neues
Produkt oder eine neue Funktion oder ein neues Supportsystem usw. Fügen Sie eine kurze
Zusammenfassung des Geschäftsbedarfs und der Treiber hinter der Initiative sowie der Unternehmens-,
Design- und Standardbeschränkungen bei. Dazu gehören beispielsweise prognostiziertes Wachstum,
Spitzenverkehrs-/Transaktionsvolumina und Referenzmarktprognosen usw. Einzelheiten entnehmen Sie
bitte der BRD.
Alternativ lässt sich das Ziel am besten als Initiative zur Lösung eines Problems beschreiben. Die
folgende Tabelle enthält ein vorgeschlagenes Format für die Problemstellung.
Das Problem von
Beeinflusst
Die Auswirkungen davon
sind
Eine erfolgreiche Lösung
wäre

4. Tabelle 2 – Projektziele/Problemstellungen

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 Projektumfang
Fügen Sie eine Erklärung ein, die den Projektumfang beschreibt.

1. Einschlüsse

2. Ausschlüsse

3. Phasenweise, falls erforderlich

2. Wichtige Stakeholder

Bereich / Position Name / Rolle Kontakt Nummer

Geschäftsinteressente
n

Technologie-
Stakeholder

Operations-
Stakeholder

Tabelle 3 – Hauptakteure

3. Projektbezogene und andere Referenzdokumente

Listen Sie alle Referenzen auf, die bei der Erstellung dieses Dokuments verwendet wurden.
Dokument Identifikation Titel / Beschreibung / Ort
Projektbezogene
Dokumente

Andere
Referenzdokumente

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

5. Tabelle 4 – Projektbezogene und andere Referenzdokumente

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

Architekturüberblick
Fügen Sie ein Architekturdiagramm der Systeme, Schnittstellen und Informationsflüsse der geplanten
Lösung ein.
Nummerieren Sie jede Schnittstelle unten als Referenz.

1. Zielschnittstellen

Schlüssel Schnittstelle Zweck/Beschreibung

Z.B. 1 Z.B. Solomon, Startrack Beispielsweise stellt die vorhandene Schnittstelle
Manifestinformationen zum Tagesende für Versandzwecke
bereit.

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

6. Architektonische Entscheidungen
Fügen Sie hier eine Zusammenfassung wichtiger Entscheidungen ein, die bei der Ableitung der Lösung
getroffen wurden.
Architekturentscheidungsidenti
Beschreibung
fikator
Z.B.
Wie erfolgt die Rechnungsstellung für zurückgegebene Bestellungen?
AD-01
Die Rechnungsstellung erfolgt durch einen täglichen Batch-Prozess
zwischen…

AD-02
…
Tabelle 5 – Architekturentscheidungen

1. Wichtige architektonische Probleme

Problem-ID Betroffen sind die Beschreibung Eigentümer Status

Systeme
ISS – 01 Identifizieren Sie die In diesem Abschnitt zu Eigentümer des Geschlossen/
betroffenen Systeme dokumentierendes Problem, z Problems, der es bis Offen
anhand des zur Lösung verwalten
Systemnamens, wie 01.01.2003: Es ist nicht klar, wird
in diesem Dokument ob XXX die Fehlermeldung
beschrieben axe generiert.
ISS – 02
….
Tabelle 6 – Wichtige architektonische Probleme

2. Architektonische Risiken und Annahmen

Die wichtigsten architektonischen Risiken und Annahmen sind wie folgt:
Hinweis: Risiken müssen durch das Projektrisikomanagement gemanagt werden
Betroffen sind die
Risikoübernahme Beschreibung
Systeme

Identifizieren Sie die

betroffenen Systeme
anhand des
Z.B. Es wird davon ausgegangen, dass die Migration zu
Systemnamens, wie in
AR – 01 Microsoft .Net Framework für dieses Portal keine Auswirkungen auf
diesem Dokument
die Funktionalität der Systeme hat, die derzeit mit diesem Portal
beschrieben
verbunden sind.
Z.B.
Prognoseportal

7. Tabelle 7 – Architekturrisiken und Annahmen

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

Lösungsbeschreibung
In diesem Abschnitt wird die High-Level-Lösung im Hinblick auf die Systeme/Komponenten und die
Interaktion jeder Komponente mit anderen Systemen/Komponenten beschrieben.

1. Komponentenmodell
Beziehen und beschreiben Sie das Komponentenmodell des Entwurfs.
Eine Komponente ist jedes einsetzbare Element einer Architektur. Es wird durch sein Verhalten oder
seine Funktion charakterisiert, wenn es über eine externe Schnittstelle offengelegt oder ausgedrückt wird.
Komponenten können in andere Komponenten zerlegt oder aggregiert werden. Beispiele hierfür sind ein
Programm, ein Softwaremodul, ein System, ein Datenspeicher, ein Netzwerkelement usw. Jede
Komponente kann die von anderen Komponenten bereitgestellten Dienste nutzen und auch eigene
Dienste bereitstellen.
Das Komponentenmodell beschreibt, wie Komponentensätze an der Definition des Designs beteiligt sind.
Es umfasst statische und dynamische Beziehungen und Interaktionen zwischen Komponenten. Die
Modelldokumentation umfasst typischerweise eine Reihe von Diagrammen, die die verschiedenen Arten
von Beziehungen ausdrücken – zum Beispiel Abhängigkeitsbeziehungen, Nutzungsbeziehungen,
Interaktions- und Zeitbeziehungen usw. Bei einer Partitionierung der Lösung müssen die einzelnen
Teilmengen des Komponentenmodells klar definiert und die Zuordnung zu den jeweiligen Anbietern
ermittelt werden. Jede Teilmenge ist anschließend Gegenstand einer Designkomponentenspezifikation
und wird in der Regel vom/von den Kunden definiert, auf deren Grundlage er eine Kosten- und
Zeitschätzung mit einem vom Projektmanager festgelegten Konfidenzniveau vorlegt.
Es ist nützlich, die folgenden Schnittstellenkategorien zu kennen:
● Benutzerschnittstellen – jene Interaktionen, die vorhanden sind, um die menschliche Interaktion
mit dem System zu ermöglichen;
● Anwendungsdienstschnittstellen – jene Interaktionen, die es ermöglichen, dass die von einem
System bereitgestellten Anwendungsdienste automatisiert von einem anderen System genutzt
werden;
● Betriebsschnittstellen – jene Interaktionen, die zur Verwaltung und zum Betrieb der
Systemumgebung verwendet werden, einschließlich Überwachung, Wiederherstellung und
Ausnahmemanagement;
● Schnittstellen für Systemsynchronisierungsdienste – jene Interaktionen, die zur
synchronisierten Aufrechterhaltung der dauerhaften Referenz- und Zustandsinformationsintegrität
über mehrere Systeme hinweg verwendet werden.

Bei der Spezifikation von Schnittstellen und Diensten ist es wichtig zu verstehen, dass es zwei
wichtige Fälle gibt:
● Funktionale Dienste – in diesem Fall handelt es sich um Dienste, die überwiegend zustandslos
sind, und es besteht eine Eins-zu-eins-Entsprechung zwischen Schnittstelle und Dienst. Jeder
dieser Dienste kann unabhängig beschrieben werden.
● Prozessdienste – Hierbei handelt es sich um Dienste, die einen Prozess implementieren, und
deren Verhalten von vorherigen Aktivitäten abhängt. Typischerweise kann ein einzelner Prozess
viele Schnittstellenaufrufe beinhalten – Aufrufe werden manchmal als „Trigger“ bezeichnet und in
diesem Fall ist es notwendig, nicht nur jede der Schnittstellen zu beschreiben, sondern auch das
Zustandsverhalten des Prozesses selbst.
2. Wiederverwendung von Komponenten
Es ist wichtig, Dienste, Komponenten, Code, Dokumentation usw. zu identifizieren, die für die
Wiederverwendung im Unternehmen in Frage kommen, und die Basisdokumentation so zu entwerfen und
zu pflegen, dass eine Wiederverwendung mit minimalen Kosten möglich ist. In diesem Abschnitt wird
beschrieben, was bei der Wiederverwendung erreicht wurde und welche Probleme auftreten.

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 3. Informationsmodell
Beziehen Sie das für die Lösung relevante Informationsmodell ein (oder verweisen Sie darauf) und
beschreiben Sie es.
Das Informationsmodell umfasst eine strukturierte Sicht auf die Geschäfts-, System- und
Zustandsinformationen, die Gegenstand des Entwurfs sind. Das Informationsmodell muss sich nicht mit
Objekten oder Daten befassen, die extern nicht offengelegt werden (oder wahrscheinlich offengelegt
werden).
Bei datenmanagementintensiven Lösungen wie den Databases of Record macht dieser Teil der Lösung
einen erheblichen Teil der Gesamtlösung aus und kann tatsächlich in einer separaten Dokumentation
enthalten sein, auf die explizit durch Titel, Datum und Version verwiesen wird.
Während die von jeder Schnittstelle übergebenen und zurückgegebenen Informationen im
Komponentenmodell beschrieben werden, ist es in den meisten Fällen auch angebracht, das konsolidierte
Informationsmodell zu beschreiben.
Bei einer Partitionierung der Lösung müssen die einzelnen Teilmengen des Informationsmodells klar
definiert und die Zuordnung zu den jeweiligen Anbietern ermittelt werden.

1. Informations- und Datenmerkmale

Definieren Sie unabhängig von der Komplexität oder Größe des Informationsmodells die erforderlichen
nichtfunktionalen Eigenschaften der Modellelemente (oder Elementgruppen). Zu den zu
berücksichtigenden Merkmalen können unter anderem folgende gehören:
● Persistenz – geben Sie an, welche Elemente des Modells über eine Transaktion oder Sitzung
hinaus bestehen bleiben müssen, einschließlich der Bedingungen, unter denen die Persistenz
möglicherweise nicht mehr erforderlich ist, und des Zeitraums der Persistenz;
● Größe – geben Sie die voraussichtliche Anzahl der Instanzen jedes Elements an;
● Sicherheit und Datenschutz – geben Sie an, welche Elemente besonders sensibler Natur sind
und besondere Zugriffs- oder Offenlegungsmaßnahmen oder Datenschutzbeschränkungen
erfordern;
● Rechtliche und behördliche Vorschriften – geben Sie an, welche Elemente eine bestimmte
Datenaufbewahrung, Archivierung, Protokollierung von Audit-Trails oder andere Maßnahmen
erfordern, um rechtliche oder behördliche Verpflichtungen zu erfüllen. Alle rechtlichen und
behördlichen Anforderungen in Bezug auf Informationen oder Daten sollten als solche
gekennzeichnet sein, auch wenn sie unter anderen Themenüberschriften aufgeführt sind (z. B.
sollten von einer staatlichen Regulierungsbehörde auferlegte Datenschutzanforderungen als
rechtliche und behördliche Anforderungen gekennzeichnet sein, auch wenn sie unter Sicherheit
und Datenschutz aufgeführt sind). );
● Integrität – gibt alle spezifischen Integritäts- oder Gültigkeitsanforderungen an, die mit den
Informationselementen verbunden sind.
4. Infrastrukturmodell
Für IT-Systeme ist möglicherweise ein Infrastrukturmodell erforderlich, in dem die zugrunde liegenden
Server, Speichermedien usw. definiert werden. (In IBM-Begriffen: das Betriebsmodell)

5. Integration und Netzwerkdesign

Gilt für einen IT-Systementwurf, bei dem das zugrunde liegende Kommunikationsnetzwerk definiert
werden muss. Definieren Sie die konzeptionellen Aspekte von Netzwerk- oder Integrationsmechanismen,
die zum Verbinden von Komponenten erforderlich sind. Das Komponentenmodell befasst sich mit
Schnittstellenmechanismen, hauptsächlich aus Sicht der Anwendungs- oder Serviceebene. Hier sind
zusätzliche Informationen zu den Kommunikationsmechanismen, Protokollen oder Netzwerkmodellen
enthalten. Typischerweise werden Einzelheiten dieses Unterabschnitts im Rahmen der
Integrationsspezifikation weiterentwickelt.

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 Es sollten sowohl funktionale als auch nichtfunktionale Merkmale der Integration und des
Netzwerkverhaltens einbezogen werden.

6. Sicherheitsarchitektur
Der Zweck dieses Abschnitts besteht darin, die Sicherheitskontrollen zu beschreiben, die in die Lösung
integriert werden.

1. Anwendungssicherheit
Beschreiben Sie Folgendes:
● Authentifizierung. Wie authentifizieren sich Benutzer beim System? Beschreiben Sie detaillierte
Passwortregeln. Beschreiben Sie, wo die externe Authentifizierungsinfrastruktur verwendet wird,
z. B. Konto-01.
● Genehmigung. Beschreiben Sie die Benutzerkategorien und die ihnen zur Verfügung stehenden
Funktionen. Beziehen Sie alle Benutzer, Kunden, Mitarbeiter und Betriebsmitarbeiter ein, die die
Plattform unterstützen
● Audit/Protokollierung. Beschreiben Sie, was protokolliert wird, und beschreiben Sie alle
verwendeten externen Prüf- oder Protokollierungsplattformen
2. Betriebssicherheit
Beschreiben Sie detailliert alle sicherheitsrelevanten Prozesse und wie das System diese Prozesse
unterstützt:
● Wie registrieren oder registrieren sich Benutzer für den Dienst? Wie werden
Authentifizierungsdaten ausgestellt und zurückgesetzt?
● Wie werden die Zugriffsrechte der Benutzer festgelegt und umgesetzt? Werden
Genehmigungsprozesse für den Benutzerzugriff entwickelt, wenn ja, von wem?
● Wie werden Benutzerzugriffsrechte widerrufen?
● Prozesse zur Verwaltung kryptografischer Schlüssel
● Prozess zur Reaktion auf Sicherheitsvorfälle
● Schwachstellenmanagement – einschließlich der Anwendung von Patches und
Schwachstellenbewertungen
8. Spezielle Prozesse zur Klassifizierung und Verarbeitung von Informationen

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 System Anforderungen
1. [System-/Komponentenname]
Füllen Sie einen pro System/Komponente aus

1. Relevantes Flussdiagramm

Flussdiagramm-ID Name des Flussdiagramms

FCXX

Tabelle 8 – Relevante Flussdiagramme

2. Anforderungen an die Lösungsarchitektur

Der Zweck dieses Abschnitts besteht darin, die spezifischen, wohlgeformten Anforderungen für betroffene
Systeme zu definieren und sie so zu unterteilen, dass die Entwurfsdefinition erleichtert wird.
Bei der Erstellung architektonischer Anforderungen sollte jede in diesem Abschnitt definierte überprüfbare
Anforderung in einem separaten Absatz enthalten sein.
Die Quelle aller Rohanforderungen sollte in der Anforderungsrückverfolgbarkeitsmatrix erfasst werden,
zusammen mit dem Querverweis auf die gekennzeichneten Anforderungen in diesem Abschnitt.
Dieser Abschnitt enthält die spezifischen Anforderungen an die Lösungsarchitektur für
[System-/Komponentenname].

3. Design Beschreibung
9. In diesem Abschnitt wird die Entwurfsantwort des Kunden in Bezug auf das spezifische System/die
spezifische Komponente, die geliefert werden soll, detailliert beschrieben. Wenn in diesem Abschnitt auf
ein Spezifikationsdokument verwiesen wurde, stellen Sie sicher, dass das entsprechende Dokument im
Anhang dieses Dokuments angehängt wurde.

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 Implementierung und Migration
Gehen Sie auf den Gesamtansatz zur Umsetzung ein. Dazu gehören eine Strategie für die Migration
bestehender Prozesse und Systeme sowie Überlegungen zur Datenmigration. In der Regel werden in
diesem Abschnitt Implementierungsphasen definiert, die die Auswirkungen auf den Geschäftsbetrieb
minimieren und gleichzeitig in jeder Phase einen zusätzlichen Geschäftswert bieten.

1. Architekturmigrationsplan
1. Migrationsplan
Fügen Sie einen Architekturmigrationsplan ein. Dieser Plan sollte sich mit dem Gesamtansatz für die
Implementierung der neuen Architektur befassen und die in Abschnitt 6 „Implementierung und Migration“
beschriebenen Details ergänzen. Beispiele für die Arten von Informationen, die hier gefunden werden
können, sind:
● die Abfolge der Migration
● neue Infrastrukturanforderungen
● Liste aller potenziellen Stilllegungen von Technologie oder Infrastruktur, die durch diesen Plan
verursacht werden
● geschäftliche Auswirkungen
● Planen Sie die Datenmigration
2. Abhängigkeiten auflisten
Dieser Abschnitt sollte alle Abhängigkeiten des Plans vom obigen Abschnitt enthalten. Alle identifizierten
Probleme und Risiken sollten über die Probleme und Risikomanagementprozesse des [Unternehmens]
gemanagt werden.
Alle Annahmen dieses Plans und Abhängigkeiten sollten im Abschnitt „Architekturrisiken und Annahmen“
aufgeführt sein.

2. GLOSSAR

Begriff/Akronym Definition / Erweiterung / Beschreibung

Tabellendaten Tabellendaten

10. Tabelle 9 – Glossar

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 funktionale Anforderungen
1. Anforderung – [Funktion 1 Titel]

Titel

BR-FID 99 F Priorität 1 Phase 9

R
I
D

Fluss Schri
der tte
Ereignis der
se Anfor
deru
ng.
Besc
hreib
en
Sie
sie
als
eine
Liste
mit
Aufz
ählun
gszei
chen/
Num
mern
Ziel das
Erge
bnis
diese
r
Reih
e von
Aktio
nen,
z. B.
Benu
tzer
ist
bei
Lösu
ng
ange
meld
et
Unterfun FID
ktionen,
Titel
Annahm Alle
en Anna
hme
n, die

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 bei
der
Ausf
ühru
ng
der
Funk
tion
eine
Rolle
spiel
en, z.
B.:
Der
Benu
tzer
ist
berei
ts
regist
riert
oder
ange
meld
et.
Die
Lösu
ng
wird
die
Rech
te
jedes
Einz
elnen
aner
kenn
en.
Wen
n der
Benu
tzer
nicht
identi
fiziert
werd
en
kann,
bena
chric
htigt
die
Lösu
ng
den
Admi
nistra
tor.
Die
Lösu
ng
speic
hert

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 die
Sitzu
ngsei
nstell
unge
n
auto
matis
ch.
Vorauss Was
etzungen sind
die
Vora
usset
zung
en
für
die
Ausf
ühru
ng
diese
s
Fluss
diagr
amm
s?
Liste
der
Bedi
ngun
gen,
die
vorlie
gen
sollte
n,
bevo
r der
Proz
ess
ausg
eführ
t
werd
en
kann,
z. B.:
Der
Benu
tzer
hat
eine
laufe
nde
Drifts
itzun
g
und
hat
auf
die

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 Lösu
ng
zuge
griffe
n.
Der
Benu
tzer
hat
Zugri
ffsrec
hte.
Der
Benu
tzer
wurd
e zur
Benu
tzerli
ste
hinzu
gefü
gt
usw.
Postbedi In
ngungen welc
hem
Zust
and
sich
die
Lösu
ng
befin
det,
nach
dem
der
Proz
ess
ausg
eführ
t
wurd
e, z.
B.:
Der
Benu
tzer
hat
entsp
rech
end
seine
n
Bere
chtig
unge
n
Zugri
ff auf
die

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 Anw
endu
ng
Benutzer Verw
oberfläc eis
he auf
den
UI-
Proto
typ
oder
spezi
fisch
e
bilds
chirm
- und
UI-
bezo
gene
Hinw
eise
Geschäft Welc
sregeln he
Bedi
ngun
gen
gelte
n für
die
Funk
tion?
Alle
dom
änen
spezi
fisch
en
Kenn
tniss
e
oder
Algor
ithme
n
oder
Validi
erun
gsre
geln
(rele
vant
für
diese
n
Anw
endu
ngsfa
ll), z.
Nach
drei
erfol

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 glose
n
Anm
eldev
ersuc
hen
sperr
t die
Lösu
ng
den
Benu
tzer
aus
und
bena
chric
htigt
den
Syst
ema
dmini
strat
or.
Verwand Dies
te ist
Flussdia optio
gramme nal.
oder Alle
Prozesse Fluss
diagr
amm
e
auflis
ten,
diese
s
Fluss
diagr
amm
oder
verw
andt
e
Fluss
diagr
amm
e
einbe
ziehe
n,
erwei
tern
oder
spezi
alisie
ren
Problem Erläu
e terun
gen
vom
Benu

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 tzer
erfor
derlic
h.
Alle
Frag
en
zum
Fluss
diagr
amm
Verweise Anfor
deru
ngsn
umm
er,
Doku
ment
e,
Pers
onen
Anmerku Alle
ngen Notiz
en,
die
zur
Verd
eutlic
hung
des
Proz
esse
s und
der
verfü
gbar
en
Infor
matio
nen
oder
Optio
nen
zur
Erled
igung
der
Aufg
abe
beitr
agen
könn
en.
Beis
piel:
Benu
tzern
ame
und
Pass
wort
sind

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 die
gleic
hen
wie
für
ihr
Mitar
beite
rkont
o.
Tabelle 10 – Funktionale Anforderungen

Das obige Raster ist für jede identifizierte Funktion zu verwenden.

Kopieren Sie bei Bedarf das Flussdiagramm von BRD in diesen Abschnitt des Dokuments.

2. Ausgänge
3. Bildschirme
4. Berichte
5. Anforderung – [Funktion 2 Titel]

Titel

BR-FID 99 F Priorität 1 Phase 9

R
I
D

Fluss Schri
der tte
Ereignis der
se Anfor
deru
ng.
Besc
hreib
en
Sie
sie
als
eine
Liste
mit
Aufz
ählun
gszei
chen/
Num
mern
Ziel das
Erge
bnis
diese
r
Reih
e von
Aktio

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 nen,
z. B.
Benu
tzer
ist
bei
Lösu
ng
ange
meld
et
Unterfun FID
ktionen,
Titel
Annahm Alle
en Anna
hme
n, die
bei
der
Ausf
ühru
ng
der
Funk
tion
eine
Rolle
spiel
en, z.
B.:
Der
Benu
tzer
ist
berei
ts
regist
riert
oder
ange
meld
et.
Die
Lösu
ng
wird
die
Rech
te
jedes
Einz
elnen
aner
kenn
en.
Wen
n der
Benu
tzer
nicht
identi

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 fiziert
werd
en
kann,
bena
chric
htigt
die
Lösu
ng
den
Admi
nistra
tor.
Die
Lösu
ng
speic
hert
die
Sitzu
ngsei
nstell
unge
n
auto
matis
ch.
Vorauss Was
etzungen sind
die
Anfor
deru
ngen
für
die
Ausf
ühru
ng
diese
s
Fluss
diagr
amm
s?
Liste
der
Bedi
ngun
gen,
die
vorlie
gen
sollte
n,
bevo
r der
Proz
ess
ausg
eführ
t

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 werd
en
kann,
z. B.:
Der
Benu
tzer
hat
eine
laufe
nde
Drifts
itzun
g
und
hat
auf
die
Lösu
ng
zuge
griffe
n.
Der
Benu
tzer
hat
Zugri
ffsrec
hte.
Der
Benu
tzer
wurd
e zur
Benu
tzerli
ste
hinzu
gefü
gt
usw.
Postbedi In
ngungen welc
hem
Zust
and
sich
die
Lösu
ng
befin
det,
nach
dem
der
Proz
ess
ausg
eführ
t
wurd

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 e, z.
B.:
Der
Benu
tzer
hat
entsp
rech
end
seine
n
Bere
chtig
unge
n
Zugri
ff auf
die
Anw
endu
ng
Benutzer Verw
oberfläc eis
he auf
den
UI-
Proto
typ
oder
spezi
fisch
e
bilds
chirm
- und
UI-
bezo
gene
Hinw
eise
Geschäft Welc
sregeln he
Bedi
ngun
gen
gelte
n für
die
Funk
tion?
Alle
dom
änen
spezi
fisch
en
Kenn
tniss
e
oder
Algor
ithme

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 n
oder
Validi
erun
gsre
geln
(rele
vant
für
diese
n
Anw
endu
ngsfa
ll), z.
Nach
drei
erfol
glose
n
Anm
eldev
ersuc
hen
sperr
t die
Lösu
ng
den
Benu
tzer
aus
und
bena
chric
htigt
den
Syst
ema
dmini
strat
or.
Verwand Dies
te ist
Flussdia optio
gramme nal.
oder Alle
Prozesse Fluss
diagr
amm
e
auflis
ten,
diese
s
Fluss
diagr
amm
oder
verw
andt
e

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 Fluss
diagr
amm
e
einbe
ziehe
n,
erwei
tern
oder
spezi
alisie
ren
Problem Erläu
e terun
gen
vom
Benu
tzer
erfor
derlic
h.
Alle
Frag
en
zum
Fluss
diagr
amm
Verweise Anfor
deru
ngsn
umm
er,
Doku
ment
e,
Pers
onen
Anmerku Alle
ngen Notiz
en,
die
zur
Verd
eutlic
hung
des
Proz
esse
s und
der
verfü
gbar
en
Infor
matio
nen
oder
Optio
nen
zur

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 Erled
igung
der
Aufg
abe
beitr
agen
könn
en.
Beis
piel:
Benu
tzern
ame
und
Pass
wort
sind
die
gleic
hen
wie
für
ihr
Mitar
beite
rkont
o.
Tabelle 11 – Funktionale Anforderungen

Das obige Raster ist für jede identifizierte Funktion zu verwenden.

Kopieren Sie bei Bedarf das Flussdiagramm von BRD in diesen Abschnitt des Dokuments.

6. Ausgänge
7. Bildschirme
11. Berichte

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 Eingaben
1. Daten
2. Anwendungen
12. Dritte Seite

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 Design
1. Farben
2. Schauen und fühlen
3. Probleme mit der Benutzerfreundlichkeit
13. Publikum

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

 Leistung
14. Beschreiben Sie die Leistungsfähigkeiten und Einschränkungen der Lösung.

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

Datenmigration und -konvertierung
15. Wenn eine Anwendung geändert werden soll, geben Sie hier an, ob Datenkonvertierungen für
vorhandene Datensätze erforderlich sind. Wenn eine neue Anwendung eine bestehende Anwendung
ersetzt, geben Sie hier an, welche Datenmigration/-konvertierung erforderlich ist

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

ANHÄNGE
Listen Sie die Dokumente auf, die für den Leser des Architectural Design Document nützlich wären

1. Definitionen
In diesem Dokument wird auf die folgenden Wörter, Akronyme und Abkürzungen verwiesen.
Begriff Definition

Tabelle 12 – Definitionen

2. Anhänge

Dokumentnummer Titel

16. Tabelle 13 – Anhänge

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]

Abmeldeliste

Projektleitung _____________________ ____/____/______

[Positionstitel]

Berater _____________________ ____/____/______

[Positionstitel]

xxxxx _____________________ ____/____/______

[Positionstitel]

XXXXX _____________________ ____/____/______

(Entwicklungsmanager)

[Unternehmen] Seite 22 von 22 SDD – [Kunde / Projekt]