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

SwissQ Requirements Trends & Benchmarks 2012 2INHALTSVERZEICHNIS

3

4

5

6

7

8

9

10

11

12

13

14

15

EDITORIAL

TRENDWAVE 2012

KEY MESSAGES

PROJEKTE

QUALITÄT

AUFWAND

REIFEGRAD UND ERFOLGSFAKTOREN

ORGANISATION UND AUSBILDUNG

AGILES REQUIREMENTS ENGINEERING

HERAUSFORDERUNGEN

WERKZEUGE

ERHEBUNGSGRUNDLAGEN

TESTING UND AGILE

Wird diese Priorisierung unterlassen oder nicht in genügendem Umfang beachtet, führt dies wiederum zu Unzufriedenheit mit dem RE (30 % empfinden den Reifegrad ihres RE als schwach bis sehr schwach). Hier ist es nun die Aufgabe des Requirements Engineers (oder Business Analyst, Product Owner, etc.) mittels geeigneten Methoden diese Einschätzung der Stakeholder abzuholen.

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. Dass dabei die Traceability die grösste Herausforderung darstellt (s. S. 12) ist ver-ständlich. Als Lösungsansatz gewinnen integrierte Tools, sogenannte Application Lifecycle Management Tools, zunehmend an Bedeutung. Mit steigender Komplexi-tät und Funktionsumfang einer Applikation wird früher oder später die Toolfrage zur effizienten Prozessunterstützung des RE noch stärker in den Fokus rücken.

Wie Heraklit schon bemerkte, bleibt die Welt ständig in Bewegung. Mit der (von den Testing Trends & Benchmarks bereits bekannten) SwissQ Trend Wave® wird aufgezeigt, welche Veränderungen im RE Markt stattfinden. Zusammen mit den anderen Ergebnissen im vorliegenden Report stellen sie einen Wegweiser dar, 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 wünscht Ihnen die SwissQ viele interessante Ausblicke und viel Vergnügen beim Lesen.

“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.

SwissQ Requirements Trends & Benchmarks 2012 3EDITORIAL

Auch in der Schweiz werden nach wie vor nur ca. 35 % der Projekte in der vorgesehenen Zeit und innerhalb vom geplanten Kostenrahmen abgeschlossen. Diese Resultate entsprechen in etwa der internationalen Situation, wie beispielsweise im „Chaos-Report“ der Standish Group nachgelesen werden kann. Die Situation hat sich zwar gegenüber früheren Umfragen leicht verbessert, doch bleibt weiterhin ein erheblicher Teil der Projekte vom Misserfolg bedroht. Die Gründe dazu sind vielfältig.

Die systematische Analyse der Stakeholder beispielsweise, welche notabene eine zentrale Quelle von Anforderungen sind, scheint für viele Befragte mehr lästiges Übel als Erfolgsfaktor zu sein. Rund 1/3 investieren gar keine Zeit mehr in diese Analyse, da die Stakeholder als gesetzt angenommen werden. Daher ist es auch nicht erstaunlich, dass fast 70 % mit der Erhebung von Anforderungen nur mittel-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. Als Erfolgsfaktor wird sie erst an fünfter Stelle erwähnt. Somit erscheint es nur allzu logisch, dass sich ändernde oder wachsende Anforderungen an das System von über 75 % der Befragten als ein Grund für ungenügende Anforderungen angegeben wurden.

Neben der mangelhaften Stakeholder-Analyse ist der fehlende Geschäftswert 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.

SwissQ Requirements Trends & Benchmarks 2012 4TRENDWAVE 2012

INTRODUCTION – Das Thema wurde erkannt und einige Unternehmen arbeiten an ersten Umsetzungen. Es ist allerdings nicht absehbar, ob sich dieser Trend positiv weiter-entwickelt und das Requirements Engineering tatsächlich erheblich beeinflussen wird.

GROWTH – Das Thema wird immer mehr anerkannt und viele Unternehmen gehen darauf ein. Es entstehen die ersten Werkzeuge und Beratungsfirmen bieten Dienst-leistungen dazu an. Mit der fehlen-den Erfahrung bei der Umsetzung gehen oft diverse Risiken einher.

MATURITY – Die meisten Unternehmen arbeiten an der Umsetzung oder haben diese bereits abgeschlossen.Das Wissen zu dem Thema ist oft sehr verbreitet, wobei oft auch Unterarten dazu entstehen.

