Requirement Engineering

• Erstellung eines Fehlerberichts.
• Beheben von Fehlern (wird typischerweise vom Autor der jeweiligen Dokumente durchgeführt).
• Check, ob die Beendigungskrite rien für das Review erfüllt sind.

• Autor
• Schriftführer / Protokollant
• Review Leader
• Reviewer
• Moderator
• Management

Arten: (geordnet von geringem Formulierungsgrad zu hohem)

• Informelles Review
• Walkthrough
• Technisches Review
• Inspektion

Erfolgsfaktoren:

• Review sollte ein klares und abgestimmtes Ziel haben.
• Die relevanten Personen sollten beteiligt sein.
• Das Auffinden von Fehlern wird positiv bewertet (Firmenkultur!).
• Atmosphäre des Vertrauens.
• Gute Vorbereitung von Meetings.
• Es gibt Checklisten und klare Rollen.
• Managementunterstützung.
• Betonung liegt auf Lernen und Prozessverbesserung.

• Impact Analysis
  • Es wird gezielt eine Analyse der Auswirkungen (Impact Analysis) durchgeführt, um potenziell von einer Änderung / Weiterentwicklung betroffene Funktionen in anderen Bereichen zu identifizieren.
• Risikobetrachtung
  • Es wird gezielt eine Risikobetrachtung (Risk Finding, Concern Matrix) durchgeführt, um potenzielle Probleme, die durch eine Änderung / Weiterentwicklung verursacht werden, zu identifizieren.
• Risiko-Eliminierung
  • Es wird gezielt versucht, die besten Lösungen gestalten, um Risiken möglichst ganz zu vermeiden.

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