RE

• Stakeholder

• Systeme, Maschinen und Kontext

• Verflechtung von Zielen,Anforderungen und Design

• Wert Orientierung

• Validierung

• Evolution

• Innovation

Wer ist der Kunde ?

Jeder der von dem System direkt oder indirekt beeinflusst wird

versch. Stakholder -> versch. Ansichten/Blickwinkel

versch Ansichten können zu Konflikten führen

RE:

• Aufdecken von Konflikten

• Verhandeln

• Moderieren

Kontext Def. : Der Teil einer Systemumgebung welcher relevant ist um das System und die Anforderungen zu verstehen

Anforderungen müssen in einen Kontext gebracht werden

Mehrere Level an Anforderungen (System aus Systemen)

System Grenze: Grenze von System und dem umgebenden Kontext

Kontext Grenze: Grenze von dem Kontext und der umgebenden Welt

Ist die Systemanforderung nur für die Software oder Hardware

bzw. welches System ist in der Anforderung gemeint

Modellierung:

• Bestimme den Grad der Spezifikation

• System als BlackBox betrachten

• Modellieren der Akteure die mit dem System interagieren und die Interaktion

• Ergebnis grafisch darstellen -> Context Model

Probleme

• Manchmal erfüllen die Systemanforderungen nur die Weltanforderungen wenn die Domänenannahmen stimmen

Wenn man die Spezifikation S des System und die Domänenannahmen D formal definiert sollte man daraus die passenden Realwelt Anforderungen ableiten können

Höhere Level Entwurfsentscheidungen beeinflussen die Anforderungen der unteren Ebene

Designentscheidungen können zu weiteren Anforderungen führen

Unterscheiden zwischen Anforderung und Design

• Was? und Wie?

• operational (Stakeholder und Anbieter)

• Design gibt den Anforderungen einen Kontext und zeigt deren Grenzen, zudem schränkt es die Anforderungen ein und inspiriert für neue Anforderungen

• Anfoderungen sollen einen Mehrwert bieten

• dieser ergibt sich durch den Vorteil von geringerem Entwicklungsrisiko minus die Kosten des RE

• Anpassen der RE an das Risiko

  • hohes Risiko -> Volles RE

  • niedriges Risiko -> wenig RE

• Risiko wird bewertet durch den Einfluss der Anforderung auf das System und die Wichtigkeit für den Stakeholder

  • weitere EInflussfaktoren:

    • Instinkt, Shared Understanding

    • Referenzsysteme

    • Länge der Feedbackzyklen

Die Welt entwickelt sich weiter → so auch die Anforderungen

Das Problem die Anforderungen stabil zu halten aber das ändern dieser zu erlauben

Potentielle Lösungen:

• kleine Entwicklungszyklen (1-6 Wochen)

• Explizites Anforderungsmanagement

Automatisieren Sie nicht nur - es reicht nicht aus, die Beteiligten zufrieden zu stellen.

Streben Sie danach, die Beteiligten glücklich zu machen. Innovative Anforderungen sind der Schlüssel.

• System View

• User System Interaction View

• Goal View

• Statische Struktur Perspektive

  • Daten Model

  • Klassen und Objekt Modelle

  • Komponentenmodell

• Verhaltensperspektive

  • State Charts

  • Sequenzdiagramm

  • Petri Netze

• Funktions und Flow Perspektive

  • Aktivitätsdiagramm

  • Datenfluss/Informationsfluss Modelle

  • BPMN (Business Prozess Model and Notation)

• Szenarien

• Use Case

Die Kenntnis der Ziele einer Organisation (oder eines Produkts) ist unerlässlich bei der Spezifikation eines Systems, das in dieser Organisation (oder diesem Produkt) eingesetzt werden soll Produkt)

And/OR Bäume

• Jede Anforderung sollte als kleine identifizierbare Einheit spezifiziert werden