DECLINE – Das Thema wurde von den meisten Unternehmen, mit Ausnahme einzelner Nachzügler bereits umgesetzt. Wissen in diesen Bereichen neu aufzubauen generiert oft keinen Nutzen mehr, da dieses in Kürze obsolet wird.

INTRODUCTION GROWTH MATURITY DECLINE

TIME

PRIO

RITY

Requirements Modeling

RE Prozesse/Rollen

ALM Tools

RE Outsourcing Acceptance Test Driven Development (ATDD)

IIBA CBAP

IREB CPRE AL

Planguage

Business Value

Agiles RE

Sprachschablone

IREB CPRE FL

RE PoolsUse Case Spezifikation

RE Mgmt Tools

MoSCoW Priorisierung

RE Workshops

Reviews

4 5 6Fü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.

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 Ausbildung durch IREB zurückzu-führen.

Die Investitionen bei der Zusam-menarbeit zwischen Business und IT, der Ausbildung und Standardi-sierung der Requirements Prozesse nehmen stark zu, auf Kosten von Outsourcing und Bildung organisa-torischer Requirements Engineering Einheiten.

7 8 9Über 36 % prüfen ihre Anforderun-gen nicht auf ihre Notwendigkeit, wogegen die Fachlichkeit und Realisierbarkeit von mehr als 80 % geprüft werden.

Über 2/3 investieren weniger als einen Tag in die Stakeholder-analyse. Dies erstaunt, da die Stakeholderanalyse ein Erfolgsfaktor ist.

Missverständnisse in der Kommu-nikation und sich stetig ändernde Anforderungen an das Gesamt-system sind die meistgenannten Ursachen bei ungenügenden Anforderungen.

2 31 Nur 25 % der Befragten sehen ihr Requirements Engineering im Pro-jekt als gut oder ausgezeichnet an, als wichtigste Verbesserungsmass-nahmen werden Standardisierung der Requirements Prozesse und Tools genannt.

Top strategische Ziele 2012 sind Agile Requirements Engineering und Business Process Driven Requirements. Agilität ist auch hier im Vormarsch.

Modellieren der Anforderungen und Definition von Abnahmekri-terien werden als die wichtigsten Erfolgsfaktoren genannt.

SwissQ Requirements Trends & Benchmarks 2012 5KEY MESSAGES

Projektart70 % der Projekte sind Neu-Entwicklungen oder Erweiterungen bestehender Lösungen.

ProjekterfolgNur knapp über ein Drittel aller Projekte wird mit der gewünschten Funktionalität, innerhalb der vereinbarten Zeit und ohne Überschreitung des geplanten Budgets beendet.

SwissQ Requirements Trends & Benchmarks 2012 6PROJEKTE

der Befragten beschreibt die Ausgangslage für Projekte als nur zufriedenstellend oder ungenügend in Bezug auf:

>50 % Aufwandschätzung Planung Anforderungs-Definition Realistische Erwartungen

12 %

39 %

31 %

10 %

8 % Neu-Entwicklung

Erweiterung einer bestehenden Lösung

Migration

Einführung Standard- Software

Betrieb, Support, Wartung, Re-Design, ...

Projektgrösse (in CHF)

bis 1 Mio0 %

20 %

40 %

über 20 Miobis 20 Mio

51 %

39.2 %

10.8 %Projekt

gestopptProjekt

verlängert/neu geplant

im Rahmen, über Budget und/oder Zeit

grosse funktion. Änderungen, aber Projekt

beendet

Projekt in Zeit, Budget,

Funktionalität beendet

0 %

10 %

20 %

30 %

40 %

35.1 %

17.5 %18.1 %

25.1 %

4.1 %

Klassische Fehler bei RequirementsSprachliche Fehler sind und bleiben die am häufigsten genannten Probleme von Anforderungen. Dass trotz agilen Vorgehensweisen der fehlende Business Value in (zu) vielen Fällen ein Problem ist, erstaunt.

Prüfkriterien von Anforderungen

Gründe für ungenügende Anforderungen

SwissQ Requirements Trends & Benchmarks 2012 7QUALITÄT

der Projekte ist fehlender Business Value immer noch ein Problem.

