Erfolgreich umgesetzte Requirements sindausschlaggebend für den Unternehmenserfolg.Warum also werden sie nicht effizient verwaltet?Um ihre Entwicklungsprozesse flexibel, transparent und vollständig koordinieren zu können, stellen Anwender an eine effizienteRequirements Management-Lösung bestimmte Anforderungen: Nachvollziehbarkeit von der Anforderung bis zur Auslieferung,zielgerichtete Beantwortung von Kundenanforderungen, zuverlässige Bearbeitung und Umsetzung aller geplanter Anforderun -gen, Wiederverwendung von Anforderungen in Varianten und Produktlinien, kürzere Entwicklungszeiten, nachweisbare Erfüllungvon Regularien. Serena Software stellt mit ihrer sogenannten „Orchestrated ALM Solution“ (O-ALM = orchestriertes Anwendungs -lebenszyklus-Management) eine Lösung zur Verfügung, die diese Anforderungen erfüllt. Neben den gebrauchsfertig gelieferten,vorkonfigurierten Abläufen hat der Kunde aber auch die Flexibilität, seine eigenen Prozesse zu konfigurieren und sogar bereitsvorhandene Werkzeuge in diese Prozesse einzubinden. Das eigentliche Requirements Management wird dabei vom SerenaRequirements Manager (RQM) abgebildet, der durch Hinzunahme weiterer Module bei Bedarf schrittweise bis zur vollen O-ALM-Suite ausgebaut werden kann.

Code-Änderung erscheint, kann plötz-lich mehrere Teams, Projekte undProdukte betreffen. Der Wunsch nachWiederverwendung fügt dabei zusätzli-che Komplexität hinzu. Dies vorab ein-schätzen und erkennen zu können, istZiel der Impact-Analyse.

■ Regularien und StandardsIn vielen Bereichen gelten spezielleRegularien oder Entwicklungsricht -linien, wie V-Modell, DO-178 usw.Solche Vorgaben finden wir speziell inBereichen wie Verteidigung, Auto mo -tive, Banken/Versicherungen oderPharma zie/Medizin.

Liefern, was Kundenwirklich benötigenGute Applikationen entstehen nicht in derEntwicklung und werden dann auf magi-sche Weise verfügbar. Innovation entstehtaus der engen Zusammenarbeit von Ent -

bundener und teilweise ineinandergrei-fender Prozesse. Während Anfor -derungs management und Entwicklungdurchaus agil werden können, kann dieVerbindung mit Tests und derQualitätssicherung häufig linear undeher wasserfallartig bleiben. Einebekannte Beschwerde aus der Quali -täts sicherung lautet: „Ich kann nichttesten, bis meine Zielumgebung fertig-gestellt ist – unabhängig davon, wieschnell mein Entwicklungsteam mireine neue Entwicklungsbasis gibt“.Leider betrachten agile Puristen dieseQualitätssicherungsrealität als Prozess -un flexibilität.

■ ProjektkomplexitätMit wachsendem Produktportfolio undzunehmender Komplexität wird esimmer schwieriger, Kundenanfor derun -gen umzusetzen. Was auf den erstenBlick als einfache Anforderungs- oder

Die HerausforderungenKönnen Sie

■ sicherstellen, dass das neueste Release allegeplanten Anforderungen beinhaltet?

■ feststellen, welche Anforderungen sichbereits in der Umsetzung befinden undggf. wie weit diese schon umgesetztsind?

■ erkennen, welche Anforderungen inwelches Release eingeflossen sind?

■ identifizieren, welche Anforderungen inmehreren Produkten relevant sind?

Unternehmen sehen sich bei der Entwick -lung ihrer Produkte und Applikationen mitverschiedenen Herausforderungen kon-frontiert:

■ Verknüpfte ProzesseTatsächlich ist System- bzw. Software -entwicklung eine Serie miteinander ver-

der au tor

Hans-Joachim Erchinger

(hjerchinger@serena.com)startete nach seinem Mathematikstudium als Entwicklungsingenieur beiMarconi Communications, vormals Bosch Telecom, in den BereichenVorentwicklung und Mobilfunkentwicklung. Seit Oktober 2000 arbeitet er alsSolution Architect bei der Serena Software GmbH. In seiner Tätigkeit beiSerena und auch schon zuvor betreute er eine Vielzahl von Kundenprojektenund sammelte viele Anforderungen und Beispiele für Change- undConfiguration-Management sowie Requirements Management in realenKundensituationen.

