2.2.3 Qualitätskriterien von Anforderungen

• Jede Anforderung wird einzeln getestet. Beispiele fuer Qualitätsktriterien sind:
• Ist die Anforderung wirklich eine Anforderung, oder schon eine mögliche Lösung zu einer Anforderung
• Ist die Anforderung sowohl fuer Kunde und Entwickler verständlich.
• Ist die Einhaltung der Anforderung testbar
• Ist der Kontext in dem die Anforderung steht beschrieben
• zu welchem UseCase gehört die Anforderung?
• Verweis auf externe Dokumente vorhanden?
• Von wem kommt die Anforderung ?
• Angabe der Priorität vorhanden ?
• Rechtliche Relevanz der Anforderung ?
• Die Anforderungen werden in der Gesamtheit getestet.
• Widersprechen sich zwei oder mehrere Anforderungen
• Fehlen noch wichtige Anforderungen, sind alle wichtigen UseCases gefunden.

Aus den Anforderungen müssen Akzeptanzkriterien abgeleitet werden können, die den (Nicht) Erfolg des Projekts messen

Das Auffinden der Anforderungen ist i.a. ein sehr komplexer iterativer und inkrementeller Prozess. Dieser Prozess erstreckt sich waehrend der gesamten Lebenszyklus des Projekts. Anforderungen ändern sich, es kommen neue hinzu, alte Anforderungen werden gelöscht.

In der Literatur sind verschiedenartige Prozesse aufgelistet. Ich versuche die Gemeinsamkeiten herauszufinden:

• Beschreibung des Projektziels
• Finden der Stakeholders. Stakeholders sind Personen, die Interesse an diesem Projekt haben (Anwender sind nur ein Teil davon).
• Beschreibung der Systemgrenzen.
• Abgrenzung gegenüber anderen Systemen.
• Welche Systeme sind an dem zu erstellenden System angeschlossen.
• Welche Datenströme kommen herein, und welche kommen heraus, und in welcher Form sind diese Ströme
• Wann und wie wird das zu erstellende System getriggert.
• Finden der UseCases bzw. Geschaeftsprozesse.
• Finden der funktionellen und nicht funktionellen Anforderungen.
• Festlegen der Rahmenbedingungen
• z.B.: Was darfs kosten.
• z.B: Wann ist Abgabetermin
• Qualitätskontrolle
• jeder einzelnen Anforderung.
• Gesamtheit aller Anforderungen.