Diese Prezi Präsentation wurde anlässlich der Vorstellung der Resultate der Agile Trends und Benchmarks 2012 und Requirements Trends und Benchmarks 2012 gehalten. Erfahren Sie Zahlen zu der Verwendung von Scrum oder wo die Unternehmen die grössten Probleme im Requirements Engineering sehen.

1. SwissQ Requirements Trends &
Benchmarks Schweiz 2012
Wo stehen wir – wohin geht es?

2. INHALTSVERZEICHNIS SwissQ Requirements Trends & Benchmarks 2012 2
3 EDITORIAL
4 TRENDWAVE 2012
5 KEY MESSAGES
6 PROJEKTE
7 QUALITÄT
8 AUFWAND
9 REIFEGRAD UND ERFOLGSFAKTOREN
10 ORGANISATION UND AUSBILDUNG
11 AGILES REQUIREMENTS ENGINEERING
12 HERAUSFORDERUNGEN
13 WERKZEUGE
14 ERHEBUNGSGRUNDLAGEN
15 TESTING UND AGILE

3. EDITORIAL SwissQ Requirements Trends & Benchmarks 2012 3
“Die einzige Konstante im Universum ist die Veränderung.”
Schon vor über 2500 Jahren hat Heraklit von Ephesos den Nagel auf den Kopf getroffen. Damit Sie sich einen Überblick über diese
Veränderungen verschaffen können und somit für sich oder Ihre Organisation den Veränderungsprozess gezielt gestalten können, hat SwissQ
den vorliegenden „Requirements Trends & Benchmarks Report“ für Sie erstellt. Die Grundlage für diesen Report bilden über 300 ausgefüllte
Fragebögen aus der IT Community in der Schweiz. Ergänzend wurden mehrere IT-Entscheidungsträger aus unterschiedlichen Firmen, Branchen
und Regionen, in einem persönlichen Interview zu den aktuellen Trends befragt. Aus der Online-Umfrage und den persönlichen Interviews
entstanden ein repräsentativer Überblick zum Stand des Requirements Engineering (RE) in der Schweiz im Jahr 2012 und ein Ausblick auf die
wichtigsten Trends der kommenden Zeit. Lassen Sie sich überraschen, welche interessanten Ergebnisse aufgedeckt wurden.
Auch in der Schweiz werden nach wie vor nur ca. 35 % der Projekte in der Wird diese Priorisierung unterlassen oder nicht in genügendem Umfang
vorgesehenen Zeit und innerhalb vom geplanten Kostenrahmen abgeschlossen. beachtet, führt dies wiederum zu Unzufriedenheit mit dem RE (30 % empfinden
Diese Resultate entsprechen in etwa der internationalen Situation, wie den Reifegrad ihres RE als schwach bis sehr schwach). Hier ist es nun die Aufgabe
beispielsweise im „Chaos-Report“ der Standish Group nachgelesen werden kann. des Requirements Engineers (oder Business Analyst, Product Owner, etc.) mittels
Die Situation hat sich zwar gegenüber früheren Umfragen leicht verbessert, geeigneten Methoden diese Einschätzung der Stakeholder abzuholen.
doch bleibt weiterhin ein erheblicher Teil der Projekte vom Misserfolg bedroht.
Die Gründe dazu sind vielfältig. Ein weiterer Grund für mangelhaftes RE ist der ungeeignete Einsatz von Tools.
Die meisten Befragten (>85 %) verwenden weiterhin Microsoft Office für RE Aufgaben.
Die systematische Analyse der Stakeholder beispielsweise, welche notabene eine Dass dabei die Traceability die grösste Herausforderung darstellt (s. S. 12) ist ver-
zentrale Quelle von Anforderungen sind, scheint für viele Befragte mehr lästiges ständlich. Als Lösungsansatz gewinnen integrierte Tools, sogenannte Application
Übel als Erfolgsfaktor zu sein. Rund 1/3 investieren gar keine Zeit mehr in diese Lifecycle Management Tools, zunehmend an Bedeutung. Mit steigender Komplexi-
Analyse, da die Stakeholder als gesetzt angenommen werden. Daher ist es auch tät und Funktionsumfang einer Applikation wird früher oder später die Toolfrage
nicht erstaunlich, dass fast 70 % mit der Erhebung von Anforderungen nur mittel- zur effizienten Prozessunterstützung des RE noch stärker in den Fokus rücken.
mässig oder gar nicht zufrieden sind. Die Einsicht, dass die Stakeholder-Analyse
wichtig für den Projekterfolg ist, scheint noch nicht überall etabliert zu sein. Wie Heraklit schon bemerkte, bleibt die Welt ständig in Bewegung. Mit der
Als Erfolgsfaktor wird sie erst an fünfter Stelle erwähnt. Somit erscheint es nur (von den Testing Trends & Benchmarks bereits bekannten) SwissQ Trend Wave®
allzu logisch, dass sich ändernde oder wachsende Anforderungen an das System wird aufgezeigt, welche Veränderungen im RE Markt stattfinden. Zusammen mit
von über 75 % der Befragten als ein Grund für ungenügende Anforderungen den anderen Ergebnissen im vorliegenden Report stellen sie einen Wegweiser dar,
angegeben wurden. an dem sich die RE Community im Sturm der Veränderung orientieren kann.
Deshalb wird dieser Report künftig regelmässig erscheinen. In diesem Sinne
Neben der mangelhaften Stakeholder-Analyse ist der fehlende Geschäftswert wünscht Ihnen die SwissQ viele interessante Ausblicke und viel Vergnügen beim Lesen.
von Anforderungen für über 50 % der Befragten ein Problem. Dies ist umso er-
staunlicher, als dass die agilen Methoden in Unternehmen längst Einzug erhalten
haben (75 % der Befragten haben schon Erfahrungen mit agilen Vorgehensweisen
gemacht), denn für agile Projekte ist der Fokus auf den Geschäftswert ein zentrales
Element. Mittlerweile sind erprobte Techniken auf dem Markt – wie zum Beispiel
„Priority Poker“ von SwissQ – mit welchen effizient Anforderungen nach ihrem
Geschäftswert priorisiert werden können.