1 www.objektspektrum.de

advertorial

wick lung mit Kunden sowie Geschäfts-oder Fachbereichen. Egal, ob die Ent wick -lung agil, traditionell oder hybrid arbeitet,das kontinuierliche Bestreben, höchsteQualität auf Basis von nach Kunden -bedürfnissen priorisierten Anforderungenzu liefern, ist die einzige erfolgreicheStrategie, um Kundenzufriedenheit zuerzielen.

Nach einer Studie der IAG Consultingliefern Unternehmen, die ihre Require -ments effizienter managen, 75 % mehrAnforderungen aus, wickeln Entwicklungs -projekte 161 % schneller ab und reduzie-ren so die Entwicklungskosten um 75 %([IAG09], vgl. Abbildung 1).

Aber wenn gute Anforderungen soerfolgskritisch sind, warum werden siedann vielerorts nur mangelhaft verwaltet?Obwohl Unternehmen seit Jahrzehntenversuchen, Requirements Managementerfolgreich zu etablieren, es scheint nachwie vor nicht zu gelingen:

■ 60 % der Projekte erfüllen die meistenUnternehmensanforderungen nicht(vgl. [Sta09])

■ 90 % der Software-Funktionen werdenfür jedes neue Projekt erneut geschrie-ben (vgl. [Bro06])

■ 33 % der Entwicklungskosten werdendurch schwache Requirements ver-schwendet (vgl. [IAG09])

Offenbar sind genau die Werkzeuge, dieeigentlich zum Management der Require -ments gemacht wurden, der Hinderungs -grund für deren erfolgreiche Umsetzung.Forrester stellt fest, dass häufig zu komple-xe und schwerfällige Requirements Ma -nage ment-Werkzeuge verwendet werden:

„Prozess-Spezialisten und Entwickler las-sen sich bei der Suche nach der bestenRequirements Management-Lösung gernevom Ehrgeiz leiten und versuchen, Systemeeinzuführen, die zu komplex, zu kompli-ziert zu bedienen und zu teuer für ihreneigentlichen Einsatz sind” [SaT07].

Häufig bleibt es bei der Auswahl vonRequirements Management-Werkzeugenbei der bloßen Fokussierung auf „Featuresund Funktionen“ wie Baselining, Versio -nierung, Verlinkbarkeit und Nachverfolg -barkeit. Leider wird dabei meist derGesamtprozess vergessen. Diesen im Augezu behalten, wäre häufig die bessereLösung als sich nur auf „RequirementsManagement“ zu beschränken.

Der Prozess kommtvor den WerkzeugenEgal, ob agil oder traditionell entwickeltwird, Projekte müssen nach einem End-to-End-Prozess durchgeführt werden. Ein sol -cher Gesamtprozess kann an ein wachsen-des Portfolio und zunehmendePro dukt komplexität angepasst werden.Mary Gerush, Forrester, schreibt: „DieDefinition und das Management vonRequirements ist oftmals wie das Wechselnder Reifen bei einem fahrenden Auto. Es istnicht überraschend, dass Unternehmendamit kämpfen, sinnvolle und effiziente

Software-Requirements zu definieren undzu liefern. Um dies erfolgreich bewerkstelli-gen zu können, müssen sie den gesamtenRequirements-Lebenszyklus berücksichti-gen” [Ger10]. Sie bestätigt damit SerenasSicht, dass der Prozess entscheidend ist.

Im Folgenden beschränken wir uns zuerstauf den Teilprozess des Require mentsManagements. Schlüsselüberlegun gen beider Gestaltung dieses Prozesses sind:

1. Wie werden die Anforderungen erar-beitet?

2. Wie werden sie priorisiert?3. Wie werden Anforderungsänderungen

allen davon Betroffenen kommuniziert?4. Wann und wie sollen die umgesetzten

Anforderungen in Produktion gebrachtwerden?

5. Wie wird der Kunde erfolgreich in dieunterschiedlichen Stufen des Gesamt -prozesses eingebunden?

Der Prozess besteht aus fünf Phasen. Diesekönnen sowohl innerhalb eines einzigenSprints wie auch über die gesamte Projekt -laufzeit verteilt sein. Organisationen, wel-che diesen Ablauf erfolgreich automatisie-ren und sowohl Teams als auch Werkzeugeintegrieren, werden die Kundenzufrie -denheit steigern, Rework reduzieren unddamit ihre Entwicklungskosten senken(vgl. Abbildung 2).

1. Capture („Erfassen“): Dies ist diePhase, in der Fehler, Verbesserungenund auch neue Anforderungen vonallen Entwicklern, beliebigen anderenMitarbeitern, Partnern oder Kundeneingebracht werden können. Die Infor -mation kann sowohl online eingebrachtals auch in Workshops, Interviews oderStudien erarbeitet und danach erfasstwerden. Modelle oder visuelle Proto -typen helfen bei der Definition,Priorisierung und Genehmigung derAnforderungen.

2. Collaborate („Zusammenarbeit“): Sinddie Anforderungen erfasst, muss engund intensiv mit den verschiedenenBeteiligten („Stakeholdern”) zusam -

2Online-Themenspecial Requirements Engineering 2012

Online-Themenspecial Requirements Engineering 2012 advertorial

Abb. 1: Fokussierung auf Kundenanforderungen führt zu dramatischenVerbesserungen

Abb. 2: Die fünf Phasen zur Orchestrierung des Requirements-Prozesses

4. Continue („Fortsetzung“): Eine Anfor -derung ist nach ihrer Umsetzung undAuslieferung noch nicht abgeschlossen.Hat die Umsetzung erreicht, was derKunde erwartete? Haben sich Umge -bungsbedingungen geändert, sodassdiese Anforderung hinfällig wurde (dieskann z. B. von Gesetzesänderungenkommen)? Gibt es Änderungen bei derTechnologie, bei Geschäftsprozessenoder im Markt, die Anforderungs -änderungen nach sich ziehen? Und wel-che sind die sich daraus ergebendenFolgeänderungen („Impacts“)?

5. Control („Verwaltung“): Über den ge -samten Requirements-Lebenszyklushinweg muss gewährleistet sein, dassdie unweigerlich auftretenden Ände-rungen beherrschbar bleiben: Allepotenziellen Auswirkungen auf Betei -ligte, Teams, Projekte und Produktemüssen erkannt werden. Je mehrProdukte und Varianten existieren,umso wichtiger wird hier die effizienteUnterstützung auch über Werkzeug -grenzen hinweg, damit Änderungennicht zu einem logarithmischenAlbtraum werden.

Ein Beispiel aus der Praxis unsererKunden:Ein Fortune 500-Unternehmen in den USAhat vor Kurzem begonnen, mithilfe vonSerena ihren Requirements-Prozess überalle Beteiligte, Werkzeuge und Teilprozessezu orchestrieren. Die bisher isoliert arbei-tenden Werkzeuge wurden in diesemProzess zusammengeführt (orchestriert),manuelle Zwischenschritte wurden redu-ziert. Das Unternehmen erwartet da durchbeeindruckende Einsparungen inMillionenhöhe und hat die Zeit bis zurAuslieferung schon um 25 % reduzierenkönnen.

Aber was bedeutet „orchestrieren“?Unter „orchestrieren“ verstehen wir, ver-schiedene unterschiedliche „Spieler“ zueinem homogenen Ganzen, dem „Orches -ter“, zu vereinen. In der IT bedeutet das,verschiedene Werkzeuge so zusammenzu-schalten, dass sie gemeinsam den Gesamt -ablauf abbilden und unterstützen. Wiebeim Orchester heißt dies aber auch, dassjedes einzelne Werkzeug auf diesenGesamtablauf eingerichtet werden muss,um seinen spezifischen Teil übernehmen

lungen) umgesetzt und getestet werden.Um dies korrekt tun zu können, wirddie volle Übersicht über verknüpfteAnforderungen (Funktionen, gesetzli-che Anforderungen, Wartungsanfor -derungen, …), Soft- und Hardware-Konfigurationen, Test-Skripts, usw.benötigt. Es ist daher eminent wichtig,dass auch und gerade Entwickler sichdiese volle Übersicht per Knopfdruckbeschaffen können.Umgekehrt ist es auch von großemNutzen, wenn aus dem RequirementsManagement heraus sofort ersichtlichist, wie weit die Umsetzung der Ent -wicklungsaufgaben bereits gediehen ist.Selbstverständlich ist dazu innerhalbder Entwicklung jede Aufgabe miteinem (wenn auch kleinen) Prozess ver-knüpft.Diese Übergabe an die Entwicklung(abgebildet z. B. durch den SerenaDevelopment Manager, DVM) erfolgtdabei auf denkbar einfache Art: NachFreigabe („Approval“) einer Spezifika -tion wird diese zum Übergabecontainerund die darin befindlichen Require -ments sind sofort im zugeordnetenEntwicklungsprojekt im Konfigura -tions management sichtbar.

men gearbeitet werden, um ggf. dieRequirements zu verfeinern („refine-ment“) oder weiter aufzusplitten(„decomposition“). Dies ist der wich-tigste und kritischste Schritt im Prozess! Ob weitere Verfeinerungen nötig sind,hängt vom Grad der Komplexität derinitialen Anforderung ab. WeitereIndikatoren sind: Auswirkungen derbetreffenden Anforderung auf Ska -lierbar keit, Kompatibilität, Sicherheitoder was sonst noch als wichtig einge-stuft wird.Durch entsprechendes Rechtemanage -ment können verschiedene Stakeholderauf eine einzige Basis von Infor ma -tionen zugreifen – jeder hat dabeijedoch nur die seiner Rolle zugedach-ten Informationen zur Verfügung.Damit können auch Kunden undLieferanten in den Requirements-Prozess nahtlos eingegliedert werden.