• Metadaten sollten hinzugefügt werden ( Autor, Datum Status etc.)

• Das Dokument sollte strukturiert sein mit einem Template

• Anpassen der Details an das Risiko der Anforderung

• Normale und Ausnahmefälle spezifizieren

• Qualitätsanforderungen und Constraints nicht vergessen

Einschränken der Sprache

Benutzen eines Glossars

Definieren von Akzeptanztests

Gegebenenfalls quantifizieren

Fomalisieren

• Benutze aktive Sprache und definierte Subjekte

• Bilde Sätze mit einer kompletten verbalen Struktur

• Benutze Terme wie im Glossar definiert

• Definiere präzise Bedeutungen für Wörter wie (sollte, muss etc.)

• Suche nach Nomen mit unspezifizierter Semantik wie (die Daten, die Kunden etc.) und ersetze diese durch genauere Beschreibung

• Bei der Verwendung von Adjektiven in vergleichender Form ist ein Bezugspunkt anzugeben: "besser" → "besser als"

• Allquantifikatoren sollten gemieden werden

• Nur eine Anforderung pro Satz

• eindeutige ID für jede Anforderung

• Strukturieren der Anforderungen in Abschnitte und Unterabschnitte

• Redundanz vermeiden “never ever” → “never”

Template für die Erzeugung gut definierter Anforderungen

[<Bedingung>] <Subjekt> <Action> <Objekt> [<Einschränkung>]

Wenn eine valide Karte erkannt wie, soll das System ein Kommando “Öffne für eine Drehung” schicken innerhalb von 100ms

• Ein Satz über eine Anforderung

• geschrieben in der Stakeholder Perspektive

• Optional mit den erwarteten Vorteil

• Begleitet von Akzeptanzkriterien für die Anforderung

• Akzeptanzkriterien machen diese präziser

• Template

  Als ein <Rolle> möchte ich das <meine Anforderung> [sodass <Vorteil>]

• Dimension 1: Linear oder Evolutionär?

  • Linear

    • klare, stabile vorher bekannte Anforderungen

    • kleines Risiko

    • Relativ kurze Dauer des Projekts

    • Komplexer Prozess zur Änderung von Anforderungen ist akzeptabel

    
    

  • Evolutionär

    • Hohes Risiko

    • Entwicklung der Anforderungen

    • Lange Dauer des Projektes

    • Die Fähigkeit, Anforderungen leicht zu ändern, ist wichtig

    
    

• Dimension 2: Vorgeschrieben oder Explorativ oder COTS-driven

  • Vorgeschrieben

    • Anforderungsspezifikation ist ein Vertrag

    • Funktionalität bestimmt Kosten und Fristen

    • Die Entwicklung des spezifizierten Systems kann ausgelagert werden

    • Häufig kombiniert mit linearen Prozessen

  • Explorativ

    • Nur bekannte Ziele, konkrete Anforderungen Erfordernisse müssen erforscht werden

    • Stakeholder stark involviert, kontinuierliches Feedback

    • Prioritäten setzen und aushandeln umzusetzende Anforderungen

    • Fristen und Kosten begrenzen Funktionalität

    • Funktioniert typischerweise nur bei evolutionären Prozessen

  • COTS-driven (Component of the Shelf)

    • Das System wird mit COTS-Software implementiert

    • Die Anforderungen müssen die Funktionalität der gewählten COTS-Lösung widerspiegeln

    • Die Anforderungen müssen priorisiert werden

    • Häufig werden nur Anforderungen spezifiziert, die die von der COTS-Lösung nicht abgedeckt werden, spezifiziert

• Dimension 3: Kundenspezifisch oder marktorientiert

  • Kundenspezifisch

    • System wird von einem Kunden bestellt

    • Individuelle Personen können identifiziert werden als Stakeholder

    • Stakeholder auf der Kundenseite sind Hauptquelle für Anforderungen

  • marktorientiert