4. TRENDWAVE 2012 SwissQ Requirements Trends & Benchmarks 2012 4
INTRODUCTION GROWTH MATURITY DECLINE
PRIORITY
RE Prozesse/Rollen RE Pools
IREB CPRE FL Use Case Spezifikation
ALM Tools RE Mgmt Tools
MoSCoW
Sprachschablone
Priorisierung
Requirements Modeling
RE Workshops
Agiles RE
Business Value Reviews
Planguage
IREB CPRE AL
IIBA CBAP
Acceptance Test Driven Development (ATDD)
RE Outsourcing
TIME
INTRODUCTION – Das Thema wurde GROWTH – Das Thema wird immer MATURITY – Die meisten Unternehmen DECLINE – Das Thema wurde von
erkannt und einige Unternehmen mehr anerkannt und viele arbeiten an der Umsetzung oder den meisten Unternehmen, mit
arbeiten an ersten Umsetzungen. Unternehmen gehen darauf ein. haben diese bereits abgeschlossen. Ausnahme einzelner Nachzügler
Es ist allerdings nicht absehbar, ob Es entstehen die ersten Werkzeuge Das Wissen zu dem Thema ist oft bereits umgesetzt. Wissen in diesen
sich dieser Trend positiv weiter- und Beratungsfirmen bieten Dienst- sehr verbreitet, wobei oft auch Bereichen neu aufzubauen generiert
entwickelt und das Requirements leistungen dazu an. Mit der fehlen- Unterarten dazu entstehen. oft keinen Nutzen mehr, da dieses in
Engineering tatsächlich erheblich den Erfahrung bei der Umsetzung Kürze obsolet wird.
beeinflussen wird. gehen oft diverse Risiken einher.