3. Confirm („Bestätigung“): Nachdem dieAnforderungen hinreichend überarbei-tet sind, werden sie mit Tests verknüpftsowie an die Entwicklung weitergege-ben. Dort werden dann Entwick lungs -aufgaben mit den Anforderungen ver-knüpft, die von den Entwicklern alsCode-Änderungen (oder Neuerstel -

advertorial

3 www.objektspektrum.de

Abb. 3: Modelle und simulationsfähige Prototypen erleichtern die Diskussion

und geeignet mit den anderen Werkzeugenkommunizieren zu können.

In unserem Beispiel kann so der SerenaRequirements Manager mit verschiedenenKonfigurationsmanagement (KM) -Werk -zeugen, wie Serena PVCS Version Manager,Serena Development Manager (DVM) aberauch Subversion (SVN), zusammenarbei-ten. Auch Lösungen für den Mainframe,wie Serena ChangeMan ZMF, können eingebunden werden und erlauben dieAnwen dung gleicher Änderungs- undEntwick lungsprozesse für Host- und Distri -buted-Entwicklung. Eine weitere wichtigeSchnittstelle für die Orchestrierung desGesamtprozesses ist die zum Testmanage -ment, z. B. mit HP Quality Center.

Strategien zur Orchestrierungdes Requirements-ProzessesDie Orchestrierung des Requirements-Pro -zesses fällt natürlich nicht vom Himmel. Esgibt aber einige Erfolgsfaktoren, die helfen,schneller zu einem erfolgreichen Require -ments-Prozess zu gelangen:

1. Prozesszentrierung mit Flexibilität: Zu -allererst muss der vorhandene odergewünschte End-to-End-Prozess be -trach tet werden: Wie werden Anfor -derungen aufgenommen, umgesetzt,verwaltet und validiert? WelcheSchritte werden benötigt, um mit allenwesentlichen Beteiligten zu arbeiten,Anforderungen zu priorisieren, kriti-sche zu identifizieren und dann mög-lichst schnell und reibungsfrei in dieProduktion zu gehen?Ein grundsätzlich Erfolg versprechen-der Ansatz ist, den Prozess der Über-prüfungen, Genehmigungen und Noti -fi kationen zu automatisieren und zustraffen, damit alle stets auf dem neue-sten Stand sind. Im Idealfall wird dieKommunikation mit dem Kunden bzw.zukünftigen Nutzer hier einbezogen.

2. Einbinden verschiedener Werkzeuge: Jegrößer die Organisation, umso wahr-scheinlicher ist, dass verschiedeneTeams unterschiedliche Werkzeuge undTechniken zur Bewältigung ihrer Auf -gaben nutzen. Kommen noch Kundenund Partner hinzu, entsteht schnell einwildes Sammelsurium unterschiedlich-ster Werkzeuge.Die Strategie der Orchestrierung musssein, diese Werkzeuge und Technikenwie einzelne Steinchen auf intelligente

Weise zu einem Mosaik zusammenzuset-zen und so den Gesamtprozess über dieverschiedenen Werkzeuge sicherzustel-len. Werkzeuge, die nicht effizient zumProzess beitragen, müssen identifiziertund eliminiert oder ersetzt werden.

3. Änderungsmanagement: Der griechi-sche Philosoph Heraklit hätte überKundenanforderungen reden können,als er sagte „Das einzig Beständige istder Wandel“. Um erfolgreich mit sol-chen Änderungen umgehen zu können,müssen diese erkannt, verstanden undihre Auswirkungen auf Projekte, Kun -den, Anwendungen und Werkzeugeabschätzbar werden.

4. Wiederverwendung von Anforderun -gen: Organisationen müssen entschei-den, ob eine Wiederverwendungs stra -tegie für Anforderungen für sie passt. Jegrößer die Organisation ist, je mehrProjekte vorhanden sind und je mehrTeams in den Entwicklungsprozessinvolviert sind, umso mehr Sinn machtdie Wiederverwendung von Require -ments.Wiederverwendung ist aber mehr, alsnur in einem zentralen Repository zusuchen: Es muss festgelegt werden, inwelcher Weise die gemeinsame Nut -zung stattfindet, wie der Änderungs-prozess abläuft und wie die Kom -munikation bezüglich gemeinsamgenutzter Requirements zwischen denbetroffenen Beteiligten aussieht.

5. Nachverfolgbarkeit: Besonders imregulierten Umfeld arbeitende Unter -nehmen (z. B. Luft- und Raum fahrt -technik, Automobil, Verteidigung,Pharmazie) müssen Nachverfolgbarkeitund Auditierbarkeit von Anfor derun -gen gewährleisten, aber alle Organi -sationen müssen sicherstellen, dass ihreReleases den Kundenanforderungengenügen. Auch in nicht-reguliertenIndustrien drohen schnell mehrstelligeMillionenstrafen bei Verzug durchNichterfüllung von wichtigen Anfor -derungen.

6. Nur das Nötige: Alle arbeiten unter-schiedlich. Es kann also keineUniversallösung für alle Requirements-Prozesse geben. Organisationen solltenden „das Nötige-Prozess“ identifizierenund dabei auf die Straffung vonAbläufen, Verwendung von bewährtenPraktiken und den Einsatz derWerkzeuge achten, damit genau diebenötigte Funktionalität erreicht wird.

Von den Mitarbeitern akzeptierte Werk -zeuge und Prozesse sollen durch Orches -trationen in den Gesamtprozess eingebun-den und nicht ersetzt werden.

Bei wachsendem Reifegrad des Unter -neh mens verändert sich diese Lösung. Esmuss daher möglich sein, auch denRequirements-Prozess entsprechend anzu-passen und auszubauen.

Prozesse überwachen undmessenWerkzeugunterstützte und automatisierteProzesse dienen dazu, die beteiligten Mit -arbeiter zu führen und zu unterstützen, umsie so von Routinearbeiten zu entlasten.Die Fokussierung auf ihre eigentlicheArbeit kann jedoch nur gelingen, wenn dieimplementierten Prozesse bestmöglichdafür maßgeschneidert sind.

Mithilfe von Metriken lassen sich vieleFragen schnell und jederzeit aktuell beant-worten:

■ In welcher Phase befindet sich meinProjekt?

■ Sind wir noch im Zeitplan?■ Wie viele Änderungen mussten wir

bearbeiten?■ Wie steht es um die Qualität des

Projektes – wie viele Fehler sind nochzu korrigieren?

■ Welche unserer Projekte laufen Gefahr,in Verzug zu geraten?

■ An wie vielen Projekten arbeiten wirgerade?

■ Wie oft werden Anforderungen geän-dert?

Darüber hinaus können über Prozess -metriken auch Ablaufengpässe erkannt undbehoben werden:

■ Welcher Prozessschritt dauert im Mittelbesonders lange?

■ Welcher Prozessschritt bleibt im Mittelbesonders lange liegen, bevor er durch-geführt wird?

■ Welcher Prozessschritt wird typischer-weise übersprungen?

■ Gibt es eine Häufung von Aufgaben beibestimmten Teams (Überlastung -> per-sonelle Aufstockung nötig)?

■ Gibt es in einer bestimmten Phasebesonders viele Änderungen undWiederholungen?

4Online-Themenspecial Requirements Engineering 2012

Online-Themenspecial Requirements Engineering 2012 advertorial

3. Modularität: Jedes der Module kannfür sich allein verwendet werden. BeiBedarf können über entsprechendeOrches trier ung Funktionalitäten ande-rer Werkzeuge auch von Fremdan -bietern benutzt werden.

4. Erweiterbarkeit: Werden weitere Mo -dule der Serena ALM-Suite hinzuge-nommen, wird dies automatisch er -kannt und verfügbar gemacht („Plugand Play“-Prinzip).

5. Tailoring: Um die spezifischen Ge -geben heiten einer Organisation abzu-bilden, können die gebrauchsfertig ge -lieferten Prozesse und Modelle durcheinfache Konfiguration kundenspezi-fisch erweitert und angepasst werden.

6. Integrationen: Serena-Lösungen kön-nen mit der zugrundeliegenden Prozess -technologie sehr gut in existierende„Werkzeug-Landschaften“ eingebun-den (kein Herausreißen und Ersetzen(„Rip and Replace“)) und daher sehrgut schrittweise im laufenden Pro -jektgeschäft implementiert werden.

7. Administration: Alle Module haben ein-fach zu bedienende Web-Clients –Installationen und Rollouts entfallendamit. Wo es aus Performance-Grün denSinn macht, sind auch Thick Clients fürverschiedene Betriebs syste me vorhanden.

FazitDer Serena Requirements Manager bietetUnternehmen einen innovativen Weg, ihrenEntwicklungsprozess so zu orchestrieren,dass sie die Kundenzufriedenheit steigernund selbst so effizient wie möglich arbeitenkönnen. Unternehmen, die Serenas umfas-sendes ALM-Funktionsportfolio nutzen,erzielen signifikant bessere Ergebnisse –zufriedenere Kunden, größere Transparenz,erhöhte Wiederverwendbarkeit vonRequire ments und Code sowie vollständigeAuditierbarkeit. ■

Serena Software bietet mit ihrer„Orchestrated ALM“-Lösung eine Suite,deren Module diese Teilprozesse optimalaufeinander abgestimmt abbilden. DieFundamente dieser ALM-Lösung sind:

1. ALM-Prozess: Abbildung der Teil pro -zesse ohne den End-to-End-Prozess ausden Augen zu verlieren.

2. Akzeptanz: Jeder Prozessbeteiligtebekommt abhängig von seiner Rollegenau die Sicht, die er zur Erledigungseiner Aufgabe benötigt. Bei Bedarfkann er aber auf weitere Informationenzugreifen.

Solche Metriken erstrecken sich durchausüber mehrere der Phasen des Gesamt -prozesses (vgl. Abbildung 4).

Requirements Management imALM-GesamtkontextDer Requirements-Prozess ist ein Teil desgesamten Application Lifecycle (ALM)-Prozesses. Er steht in Beziehung zu ver-schiedenen anderen Teilprozessen, wieRelease-Management, Testmanagement,Konfigurationsmanagement, Change-Ma -nage ment, Issue- und Defect-Managementund natürlich auch zum Projekt -management.

advertorial

5 www.objektspektrum.de

Abb. 4: Metriken ermöglichen einen schnellen Überblick

Abb. 5: Die Serena ALM-Lösung im Überblick

Referenzen

[IAG09] IAG Consulting, „Business Analysis

Benchmark”, 2009.

[Sta09] Standish Group, „Chaos Summary”,

2009.

[Bro06] Manfred Broy, „Challenges in Auto -

motive Software Engineering”, 2006.

[SaT07] Carey Schwaber and Peter Sterpe,

„Selecting The Right Requirements Manage ment

Tool – Or Maybe None Whatsoever”, 2007.

[Ger10] Mary Gerush, „Right Tools. Write

Requirements. Right On!” 2010.