Vor ein paar Wochen nahm ich an einer Open Space Veranstaltung zum Thema Requirements Engineering teil. Schon kurz nach Beginn war absehbar, dass sich dieses Treffen lohnen würde. Denn schnell füllte sich die Pinnwand mit praxisnahen Themen, die alle bewegten: “Wie führt man Requirements Engineering ein?“, “Traceability: Möglichkeit vs. Notwendigkeit”, “Sind Modelle Anforderungen?”, “Wie geht man mit Standards um? Kopieren vs. Referenzieren.”, “Qualität: Fehler vermeiden vs. Fehler finden?” … Bei lebhafter Diskussion verstrich die Zeit wie im Flug. Kurz vor dem geplanten Ende war aber noch eine nicht behandelte Karte an der Pinnwand: “Was sind die essenziellen Attribute eines Requirements?”. Den meisten Teilnehmern erschien dieses Thema offenbar “unspannend”. Für sie lag die Antwort auf der Hand: ID, Owner, Quelle, Status, Beschreibung, Priorität, Abnahmekriterium – und ASIL. A-was? Nun, ich befand mich in einer Runde von Automotive-Spezialisten, denen anders als mir das Risikoklassifizierungsschema nach dem Automotive Safety Integrity Level – kurz ASIL – gemäß ISO 26262 geläufig war. Wie hätte die Attributliste wohl ausgesehen, wenn die Teilnehmer – sagen wir – aus dem Bereich Handel, Banken und Versicherungen gekommen wären? Die Attributierung* von Anforderungen ist durchaus spannend. Sie ist branchen-, unternehmens- und ggf. auch projektabhängig. Sehen wir uns das Thema deshalb unter den Aspekten Zweck, Nutzen, Vorgehen und Tool-Unterstützung einmal näher an.
Zweck und Nutzen eines Attributierungsschemas
Was ist eigentlich ein Attribut? Wir verstehen darunter eine charakteristische Eigenschaft einer Entität, hier also einer Anforderung. Nach IREB (siehe [1]) wird die Menge aller Attribute für eine Klasse von Anforderungen (wie funktionale Anforderungen und Qualitätsanforderungen) als Attributierungsschema bezeichnet. Mit einem definierten Attributierungsschema, das neben den Attributen z.B. auch ihre Wertemengen festlegt, sorgen Sie dafür, dass Anforderungen einheitlich beschrieben werden.
Attribute liefern Meta-Informationen über Anforderungen. Die Auswahl der Attribute eines Attributierungsschemas wird durch die Aufgaben bestimmt, die Sie unterstützen wollen. Mögliche Aufgaben sind:
- die Priorisierung von Anforderungen für die Projekt- und speziell die Release-Planung,
- die Schätzung von Anforderungen für das Projektmanagement,
- die Ermittlung des Projektstatus im Rahmen des Projektmanagements,
- das Risikomanagement anhand von Attributen zur Stabilität und Verbindlichkeit von Anforderungen,
- Testmanagement mit der Testabdeckung von Anforderungen,
- die Traceability, also die Nachverfolgbarkeit von Anforderungen zurück zu ihrer Quelle und bis hin zur entwickelten Komponente.
Um die Unterstützung nutzen zu können, die die Anforderungsattribute für diese Aufgaben bieten, benötigen Sie Sichten auf die Anforderungen. Dazu später mehr. Zunächst aber ein Blick auf das …
Vorgehen zur Entwicklung eines Attributierungsschemas
Unterschiedliche Klassen von Anforderungen können verschiedene Attributierungsschemata besitzen – so die obige Definition. Das erste, was Sie tun müssen, ist deshalb
- Klassen von Anforderungen definieren, mit denen Sie arbeiten wollen.
Hier kann es hilfreich sein, ein Metamodell für die Klassen von Anforderungen einschließlich ihrer Beziehungen zu anderen Artefakttypen des Requirements Engineering zu erstellen und z.B. mit einem Klassendiagramm zu visualisieren.
In diesen Schritten geht es dann weiter:
- Attribute erheben.
Nutzen Sie hier vorhandene Quellen wie Attributschemata früherer Projekte oder Referenzschemata aus der Literatur. Aber auch die Befragung von Beteiligten am Requirements-Engineering-Prozess (Auftraggeber, Projektmanager, QS-Beauftragter, Tester etc.) kann “ergiebig” sein.
- Wertemenge für die Attribute definieren.
Legen Sie fest, welche Werte und Wertkombinationen für ein Attribut zulässig sein sollen.
Der letzte Schritt besteht darin, ein Tool so einzurichten, dass es Sie bei der Erfassung, Auswertung und Dokumentation der Anforderungen und ihrer Attribute unterstützt. Mit unserem Tool objectiF RM für Requirements Engineering und unserer Unternehmenssoftware objectiF RPM sieht das so aus:
Attributierung von Anforderungen mit objectiF RM und objectiF RPM
Ich werde mich nachfolgend auf objectiF RPM beziehen. Die Funktionalität ist aber in beiden Tools weitgehend identisch.
objectiF RPM bietet ein Standardformular zum Erfassen von Anforderungen an. Es basiert auf einem Attributierungsschema, dessen Quelle unter anderem das Basiswissen Requirements Engineering nach dem IREB-Standard ist (siehe [2]). Das Standardformular enthält keine branchenspezifischen Attribute, ist also branchenneutral.
Bild 1: Das Standard-Anforderungsformular in objectiF RPM: Die ID wird automatisch erzeugt, die Zustandswechsel erfolgen ereignisgesteuert über einen Zustandsautomaten, der angepasst werden kann. Die Attribute sind nach Themen gegliedert auf mehreren Registerkarten angeordnet. Dort finden sich unter anderem auch die Beziehungen der Anforderungen zu ihren Verfeinerungen, Ableitungen etc. sowie zu anderen Artefakten des Requirements Engineering wie den Stakeholdern und ihren Zielen (Quellen), den zugehörigen Testfällen und den erfüllenden Komponenten (Realisierung).
Wenn Sie eine spezielle Klasse von Requirements und branchenspezifische Attribute benötigen, gehen Sie so vor:
- objectiF RPM bietet bereits mehrere Klassen von Requirements – wir sprechen von Stereotypen – an. Wenn ein passender Stereotyp fehlt, legen Sie einfach einen weiteren an:
Bild 2: Hier sehen Sie das “Standardangebot” an Sub-Stereotypen von Anforderungen. Sie können es ganz leicht nach Bedarf erweitern.
- Zu jedem Stereotyp, natürlich auch zu den bereits vorhandenen, können Sie neue Eigenschaftstypen – sprich Attribute – und ihre Wertemengen definieren. Das sieht z.B. so aus:
Bild 3: Wie war das mit dem Attribut ASIL? Wenige Klicks genügen, die funktionalen Anforderungen um dieses Attribut zu erweitern.
Wenn Sie auf das Bild 1 schauen und sich vorstellen, dass branchenspezifisch noch Attribute unter “Weitere Eigenschaften” hinzukommen, drängt sich Ihnen da nicht die Frage auf: Wer soll mit diesem riesigen Anforderungsformular eigentlich arbeiten? Stakeholder sicher nicht. Aber braucht man für jeden Anforderungsstereotyp wirklich die Sicht auf alle Attribute? Auch das sicher nicht. Besser wäre es doch, für jede Zielgruppe oder jeden Anwendungszweck nur die jeweils relevante Teilmenge von Attributen in einem Formular zu sehen. Das lässt sich machen:
Verschiedene Formulare für einfaches Arbeiten
Zu jedem Anforderungsstereotyp können Sie eigene Formulare definieren. Auch mehrere Formulare pro Stereotyp sind möglich. In ein eigenes Formular nehmen Sie dann nur die Attribute auf, die für eine bestimmte Zielgruppe oder einen speziellen Bearbeitungsvorgang relevant sind.
Das Tool bietet Ihnen dafür einen integrierten Formulardesigner an. Er bringt auch einen Vorrat an Oberflächenelementen mit. Damit können Sie Formulare erstellen, die sich nahtlos in die Bedienoberfläche des Tools einfügen.
Bild 4: Ein Beispiel für den Entwurf eines reduzierten Anforderungsformulars. Zur Verfügung stehen beim Entwurf alle bis dahin definierten Attributtypen sowie die Beziehungen, die zwischen Anforderungen und anderen Artefakttypen definiert wurden. Sie können sowohl eigene Artefakttypen als auch Beziehungstypen definieren. Hier tun sich viele Möglichkeiten zur individuellen Konfiguration des Tools auf.
Von der Attributierung profitieren – durch Sichten und Abfragen
Aus der Attributierung der Anforderungen können Sie noch auf andere Weise Nutzen ziehen. Nämlich indem Sie den komplexen Informationsumfang von Anforderungen aufgabenorientiert einschränken oder auswerten. Um aus einem speziellen Blickwinkel auf die Menge der Anforderungen und der zugehörigen Informationen zu schauen, bietet Ihnen das Tool zwei Möglichkeiten an:
- programmierte Sichten, die Sie im Detail konfigurieren können,
- (Repository-) Abfragen, die Sie selbst definieren können.
Zu den programmierten Sichten gehören insbesondere Domänen-, Release-, Team-und Sprint-Backlogs, die die Projektplanung auf den unterschiedlichen Planungsniveaus unterstützen. Aber auch Übersichten der Anforderungen mit Aktivitäten oder Revisionen gehören dazu. Welche Attribute Sie in diesen Sichten sehen wollen, in welcher Reihenfolge die Attribute angeordnet und wonach die Sichten sortiert sein sollen, bestimmen Sie nach Bedarf.
Bild 5: Ein Beispiel für programmierte aufgabenorientierte Sichten: Die Planungssicht für die Release-Planung, d.h. zum Übernehmen von Anforderungen aus dem Product Backlog in ein Release Backlog.
Abfragen des Repository können Sie selbst anlegen und für eine Projektaufgabe spezifisch ausprägen. Aber im Tool finden Sie auch zahlreiche vorbereitete Abfragen, die Fragen beantworten wie: “Wo stehen wir im Projekt, d.h. welche Anforderungen befinden sich in welchem Zustand?”, “Welche Reviews von Anforderungen sind für mich persönlich geplant?”, “Zu welchen Anforderungen gibt es welche Testfälle?” etc.
Sie können alle vorbereiteten Abfragen ebenfalls an Ihren Bedarf anpassen. Oder Sie kopieren eine Abfrage und prägen die Kopie spezifisch aus, indem Sie zum Beispiel:
- weitere Attribute spaltenweise anzeigen lassen,
- Attribute, die für Sie nicht interessant sind, aus der Abfrage löschen,
- die Spalten sortieren.
Sie können alle Abfragen “live” filtern und darin direkt editieren.
Bild 6: Ein Beispiel für vorbereitete Abfragen ist die Liste der “Anforderungen mit interessierten Stakeholdern”.
Die gute Nachricht zum Schluss
In der Literatur zum Anforderungsmanagement wird beim Thema Attributierung gern vor dem Aufwand gewarnt, der sich ergibt, wenn man nicht gründlich genug vorgeht und im laufenden Projekt bemerkt, dass ein zusätzliches Attribut benötigt wird. Selbst wenn Sie die Attributierung gut durchdacht und nichts vergessen haben, kann dieser Fall eintreten. Denken Sie zum Beispiel an den Gesetzgeber oder an neue Normen und Standards, die weitere Eigenschaften (ähnlich wie ASIL) fordern.
Hier möchte ich Entwarnung geben. Bei der Arbeit mit objectiF RPM und objectiF RM verliert dieses Szenario an Schrecken.
- Zum Stereotyp Requirement und zu seinen Sub-Stereotypen definieren Sie jederzeit neue Eigenschaften – wie anfangs beschrieben – mit wenigen Klicks.
- Für das Erfassen und Bearbeiten neuer Anforderungen müssen Sie das Standardformular oder Ihr benutzereigenes Formular um eine Eingabemöglichkeit für die Werte des neuen Attributs erweitern. Dazu benötigen Sie auch nur ein paar Minuten.
- Der größte Aufwand fällt beim Nacharbeiten der bereits erfassten Anforderungen an. Das Nacharbeiten lässt sich leider nicht vermeiden. Aber wenn Sie die bereits vorhandene Abfrage Anforderungsliste mit wenigen Klicks um eine Spalte für das neue Attribut erweitern, können Sie anschließend die Attributwerte direkt in dieser Liste editieren. Wenn das Attribut den Typ Aufzählungswert besitzt, geht das besonders schnell (Bild 6 zeigt eine vergleichbare Situation).
Wie leicht handhabbar die Attributierung von Anforderung ist, davon verschaffen Sie sich am besten selbst einmal einen lebendigen Eindruck – mit den Trial-Editionen von objectiF RM und objectiF RPM.
* Während ich diesen Text schreibe, mahnt die Rechtschreibprüfung von MS Word das Wort “Attributierung” ständig als fehlerhaft an. MS Word und auch der Duden meinen, es müsse Attribuierung heißen. Nach den Regeln der Wortbildung stimmt das. Aber Attribuierung ist eben nicht gebräuchlich. Also ignoriere ich den gut gemeinten Rat einfach.
Quellen
[1] Stan Bühne, Andrea Herrmann, Handbuch Requirements Management nach IREB-Standard, abrufbar unter: https://www.ireb.org/content/downloads/16-cpre-advanced-level-requirements-management-handbook/ireb-cpre-handbook-for-requirements-management-advanced-level-de-v1.1.pdf
[2] Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation. Klaus Pohl, Chris Rupp, dpunkt Verlag, 4. Auflage