Definition des RM aus unterschiedlichen Sichten Bevor wir nher in den Vergleich von klas-sischer und agiler Welt einsteigen, definie-ren wir vorab den Begriff Requirements Management (RM) (Anforderungsma-nagement). Hierbei geben wir einen kur-zen Ausblick, wie die Definition nach dem International Requirements Engineering Board (IREB) zu verstehen ist und was wir darunter verstehen.
Definition des RM nach dem IREBIn der weiten Welt des Requirements En-gineering (RE) gibt es eine Vielzahl an Definitionen des RE-Teilbereichs RM, der neben den anderen Teilbereichen Ermit-teln, Dokumentieren, Prfen und Abstimmen steht. Hufig werden die Begriffe Requirements Engineering und
Requirements Management in einen Topf geworfen und jeweils fr den anderen als Synonym verwendet. Die beiden Begrif-fe mssen jedoch abgegrenzt voneinander betrachtet werden (vgl. [Bh15]).Kommen wir nun zur Definition des RM. Dabei bedienen wir uns der Definition des IREB: Das Requirements Management (RM) als Prozess dient dazu, um existieren-de Anforderungen und die mit ihnen ver-bundene Artefakte zu verwalten. Dies bein-haltet die Speicherung, die Vernderungen und die Verfolgung der Anforderungen und der weiteren Artefakte. Darunter fllt unter anderem Anforderungen zu strukturieren, aufzubereiten sowie konsistent zu ndern und umzusetzen. (vgl. [Bh15])
Unsere Definition des RMDas Rahmenwerk der Anforderungsfabrik (vgl. [Anf16]) beinhaltet alle Aktivitten
des RE, wobei wir fnf Aktivittsgruppen unterscheiden:
n Ausrichtenn Einbindenn Ermittelnn Dokumentierenn Managen
Auch fr uns stellt das RM einen essenzi-ellen Bestandteil des RE dar. Es findet sich in unterschiedlichen Aktivitten in unserem Rahmenwerk wieder (siehe Abbildung 1).Die Aktivittsgruppe Managen liegt im Zentrum unseres Rahmenwerks und meint in erster Linie das Steuern der einzelnen RE-Aktivitten. Das zuvor beschriebene RM als solches findet sich hier in unter-schiedlichen Aktivitten wieder:
Requirements Management:Zwischen den Welten
Requirements Management (RM) ist ein wesentlicher Bestandteil des Requirements Engineering (RE). Es sorgt dafr, dass Anforderungen strukturiert dokumentiert und verwaltet werden. In der Vergangenheit wurde dem RM hauptschlich in der traditionellen, phasengetriebenen Welt der IT-Entwicklung Beachtung geschenkt.
Immer mehr Projekte in der IT-Entwicklung werden heute jedoch mit agilen Vorgehensweisen umgesetzt. In diesem Artikel mchten wir einen berblick geben, wie das RM innerhalb der klassischen und der agilen Welt der IT-Entwicklung gelebt wird, und der Frage nachgehen, ob die Umsetzung des RM in beiden Welten
tatschlich so weit auseinanderliegt, wie vielfach behauptet.
Requirements Management: Zwischen den Welten
50
http://www.anforderungsfabrik.de/index.php/dokumente
Gas
tbei
trag
Abb. 1: Das Rahmenwerk zum Vorgehen in der Anforderungsfabrik.
n Auch die Aktivitt Vorgehen sicher-stellen ist ein Bestandteil des RM. Eine gleichbleibende Qualitt hinsichtlich der Prozesskonformitt und der doku-mentierten Anforderungen soll dadurch garantiert werden.
n Das nderungen managen, das zu einer der wichtigsten Sulen des RM zhlt, darf natrlich nicht fehlen.
n Die Aktivitt Kommunikation fr-dern untersttzt das RM, da sie eine wichtige Anlaufstelle in Bezug auf die Anforderungen fr die gesamten Stake-holder darstellt. So stellt diese Aktivitt unter anderem sicher, dass die Stakehol-der in einer strukturierten Form jederzeit Zugriff auf die Anforderungen haben.
In der Aktivittsgruppe Dokumentieren unseres Rahmenwerks finden wir Bestand-teile des RM wieder. Darunter fllt die Ak-tivitt Kategorien, Qualittskriterien und Richtlinien festlegen. Durch diese Aktivi-tt werden zwei Ergebnisse erzielt.
n Zum einem geben wir den Anforde-rungen eine Struktur und ein Attri-butierungsschema, was ein zentraler Bestandteil fr das Verwalten der An-forderungen im weiteren Projektverlauf ist.
n Zum anderen wird dadurch auch ei-nem der wichtigsten Bestandteile des RM eine Basis gegeben: der Nachver-folgbarkeit von Anforderungen. Sie gewhrleistet, dass der gesamte Lebens-weg einer Spezifikation nachvollzogen und ihre Beziehungen zu anderen Ar-tefakten transparent verwaltet werden kann.
RM klassisch oder agil?
RM im klassischen IT-EntwicklungsumfeldIn der Regel wird das klassische RM mit seinen festen sieben Teilbereichen im Rah-men der industriellen, stufenweisen Ferti-gung gelebt und umgesetzt (vgl. [Bh15]):
1. Attributierung und Sichten2. Verfolgbarkeit3. Versionierung und
nderungsmanagement4. Bewertung und Priorisierung5. Variantenmanagement6. Berichtswesen7. Management der Prozesse
Das hat mehrere Grnde. Zum einen haben die Produkte einen in der Regel wesentlich
lngeren Produktlebenszyklus, bei dem es unabdingbar ist, dass eine durchgngige Nachverfolgbarkeit der Anforderungen gegeben ist. Begrndet wird dies z.B. mit gesetzlichen Anforderungen, bei denen eine Verfolgbarkeit der entsprechenden Anfor-derungen und deren Abhngigkeiten zu anderen Artefakten bis hin zum Ursprung der Anforderung gegeben sein muss (z.B. sicherheitsrelevante Bauteile im Auto).Zum anderen werden in der Regel Evoluti-onsstufen oder mehrere Varianten des Pro-dukts entwickelt, die auf den bestehenden Anforderungen basieren. Das RM unter-sttzt dabei den nicht zu unterschtzenden Aspekt der Wieder- und Weiterverwendung von Anforderungen. Das RM tritt im klassischen IT-Entwick-lungsumfeld bereits in der frhen Phase des Produktentstehungsprozesses in Erschei-nung. Grund hierfr ist, dass in der klas-sischen Welt der IT-Entwicklung bereits in den ersten Phasen des Prozesses eine komplett definierte und messbare Anfor-derungsspezifikation vorliegen muss, um so einen reibungslosen bergang in die nchste Phase einleiten zu knnen. (Beispiel bergabe Lastenheft > Pflichtenheft). Daher bedarf es frh eines strukturierten und gleichzeitig koordinierten RMs, um so ein in sich konsistentes, abgestimmtes und qualittsgesichertes Anforderungsdoku-ment zu erhalten. Dies macht noch einmal sehr deutlich, wie wichtig das RM beson-ders in diesem IT-Entwicklungsumfeld ist, damit ein einheitliches, strukturiertes und auch konsistentes Bild der dokumentierten Anforderungen entsteht und vorliegt.Egal wie gut man ermittelt, dokumentiert und alle anderen Aktivitten des RE durch-luft, darf man dabei nicht vergessen: Die nderungen an den Anforderungen wer-den kommen! Hierbei erweist das RM ei-nen groen Dienst, denn es sorgt fr einen strukturierten Ablauf des nderungspro-zesses und mit einer entsprechenden Versio-nierung der Anforderungen hlt auch noch die Transparenz ber nderungen Einzug in den RE-Prozess (Stichwort: Konfigura-tionsmanagement). Halten wir fest: Das RM, so wie es in der klassischen Welt der IT-Entwicklung be-steht, hat definitiv seine Daseinsberechti-gung.
Der Trend: RM im agilen IT-EntwicklungsumfeldWas vor ein paar Jahren bei vielen noch in der Schublade schlummerte, tritt nun seit Anfang des neuen Jahrtausends seinen Sie-
02/2016 51
www.objektspektrum.de
geszug rund um den Globus an: Eine Agi-lisierung der Entwicklungsprozesse weg von dem plangetriebenen, hin zu einem ite-rativ-inkrementellen Produkt-Entstehungs-prozess. Einer der Hauptgrnde fr diese Entwicklung liegt in der Notwendigkeit, immer schneller auf Vernderungen des Marktes reagieren zu mssen. Wo bleibt denn jetzt noch Platz fr das RM? Wenn man genauer hinschaut, so gibt es auch im agilen IT-Entwicklungsumfeld ein RM, jedoch in einer eher minimalistischen und lebhafteren Umsetzung. Zudem kommt das RM nicht verstrkt am Anfang, wie bei klassischen Anstzen, zum Einsatz, sondern erstreckt sich nahezu gleichmig ber den gesamten Entstehungsprozess. So sagt das Agile Manifest der Softwareent-wicklung nicht Nein zum RM, sondern gewichtet die Schwerpunkte anders. Scrum hat sich inzwischen als so genannter Quasi-Standard fr agile Prozesse etabliert. Die Rolle des RM nimmt hierbei zu einem Groteil der Product Owner (PO) ein. Er ist verantwortlich fr die Verwaltung von Anforderungen, den User-Storys.Im Gegensatz zum klassischen IT-Ent-wicklungsumfeld werden Anforderungen im agilen IT-Entwicklungsumfeld nicht in einem Lasten- oder Pflichtenheft, son-dern in einem Product Backlog verwaltet. Das Entscheidende ist, dass auch hier die Aktivitten des RM, wie Bewertung und Priorisierung und auch die Attributierung, Verwendung finden. Innerhalb des Product Backlogs sollte ein Attributierungssche-ma definiert werden. Beispiele hierfr sind Prioritt, ID, Status, Thema (Epic) und Release-Zugehrigkeit. Auch Quellen oder Senken von Anforderungen knnen hier festgehalten werden, um eine Verfolgbar-keit zu untersttzen. Der Verfolgbarkeit wird allerdings nur we-nig Beachtung geschenkt. Nichtsdestotrotz sollte man sich Gedanken darber machen, welche Vorteile eine Nachverfolgbarkeit mit sich bringt. Wie bereits erwhnt, fallen hierunter unter anderem die Weiter- und Wiederverwendung von Anforderungen, was zu einer Kosten- und Zeitersparnis in Nachfolgeprojekten fhren kann. Dies macht sich zum Beispiel dann bemerkbar, wenn zwei Varianten eines Produkts parallel zu einander entwickelt werden. Als Beispiel ist hier die App-Entwicklung zu nennen, wo die zu entwickelnde App fr unterschiedli-che Plattformen, jedoch mit der identischen Funktionalitt entwickelt werden soll. Hier greift der Vorteil der Weiterverwendbarkeit:
