Seven Principles Framework

„Keep it simple.“ Frei nach diesem Motto machte sich ein Team der SEVEN PRINCIPLES an die Arbeit, ein Rahmenwerk zu entwickeln, das dem Umgang mit Anforderungen in den Projekten eine klare Struktur gibt.

Sie gründeten eine Fachgruppe und riefen über 20 Experten unterschiedlicher Aufgabenbereiche und Branchen zusammen. Gemeinsam entstand so das 7P-REflex Framework. Dieses Requirements Engineering Rahmenwerk basiert auf den praktischen Erfahrungen der Experten aus der Fachgruppe sowie den Lehrinhalten des IREB. Das Ergebnis der Kombination aus Praxis und Theorie: Mit 7P-REflex kann den Herausforderungen bei der strukturierten Aufnahme von Anforderungen effizient begegnet werden! Bei der Entwicklung des Rahmenwerks ging es nicht um Wiederverwendbarkeit, nicht um UML, nicht um neue Gesetze, nicht um Agilität, Lightweight oder andere – mehr oder weniger große – Hypes. Es ging auch nicht darum, die ganze (Projekt-)Welt zu retten. Es ging um einfache und schnelle Hilfestellung in Projekten, die im Branchenvergleich immer kürzere Projektlaufzeiten haben, zunehmend komplexer werden und bei denen die SEVEN PRINCIPLES und ihre Klienten oft an mehreren dieser Projekte gleichzeitig arbeiten.

7P-REflex fasst die notwendigen Tätigkeiten im Rahmen der Entwicklung von Anforderungen zusammen, bringt diese in eine praktikable Reihenfolge und bietet daneben zahlreiche Hilfestellungen, Checklisten und Dokumentenvorlagen. Das 7P-REflex als iterativer Ansatz umfasst vier Phasen sowie die Querschnittsaktivität „Managen“. Im Folgenden wird das Rahmenwerk beschrieben.

 1. Rahmen

In Phase Eins wird der Rahmen des Projektes innerhalb der drei Aktivitäten ‚Bedarf formulieren‘, ‚Scope ermitteln‘ und ‚Einflussfaktoren analysieren‘ festgelegt. Es werden zunächst Gespräche mit den direkten Projektleitern/Auftraggebern geführt, um den Kundenbedarf und Projektnutzen zu ermitteln. Im zweiten Schritt wird der Arbeitsumfang abgesteckt, bei dem das System und der Systemkontext genau definiert werden. Zum Schluss dieser Phase werden die Kundenvorgaben identifiziert und priorisiert und die Verfügbarkeit der Projektbeteiligten ermittelt. Bei den Projektbeteiligten sind neben kulturellen und sprachlichen Hürden auch zwischenmenschliche Faktoren zu berücksichtigen, da diese Einfluss auf das weitere Vorgehen im Requirements Engineering haben können.

2. Quellen

In der Phase Zwei werden die Quellen von Anforderungen identifiziert, d.h. wer oder was die Anforderungen vorgibt. Hierbei werden mit ‚Stakeholder identifizieren‘ und ‚Anforderungsquellen identifizieren‘ zwei Aktivitäten zur Ermittlung der Anforderungsquellen durchlaufen. Um die relevanten Rollen der Stakeholder einfacher zu ermitteln, bietet das Rahmenwerk eine Reihe von möglichen Leitfragen wie z.B.:

• Wer bezahlt das System?
• Wer spezifiziert das System?
• Wer entwickelt das System?
• Wer nutzt das System?
• Wer wird durch das System tangiert?

Darüber hinaus lassen sich noch mögliche Vertreter von Interessengruppen aus unterschiedlichen Bereichen, wie z.B. aus dem Marketing, dem Management, den Sicherheitsexperten und dem Betriebsrat, identifizieren.

Außerdem sind mögliche weitere Quellen z.B. in Form von schriftlichen Dokumentationen zu einem System, Unternehmensrichtlinien und gesetzliche Vorgaben zu bestimmen. Als Ergebnis werden die Stakeholder und weitere Quellen in einer Stakeholderliste zusammengeführt.

3. Ermitteln

In Phase Drei werden anhand der Aktivitäten ‚Ermittlungstechniken festlegen‘ und ‚Anforderungen ermitteln‘ die Anforderungen identifiziert. Mit Hilfe der Ergebnisse der ersten und zweiten Phase werden geeignete Ermittlungstechniken ausgewählt, festgelegt und durchgeführt, um die Anforderungen exakt und ganzheitlich zu bestimmen.

4. Dokumentieren