der Fälle werden Anforderungen auf fachliche Richtigkeit, Reali-sierbarkeit und Vollständigkeit geprüft.

In über

In über

50 %

80 %der Befragten prüfen Anforderungen selten oder nie auf ihre Notwendigkeit.

Über

der Projekte sind sprachliche Fehler in Anforderungen ein Problem.

In

75 %

36 %

0 % 20 % 60 %40 % 80 % 100 %

Systematische Fehler:Fehlender Business Value /

Nutzen für das Projekt

Logische Fehler:Widersprüchlichkeit,

Redundanz

Inhaltliche Fehler: Falsche Sachverhalte,

Unvollständigkeit

Sprachliche Fehler: Unverständlichkeit,

Missverständlichkeit, Unquantifizierbarkeit

25.5 %57.5 %

58.5 % 26.4 %

49.1 % 38.9 %

48.1 %46.2 %

17.0 %

15.1 %

12.0 %

5.8 %

0 % 20 % 60 %40 % 80 % 100 %

Missverständnisse in der Kommunikation

Wachsende oder ändernde Anforderungen an das Gesamtsystem

Zu abstrakte Formulierungen (erfordern Detaillierung / Präzisierung)

Neue Erkenntnisse (Pilotbetrieb, Prototypen, Analysen, etc.)

Änderung von Randbedingungen (Priorisierung, Budgetierung, etc.)

Machbarkeit falsch eingeschätzt

Änderung der Stakeholder- Zusammensetzung

65.1 %

56.5 %

22.6 %

23.1 %

29.2 %50.9 %

42.3 %49.0 %

45.4 %43.5 %

12.3 %

20.4 %

19.8 %

8.7 %

11.1 %

70.5 %26.7 %

73.6 %23.6 %

Immer Oft Selten/nie

Die wichtigsten Quellen von AnforderungenErwartungsgemäss sind die Auftraggeber und Anwender die wichtigsten Quellen von Anforderungen.

der Befragten verwenden weniger als 15 % des Gesamtprojektaufwandes für Requirements Engineering.

50 %

SwissQ Requirements Trends & Benchmarks 2012 8

Anteil RE Aufwand am GesamtprojektaufwandDer RE Aufwand gemessen am Gesamtprojektaufwand zeigt keine eindeutige Tendenz auf. Je nach Projekt wird von sehr wenig bis sehr viel in das RE investiert.

Aufwand für Stakeholderanalyse2/3 der Befragten investieren weniger als 1 Tag in die Stakeholderanalyse.

AUFWAND

0 %5 - 10 %

15 - 20 %

10 - 15 %

20 - 30 %

30 - 50 %

darüber< 5 %

10 %

5 %

25 %

15 %

20 %

17.6 %

19.6 %

15.7 %

23.5 %

14.7 %

6.9 %

2.0 %

Sponsoren/ Auftraggeber und Anwender

51 % Bestehendes Produkt / Software

21 %

Regulatorien & gesetzliche

Bestimmungen

14 %

Designer &

Entwickler

8 %

Übrige

6 %

6.3 %

37.3 %

30.9 %

25.5 %

Kein Aufwand da vorgegeben

1-5 Personentage

Weniger als 1 Personentag

Mehr als 5 Personentage

RE-Aufwand im Verhältnis zum Gesamtaufwand

SwissQ Requirements Trends & Benchmarks 2012 9

ZufriedenheitDie Analyse und Erhebung von Anforderungen ist einigermassen zufriedenstellend, dagegen scheinen in der Verwaltung von Anforderungen die grössten Probleme zu liegen.

Massnahmen zur QualitätssteigerungGut ausgebildete Mitarbeiter und Etablierung von Standard Prozessen sind die wichtigsten Massnahmen zur Steigerung der RE Qualität.

Reifegrad des RE in ProjektenNur gerade 1/4 der Befragten beurteilen ihr RE als gut oder ausgezeichnet.

Die wichtigsten ErfolgsfaktorenDie Modellierung zusammen mit dem Erstellen von Abnahmekriterien gelten als die wichtigsten Erfolgsfaktoren im RE.

REIFEGRAD UND ERFOLGSFAKTOREN

22.7 % 8.2 %43.6 %25.5 %

Gut/ausgezeichnet Mittelmässig Schwach Sehr schwach

