Requirement Engineering

• Werden nicht vom Kunden beschrieben
• Unerwarteter Zusatznutzen
• Erzeugen Kundenloyalität

z.B. Bezahlung von Fahrkarten mit dem Mobiltelefon

Rückweisungs-Merkmale: z.B. falsche Farbe, oder laufende Kosten durch Aboverträge, ...

• Welche Merkmale, Eigenschaften oder Funktionen zeichnen das Produkt aus?
• Welcher dieser Merkmale machen die Leistung im Vergleich zum Wettbewerb besonders oder einzigartig?
• Auf welche Merkmale legen Kunden und einzelne Zielgruppen oder Kundensegmente besonderen Wert?
• Welche Merkmale vergleichen die Kunden bei der Kaufentscheidung mit denen der Konkurrenzangebote?
• Welche Merkmale sind für die Kunden selbstverständlich?

Funktional (positiv):

• Was würden Sie sagen, wenn das Produkt über ... verfügt?
• Was würden Sie sagen, wenn es mehr ... gäbe?

Dysfunktional (negativ):

• Was würden Sie sagen, wenn das Produkt NICHT über ... verfügt?.
• Was würden Sie sagen, wenn es weniger ... gäbe?

Mögliche Antworten:

• Das würde mich sehr freuen
• Das setze ich voraus
• Das ist mir egal
• Das nehme ich gerade noch hin
• Das würde mich sehr stören

• 1. Produktanforderungen identifizieren .
• 2. KANO Fragebogen konstruieren
• 3. Durchführung des Interviews

Funktionale Frage:

Wie denken Sie darüber, wenn die Bahn zukünftig auch Robotertaxis anbieten würde?

Antwort: Das würde mich sehr freuen

Dysfunktionale Frage:

Wenn die Bahn zukünftig keine Robotertaxis anbieten würde, wie denken Sie darüber?

Antwort: Das ist mir egal

• Agenda eines agilen Requirements Workshops (Backlog Refinement)
• Literatur zu Sketchnotes und Graphic Recording (informelle Anforderungsdokumentation und Workshop-Moderation)
• Canvas-Methoden
• Proof of concept (POC) journey
• Process journey
• Ishikawa diagram
• Interviews

• Mehrdeutigkeit
• zu viele Worte
• Komplexität
• Auslassungen, fehlende Elemente
• Zu vage Beschreibungen
• nicht testbar
• Dubletten

