CARR ist ein Akronym und steht für:
- Constraints
- Assumptions
- Requirements
- Risks
Worum geht es da genau? Es geht um die strukturierte Erhebung von Anforderungen, Annahmen, Nebenbedingungen und Risiken. Ich erlebe es immer wieder, dass z.B. Kunden nicht in der Lage sind, diese Angaben aus dem Stegreifzu formulieren. Sehr oft ist das, was der Kunde formuliert, schon viel zu detailliert oder missverständlich. Am Ende hat man ein Projektziel, welches eher ein bewegliches Ziel, als einem definierten Zustand gleicht. Das macht es nicht leichter, die Erwartungshaltung des Kunden zu befriedigen. Aber es gibt eine Lösung in Form eines strukturierten Vorgehens.
Requirements sind Anforderungen. Anforderungen geben vor, was erreicht werden soll. Sie sollten messbar, nachvollziehbar, erreichbar, spezifisch und eindeutig sein.
Assumptions sind Annahmen. Sie dienen in der Definitionsphase dazu, bestimmte Dinge als gegeben anzunehmen, ohne es zu diesem Zeitpunkt geprüft zu haben.
Constraints sind Nebenbedingungen. Damit werden Nebenbedingungen, Limitationen o.ä. festgehalten. Typischerweise findet man hier z.B. Vorgaben für Hersteller oder Budgets.
Risks sind Risiken, die Ziele gefährden oder beeinflussen können.
Requirements und Constraints sind, aus dem Requirements Engineering bekannt, funktionale und nicht-funktionale Anforderungen. Hat man diese benannt, so kann man relativ problemlos Risiken und Annahmen hinzufügen. Am Ende hat man nicht nur seine Ziele sauber formuliert, sondern auch Risiken benannten und Rahmenbedingungen abgesteckt. Die Methode eignet sich sehr gut zum strukturierten Erheben von Anforderungen in Designprozessen.
