RE-Prinzipien

Typ: Regel-Satz
Status: finished
Version: 2007-04-28
English Principles for RE Tasks

Das Anforderungsmanagement von folgt folgenden Prinzipien:
R1: Die Anforderungen werden fachseitig vorgegeben und nur wo notwendig technisch oder durch Lösungen eingeschränkt.
R2: Zuerst werden die fürs Geschäft wertvollen Anforderungen analysiert und realisiert.
R3: Fehler im System werden vermieden, nicht herausgeprüft.
R4: (Potentiell) kontroverse Diskussionen werden so früh wie möglich geführt. Unklare, riskante oder aufwändig zu beschreibende Sachverhalte werden so früh wie möglich geklärt.
R5: Die Bandbreite in der Kommunikation der Anforderungen und über die Anforderungen ist so groß wie möglich.
R6: Wenn eine Regel, eine Festlegung oder ein Standard, ob vom Projekt stammend, vom Unternehmen oder von außerhalb, der Verständlichkeit der formulierten Anforderungen entgegensteht, so wird sie missachtet.
R7: Lösungen zu Anforderungen werden nur in Form von optionalen Vorschlägen behandelt.
R8: Das AM-Konzept unterliegt einem kontinuierlichen Verbesserungsprozess.
R9: Es gilt AllgRegelnPAEE ("Allgemeine Regeln zu Priorisierung von Aufgaben in evolutionären Entwicklungen")

Zu RE-Prinzipien.R3: Anforderungsbezogene Fehler in IT-Systemen
Fehler in IT-Systemen zu beheben wird umso teuerer, je „später" im Entwicklungsprozess sie entdeckt werden. Dies ist so, weil im Systems Engineering ein- und dieselbe Sache mehrfach beschrieben wird: als grobe Anforderung, als Architektur, als feine Anforderung, als Design, als Test, als Code, in Handbüchern. Je mehr Artefakte aufgrund eines Fehlers zu ändern sind, desto teuerer. Hinzu kommen u. U. noch Kosten, eine Fehlerbehebung in die Fläche zum Anwender zu bringen.
Somit ist es zweckmäßig, Fehler von vornherein zu vermeiden.

Was das Anforderungsmanagement anbelangt entstehen Fehler an 4 Stellen im Prozess:
1) Wenn die Stakeholder ihre Anforderungen falsch oder unvollständig definieren.
2) Wenn Analytiker die Anforderungen falsch/unvollständig dokumentieren. Gute Anforderungen zu schreiben ist kein Hexenwerk.
3) Wenn Entwickler Unit Tests schreiben, die die falsche Implementierung testen. Selbst mit effizienten Verfahren zur ständigen Integration von Implementierungsartefakten wird damit nur sehr effizient das Falsche getestet.
4) Wenn Tester sicherstellen, dass die falschen / nicht alle Anforderungen implementiert wurden. Man verschwendet Zeit damit, Anforderungen zu testen (unf ggf. Fehler zu beheben), die gar keine sind.

Welche Strategie verwenden wir im Projekt dagegen? Wir bauen an den entsprechenden Stellen Feedback-Zyklen ein.

Zu 1): Den ROI des Projektes in den Mittelpunkt zu stellen bewirkt, das sich die Stakeholder auf die wichtigen Anforderungen konzentrieren. Verschiedene Erhebungstechniken helfen dabei. Die Stakeholder geben die von den Analytikern geschriebenen Anforderungen inhaltlich frei.
Zu 2): SQC-Prozess zur Sicherung der Anforderungsqualität. Ein oder mehrere Analytiker geben die Erbeit eines Analytikers formal frei. Ziel ist vorrangig die Verbesserung des Analytikers, nicht der Spezifikation
Zu 3): zwischen Analytikern, Architekten und Entwicklern hilft sicherzustellen, dass die Entwickler die Anforderungen verstanden haben.
Zu 4): Die von den Testern erstellten Testfälle und Testdaten werden von den Analytikern freigegeben.