Geplant Umgesetzt Nicht geplantZufrieden Mittelmässig Unzufrieden

Erstellen von Abnahmekriterien

Modellierung der Anforderungen

Saubere Stakeholderanalyse Verwendung eines

definierten RE Prozesses

Strukturierte Reviews

Interne Aus- und Weiterbildung

Etablierung Standard RE Prozesse

Etablierung interner Vorlagen und Normen

Etablierung von Standard Tools

Gezieltes Einstellen von RE/BA

Definierte Fachlaufbahn für RE/BA

Systematische Ausbildung nach IREB

Einkauf von externen Spezialisten

Systematische Ausbildung nach IIBA

0 % 20 % 60 %40 % 80 % 100 %

20.9 %50.9 %28.2 %

21.2 %36.5 %42.3 %

25.2 %38.3 %36.4 %

32.1 %34.9 %33.0 % %

35.2 %48.6 %16.2 %

58.4 %29.7 %11.9 %

69.2 %25.0 %

85.9 %7.1 %

49.5 %24.3 %26.2 %

Verwalten

Dokumentieren

Prüfen

Erheben

Analysieren

0 % 20 % 60 %40 % 80 % 100 %

18.2 %46.4 %35.5 %

20.2 %48.6 %31.2 %

27.5 %50.5 %22.0 %

45.9 %36.7 %17.4 %

31.8 %38.2 %30.0 %

AusbildungenDer IREB® CPRE Foundation Level scheint bei den meisten RE/BAs bereits zum 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.

SwissQ Requirements Trends & Benchmarks 2012 10

Wer führt RE durchDie Rolle des Requirements Engineers ist bekannt und wird unabhängig von der Grösse des Unternehmens mit den entsprechenden Aufgaben betreut.

Ansehen des Requirements EngineeringImmerhin fast 2/3 der Befragten erkennen den Wert des Requirements Engineerings. Die 17 % welche das RE als notwendiges Übel oder gar überflüssig ansehen, zeigen hingegen den Entwicklungsbedarf für das Thema auf.

ORGANISATION UND AUSBILDUNG

Hab ich schon Ist geplant Kein ThemaMal in ferner Zukunft

IREB® CPRE (Foundation Level)

Agiles Requirements Engineering

Projektmanagement (IPMA, PMI, ...)

Certified Product Owner

Certified Scrum Master

Certified IT Process and Quality Manager

IREB® CPRE (Advanced Level Elicitation & Consolidation)

IREB® CPRE (Advanced Level Requirements Modeling)

IIBA CBAP (Certified Business Analysis Professional)

0 % 20 % 60 %40 % 80 % 100 %

18 % 17 %63 %

43 % 28 %19 %11 %

43 % 29 %27 %2 %

23 % 44 %12 %21 %

25 % 48 %6 %21 %

20 % 53 %8 %18 %

17 % 65 %6 %13 %

31 % 50 %17 %

42 % 37 %21 %

RequirementsEngineer

40 %Produkt-manager /Product Owner24 %

Projekt-leiter20 %

EntwicklerTester12 % Keine

4 %

Für Erfolg der Organisation strategisch

Wichtiger Faktor für verlässliche Software

Es hat tiefe Priorität

Notwendiges Übel

Überflüssig

2.7 %

8.2 %14.5 %

20.9 %

53.7 %

der Befragten haben schon Erfahrungen mit agilen Vorgehensmethoden gemacht.

der Befragten haben weniger als 2 Jahre Erfahrung in agilen Projekten.

3/4 2/3

SwissQ Requirements Trends & Benchmarks 2012 11

Trends im agilen Requirements EngineeringDas hohe Tempo der Anpassungen im agilen Umfeld stellt manch gestandenen Requirements Engineer vor grosse Herausforderungen. Dabei greift es zu kurz, einfach den Product Owner als Lösung zu propagieren, quasi nach dem Motto „alter Wein in neuen Schläuchen“. Das agile Requirements Engineering muss den Werten und Vorgehensweisen im agilen Kontext Rechnung tragen. Dazu gehören beispielsweise Ansätze wie:

Extreme Priorisierung (nach Geschäftswert)

Fortwährende Planung

Backlog-Management (Wer füllt? Wann wird gefüllt? Wann wird verfeinert? Synchronisation mit strategischen Vorhaben, ...)