5. KEY MESSAGES SwissQ Requirements Trends & Benchmarks 2012 5
1 Nur 25 % der Befragten sehen ihr
Requirements Engineering im Pro-
jekt als gut oder ausgezeichnet an,
als wichtigste Verbesserungsmass-
nahmen werden Standardisierung
2 Top strategische Ziele 2012 sind
Agile Requirements Engineering
und Business Process Driven
Requirements.
Agilität ist auch hier im Vormarsch.
3 Modellieren der Anforderungen
und Definition von Abnahmekri-
terien werden als die wichtigsten
Erfolgsfaktoren genannt.
der Requirements Prozesse und
Tools genannt.
4 Für knapp die Hälfte der Befragten
hat das Requirements Engineering
eine tiefe Priorität in der Organisati-
on oder wird sogar als notwendiges
Übel betrachtet.
5 Das Berufsbild des Requirements
Engineers / Business Analyst
scheint sich im Markt zu etablie-
ren. Dies ist nicht zuletzt auf die
seit fünf Jahren standardisierte
6 Die Investitionen bei der Zusam-
menarbeit zwischen Business und
IT, der Ausbildung und Standardi-
sierung der Requirements Prozesse
nehmen stark zu, auf Kosten von
Ausbildung durch IREB zurückzu- Outsourcing und Bildung organisa-
führen. torischer Requirements Engineering
Einheiten.
7 Über 36 % prüfen ihre Anforderun-
gen nicht auf ihre Notwendigkeit,
wogegen die Fachlichkeit und
Realisierbarkeit von mehr als 80 %
geprüft werden.
8 Über 2/3 investieren weniger
als einen Tag in die Stakeholder-
analyse. Dies erstaunt, da
die Stakeholderanalyse
ein Erfolgsfaktor ist.
9 Missverständnisse in der Kommu-
nikation und sich stetig ändernde
Anforderungen an das Gesamt-
system sind die meistgenannten
Ursachen bei ungenügenden
Anforderungen.

6. PROJEKTE SwissQ Requirements Trends & Benchmarks 2012 6
Projektart
70 % der Projekte sind Neu-Entwicklungen oder Erweiterungen
bestehender Lösungen.
>50 %
der Befragten beschreibt die Ausgangslage für Projekte als nur
zufriedenstellend oder ungenügend in Bezug auf:
12 %
8% Neu-Entwicklung Aufwandschätzung
Planung
39 % Erweiterung einer
bestehenden Lösung Anforderungs-Definition
10 % Migration Realistische Erwartungen
Einführung Standard-
Software
31 % Betrieb, Support, Wartung,
Re-Design, ...
Projekterfolg
Nur knapp über ein Drittel aller Projekte wird mit der gewünschten
Funktionalität, innerhalb der vereinbarten Zeit und ohne Überschreitung
des geplanten Budgets beendet.
Projektgrösse (in CHF)
40 %
51 %
35.1 %
30 %
40 %
39.2 % 25.1 %
20 %
18.1 % 17.5 %
20 % 10 %
4.1 %
10.8 % 0 %
Projekt in im Rahmen, grosse funktion. Projekt Projekt
Zeit, Budget, über Budget Änderungen, verlängert/neu gestoppt
0 % Funktionalität und/oder Zeit aber Projekt geplant
bis 1 Mio bis 20 Mio über 20 Mio beendet beendet

