Spezifikationstechniken und -werkzeuge
In dieser Lerneinheit befasst du dich mit Structured Analysis/Design und Data Flow Diagrams als zentrale Techniken zur Systemmodellierung. Du lernst die methodische Zerlegung komplexer Systeme in überschaubare Komponenten und deren Darstellung durch standardisierte Diagramme. Diese Werkzeuge und Techniken helfen dir bei der systematischen Analyse von Geschäftsprozessen und der Entwicklung passgenauer Softwarelösungen im Projektalltag.
Einführung
Ein Kunde möchte eine individuelle Software für sein Unternehmen. Du beginnst mit Gesprächen, sammelst Anforderungen und verstehst die Geschäftsprozesse. Doch wie stellst du sicher, dass alle Beteiligten dasselbe System vor Augen haben?
Ohne klare, visuelle Darstellung von Datenflüssen und Anforderungen entstehen Missverständnisse. Das Projekt droht zu scheitern, bevor die Entwicklung beginnt.
Spezifikationstechniken wie Data Flow Diagrams und Requirements Management Tools lösen dieses Problem. Sie schaffen eine gemeinsame Sprache zwischen Kunde, Entwicklung und allen Stakeholdern.
In dieser Lerneinheit lernst du, wie du mit DFDs Datenflüsse visualisierst, Anforderungen systematisch verwaltest und so die Grundlage für erfolgreiche kundenspezifische Softwareprojekte legst.
Lernziele
Nach dieser Lerneinheit kannst du:
- Data Flow Diagrams (DFDs) erstellen und hierarchisch verfeinern
- Die korrekte DFD-Notation anwenden
- Requirements Management Tools gezielt einsetzen
- Traceability mit Requirements Traceability Matrix (RTM) sicherstellen
- Entscheiden, wann welche Spezifikationstechnik geeignet ist
Überleitung
Um kundenspezifische Software erfolgreich zu entwickeln, brauchst du Techniken zur Visualisierung von Datenflüssen und zur systematischen Anforderungsverwaltung.
Wir beginnen mit Data Flow Diagrams, einer bewährten Technik zur Darstellung von Informationsflüssen in Systemen.
Überblick: Spezifikationstechniken
Bei kundenspezifischer Softwareentwicklung gibt es verschiedene Techniken zur Spezifikation:
Data Flow Diagrams (DFD): Visualisierung von Datenflüssen in Systemen. Besonders geeignet für High-Level-Übersichten und Kommunikation mit Stakeholdern ohne IT-Hintergrund.
UML (Unified Modeling Language): Standardisierte Modellierungssprache für objektorientierte Softwareentwicklung. Detaillierte Darstellung von Klassen, Verhalten und Interaktionen.
SysML (Systems Modeling Language): Erweiterung von UML für Systems Engineering. Geeignet für Hardware-Software-Integration und physische Systeme.
Hinweis: UML und SysML lernst du ausführlich im eigenen Modul. Hier konzentrieren wir uns auf DFDs und Requirements Management, die für kundenspezifische Projekte besonders kritisch sind.
DFD: Was sind Data Flow Diagrams?
Data Flow Diagrams (DFD) helfen dir, die Bewegung von Daten durch ein System zu visualisieren. Sie zeigen, wo Daten herkommen, wie sie verarbeitet werden und wohin sie gehen.
DFDs sind besonders wertvoll in den frühen Phasen der Systemanalyse. Sie schaffen eine gemeinsame Sprache zwischen Kunde, Entwicklung und allen Beteiligten.
DFDs bestehen aus vier Hauptkomponenten:
- Prozesse: Transformieren oder manipulieren Daten
- Datenflüsse: Zeigen die Bewegung von Daten (Pfeile)
- Datenspeicher: Orte, an denen Daten gespeichert werden
- Externe Entitäten: Systemelemente außerhalb des Systems, die Daten produzieren oder verbrauchen
Wir schauen uns im nächsten Block die korrekte Notation dieser Komponenten an.
DFD: Korrekte Notation (Zwei Standards)
Es gibt zwei etablierte DFD-Notationen. Beide sind Standard, die Wahl hängt vom Projektkontext ab:
| Komponente | Yourdon/Coad | Gane/Sarson |
|---|---|---|
| Prozesse | Kreise | Abgerundete Rechtecke |
| Externe Entitäten | Rechtecke | Rechtecke |
| Datenspeicher | Offene Rechtecke (ein Ende offen) | Zwei parallele Linien |
| Datenflüsse | Pfeile mit Beschriftung | Pfeile mit Beschriftung |
Wichtig: Prozesse werden NICHT als einfache Rechtecke dargestellt. Externe Entitäten haben KEINE abgerundeten Ecken.
Beide Notationen sind in der Praxis anerkannt. Wähle eine und bleibe konsistent im gesamten Projekt.
DFD: Hierarchische Ebenen (Level 0, 1, 2+)
DFDs werden hierarchisch verfeinert. Das ist ein fundamentales Konzept für die Top-Down-Analyse komplexer Systeme:
Level 0 (Context Diagram):
- Zeigt das Gesamtsystem als einen einzigen Prozess
- Identifiziert alle externen Entitäten und deren Datenflüsse
- Gibt die höchste Übersicht
Level 1:
- Zerlegt den Hauptprozess in Hauptprozesse
- Zeigt die wichtigsten Datenflüsse zwischen diesen Prozessen
- Detaillierter als Level 0, aber noch übersichtlich
Level 2+:
- Verfeinert einzelne Prozesse aus Level 1 weiter in Subprozesse
- Kann beliebig tief gehen, je nach Komplexität
- Jedes Level zeigt mehr Details
Regel: Beginne mit Level 0 für die Übersicht. Verfeinere dann Schritt für Schritt, wo Details benötigt werden.
DFD: Erstellung Schritt für Schritt
So erstellst du ein DFD systematisch:
Schritt 1: Externe Entitäten identifizieren
Was sind die Quellen und Ziele der Daten? Wer oder was interagiert mit dem System?
Schritt 2: Hauptprozesse ermitteln
Welche Hauptaktivitäten müssen mit den Daten durchgeführt werden?
Schritt 3: Datenflüsse definieren
Wie bewegen sich Daten zwischen Prozessen und externen Entitäten? Benenne die Datenflüsse beschreibend.
Schritt 4: Datenspeicher bestimmen
Wo müssen Daten im Prozess gespeichert werden? Welche Daten werden persistent gehalten?
Schritt 5: Verfeinerung
Beginne mit Level 0 (Context Diagram) und verfeinere schrittweise zu Level 1, Level 2+ wo Details benötigt werden.
Best Practice: Vermeide Überkomplexität. Ein DFD soll verständlich bleiben.
DFD: Praxisbeispiel Online-Buchhandel
Szenario: Ein Online-Buchhandel soll Bücher verkaufen. Kunden können Bücher suchen, bestellen und bezahlen.
Level 0 (Context Diagram):
Level 1 (Hauptprozesse):
Hinweis: Die Mermaid-Darstellung ist vereinfacht. In professionellen Tools würdest du die standardisierte Notation verwenden.
Wann welche Technik? Entscheidungshilfe
Bei der Wahl der Spezifikationstechnik kommt es auf den Kontext an:
| Technik | Wann einsetzen? | Typische Projekte |
|---|---|---|
| DFD | Datenfluss im Vordergrund, High-Level-Übersicht, Stakeholder ohne IT-Hintergrund | Geschäftsprozessanalyse, Legacy-System-Migration, Anforderungsanalyse |
| UML | Objektorientiertes Design, detaillierte Software-Architektur, Code-Generierung | Web-Apps, Mobile Apps, Backend-Systeme |
| SysML | Hardware-Software-Integration, physische Systeme, Systems Engineering | Embedded Systems, IoT, Automotive, Robotik |
Für kundenspezifische Software: DFD ist oft der beste Einstieg, um Geschäftsprozesse mit dem Kunden zu diskutieren. UML kommt später für das technische Design.
UML und SysML behandelst du ausführlich im eigenen Modul. Hier fokussieren wir auf DFDs und Requirements Management.
Requirements Management: Warum wichtig?
Bei kundenspezifischer Software sind Anforderungen das Fundament. Ohne systematisches Requirements Management drohen:
Fehlende Anforderungen: Wichtige Funktionen werden übersehen und erst spät entdeckt.
Inkonsistente Anforderungen: Verschiedene Stakeholder verstehen unterschiedliche Dinge.
Unkontrollierte Änderungen: Anforderungen ändern sich, aber niemand dokumentiert es.
Fehlende Nachverfolgbarkeit: Nicht nachvollziehbar, welche Tests welche Anforderungen prüfen.
In kundenspezifischen Projekten ist Requirements Management besonders kritisch, weil der Kunde oft selbst noch nicht genau weiß, was er will.
Requirements Management Tools (RM-Tools) helfen dir, Anforderungen systematisch zu erfassen, zu verwalten und zu verfolgen.
RM-Tools: Kernfunktionen (Teil 1)
Requirements Management Tools bieten diese Kernfunktionen:
Anforderungserfassung
- Unterstützung verschiedener Formate (Text, Diagramme, Tabellen)
- Strukturierung in funktionale und nicht-funktionale Anforderungen
- Templates für konsistente Erfassung
Versionierung und Änderungsmanagement
- Protokollierung aller Änderungen an Anforderungen
- Versionierung ermöglicht Rückverfolgung
- Nachvollziehbarkeit wer, wann, was geändert hat
RM-Tools: Kernfunktionen (Teil 2)
Traceability-Mapping
- Verknüpfung zwischen Anforderungen und Testfällen
- Verknüpfung zwischen Anforderungen und Code
- Verknüpfung zwischen Anforderungen und Design-Dokumenten
- Bidirektionale Traceability für Impact-Analysen
Berichterstellung und Analyse
- Status-Reports über Anforderungen (offen, in Arbeit, abgeschlossen)
- Fortschritts-Tracking der Implementierung
- Coverage-Analysen für Tests (welche Anforderungen sind getestet?)
- Compliance-Reports für Audits
Traceability in der Praxis: Requirements Traceability Matrix (RTM)
Traceability bedeutet, dass du den Lebenszyklus einer Anforderung von der Entstehung bis zur Implementierung und Tests nachvollziehen kannst.
Das zentrale Werkzeug ist die Requirements Traceability Matrix (RTM). Sie verknüpft Anforderungen mit anderen Artefakten:
- Anforderung
REQ-101: Login-System - Verknüpft mit Testfall
TC-201: Prüft Login-Funktionalität - Verknüpft mit Code
CODE-301: Implementierung des Logins - Verknüpft mit Design
DES-401: Architektur-Entscheidungen
Bei Änderungen an REQ-101 siehst du sofort, welche Tests, Codebereiche und Dokumente betroffen sind.
RTM: Best Practices
Diese Best Practices machen deine Requirements Traceability Matrix wirkungsvoll:
1. Starte mit klaren, messbaren Anforderungen
Jede Anforderung braucht eine eindeutige ID und muss präzise formuliert sein. Vage Anforderungen führen zu unklarer Traceability.
2. Nutze automatisierte Tools
Manuelle RTMs sind fehleranfällig und aufwändig zu pflegen. Tools wie JIRA, Azure DevOps oder spezialisierte RM-Tools unterstützen automatisches Traceability-Mapping.
3. Beziehe das gesamte Team ein
Traceability ist keine Aufgabe für Einzelne. Alle im Team müssen Verknüpfungen aktiv pflegen.
4. Führe regelmäßige Reviews durch
Die RTM ist ein living document. Plane regelmäßige Reviews ein, um Aktualität zu gewährleisten.
5. Dokumentiere Änderungen und Rationale
Warum wurde eine Anforderung geändert? Diese Information ist wertvoll für Audits und Retrospektiven.
Für Agile-Projekte: Integration mit deinem Sprint-Planning-Tool ist entscheidend für aktuelles Traceability.
Tool-Auswahl: Kriterien für RM-Tools
Bei der Auswahl eines Requirements Management Tools solltest du diese Kriterien berücksichtigen:
1. Skalierbarkeit
Das Tool sollte mit der Größe und Komplexität deines Projekts wachsen können. Ein Tool für 5 Personen funktioniert nicht für 50.
2. Integration
Nahtlose Integration mit Versionskontrollsystemen (Git), Test-Management-Tools und Issue-Trackern (JIRA) ist essentiell.
3. Benutzerfreundlichkeit
Eine intuitive Benutzeroberfläche reduziert die Einarbeitungszeit für dein Team. Komplexe Tools werden nicht akzeptiert.
4. Anpassbarkeit
Das Tool sollte sich an deine spezifischen Prozesse anpassen lassen (Custom Fields, Workflows, Templates).
Beliebte RM-Tools:
- JIRA (mit Plugins) - Weit verbreitet, agil-freundlich
- Azure DevOps - Microsoft-Ökosystem, CI/CD-Integration
- IBM DOORS - Enterprise-Lösung, regulierte Industrien
- Confluence - Leichtgewichtig, für kleinere Projekte
Tipp: Starte mit einem leichtgewichtigen Tool und wechsle bei Bedarf zu spezialisierteren Lösungen.
Zusammenfassung und Ausblick
Zusammenfassung
Spezifikationstechniken sind unverzichtbar für kundenspezifische Softwareentwicklung. Diese Lesson behandelte:
Data Flow Diagrams (DFD): Visualisierung von Datenflüssen mit standardisierter Notation (Yourdon/Coad oder Gane/Sarson). Die hierarchische Verfeinerung (Level 0, Level 1, Level 2+) ermöglicht Top-Down-Analyse komplexer Systeme.
Requirements Management: Systematische Erfassung, Verwaltung und Verfolgung von Anforderungen. RM-Tools bieten Versionierung, Traceability-Mapping und Berichterstellung.
Requirements Traceability Matrix (RTM): Verknüpft Anforderungen mit Testfällen, Code und Design-Dokumenten. Best Practices: automatisierte Tools nutzen, Team einbeziehen, regelmäßige Reviews durchführen.
Entscheidungshilfe: DFD für High-Level-Übersichten und Kommunikation mit Stakeholdern ohne IT-Hintergrund. UML für detailliertes objektorientiertes Design (eigenes Modul). SysML für Hardware-Software-Integration (eigenes Modul).
Ausblick
In der nächsten Lerneinheit beschäftigst du dich mit Qualitätssicherung und Validierung. Du lernst, wie du die spezifizierten Anforderungen systematisch prüfst und sicherstellst, dass die entwickelte Software die Kundenerwartungen erfüllt.