TDD und ATTD (Acceptance Test Driven Development)

Starke Verwendung von iterativem RE (schnelle Feedbackzyklen und Anpassungen)

Vermehrte Face-to-face Kommunikation

Umfang und Nachhaltigkeit der Anforderungsdokumentation

Passendes Schneiden von Anforderungen (Geschäftswert versus Umsetzung innerhalb eines Sprints)

usw.

An der Tatsache, dass am Ende eines Projekts der Kunde genau das erhalten will, was er sich vorgestellt hat, hat sich jedoch nichts geändert. Für einen „klassi-schen“ Requirements Engineer sind dies teilweise bekannte Fragestellungen. Es gilt nun, das klassische Methodenwissen für das agile Umfeld so anzupassen, dass „good practices“ nicht verloren gehen und die Methode trotzdem mit dem leichtgewichtigen, agilen Ansatz verträglich ist.

Wir von der SwissQ sind gerne bereit, unsere Erfahrungen in verschiedenen agilen Vorhaben mit Ihnen zu teilen.

Einsatz agiler TechnikenIterative Planung, Daily Standup und Verwaltung eines Backlogs sind weit verbreitete Techniken im agilen Umfeld.

Teilprojektleiter Bereichsleiter

„Oft wird ein Feature fertig entwickelt und dann finden wir keinen User / Stakeholder dazu!“

„Der Erfolg eines SCRUM Projektes hängt von der Persönlichkeit des Product Owner ab.“

AGILES REQUIREMENTS ENGINEERING

Iterative Planung

Daily Standup

Backlog Management

Taskboard

Retrospektiven

Burndown Chart

Definition of Done

Velocity Chart

On-Site Customer

Co-Location

Test Driven Dev. (TDD)

Kanban

Acceptance Test Driven Dev. (ATDD)

0 % 20 % 60 %40 % 80 % 100 %

20.3 %

15.9 %

11.1 %

89.6 %

57.8 %

38.1 %

34.8 %

26.6 %

82.1 %

80.6 %

75.8 %

67.2 %

72.7 %

Setzen wir ein

Ist geplant

Nicht mehr

kein Thema

Wo wird investiert?Ausbildung in die Mitarbeiter wird nach wie vor gross geschrieben. Die engere Zusammenarbeit zwischen Business und IT ist das zweite grosse Investitionsthema.

SwissQ Requirements Trends & Benchmarks 2012 12

HerausforderungenDie Traceability (Beziehung von RE Artefakten zu vor- und nachgelagerten Artefakten) scheint die grösste Herausforderung zu sein.

HERAUSFORDERUNGEN

Investitionennehmen zu

Investitionenbleiben gleich

Investitionennehmen ab

Aus- und Weiterbildung für Mitarbeiter

Engere Zusammenarbeit zwischen Business und IT

Standardisierung der internen RE Prozesse

Ausarbeitung / Definition der RE Rolle

Entwicklung von Vorlagen und Guidelines

Anstellung neuer RE-Mitarbeiter

Etablierung spezifischer RE Tools

Etablierung eigener RE-Bereiche / -Abteilungen

Auslagerung von RE Aktivitäten

0 % 20 % 60 %40 % 80 % 100 %

33.0 %

33.0 %

25.7 %

24.3 %

22.4 %

22.1 %

21.9 %

17.9 %

11.8 %

13.2 %

14.2 %

13.8 %

15.9 %

16.8 %

23.1 %

14.3 %

19.8 %

40.2 %

53.8 %

52.8 %

60.6 %

59.8 %

60.7 %

54.8 %

63.8 %

62.3 %

48.0 %

Traceability

55 %41 %

Anforderungs-erhebung in

verteilten Teams

41 %

Nicht funktionale

Anforderungen

35 %

Verwaltung von > 500

Anforderungen

31 %

Natürlich- sprachliche

Anforderungen vs. Use Cases

30 %

Requirements Engineering in

agilen Projekten

68 %der Befragten verwenden Microsoft Office auch als Requirements Tool im agilen RE.

SwissQ Requirements Trends & Benchmarks 2012 13

Eingesetzte Tools im agilen UmfeldÄhnlich ist die Situation im agilen Umfeld. Dort dominiert ebenfalls Office mit 68 % der Nennungen. Jira steht mit ca. 30 % an zweiter Stelle, dicht gefolgt von HP QC/ALM und Open Source Tools.