7. QUALITÄT SwissQ Requirements Trends & Benchmarks 2012 7
Klassische Fehler bei Requirements Prüfkriterien von Anforderungen
Sprachliche Fehler sind und bleiben die am häufigsten genannten
Probleme von Anforderungen. Dass trotz agilen Vorgehensweisen der
In über Über
fehlende Business Value in (zu) vielen Fällen ein Problem ist, erstaunt.
Sprachliche Fehler:
Unverständlichkeit,
17.0 % 57.5 % 25.5 %
80 %
der Fälle werden Anforderungen
36 %
der Befragten prüfen
Missverständlichkeit,
Unquantifizierbarkeit auf fachliche Richtigkeit, Reali- Anforderungen selten oder
sierbarkeit und Vollständigkeit nie auf ihre Notwendigkeit.
Inhaltliche Fehler:
geprüft.
Falsche Sachverhalte, 15.1 % 58.5 % 26.4 %
Unvollständigkeit
Logische Fehler:
Widersprüchlichkeit, 12.0 % 49.1 % 38.9 %
Redundanz
Gründe für ungenügende Anforderungen
Systematische Fehler:
Fehlender Business Value / 5.8 % 46.2 % 48.1 %
Nutzen für das Projekt
Missverständnisse in der Kommunikation 12.3 % 65.1 % 22.6 %
0 % 20 % 40 % 60 % 80 % 100 %
Wachsende oder ändernde
Anforderungen an das Gesamtsystem
20.4 % 56.5 % 23.1 %
Zu abstrakte Formulierungen
(erfordern Detaillierung / Präzisierung) 19.8 % 50.9 % 29.2 %
Neue Erkenntnisse
(Pilotbetrieb, Prototypen, Analysen, etc.)
8.7 % 49.0 % 42.3 %
In über In Änderung von Randbedingungen
50 % 75 %
(Priorisierung, Budgetierung, etc.) 11.1 % 43.5 % 45.4 %
Machbarkeit falsch eingeschätzt 26.7 % 70.5 %
der Projekte ist fehlender der Projekte sind Änderung der Stakeholder-
Zusammensetzung 23.6 % 73.6 %
Business Value immer sprachliche Fehler in
noch ein Problem. Anforderungen ein 0 % 20 % 40 % 60 % 80 % 100 %
Problem.
Immer Oft Selten/nie

8. AUFWAND SwissQ Requirements Trends & Benchmarks 2012 8
Anteil RE Aufwand am Gesamtprojektaufwand Die wichtigsten Quellen von Anforderungen
Der RE Aufwand gemessen am Gesamtprojektaufwand zeigt keine Erwartungsgemäss sind die Auftraggeber und Anwender die wichtigsten
eindeutige Tendenz auf. Je nach Projekt wird von sehr wenig bis sehr Quellen von Anforderungen.
viel in das RE investiert.
25 %
23.5 % Sponsoren/ Auftraggeber
20 % und Anwender
19.6 %
17.6 % 51 % Bestehendes
15 %
15.7 % Produkt / Regulatorien &
14.7 % Software gesetzliche Designer
&
10 % 21 % Bestimmungen
Entwickler
Übrige
14 % 8 %
6 %
6.9 %
5 %
2.0 %
0 %
< 5 % 5- 10 - 15 - 20 - 30 - darüber
Aufwand für Stakeholderanalyse
10 % 15 % 20 % 30 % 50 %
2/3 der Befragten investieren weniger als 1 Tag in die Stakeholderanalyse.
RE-Aufwand im Verhältnis zum Gesamtaufwand
6.3 %
Kein Aufwand da vorgegeben
50 %
37.3 %
Weniger als 1 Personentag
30.9 %
1-5 Personentage
der Befragten verwenden weniger als 15 %
Mehr als 5 Personentage
des Gesamtprojektaufwandes für
Requirements Engineering.
25.5 %

