Requirement Engineering

Risiko = Eintrittswahrscheinlichkeit * erwarteter Schaden

Produktrisiken:

Risiken, die sich aus der Qualität des Produktes ergeben:

• Potenzial, dass ein Fehler einer Person oder einer Organisation Schaden zufügt
• Generell unzureichende Softwarequalität
• Unzureichende Datenintegrität

Projektrisiken

Probleme bei Lieferanten

• Mangelnde Lieferfähigkeit
• Nichteinhaltung vertraglicher Vorgaben

Probleme innerhalb der eigenen Organisation

• Zuwenig Ressourcen, mangelnde fachliche Fähigkeiten oder Qualifikationen
• Politische Themen und ungünstige Unternehmenskultur (z.B. Fehler und Probleme werden nicht weitergemeldet, sondern vertuscht)

• Vorbeugen (Resolved)
• Mindern (Mitigated)
• Auslagern (Owned)
• Akzeptieren (Accepted)

Software-Entwicklungs-Lebenszyklus (Software Development Lifecycle SDLC)

beschreibt, welche Entwicklungs- und Testaktivitäten wann ausgeführt werden und wie diese zeitlich und logisch zusammenhängen. Es gibt sequentielle und iterative / inkrementelle Varianten.

• Wasserfall-Modell
• Agile Modelle (z.B. Kanban, Scrum)
• V-Modell

Wir entdecken neue und bessere Wege zur Entwicklung von Software und möchten andere dabei unterstützen, dies ebenfalls zu tun. Daher vertreten wir die folgenden Werte:

• Menschen und deren Zusammenarbeit sind wichtiger als Prozesse und Werkzeuge
• Funktionierende Software ist wichtiger als eine verständliche Dokumentation
• Die Zusammenarbeit mit dem Kunden ist wichtiger als die Vertragsverhandlung
• Eine Antwort auf Veränderung zu finden ist wichtiger als einen Plan einzuhalten

• dient dazu, von den Symptomen abgeleitet die „Grundursache“ eines Problems herauszufinden
• Um sicherzustellen, dass nicht an Symptomen „herumgedoktert“ wird, sondern die zentrale Ursache erkannt wird
• liefert noch keine Lösung bzw. Implementierung, aber durchaus eine konkrete Anforderung (die Anforderung ist NICHT die Lösung selbst).

Wenn bsw. ein Unternehmen Probleme mit einer niedrigen Produktivität hat und erkennt, dass die eigentliche Ursache in mangelnder Ausbildung der Mitarbeitenden liegt, dann lassen sich gezielt Anforderungen an ein Ausbildungsprogramm formulieren. Z.B. in Form einer User Story:

„Als Produktionsmitarbeiter benötige ich eine detaillierte Einführung in die Bedienung der Maschine in Form einer zweitägigen Schulung, um die vorgeschriebene Taktzahl einhalten zu können.“

Aber: Die konkrete Formulierung der Anforderungen lässt sich aus dem Ishikawa-Diagramm nicht ableiten (auch nicht aus dem Kano-Modell und auch nicht aus anderen Methoden). Die Übersetzung von Kundenproblemen in konkrete Anforderungen ist daher echtes Engineering!!!

Für mehrere Themenkreise / Probleme können mehrere Ishikawa-Diagramm sinnvoll sein!

Definition Modell:

Ein Modell ist ein abstraktes Abbild einer existierenden oder noch zu erschaffenden Realität.

Eigenschaften von Modellen:

• Modelle sind (nur) ein Abbild der Realität.
• Modelle verkürzen (oft) die Realität.
• Pragmatische Eigenschaft, d.h. Modelle sind für einen spezifischen Verwendungszweck konstruiert (wie eine Metapher).

Formale Modellierungssprache:

• Syntax legt die zu verwendenden Modellelemente fest.
• Semantik definiert die Bedeutung der einzelnen Modellierungselemente.

Formalisierungsgrad:

• Informal → Manuelle Zeichnungen, Strichmännchen, Skizzen, Design Thinking Prototypen
• Semiformal → z.B. Zielmodelle mit Und-Oder Bäumen
• Formal → v.a. UML (Unified Modeling Language) und BPMN (Business Process Model and Notation)

• bessere Verständlichkeit
• unterstützen bestimmte Perspektiven Beispiel: U-Bahn-Netz, Länge der Verbindungslinien entspricht der Fahrzeit und nicht der Entfernung
• verschiedene Abstraktionsgrade

Meist wird eine Kombination von natürlicher Sprache und grafischen Anforderungsmodellen verwendet.

Ziele: Beschreiben Intentionen von Stakeholdern oder StakeholderGruppen. Sie können mitunter auch in Konflikt zueinander stehen.

Use Cases und Szenarien: Beispielhafte Abläufe der Systemnutzung.

Systemanforderungen (allgemein als Anforderungen bezeichnet): Beschreiben detaillierte Funktionalitäten und Qualitäten, die das zu entwickelnde System umsetzen soll und die möglichst vollständig und präzise als Eingabe für die weiteren Entwicklungsschritte dienen.