In der vierten Phase werden die zuvor ermittelten Anforderungen dokumentiert. Diese Phase wird in die Aktivitäten ‚Kategorien festlegen‘, ‚Dokumentationsrichtlinien festlegen‘, ‚Qualitätskriterien festlegen‘,  ‚Anforderungen spezifizieren und modellieren‘ und ‚Anforderungen prüfen‘ unterteilt. Ziel der Kategorisierung ist eine klare Anforderungsstruktur, die gleichzeitig auch die Grundlage für das Design und Implementierung eines Systems liefert. Mit Anforderungstypen, Priorisierung, Machbarkeit, Aufwand, Release-Zyklen und dem Kano-Modell gibt es verschiedene Ansätze zur Kategorisierung von Anforderungen. Anstatt das Rad neu zu erfinden, greift 7P-REflex hierbei auf bestehende Ansätze in der Literatur zurück.

Dokumentationsrichtlinien legen die Rahmenbedingungen zur Dokumentation von Anforderungen fest. Diese werden an das konkrete Projekt angepasst, um die Grundlage für ein projektspezifisches Handbuch zur Anforderungsdokumentation zu bilden.

Die Definition von inneren und äußeren Qualitätskriterien gewährleistet, dass sowohl für jede einzelne Anforderung, als auch für das gesamte Anforderungsdokument eine klare Struktur, Eindeutigkeit und Konsistenz, Vollständigkeit und die Verfolgbarkeit sichergestellt wird.

Bei der Aktivität ‚Anforderungen spezifizieren und modellieren‘ erfolgt die Dokumentation der Anforderungen gemäß der durchgeführten Kategorisierung, der Dokumentationsrichtlinien und der Qualitätskriterien. Der angewandte Formalitätsgrad kann formal, durch konzeptuelle Modelle wie z.B. die UML, oder informal, durch die natürliche Sprache, erfolgen. In der Praxis zeigt sich, dass eine Mischform aus natürlicher Sprache und formalen Modellen die effizienteste Möglichkeit darstellt.

Mithilfe von Reviews werden bei der Aktivität ‚Anforderungen prüfen‘ Anforderungen und das Anforderungsdokument im Ganzen auf die Einhaltung der inneren und äußeren Qualitätskriterien sowie der Dokumentationsrichtlinien hin geprüft, um als Ergebnis ein hochwertiges Anforderungsdokument zu erhalten.

Managen

Managen wird als eine phasenübergreifende, unterstützende Querschnittsaktivität definiert, die parallel alle vorherigen Phasen begleitet und die Aktivitäten ‚Kommunikation‘, ‚Änderungsmanagement‘, ‚Prozess sicherstellen‘, ‚nächste Phase planen‘ sowie ‚Akzeptanz / RE-Motivation‘ beinhaltet.

Die Kommunikation nimmt beim RE-Vorgehen eine wichtige Rolle ein, da der Requirements Engineer für die Projektbeteiligten als zentraler Ansprechpartner fungiert. So gilt es u.a. aufkommende Konflikte frühzeitig zu erkennen, und mit geeigneten Mitteln zu lösen. Weiterhin sorgt die Erstellung eines Glossars mit den wichtigen projektrelevanten Begriffen/Abkürzungen für Klarheit und fördert somit ein gemeinsames Verständnis.

Beim Änderungsmanagement findet die Prüfung, Annahme, Klassifizierung, Dokumentation, Beurteilung und Abstimmung von geänderten und neu definierten Anforderungen statt. Durch ein eingesetztes Change Control Board kann sichergestellt werden, dass der Änderungsprozess gemäß der Dokumentationsphase eingehalten wird.
Mit einem Monitoring der RE-Phasen wird sicherstellt, dass die definierten RE-Aktivitäten eingehalten werden, um eine kontinuierlich hohe Qualität der Anforderungen zu gewährleisten.

Nach jeder der vorher beschriebenen vier Phasen werden die Ergebnisse gesichtet und zur Planung der nächsten Phase herangezogen, um die folgenden Aktivitäten der nachgelagerten Phase abzustimmen.

Während der gesamten Projektdauer ist eine der wichtigsten Aktivitäten von „Managen“, ein gemeinsames RE-Bewusstsein und Transparenz für das RE-Vorgehen zu schaffen, sowie die Motivation aller Stakeholder im Projekt zu gewährleitsten, um aus „Betroffenen“ Stakeholdern „Beteiligte“ zu machen.

Anforderungsmanagement mit Toolunterstützung

Wie lassen sich Anforderungen konsistent dokumentieren? Welche Abhängigkeiten gibt es zwischen einzelnen Anforderungen und welchen Status haben sie? Finden Sie die Antworten in meinem nächsten Beitrag, der sich der Integration des 7P-REflex in die Projektmanagement-Software in-STEP BLUE von microTOOL widmet.