9. REIFEGRAD UND ERFOLGSFAKTOREN SwissQ Requirements Trends & Benchmarks 2012 9
Reifegrad des RE in Projekten Die wichtigsten Erfolgsfaktoren
Nur gerade 1/4 der Befragten beurteilen ihr RE als gut oder ausgezeichnet. Die Modellierung zusammen mit dem Erstellen von Abnahmekriterien gelten
als die wichtigsten Erfolgsfaktoren im RE.
Erstellen von
25.5 % 43.6 % 22.7 % 8.2 % Abnahmekriterien Strukturierte
Reviews
Modellierung
Gut/ausgezeichnet Mittelmässig Schwach Sehr schwach der Anforderungen
Saubere
Stakeholderanalyse Verwendung eines
definierten RE Prozesses
Zufriedenheit Massnahmen zur Qualitätssteigerung
Die Analyse und Erhebung von Anforderungen ist einigermassen Gut ausgebildete Mitarbeiter und Etablierung von Standard Prozessen sind die
zufriedenstellend, dagegen scheinen in der Verwaltung von Anforderungen wichtigsten Massnahmen zur Steigerung der RE Qualität.
die grössten Probleme zu liegen.
Interne Aus- und Weiterbildung 28.2 % 50.9 % 20.9 %
Analysieren 35.5 % 46.4 % 18.2 %
Etablierung Standard RE Prozesse 42.3 % 36.5 % 21.2 %
Etablierung interner Vorlagen und Normen 36.4 % 38.3 % 25.2 %
Erheben 31.2 % 48.6 % 20.2 %
Etablierung von Standard Tools 33.0 % % 34.9 % 32.1 %
Prüfen 22.0 % 50.5 % 27.5 % Gezieltes Einstellen von RE/BA 16.2 % 48.6 % 35.2 %
Definierte Fachlaufbahn für RE/BA 26.2 % 24.3 % 49.5 %
Dokumentieren 30.0 % 38.2 % 31.8 % Systematische Ausbildung nach IREB 11.9 % 29.7 % 58.4 %
Einkauf von externen Spezialisten 25.0 % 69.2 %
Verwalten 17.4 % 36.7 % 45.9 %
Systematische Ausbildung nach IIBA 7.1 % 85.9 %
0 % 20 % 40 % 60 % 80 % 100 % 0 % 20 % 40 % 60 % 80 % 100 %
Zufrieden Mittelmässig Unzufrieden Geplant Umgesetzt Nicht geplant

10. ORGANISATION UND AUSBILDUNG SwissQ Requirements Trends & Benchmarks 2012 10
Wer führt RE durch Ausbildungen
Die Rolle des Requirements Engineers ist bekannt und wird unabhängig Der IREB® CPRE Foundation Level scheint bei den meisten RE/BAs bereits zum
von der Grösse des Unternehmens mit den entsprechenden Aufgaben betreut. Standardrepertoire zu gehören. Der Fokus für die Zukunft liegt im Bereich der
IREB® CPRE Advanced Levels und der Business Analyse sowie dem Agilen RE.
Hab ich schon Ist geplant Mal in ferner Zukunft Kein Thema
Requirements
Engineer Produkt-
63 % 18 % 17 %
manager / IREB® CPRE (Foundation Level)
40 % Product Projekt-
Owner leiter Entwickler
Tester
24 % 20 % 12 % Keine Agiles Requirements Engineering 11 % 19 % 43 % 28 %
4 %
IREB® CPRE (Advanced Level Elicitation & 2 % 27 % 43 % 29 %
Consolidation)
Ansehen des Requirements Engineering
IREB® CPRE (Advanced Level Requirements 21 % 42 % 37 %
Immerhin fast 2/3 der Befragten erkennen den Wert des Requirements Modeling)
Engineerings. Die 17 % welche das RE als notwendiges Übel oder gar
überflüssig ansehen, zeigen hingegen den Entwicklungsbedarf für das Thema auf.
Projektmanagement (IPMA, PMI, ...) 21 % 12 % 23 % 44 %
2.7 %
Certified Product Owner 21 % 6 % 25 % 48 %
14.5 % 8.2 % Für Erfolg der Organisation
strategisch
Wichtiger Faktor für IIBA CBAP (Certified Business Analysis 17 % 31 % 50 %
verlässliche Software Professional)
20.9 % Es hat tiefe Priorität
Certified Scrum Master 18 % 8 % 20 % 53 %
53.7 % Notwendiges Übel
Certified IT Process and Quality Manager 13 % 6 % 17 % 65 %
Überflüssig
0 % 20 % 40 % 60 % 80 % 100 %