Zielmodelle Eignen sich besonders um die Vision des Systems zu verfeinern. Dies wird als Zieldekomposition bezeichnet.

Einfache Technik: UND-ODER-Bäume

• BPMN - Business Process Model and Notation (aktuelle Version 2.0.2)
• Standard für die Beschreibung und Modellierung von Geschäftsprozessen
• Wird von der OMG (Object Management Group) gepflegt und weiterentwickelt (die OMG betreut u.a. auch UML, Unified Modeling Language)

• Spezifikation
• Visualisierung
• Architekturdesign
• Konstruktion
• Simulation und Test
• Dokumentation

• betonen die Fokussierung auf wesentliche Funktionalitäten im Überblick
• sind ein Werkzeug, um die Interaktion von Benutzern mit dem System darzustellen
• stellen die Anforderungen von Anwendern in den Mittelpunkt der Betrachtung

siehe Bild

Siehe Bild

• Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
• Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.
• Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäss (1) oder (2).

• Kontext identifizieren
• Anstösse spezifizieren
• Antworten finden
• Restriktion beachten

• Abgestimmt
  • Anforderung ist für alle Stakeholder korrekt und akzeptiert.
• Eindeutig
  • Kann nur auf eine einzige Weise verstanden werden (kein Interpretationsspielraum).
• Notwendig
  • Eine Anforderung muss die Gegebenheiten im Systemkontext so wiederspiegeln, dass sie hinsichtlich der aktuellen Gegebenheiten im Systemkontext gültig ist.
• Konsistent
  • Anforderungen müssen widerspruchsfrei sein.
• Verständlich
  • Die Anforderungen müssen für alle Stakeholder verständlich sein.
• Machbar
  • Eine Anforderung muss technisch (und ggf. finanziell) machbar sein.
• Prüfbar
  • Eine Anforderung muss sich durch einen Test oder eine Messung nachweisen lassen.
• Realisierbar
  • Es muss möglich sein, jede Anforderung innerhalb des gegebenen Projektrahmens auch umzusetzen.
• Verfolgbar
  • Der Ursprung der Anforderung als auch deren Umsetzung muss nachvollziehbar und nachverfolgbar sein (Traceablility).
• Vollständig
  • Jede einzelne Anforderung muss die geforderte und zu liefernde Funktionalität vollständig beschrieben. Unvollständige Anforderungen sind zu kennzeichnen.
• Glossar
  • Verwendete Fachbegriffe müssen einheitlich verwendet und in einem zentral verwalteten Glossar beschrieben sein.

Bei umfangreicheren Spezifikationen sind spezielle ITSysteme hilfreich, um eine Verfolgbarkeit (engl. Traceability) zu gewährleisten.

Beispiel:

• Geschäft
  • Auf dem bestehenden Schienennetz sollen pro Tag zusätzlich 10.000 Personen transportiert werden.
• System
  • Die Minimaldistanz zwischen 2 Zügen soll stets grösser als der maximale Bremsweg des nachfolgenden Zuges sein.
• Software
  • Der maximale Bremsweg soll alle 100 ms neu berechnet werden.

Verzahnung (Traceability) der Anforderungen ist wichtig.

Verifikation stellt sicher, dass wir die Software (bzw. Produkt / Prozess) richtig entwickeln.

Validierung stellt sicher, dass wir die richtige Software (bzw. Produkt / Prozess) entwickeln.

• Definiert das “was”
• Black Box
• Sinn & Zweck
• Anwendungssituation
• Betont Nutzerperspektive
• Beschreibt nicht die Lösung oder Implementierung

• Definiert das „wie“
• White Box
• Systemarchitektur
• Systemumgebung
• Funktionalität
• Komponente
• Schnittstellendefinition

Das „Was“ bzw. „Wie“ sind kontextabhängig. Je nach Situation kann es sich um eine Entwurfsentscheidung oder um eine Anforderung handeln. Es gibt keine scharfe Trennlinie.

Kundenwunsch:

• Unvollständig
• Unverständlich
• Inkonsistent
• Falsch formuliert
• Redundant
• Mehrdeutig
• Nicht testbar

Kundenanforderung:

• Verstanden
• Akzeptiert
• Voraussetzungen geprüft
• Lücken geschlossen

System Requirement:

• Vollständig
• Konsistent
• Testbar
• Risiken klar
• Auswirkungen (Impact) evaluiert
• Machbarkeit bestätigt
• Voraussetzungen geprüft
• Lücken geschlossen

• Anforderungen erheben
• Anforderungen validieren und verhandeln
• Anforderungen dokumentieren
• Anforderungen pflegen und verwalten

• Erstellen und Pflegen von technischer Dokumentation
• Vision & Strategie mitgestalten
• Hindernisse ausräumen (engl. Impediments)
• Kommunikation, Validierung und Verhandlung
• Stakeholder Management
• Dokumentation von Anforderungen

• Durchhaltevermögen
• Technische Expertise
• Konflikte lösen
• Analytisches Denken
• Kommunikation
• Moderation
• Selbstvertrauen
• Kreativität
• Empathie

siehe Bild