Requirements Engineering

Wo Empathie auf analytische Präzision trifft

Im Zentrum der Softwareentwicklung stehen für mich immer die Menschen, die das System nutzen.

Klare Ziele der Auftraggeber sind wichtig – aber das Verständnis der Bedürfnisse aller Stakeholder macht den Unterschied.

Analytische Fähigkeiten und zwischenmenschliche Stärken gehören zusammen: die richtigen Fragen stellen, aktiv zuhören, Gedanken teilen – und bei Bedarf auch konstruktiv diskutieren.

Zertifiziert nach

IREB/CPRE & PRINCE2 Agile

Meine Philosophie: Empathie als Fundament

Empathie ist nicht nur ein „Nice-to-have" – sie hilft, echte Bedürfnisse sichtbar zu machen und bildet die Grundlage für umsetzbare Anforderungen.

Das ist seit Langem ein persönlicher Antrieb für mich.

Tatsächlich war es genau diese Leidenschaft für Requirements Engineering, die mich letztlich in die Softwareentwicklung geführt hat.

Die Balance zwischen Mensch und Methodik
  • Menschen verstehen: Verschiedene Stakeholder haben verschiedene Perspektiven – alle sind wichtig
  • Aktiv zuhören: Was wird gesagt – und was wird nicht gesagt?
  • Implizites explizit machen: Annahmen und unausgesprochene Erwartungen sichtbar machen
  • Gemeinsames Verständnis: Eine Sprache zwischen Business, IT und Management schaffen

Mein Vorgehen nach IREB/CPRE-Standards

Ausgerichtet an IREB/CPRE-Prinzipien liegt mein Fokus auf messbaren, testbaren und nachvollziehbaren Anforderungen .

Requirements Elicitation
Anforderungen ermitteln
  • Stakeholder-Workshops strukturiert moderieren
  • Interviews mit Anwendern, IT, Management
  • Beobachtung bestehender Prozesse
  • Dokumentenanalyse existierender Systeme
  • Prototyping zur Validierung von Konzepten
Requirements Analysis
Anforderungen analysieren
  • Konfliktanalyse zwischen Stakeholder-Anforderungen
  • Priorisierung nach Geschäftswert und Risiko
  • Machbarkeitsanalyse technisch und organisatorisch
  • Gap-Analyse zwischen Ist- und Soll-Zustand
  • Impact-Analyse auf bestehende Systeme
Requirements Specification
Anforderungen spezifizieren
  • SRS-Dokumente nach IEEE-Standard
  • Use Cases mit Vor-/Nachbedingungen
  • UML-Diagramme (Activity, Sequence, State)
  • Akzeptanzkriterien testbar formuliert
  • NFR-Spezifikation (Performance, Security, etc.)
Requirements Validation
Anforderungen validieren
  • Review-Workshops mit allen Stakeholdern
  • Walkthrough von Use Cases und Szenarien
  • Prototyp-Demos für frühe Validierung
  • Testfall-Ableitung aus Akzeptanzkriterien
Requirements Management
Anforderungen verwalten
  • Traceability Matrix zwischen Requirements und Tests
  • Change Management für Anforderungsänderungen
  • Versionierung aller Requirements-Dokumente
  • Baseline-Management für regulierte Umgebungen

Zentrale Arbeitsergebnisse & Deliverables

Ich liefere klare, umsetzbare Artefakte, die die Grundlage für eine erfolgreiche Umsetzung bilden:

Anforderungs­spezifikationen

Funktionale Anforderungen: Was soll das System tun?

Nicht-funktionale Anforderungen: Wie soll es das tun? (Performance, Security, Usability)

Constraints: Rahmenbedingungen und Randbedingungen

Use Cases & UML-Diagramme

Use Case Specifications: Akteure, Vorbedingungen, Haupt-/Alternativflüsse

Activity Diagrams: Prozessabläufe visualisiert

Sequence Diagrams: Interaktionen zwischen Systemkomponenten

State Diagrams: Zustandsübergänge im System

Akzeptanzkriterien & Tests