11. AGILES REQUIREMENTS ENGINEERING SwissQ Requirements Trends & Benchmarks 2012 11
Einsatz agiler Techniken Trends im agilen Requirements Engineering
Iterative Planung, Daily Standup und Verwaltung eines Backlogs sind Das hohe Tempo der Anpassungen im agilen Umfeld stellt manch gestandenen
weit verbreitete Techniken im agilen Umfeld. Requirements Engineer vor grosse Herausforderungen. Dabei greift es zu kurz,
einfach den Product Owner als Lösung zu propagieren, quasi nach dem Motto
Iterative Planung
„alter Wein in neuen Schläuchen“. Das agile Requirements Engineering muss den
89.6 %
Werten und Vorgehensweisen im agilen Kontext Rechnung tragen.
Daily Standup 82.1 % Dazu gehören beispielsweise Ansätze wie:
Extreme Priorisierung (nach Geschäftswert)
Backlog Management 80.6 %
Fortwährende Planung
Taskboard 75.8 % B
acklog-Management (Wer füllt? Wann wird gefüllt? Wann wird verfeinert?
Retrospektiven
Synchronisation mit strategischen Vorhaben, ...)
72.7 %
TDD und ATTD (Acceptance Test Driven Development)
Burndown Chart 67.2 %
Starke Verwendung von iterativem RE (schnelle Feedbackzyklen und Anpassungen)
Definition of Done 57.8 % Vermehrte Face-to-face Kommunikation
Umfang und Nachhaltigkeit der Anforderungsdokumentation
Velocity Chart 38.1 %
P
assendes Schneiden von Anforderungen (Geschäftswert versus Umsetzung
On-Site Customer 34.8 % innerhalb eines Sprints)
26.6 %
u
sw.
Co-Location
Setzen wir ein
An der Tatsache, dass am Ende eines Projekts der Kunde genau das erhalten will,
Test Driven Dev. (TDD) 20.3 % Ist geplant was er sich vorgestellt hat, hat sich jedoch nichts geändert. Für einen „klassi-
Kanban 15.9 % Nicht mehr schen“ Requirements Engineer sind dies teilweise bekannte Fragestellungen.
kein Thema
Es gilt nun, das klassische Methodenwissen für das agile Umfeld so anzupassen,
Acceptance Test Driven Dev. (ATDD) 11.1 % dass „good practices“ nicht verloren gehen und die Methode trotzdem mit dem
leichtgewichtigen, agilen Ansatz verträglich ist.
0 % 20 % 40 % 60 % 80 % 100 %
Wir von der SwissQ sind gerne bereit, unsere Erfahrungen in verschiedenen agilen
Vorhaben mit Ihnen zu teilen.
3/4
der Befragten haben
2/3
der Befragten haben
„Oft wird ein Feature
fertig entwickelt und
„Der Erfolg eines SCRUM
Projektes hängt von der
dann finden wir keinen Persönlichkeit des Product
schon Erfahrungen mit weniger als 2 Jahre User / Stakeholder dazu!“ Owner ab.“
agilen Vorgehensmethoden Erfahrung in agilen
gemacht. Projekten. Teilprojektleiter Bereichsleiter