• Vollständige Sätze
• 1 Anforderung pro Satz (das bedeutet nicht, dass alle Anforderungen in einem Satz beschrieben werden können).
• Vermeidung von Passiv-Formulierungen, immer das Subjekt benennen.
• Konsistente Terminologie (Glossar verwenden)
• Unklare Bezüge vermeiden (z.B. das soll gedruckt werden → was ist „das“? Besser: Der Anwender soll das auf dem Bildschirm angezeigte Dokument ausdrucken.

Falls die ABC-Software-Komponente abstürzt, soll ein Neustart des Systems ausgeführt werden.

Nominalisierung

außerdem:

Passiv-Formulierung.

Unklar wie der Neustart erfolgen soll

Besser:

Falls die ABC-Software-Komponente sich nicht innerhalb von 10 ms zurückmeldet, soll der Benutzer die „Initialisiere Neustart“-Routine aufrufen.

Das Fahrspur-Erkennungssystem soll dynamische Verkehrssituationen in den verschiedenen Level erkennen, um Reaktionen für das Bremssystem vorzubereiten.

Substantive ohne Bezugsindex, also mit fehlendem Bezug.

Besser:

Das Fahrspur-Erkennungssystem soll auf der Autobahn mit einer bis maximal vier Spuren vorausfahrende Fahrzeuge erkennen, um den Bremsdruck für eventuelle Reaktionen des Bremssystems einzustellen.

Das System soll alle Daten in allen Untermenüs anzeigen.

Universalquantoren (unklare, unbestimmte Mengenangaben)

Besser:

Das System soll die Namen der als Administrator eingetragenen Personen im Untermenü „Zugriffsrechte“ anzeigen.

Das Benzin-Einspritzpumpen-System soll zusätzlichen Brennstoff einspritzen, wenn die Temperatur 25 Grad übersteigt.

Universalquantor, unklare Mengenangabe

außerdem:

Grad Celsius???

Was ist bei <= 25 Grad???

Besser:

Das Benzin-Einspritzpumpen-System soll zusätzlich 10 Milliliter Brennstoff pro Sekunde einspritzen, wenn die Temperatur 25 Grad übersteigt.

Um einen Benutzer anzumelden, sollen die Login-Daten eingegeben werden.

Unvollständig spezifizierte Prozesswort

Weiterhin Passiv-Formulierung

Besser:

Das System soll eine Eingabemaske anzeigen, mit der der Benutzer seinen User-Namen und sein Passwort über die Tastatur am Terminal eingeben kann.

Jedem Buch soll ein eindeutiger Platz zugewiesen werden.

Passiv, unklare Bezeichnung

Besser:

Der Bibliothekar soll jedem Buch einen Platz entsprechend dem alphabetischen Namen des Autors zuweisen.

Die Logik zur Steuerung der Geschwindigkeit soll unterdrückt werden, z.B. wenn der Aktivitätsschalter gesetzt ist.

Unklare Formulierung

Besser:

Die Logik zur Steuerung der Geschwindigkeit soll in folgenden Fällen unterdrückt werden, wenn mindestens eine der drei folgenden Bedingungen zutrifft:

1. der Aktivitätsschalter ist gesetzt oder

2. das ABC-Signal hat den Wert 1

3. der XYZ-Wert ist größer als 3

• Nominalisierung
• Substantive ohne Bezugsindex
• Universalquantoren
• Unvollständig spezifizierte Bedingungen
• Unvollständig spezifizierte Prozesswörter
• Passiv-Formulierungen
• Missverständliche Formulierungen

Eine Satzschablone (Requirements Template) ist ein Bauplan für die syntaktische Struktur einer einzelnen Anforderung.

Es geht also darum, Sätze grammatikalisch zu standardisieren.

Schritt 1: Festlegen der rechtlichen Verbindlichkeit

• muss

Schritt 2: Kern der Anforderung festlegen.

• Prozess-Verb
  • also was soll gemacht werden, z.B. drucken, speichern, übertragen, berechnen

Schritt 3: Charakterisieren der Aktivität des Systems

• Typ1: Autonome, selbständige Systemaktivität, z.B. drucken
  • Prozess-Verb
• Typ2: Benutzerinteraktion. Das System stellt dem Nutzer die Prozessfunktionalität zur Verfügung.
  • <wem?> die Möglichkeit bieten <Prozesswort>
• Typ3: Schnittstellenanforderung. Das System führt einen Prozess in Abhängigkeit von einem Dritten aus, ist an sich passiv und wartet auf ein externes Ereignis
  • fähig sein <Prozesswort>

Schritt 4: Objekte einfügen

Prozessverb vervollständigen

„drucken“ → was und wo gedruckt werden soll

Objekt & Ergänzung des Objekts

Schritt 5: Formulierung von logischen und zeitlichen Bedingungen

Wann? Unter welcher Bedingung?

temporal - sobald, während, solange

konditional - falls

Achtung bei “wenn“: zeitlich und konditional

Siehe Bild:

User Story:

Als <Art von Benutzer / Rolle> benötige ich <Funktion / Anforderung> damit ich <Nutzen>

• Einfach zu verstehen
• Aufforderung zur Diskussion
• Gibt das Ziel an, für das die Anforderung relevant ist
• Aus Nutzersicht formuliert
• Verifikations- bzw. Akzeptanzkriterium definiert (nicht zu detailliert, dient als Benchmark für die Abnahme)

1. Beispiel:

„Als Zugführer benötige ich eine Notbremse, damit ich im Notfall den Zug anhalten kann.“

2. Beispiel:

„Als CFO benötige ich den Quartalsabschluss am 3. Tag nach Ablauf des jeweiligen Quartals, um den Bericht für die Aktionäre fertigzustellen und freigeben zu können.“

User Story - Variante 1:

„Als Kunde benötige ich einen Button „Rechnung anzeigen“ auf der Übersichtsseite der letzten Bestellungen, um mir nochmals alte Rechnungen anzeigen lassen zu können.“

User Story - Variante 2:

„Als Kunde möchte ich alte Rechnungen nochmals anzeigen können.“

„Invest in good user stories“

• Independant
  • unabhängig voneinander
• Negotiable
  • verhandelbar
• Valueable
  • liefert Mehrwert
• Estimable
  • schätzbar
• Small
  • möglichst klein
• Testable
  • testbar

Wichtig ist die “Definition of Done”, also eine Vereinbarung, wann eine User Story erledigt ist, z.B.

• Funktion ist implementiert.
• Funktion ist fehlerfrei und getestet.
• Funktion ist dokumentiert.
• Funktion ist dem Kunden bereitgestellt.
• Funktion wurde durch den Kunden akzeptiert.

Ein Glossar ist eine Sammlung von wichtigen Begriffen und enthält:

• Kontextspezifische Fachbegriffe
• Abkürzungen und Akronyme
• Alltägliche Begriffe, die im gegebenen Kontext eine spezifische Bedeutung haben
• Synonyme (verschiedene Begriffe mit gleicher Bedeutung)
• Homonyme (Begriff mit verschiedenen Bedeutungen)

In jedem Requirements Projekt sollte es ein Glossar geben (fehlendes Glossar ist häufig eine Ursache von Fehlern und Bugs).

Regeln zum Umgang mit einem Glossar:

• Es muss zentral verwaltet werden
• Es muss konkrete Verantwortlichkeiten geben (also wer für das Glossar zuständig ist und wer Aktualisierungen durchführt)
• Es muss gepflegt werden
• Es muss allgemein zugänglich sein
• Es muss verbindlich verwendet werden
• Es muss mit den Stakeholdern abgestimmt sein

• Jeden einzelnen Fehler zu finden
• Nicht etwas das man halt macht, wenn die Programmierung abgeschlossen ist
• Zufallsgesteuert irgendwelche Knöpfe drücken und hoffen, dass etwas kaputt geht
• Nichts das man so lange aufschiebt, bis sich die ersten Anwender beschweren

Dies bedeutet für das zu testende System (oder die zu testende Komponente), dass

• es korrekt auf alle möglichen Eingaben reagiert.
• es seine Funktion innerhalb akzeptabler Zeit erfüllt.
• es hinreichend benutzbar ist.
• es in der vorgesehenen Umgebung installiert und ausgeführt werden kann.
• es die Erwartungen der Stakeholder erfüllt..
• es die Anforderungen erfüllt, für die es entwickelt wurde.

Software Tester testen also gegen die Anforderungen!!!

Software Testing ist eine Aktivität, die ausgeführt wird, um Stakeholder Informationen bezüglich der Qualität des getesteten Produktes oder Services geben. (Wikipedia)

Verifikation stellt sicher, dass wir die Software richtig entwickeln.

Stellt sicher, dass das System nicht abstürzt, es die Anforderungen erfüllt und es Sinnvoll mit Fehlern umgeht. Es wird sichergestellt, das das die Spezifikationen korrekt umgesetzt wurden.

Validierung stellt sicher, dass wir die richtige Software entwickeln.

Stellt sicher, daass die Anforderungen die tatsächlichen Bedürfnisse des Kunden abdecken. Es wird geprüft, ob ein Produkt eine fetsgelegte Aufgabe auch löst.

Die Fehler die weiter gegeben werden werden immer um den Faktor 10 Teurer.

• Requirements ⇒ Faktor 1
• Entwicklung ⇒ Faktor 10
• Testing ⇒ Faktor 100
• Kunde / Produktion ⇒ Faktor 1000

Dynamische Tests:

• Software wird ausgeführt

Statische Tests:

Manuelle (oder werkzeugbasierte) Untersuchung von Arbeitsprodukten, z.B.

• Spezifikationen
• Prozessbeschreibungen
• Funktionale / nicht-funktionale Anforderungen
• Testprozeduren
• Testskripte
• Dokumentationen
• Webseiten
• Verträge
• Projektpläne
• Budgets
• Entwürfe