Eingesetzte ToolsNach wie vor dominieren die Microsoft Produkte als Tool für Requirements Engineering, denn mehr als 80 % der Befragten haben Office als das wichtigste RE Tools angegeben. Mit grossem Abstand folgt ein ehemaliges 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.

WERKZEUGE

Microsoft OfficeAtlassian Jira

HP QC/ALM

Open Source

Microsoft TFS

PolarionInflectra Spira

Rally SoftwareEigenentwicklung

Version One

Microsoft Office Suite (doc, xls, ppt)

Microsoft Visio

HP QC / ALM

Open Source

IBM Rational Requisite Pro

IBM Rational DOORS

Andere

MS Team Foundation Server

Sparx Enterprise Architect

Eigene Entwicklung

Polarion

MKS Integrity

Serena Dimension RM

Wiki

microTOOL In-Step

Atlassian JIRA

0 % 20 % 60 %40 % 80 %

85 %

47 %

21 %

14 %

13 %

12 %

12 %

10 %

6 %

4 %

3 %

3 %

2 %

2 %

2 %

2 %

IT-MitarbeitendeEtwas mehr als die Hälfte der Befragten arbeitet in Firmen mit mehr als 500 IT-Mitarbeitenden.

SwissQ Requirements Trends & Benchmarks 2012 14ERHEBUNGSGRUNDLAGEN

AufgabenbereichÜber 50% der Befragten umschreiben ihre Tätigkeit mit mehr als einer Rolle.

0 %

IT

Finanzen, Versicherungen

Industrie

Staatliche und staatsnahe Betriebe

Transport und Verkehr

Telekom

MedTech

Andere

10 % 20 % 30 % 40 %

36.1 %

28.4 %

7.4 %

7.4 %

5.6 %

4.0 %

3.7 %

7.4 %

0 %

2001– ...

501 – 2000

251 – 500

51 – 250

11 – 50

1 – 10

5 % 10 % 15 % 20 % 25 % 30 % 35 %

33.0 %

13.6 %

17.6 %

15.4 %

14.2 %

6.2 %

Wirtschafts-SektorÜber 60 % der Befragten arbeiten entweder in der IT-Branche oder im Finanzbereich. Im Vergleich zu den Vorjahren hat sich deren Anteil jedoch reduziert, was zeigt, dass das Thema auch in anderen Branchen angekom-men ist.

der Befragten arbeiten vor allem im Projektkontext.

60 %der Befragten haben eine Linienfunktion inne.

33 %

30 %

20 %

10 %

0 %

Test

Manag

er

Abte

ilung

s- /

Team

leite

r

Requ

irem

ents

Engi

neer /

BA

Test

Engi

neer

Proj

ektle

iter

Teste

r

Requ

irem

ents

Manag

er

Softw

are

Engi

neer

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.

SwissQ Requirements Trends & Benchmarks 2012 15TRENDS & BENCHMARKS REPORTS 2012 FÜR TESTING UND AGILE

Hauptgründe für das Scheitern von agilen Vorgehensmethoden

0 %

Fehlende Erfahrung mit agilen Vorgehensmethoden

Unternehmensphilosophie nicht mit agilen Werten verknüpfbar

Externer Druck einem klassischen Vorgehensmodell zu folgen

Fehlende Unterstützung durch das Management

Fehlende Verbindung zw. den Organisationseinheiten

Fehlende / ungenügende Schulung / Coaching

Fehlender Wille des Teams

Andere

10 % 20 % 30 % 40 % 50 % 60 %

52 %

45 %

41 %

38 %

36 %

35 %

22 %

12 %

Trends & BenchmarksAgile 2012

Trends & BenchmarksTesting 2012

Kostengestiegen

bis 10 % bis 20 % bis 50 % bis 80 % KeineAussagemöglich

Kosteneinsparungen durch Testautomatisierung

10.2 %

33.3 %

2.8 %

22.6 %23.7 %

7.3 %

Ü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ürichwww.SwissQ.it | info@SwissQ.it | Tel +41 43 288 88 40 | Fax +41 43 288 88 39

Twitter: @SwissQ | Facebook: swissqconsulting