12. HERAUSFORDERUNGEN SwissQ Requirements Trends Benchmarks 2012 12
Herausforderungen Wo wird investiert?
Die Traceability (Beziehung von RE Artefakten zu vor- und Ausbildung in die Mitarbeiter wird nach wie vor gross geschrieben. Die engere
nachgelagerten Artefakten) scheint die grösste Herausforderung zu sein. Zusammenarbeit zwischen Business und IT ist das zweite grosse Investitionsthema.
Requirements
Anforderungs- Engineering in
agilen Investitionen Investitionen Investitionen
erhebung in Projekten
verteilten Teams nehmen zu bleiben gleich nehmen ab
30 %
41 % Traceability
Aus- und Weiterbildung für Mitarbeiter 33.0 % 53.8 % 13.2 %
55 %
Engere Zusammenarbeit zwischen 33.0 % 52.8 % 14.2 %
Business und IT
Natürlich- Standardisierung der internen
25.7 % 60.6 % 13.8 %
sprachliche RE Prozesse
Anforderungen
vs. Use Cases
31 % Ausarbeitung / Definition der RE Rolle 24.3 % 59.8 % 15.9 %
Verwaltung
von 500
Anforderungen Entwicklung von Vorlagen und Guidelines 22.4 % 60.7 % 16.8 %
35 %
Anstellung neuer RE-Mitarbeiter 22.1 % 54.8 % 23.1 %
Nicht
funktionale
Etablierung spezifischer RE Tools 21.9 % 63.8 % 14.3 %
Anforderungen
41 % Etablierung eigener RE-Bereiche /
-Abteilungen 17.9 % 62.3 % 19.8 %
Auslagerung von
RE Aktivitäten 11.8 % 48.0 % 40.2 %
0 % 20 % 40 % 60 % 80 % 100 %

13. WERKZEUGE SwissQ Requirements Trends Benchmarks 2012 13
Eingesetzte Tools Eingesetzte Tools im agilen Umfeld
Nach wie vor dominieren die Microsoft Produkte als Tool für Requirements Ähnlich ist die Situation im agilen Umfeld. Dort dominiert ebenfalls Office mit
Engineering, denn mehr als 80 % der Befragten haben Office als das 68 % der Nennungen. Jira steht mit ca. 30 % an zweiter Stelle, dicht gefolgt
wichtigste RE Tools angegeben. Mit grossem Abstand folgt ein ehemaliges von HP QC/ALM und Open Source Tools.
reines Test Management Tool – HP QC/ALM - welches sich zu einer Appli-
cation Lifecycle Suite entwickelt hat, in der auch Anforderungen erfasst,
dokumentiert und verwaltet werden können.
Eigenentwicklung
Microsoft Office Suite Rally Software
85 %
(doc, xls, ppt)
Microsoft Visio 47 % Open Source
Version One
HP QC / ALM 21 %
Open Source 14 % HP QC/ALM Microsoft TFS
Microsoft Office
IBM Rational
13 %
Requisite Pro
IBM Rational DOORS 12 %
Andere 12 % Inflectra Spira
MS Team Foundation
Server
10 %
Polarion
Atlassian Jira
Sparx Enterprise 6 %
Architect
Eigene Entwicklung 4 %
Polarion 3 %
MKS Integrity 3 %
Serena Dimension RM
Wiki
2 %
2 %
68 %
der Befragten verwenden
microTOOL In-Step 2 %
Microsoft Office auch als Requirements
Atlassian JIRA 2 % Tool im agilen RE.
0 % 20 % 40 % 60 % 80 %