Testbare Akzeptanzkriterien: Wann ist eine Anforderung erfüllt?

Test Scenarios: Konkrete Testfälle ableiten

Given-When-Then: BDD-Stil für Akzeptanztests

Traceability Matrix

Requirements-to-Tests: Welcher Test validiert welche Anforderung?

Requirements-to-Design: Wo wird die Anforderung implementiert?

Impact Analysis: Welche Komponenten sind bei Änderungen betroffen?

Daten- & Prozessmodelle

Entity-Relationship Diagrams: Datenmodell visualisiert

BPMN Process Models: Geschäftsprozesse dokumentiert

Data Flow Diagrams: Datenflüsse zwischen Systemen

Machbarkeitsstudien

Proof of Concept: Technische Machbarkeit validieren

Prototypen: Funktionale Demonstratoren erstellen

Spikes: Technische Risiken frühzeitig identifizieren

Technische Perspektive: Requirements + Machbarkeit

Auch wenn Programmieren nicht typischerweise Teil der Anforderungsanalyse ist, ermöglicht mir meine praktische Erfahrung in C#, .NET und Systemintegration einzigartige Vorteile:

Realistische Aufwandsschätzung

Ich verstehe nicht nur was umgesetzt werden soll, sondern auch wie – und kann daher Aufwände und Machbarkeit realistisch einschätzen.

Technische Randbedingungen

Ich erkenne frühzeitig technische Constraints und kann diese in die Anforderungsspezifikation integrieren.

Proof-of-Concept Implementierungen

Bei Bedarf kann ich kleine Testanwendungen entwickeln, um technische Machbarkeit zu validieren – besonders wertvoll bei Integrationen mit externen Systemen (LIMS, OPC/UA, REST APIs).

Gemeinsame Sprache mit Entwicklern

Ich spreche sowohl die Sprache der Business-Stakeholder als auch die der Entwickler – und kann zwischen beiden Welten übersetzen.

Das Ergebnis

Ein detailliertes, umsetzbares Konzept – bereit für die Implementierung. Komplexität wird greifbar, Entscheidungen werden handlungsfähig.

Spezialisierung: Requirements Engineering in regulierten Umgebungen

BioPharma, Healthcare IT und Life Science stellen besondere Anforderungen an Requirements Engineering:

GxP-konforme Dokumentation
  • User Requirements Specification (URS): Strukturiert nach GAMP5
  • Functional Specification (FS): Wie werden URS umgesetzt?
  • Design Specification (DS): Technisches Design dokumentiert
  • Traceability Matrix: URS → FS → DS → Tests
  • Risk Assessment: Welche Requirements sind kritisch?
Validation & Compliance
  • IQ/OQ/PQ-Vorbereitung: Requirements müssen testbar sein
  • 21 CFR Part 11: Electronic Records/Signatures berücksichtigen
  • Data Integrity (ALCOA+): Requirements für Audit Trail, Versioning
  • Change Control: Impact Assessment bei Anforderungsänderungen
  • Audit-Readiness: Dokumentation für Inspektionen vorbereitet

Kommunikation: Die Brücke zwischen allen Welten

Requirements Engineering ist zu 80% Kommunikation und zu 20% Dokumentation.

Die richtigen Fragen stellen

Was ist das eigentliche Problem? Was sind die Ziele? Welche Annahmen gibt es?

Aktiv zuhören

Nicht nur hören, was gesagt wird – sondern auch verstehen, was gemeint ist.

Gedanken teilen

Ideen offen kommunizieren, Feedback einholen, gemeinsam die beste Lösung finden.

Ein gemeinsames Verständnis schaffen

Zwischen Business , IT und Management – damit am Ende alle das gleiche System meinen.

Bereit für Ihr Requirements Engineering Projekt?

Sie planen ein Software-Projekt in BioPharma, Healthcare IT oder Life Science?
Sie benötigen klare, messbare Anforderungen in einer regulierten Umgebung ?

Lassen Sie uns sprechen – ob LIMS, Laboratory Automation oder Healthcare IT:
Ich bringe IREB/CPRE-zertifizierte Expertise und echte Empathie mit.