14. ERHEBUNGSGRUNDLAGEN SwissQ Requirements Trends Benchmarks 2012 14
Wirtschafts-Sektor Aufgabenbereich
Über 60 % der Befragten arbeiten entweder in der IT-Branche oder im Über 50% der Befragten umschreiben ihre Tätigkeit mit mehr als einer Rolle.
Finanzbereich. Im Vergleich zu den Vorjahren hat sich deren Anteil jedoch
reduziert, was zeigt, dass das Thema auch in anderen Branchen angekom-
men ist.
30 %
IT 36.1 %
Finanzen, Versicherungen 28.4 %
Industrie 7.4 %
20 %
Staatliche und staatsnahe Betriebe 7.4 %
Transport und Verkehr 5.6 %
Telekom 4.0 %
MedTech 3.7 % 10 %
Andere 7.4 %
0 % 10 % 20 % 30 % 40 %
IT-Mitarbeitende 0 %
er ite
r A er ite
r er er er
ag le /B ne st ag ne
Etwas mehr als die Hälfte der Befragten arbeitet in Firmen mit mehr als an m er gi tle Te an gi
M ea ne En ek M En
500 IT-Mitarbeitenden. st /T gi st oj ts e
Te En Te Pr en ar
s- ts m ftw
ng en re So
ilu m q ui
te re Re
Ab ui
2001– ... 33.0 % R eq
501 – 2000 17.6 %
60 % 33 %
251 – 500 13.6 %
51 – 250 15.4 %
11 – 50 14.2 %
der Befragten arbeiten der Befragten haben eine
vor allem im Projektkontext. Linienfunktion inne.
1 – 10 6.2 %
0 % 5 % 10 % 15 % 20 % 25 % 30 % 35 %

15. TRENDS BENCHMARKS REPORTS 2012 FÜR TESTING UND AGILE SwissQ Requirements Trends Benchmarks 2012 15
Neben der vorliegenden ersten Auflage des SwissQ Requirements Trends Benchmarks Reports publiziert SwissQ im 2012 bereits in
der vierten Auflage den SwissQ Testing Trends Benchmarks Report und ebenfalls in der ersten Auflage den SwissQ Agile Trends
Benchmarks Report. Möchten Sie mehr wissen? Sie erhalten die detaillierten Reports mit weiteren Analysen über www.SwissQ.it.
Trends Benchmarks Trends Benchmarks
Testing 2012 Agile 2012
Kosteneinsparungen durch Testautomatisierung Hauptgründe für das Scheitern von agilen Vorgehensmethoden
Fehlende Erfahrung mit agilen
Vorgehensmethoden
52 %
Unternehmensphilosophie nicht mit agilen
Werten verknüpfbar 45 %
33.3 %
Externer Druck einem klassischen
Vorgehensmodell zu folgen 41 %
Fehlende Unterstützung durch das
23.7 % Management 38 %
22.6 %
Fehlende / ungenügende Schulung / Coaching 36 %
Fehlende Verbindung zw. den
Organisationseinheiten 35 %
10.2 %
7.3 % Fehlender Wille des Teams 22 %
2.8 %
Andere 12 %
Kosten bis 10 % bis 20 % bis 50 % bis 80 % Keine
gestiegen Aussage
möglich 0 % 10 % 20 % 30 % 40 % 50 % 60 %

16. ÜBER UNS
SwissQ unterstützt ihre Kunden bei der Entwicklung und Einführung von
IT-Lösungen und stellt sicher, dass die Benutzer die Funktionalität erhalten,
die sie tatsächlich benötigen. Wir erreichen dies durch die eindeutige Erfassung
der Anforderungen und das risikogerechte Testen der Umsetzung.
Unsere Vision ist es, die Wertsteigerung in der IT durch Anforderungsmanagement
und Software Testing zu verbessern. Nebst der Erbringung von hochqualitativen
Services, verfolgen wir diese Vision durch die Schaffung von unabhängigen
Plattformen wie dem Swiss Testing Day und dem Swiss Requirements Day, die
den Wissens- und Erfahrungsaustausch ermöglichen.
Ausserdem helfen wir hellen Köpfen, ihr Wissen durch unsere Schulungen
zu erweitern.
© by SwissQ Consulting AG | Stadthaus-Quai 15 | CH-8001 Zürich
www.SwissQ.it | info@SwissQ.it | Tel +41 43 288 88 40 | Fax +41 43 288 88 39
Twitter: @SwissQ | Facebook: swissqconsulting