SlideShare ist ein Scribd-Unternehmen logo
SwissQ Requirements Trends &
Benchmarks Schweiz 2012
Wo stehen wir – wohin geht es?
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
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.
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.
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.
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
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
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 %
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
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 %
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
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 %
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 %
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 %
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 %
Ü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

Weitere ähnliche Inhalte

Was ist angesagt?

Betriebsverfassungsgesetz und Scrum - Scrum Day 2012
Betriebsverfassungsgesetz und Scrum - Scrum Day 2012Betriebsverfassungsgesetz und Scrum - Scrum Day 2012
Betriebsverfassungsgesetz und Scrum - Scrum Day 2012
Lars Guillium
 
Kultur- und Komplexitätsmanagement bei Mergers und Acquisitions
Kultur- und Komplexitätsmanagement bei Mergers und AcquisitionsKultur- und Komplexitätsmanagement bei Mergers und Acquisitions
Kultur- und Komplexitätsmanagement bei Mergers und AcquisitionsDr. Karl-Michael Popp
 
C1 SetCon Broschüre Unternehmen
C1 SetCon Broschüre UnternehmenC1 SetCon Broschüre Unternehmen
C1 SetCon Broschüre UnternehmenC1 SetCon GmbH
 
Softwarequalität – Schlagwort oder Realität ?
Softwarequalität – Schlagwort oder Realität ?Softwarequalität – Schlagwort oder Realität ?
Softwarequalität – Schlagwort oder Realität ?
Ernest Wallmueller
 
Visure Solutions German Road Show 2011 Requirements Engineering - all slides
Visure Solutions German Road Show 2011  Requirements Engineering - all slidesVisure Solutions German Road Show 2011  Requirements Engineering - all slides
Visure Solutions German Road Show 2011 Requirements Engineering - all slides
Visure Solutions
 
Anforderungsmanagement und agile Vorgehen - OPITZ CONSULTING - Colette Ziller
Anforderungsmanagement und agile Vorgehen - OPITZ CONSULTING - Colette ZillerAnforderungsmanagement und agile Vorgehen - OPITZ CONSULTING - Colette Ziller
Anforderungsmanagement und agile Vorgehen - OPITZ CONSULTING - Colette Ziller
OPITZ CONSULTING Deutschland
 
Smetan Engineering Unternehmens Präsentation Deutsch
Smetan Engineering Unternehmens Präsentation DeutschSmetan Engineering Unternehmens Präsentation Deutsch
Smetan Engineering Unternehmens Präsentation DeutschHSmetan
 

Was ist angesagt? (8)

Betriebsverfassungsgesetz und Scrum - Scrum Day 2012
Betriebsverfassungsgesetz und Scrum - Scrum Day 2012Betriebsverfassungsgesetz und Scrum - Scrum Day 2012
Betriebsverfassungsgesetz und Scrum - Scrum Day 2012
 
Kultur- und Komplexitätsmanagement bei Mergers und Acquisitions
Kultur- und Komplexitätsmanagement bei Mergers und AcquisitionsKultur- und Komplexitätsmanagement bei Mergers und Acquisitions
Kultur- und Komplexitätsmanagement bei Mergers und Acquisitions
 
C1 SetCon Broschüre Unternehmen
C1 SetCon Broschüre UnternehmenC1 SetCon Broschüre Unternehmen
C1 SetCon Broschüre Unternehmen
 
Softwarequalität – Schlagwort oder Realität ?
Softwarequalität – Schlagwort oder Realität ?Softwarequalität – Schlagwort oder Realität ?
Softwarequalität – Schlagwort oder Realität ?
 
Visure Solutions German Road Show 2011 Requirements Engineering - all slides
Visure Solutions German Road Show 2011  Requirements Engineering - all slidesVisure Solutions German Road Show 2011  Requirements Engineering - all slides
Visure Solutions German Road Show 2011 Requirements Engineering - all slides
 
Quo vadis bpm
Quo vadis bpmQuo vadis bpm
Quo vadis bpm
 
Anforderungsmanagement und agile Vorgehen - OPITZ CONSULTING - Colette Ziller
Anforderungsmanagement und agile Vorgehen - OPITZ CONSULTING - Colette ZillerAnforderungsmanagement und agile Vorgehen - OPITZ CONSULTING - Colette Ziller
Anforderungsmanagement und agile Vorgehen - OPITZ CONSULTING - Colette Ziller
 
Smetan Engineering Unternehmens Präsentation Deutsch
Smetan Engineering Unternehmens Präsentation DeutschSmetan Engineering Unternehmens Präsentation Deutsch
Smetan Engineering Unternehmens Präsentation Deutsch
 

Andere mochten auch

Jesus david beltran ramos sitos turisticos, historicos y monumentos de vall...
Jesus david beltran ramos   sitos turisticos, historicos y monumentos de vall...Jesus david beltran ramos   sitos turisticos, historicos y monumentos de vall...
Jesus david beltran ramos sitos turisticos, historicos y monumentos de vall...
Centro Educativo de Sistemas Uparsistem
 
El arte de las civilizaciones antiguas II
El arte de las civilizaciones antiguas IIEl arte de las civilizaciones antiguas II
El arte de las civilizaciones antiguas II
Silvia Garavaglia
 
Persönliche prӓsentation paulina kwiatkowska
Persönliche prӓsentation paulina  kwiatkowskaPersönliche prӓsentation paulina  kwiatkowska
Persönliche prӓsentation paulina kwiatkowska
Elżbieta Dziedzicka
 
Produktion von Pop als non-monetäre Wertschöpfung in Musiknetzwerken
 Produktion von Pop als non-monetäre Wertschöpfung in Musiknetzwerken Produktion von Pop als non-monetäre Wertschöpfung in Musiknetzwerken
Produktion von Pop als non-monetäre Wertschöpfung in Musiknetzwerken
Lorenz Grünewald
 
Segundo supletorio de i bach bi cebi 2010
Segundo supletorio de i bach bi cebi 2010Segundo supletorio de i bach bi cebi 2010
Segundo supletorio de i bach bi cebi 2010
Marcelo Toro Alava
 
Gâteau au yaourt. daniel et miguel
Gâteau au yaourt. daniel et miguelGâteau au yaourt. daniel et miguel
Gâteau au yaourt. daniel et miguel
School
 
10 14 session 26
10 14 session 2610 14 session 26
10 14 session 26
nblock
 
Manual red border-1.6.1
Manual red border-1.6.1Manual red border-1.6.1
Manual red border-1.6.1
Rafael F
 
RECABLEADO DE LA UNCP
RECABLEADO DE LA UNCPRECABLEADO DE LA UNCP
RECABLEADO DE LA UNCP
GLOBAL TRNASNACIONAL
 
Geografía
 Geografía Geografía
Geografía
javier
 
Encuentro de-gerentes-ribie-2010
Encuentro de-gerentes-ribie-2010Encuentro de-gerentes-ribie-2010
Encuentro de-gerentes-ribie-2010
cchaverra
 
El Sol Y La Luna
El Sol Y La LunaEl Sol Y La Luna
El Sol Y La Luna
Biviana
 
Las Lagunas de Ruidera Óscar
Las Lagunas de Ruidera ÓscarLas Lagunas de Ruidera Óscar
Las Lagunas de Ruidera Óscar
cosasdelcoledepulgar
 
Antecedentes (practica del_higado)[1]
Antecedentes (practica del_higado)[1]Antecedentes (practica del_higado)[1]
Antecedentes (practica del_higado)[1]Olinsita Badillo
 
Historia
HistoriaHistoria
Historia
Javier Sanchez
 
Adrian
AdrianAdrian
Formato identificacion estilos de aprendizaje (final) (2) mayra
Formato identificacion estilos de aprendizaje (final) (2) mayraFormato identificacion estilos de aprendizaje (final) (2) mayra
Formato identificacion estilos de aprendizaje (final) (2) mayra
SECRETOS
 
Saliendoconotramujer
SaliendoconotramujerSaliendoconotramujer
Saliendoconotramujer
Silvia Vasquez
 
Pptbtiia jor
Pptbtiia jorPptbtiia jor
Pptbtiia jor
AnaCrespo
 

Andere mochten auch (20)

Jesus david beltran ramos sitos turisticos, historicos y monumentos de vall...
Jesus david beltran ramos   sitos turisticos, historicos y monumentos de vall...Jesus david beltran ramos   sitos turisticos, historicos y monumentos de vall...
Jesus david beltran ramos sitos turisticos, historicos y monumentos de vall...
 
El arte de las civilizaciones antiguas II
El arte de las civilizaciones antiguas IIEl arte de las civilizaciones antiguas II
El arte de las civilizaciones antiguas II
 
Persönliche prӓsentation paulina kwiatkowska
Persönliche prӓsentation paulina  kwiatkowskaPersönliche prӓsentation paulina  kwiatkowska
Persönliche prӓsentation paulina kwiatkowska
 
Produktion von Pop als non-monetäre Wertschöpfung in Musiknetzwerken
 Produktion von Pop als non-monetäre Wertschöpfung in Musiknetzwerken Produktion von Pop als non-monetäre Wertschöpfung in Musiknetzwerken
Produktion von Pop als non-monetäre Wertschöpfung in Musiknetzwerken
 
Segundo supletorio de i bach bi cebi 2010
Segundo supletorio de i bach bi cebi 2010Segundo supletorio de i bach bi cebi 2010
Segundo supletorio de i bach bi cebi 2010
 
Gâteau au yaourt. daniel et miguel
Gâteau au yaourt. daniel et miguelGâteau au yaourt. daniel et miguel
Gâteau au yaourt. daniel et miguel
 
10 14 session 26
10 14 session 2610 14 session 26
10 14 session 26
 
Manual red border-1.6.1
Manual red border-1.6.1Manual red border-1.6.1
Manual red border-1.6.1
 
RECABLEADO DE LA UNCP
RECABLEADO DE LA UNCPRECABLEADO DE LA UNCP
RECABLEADO DE LA UNCP
 
Geografía
 Geografía Geografía
Geografía
 
Encuentro de-gerentes-ribie-2010
Encuentro de-gerentes-ribie-2010Encuentro de-gerentes-ribie-2010
Encuentro de-gerentes-ribie-2010
 
El Sol Y La Luna
El Sol Y La LunaEl Sol Y La Luna
El Sol Y La Luna
 
Las Lagunas de Ruidera Óscar
Las Lagunas de Ruidera ÓscarLas Lagunas de Ruidera Óscar
Las Lagunas de Ruidera Óscar
 
Antecedentes (practica del_higado)[1]
Antecedentes (practica del_higado)[1]Antecedentes (practica del_higado)[1]
Antecedentes (practica del_higado)[1]
 
Historia
HistoriaHistoria
Historia
 
Adrian
AdrianAdrian
Adrian
 
Formato identificacion estilos de aprendizaje (final) (2) mayra
Formato identificacion estilos de aprendizaje (final) (2) mayraFormato identificacion estilos de aprendizaje (final) (2) mayra
Formato identificacion estilos de aprendizaje (final) (2) mayra
 
Saliendoconotramujer
SaliendoconotramujerSaliendoconotramujer
Saliendoconotramujer
 
Système éducatif espagnol
Système éducatif espagnolSystème éducatif espagnol
Système éducatif espagnol
 
Pptbtiia jor
Pptbtiia jorPptbtiia jor
Pptbtiia jor
 

Ähnlich wie Agile and Requirements Trends &amp; Benchmarks 2012 (Deutsch)

Software Development 2014: Trends & Benchmarks in Agile, Requirements and Tes...
Software Development 2014: Trends & Benchmarks in Agile, Requirements and Tes...Software Development 2014: Trends & Benchmarks in Agile, Requirements and Tes...
Software Development 2014: Trends & Benchmarks in Agile, Requirements and Tes...
SwissQ Consulting AG
 
IaaS-Nutzung in Deutschland 2011 Zusammenfassung der Studien-Ergebnisse
IaaS-Nutzung in Deutschland 2011 Zusammenfassung der Studien-ErgebnisseIaaS-Nutzung in Deutschland 2011 Zusammenfassung der Studien-Ergebnisse
IaaS-Nutzung in Deutschland 2011 Zusammenfassung der Studien-Ergebnisse
Dietmar Georg Wiedemann
 
Agile Trends und Benchmarks 2013
Agile Trends und Benchmarks 2013Agile Trends und Benchmarks 2013
Agile Trends und Benchmarks 2013
SwissQ Consulting AG
 
SAP Trends 2013 - die Entscheider kennen sollten ...
SAP Trends 2013 - die Entscheider kennen sollten ...SAP Trends 2013 - die Entscheider kennen sollten ...
SAP Trends 2013 - die Entscheider kennen sollten ...
IT-Onlinemagazin
 
knowtech2011-Verwaltung2.0
knowtech2011-Verwaltung2.0knowtech2011-Verwaltung2.0
knowtech2011-Verwaltung2.0
TwentyOne AG
 
Bausteine für ein Enterprise 2.0 Vorgehensmodell
Bausteine für ein Enterprise 2.0 VorgehensmodellBausteine für ein Enterprise 2.0 Vorgehensmodell
Bausteine für ein Enterprise 2.0 VorgehensmodellJoachim Niemeier
 
Agil in der Normativen Welt
Agil in der Normativen WeltAgil in der Normativen Welt
Agil in der Normativen Welt
Thomas Arends
 
Testing Trends und Benchmarks 2013 De
Testing Trends und Benchmarks 2013 DeTesting Trends und Benchmarks 2013 De
Testing Trends und Benchmarks 2013 De
SwissQ Consulting AG
 
Präsentation zum Bankenworkshop am 11.10.2012
Präsentation zum Bankenworkshop am 11.10.2012Präsentation zum Bankenworkshop am 11.10.2012
Präsentation zum Bankenworkshop am 11.10.2012
KANZLEI NICKERT
 
SAP S/4HANA: Machen Sie Ihre individuellen Erweiterungen zukunftsfähig
SAP S/4HANA: Machen Sie Ihre individuellen Erweiterungen zukunftsfähigSAP S/4HANA: Machen Sie Ihre individuellen Erweiterungen zukunftsfähig
SAP S/4HANA: Machen Sie Ihre individuellen Erweiterungen zukunftsfähig
IBsolution GmbH
 
Netzwoche: Trends und Hürden im Requirements Engineering
Netzwoche: Trends und Hürden im Requirements EngineeringNetzwoche: Trends und Hürden im Requirements Engineering
Netzwoche: Trends und Hürden im Requirements Engineering
SwissQ Consulting AG
 
Lean Lab in der Pharmazeutischen Industrie
Lean Lab in der Pharmazeutischen IndustrieLean Lab in der Pharmazeutischen Industrie
Lean Lab in der Pharmazeutischen Industrie
Lean Knowledge Base UG
 
120715 agile requirements_handout
120715 agile requirements_handout120715 agile requirements_handout
120715 agile requirements_handout
Andreas Birk
 
LeanCertification
LeanCertificationLeanCertification
LeanCertification
Learning Factory
 
Twowayys Agile Sourcing
Twowayys Agile SourcingTwowayys Agile Sourcing
Twowayys Agile Sourcing
Jörg Petters
 
Befragungsergebnisse: Die Rolle von Betriebsräten für Weiterbildungsmaßnahmen...
Befragungsergebnisse: Die Rolle von Betriebsräten für Weiterbildungsmaßnahmen...Befragungsergebnisse: Die Rolle von Betriebsräten für Weiterbildungsmaßnahmen...
Befragungsergebnisse: Die Rolle von Betriebsräten für Weiterbildungsmaßnahmen...FraunhoferIAO
 
YOUR SL GmbH
YOUR SL GmbHYOUR SL GmbH
Ramscheidt Überblick Projektmanagement-Zertifizierungen
Ramscheidt Überblick Projektmanagement-ZertifizierungenRamscheidt Überblick Projektmanagement-Zertifizierungen
Ramscheidt Überblick Projektmanagement-Zertifizierungen
Ramscheidt
 
Agiles Projekt-und Portfoliomanagement – mehr als nur agile Projekte
Agiles Projekt-und Portfoliomanagement – mehr als nur agile ProjekteAgiles Projekt-und Portfoliomanagement – mehr als nur agile Projekte
Agiles Projekt-und Portfoliomanagement – mehr als nur agile Projekte
Ayelt Komus
 
Anforderungen und Scope im Projekt - was leistet die Business Analyse?
Anforderungen und Scope im Projekt - was leistet die Business Analyse?Anforderungen und Scope im Projekt - was leistet die Business Analyse?
Anforderungen und Scope im Projekt - was leistet die Business Analyse?
microTOOL GmbH
 

Ähnlich wie Agile and Requirements Trends &amp; Benchmarks 2012 (Deutsch) (20)

Software Development 2014: Trends & Benchmarks in Agile, Requirements and Tes...
Software Development 2014: Trends & Benchmarks in Agile, Requirements and Tes...Software Development 2014: Trends & Benchmarks in Agile, Requirements and Tes...
Software Development 2014: Trends & Benchmarks in Agile, Requirements and Tes...
 
IaaS-Nutzung in Deutschland 2011 Zusammenfassung der Studien-Ergebnisse
IaaS-Nutzung in Deutschland 2011 Zusammenfassung der Studien-ErgebnisseIaaS-Nutzung in Deutschland 2011 Zusammenfassung der Studien-Ergebnisse
IaaS-Nutzung in Deutschland 2011 Zusammenfassung der Studien-Ergebnisse
 
Agile Trends und Benchmarks 2013
Agile Trends und Benchmarks 2013Agile Trends und Benchmarks 2013
Agile Trends und Benchmarks 2013
 
SAP Trends 2013 - die Entscheider kennen sollten ...
SAP Trends 2013 - die Entscheider kennen sollten ...SAP Trends 2013 - die Entscheider kennen sollten ...
SAP Trends 2013 - die Entscheider kennen sollten ...
 
knowtech2011-Verwaltung2.0
knowtech2011-Verwaltung2.0knowtech2011-Verwaltung2.0
knowtech2011-Verwaltung2.0
 
Bausteine für ein Enterprise 2.0 Vorgehensmodell
Bausteine für ein Enterprise 2.0 VorgehensmodellBausteine für ein Enterprise 2.0 Vorgehensmodell
Bausteine für ein Enterprise 2.0 Vorgehensmodell
 
Agil in der Normativen Welt
Agil in der Normativen WeltAgil in der Normativen Welt
Agil in der Normativen Welt
 
Testing Trends und Benchmarks 2013 De
Testing Trends und Benchmarks 2013 DeTesting Trends und Benchmarks 2013 De
Testing Trends und Benchmarks 2013 De
 
Präsentation zum Bankenworkshop am 11.10.2012
Präsentation zum Bankenworkshop am 11.10.2012Präsentation zum Bankenworkshop am 11.10.2012
Präsentation zum Bankenworkshop am 11.10.2012
 
SAP S/4HANA: Machen Sie Ihre individuellen Erweiterungen zukunftsfähig
SAP S/4HANA: Machen Sie Ihre individuellen Erweiterungen zukunftsfähigSAP S/4HANA: Machen Sie Ihre individuellen Erweiterungen zukunftsfähig
SAP S/4HANA: Machen Sie Ihre individuellen Erweiterungen zukunftsfähig
 
Netzwoche: Trends und Hürden im Requirements Engineering
Netzwoche: Trends und Hürden im Requirements EngineeringNetzwoche: Trends und Hürden im Requirements Engineering
Netzwoche: Trends und Hürden im Requirements Engineering
 
Lean Lab in der Pharmazeutischen Industrie
Lean Lab in der Pharmazeutischen IndustrieLean Lab in der Pharmazeutischen Industrie
Lean Lab in der Pharmazeutischen Industrie
 
120715 agile requirements_handout
120715 agile requirements_handout120715 agile requirements_handout
120715 agile requirements_handout
 
LeanCertification
LeanCertificationLeanCertification
LeanCertification
 
Twowayys Agile Sourcing
Twowayys Agile SourcingTwowayys Agile Sourcing
Twowayys Agile Sourcing
 
Befragungsergebnisse: Die Rolle von Betriebsräten für Weiterbildungsmaßnahmen...
Befragungsergebnisse: Die Rolle von Betriebsräten für Weiterbildungsmaßnahmen...Befragungsergebnisse: Die Rolle von Betriebsräten für Weiterbildungsmaßnahmen...
Befragungsergebnisse: Die Rolle von Betriebsräten für Weiterbildungsmaßnahmen...
 
YOUR SL GmbH
YOUR SL GmbHYOUR SL GmbH
YOUR SL GmbH
 
Ramscheidt Überblick Projektmanagement-Zertifizierungen
Ramscheidt Überblick Projektmanagement-ZertifizierungenRamscheidt Überblick Projektmanagement-Zertifizierungen
Ramscheidt Überblick Projektmanagement-Zertifizierungen
 
Agiles Projekt-und Portfoliomanagement – mehr als nur agile Projekte
Agiles Projekt-und Portfoliomanagement – mehr als nur agile ProjekteAgiles Projekt-und Portfoliomanagement – mehr als nur agile Projekte
Agiles Projekt-und Portfoliomanagement – mehr als nur agile Projekte
 
Anforderungen und Scope im Projekt - was leistet die Business Analyse?
Anforderungen und Scope im Projekt - was leistet die Business Analyse?Anforderungen und Scope im Projekt - was leistet die Business Analyse?
Anforderungen und Scope im Projekt - was leistet die Business Analyse?
 

Mehr von SwissQ Consulting AG

NEW: Prioritize ruthlessly: Priority Poker with Business Value Alignment
NEW: Prioritize ruthlessly: Priority Poker with Business Value AlignmentNEW: Prioritize ruthlessly: Priority Poker with Business Value Alignment
NEW: Prioritize ruthlessly: Priority Poker with Business Value Alignment
SwissQ Consulting AG
 
Prioritize ruthlessly: Priority Poker with Business Value Alignment
Prioritize ruthlessly: Priority Poker with Business Value AlignmentPrioritize ruthlessly: Priority Poker with Business Value Alignment
Prioritize ruthlessly: Priority Poker with Business Value Alignment
SwissQ Consulting AG
 
SwissQ Culture Code
SwissQ Culture CodeSwissQ Culture Code
SwissQ Culture Code
SwissQ Consulting AG
 
SwissQ Culture Desk - Intro
SwissQ Culture Desk - IntroSwissQ Culture Desk - Intro
SwissQ Culture Desk - Intro
SwissQ Consulting AG
 
SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...
SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...
SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...
SwissQ Consulting AG
 
Der Test Manager ist tot - lang lebe der Test Master
Der Test Manager ist tot - lang lebe der Test MasterDer Test Manager ist tot - lang lebe der Test Master
Der Test Manager ist tot - lang lebe der Test Master
SwissQ Consulting AG
 
GTD 2013 Adrian Zwingli - Der einsame Tester
GTD 2013 Adrian Zwingli - Der einsame TesterGTD 2013 Adrian Zwingli - Der einsame Tester
GTD 2013 Adrian Zwingli - Der einsame TesterSwissQ Consulting AG
 
GTD 2013 Stephan Wiesner - Wenn Tester Apps entwickeln
GTD 2013 Stephan Wiesner - Wenn Tester Apps entwickelnGTD 2013 Stephan Wiesner - Wenn Tester Apps entwickeln
GTD 2013 Stephan Wiesner - Wenn Tester Apps entwickelnSwissQ Consulting AG
 
Agile Trends and Benchmarks 2013 EN
Agile Trends and Benchmarks 2013 ENAgile Trends and Benchmarks 2013 EN
Agile Trends and Benchmarks 2013 EN
SwissQ Consulting AG
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
SwissQ Consulting AG
 
Scrum Rocks, Testing Sucks?! (de)
Scrum Rocks, Testing Sucks?! (de)Scrum Rocks, Testing Sucks?! (de)
Scrum Rocks, Testing Sucks?! (de)
SwissQ Consulting AG
 
Computerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQ
Computerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQComputerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQ
Computerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQ
SwissQ Consulting AG
 
Introduction Priority Poker (En)
Introduction Priority Poker (En)Introduction Priority Poker (En)
Introduction Priority Poker (En)
SwissQ Consulting AG
 
Einführung Priority Poker (De)
Einführung Priority Poker (De)Einführung Priority Poker (De)
Einführung Priority Poker (De)
SwissQ Consulting AG
 
Swiss Requirements Day 2013 - Vom Spieltrieb zur Systematik
Swiss Requirements Day 2013 - Vom Spieltrieb zur SystematikSwiss Requirements Day 2013 - Vom Spieltrieb zur Systematik
Swiss Requirements Day 2013 - Vom Spieltrieb zur Systematik
SwissQ Consulting AG
 
Netzwoche: Agil versus Wasserfall
Netzwoche: Agil versus WasserfallNetzwoche: Agil versus Wasserfall
Netzwoche: Agil versus Wasserfall
SwissQ Consulting AG
 
Netzwoche: Agile Methoden allein reichen nicht
Netzwoche: Agile Methoden allein reichen nichtNetzwoche: Agile Methoden allein reichen nicht
Netzwoche: Agile Methoden allein reichen nicht
SwissQ Consulting AG
 
SwissQ Testing Trends & Benchmarking 2011
SwissQ Testing Trends & Benchmarking 2011SwissQ Testing Trends & Benchmarking 2011
SwissQ Testing Trends & Benchmarking 2011
SwissQ Consulting AG
 
Digital Marketing - Reduktion von technischen Risiken
Digital Marketing - Reduktion von technischen RisikenDigital Marketing - Reduktion von technischen Risiken
Digital Marketing - Reduktion von technischen Risiken
SwissQ Consulting AG
 
SwissQ Testing Trends & Benchmarks 2012 (Englisch)
 SwissQ Testing Trends & Benchmarks 2012 (Englisch) SwissQ Testing Trends & Benchmarks 2012 (Englisch)
SwissQ Testing Trends & Benchmarks 2012 (Englisch)
SwissQ Consulting AG
 

Mehr von SwissQ Consulting AG (20)

NEW: Prioritize ruthlessly: Priority Poker with Business Value Alignment
NEW: Prioritize ruthlessly: Priority Poker with Business Value AlignmentNEW: Prioritize ruthlessly: Priority Poker with Business Value Alignment
NEW: Prioritize ruthlessly: Priority Poker with Business Value Alignment
 
Prioritize ruthlessly: Priority Poker with Business Value Alignment
Prioritize ruthlessly: Priority Poker with Business Value AlignmentPrioritize ruthlessly: Priority Poker with Business Value Alignment
Prioritize ruthlessly: Priority Poker with Business Value Alignment
 
SwissQ Culture Code
SwissQ Culture CodeSwissQ Culture Code
SwissQ Culture Code
 
SwissQ Culture Desk - Intro
SwissQ Culture Desk - IntroSwissQ Culture Desk - Intro
SwissQ Culture Desk - Intro
 
SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...
SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...
SwissQ Culture Desk - Kapitel 5: Wir alle haben Freiheiten - und tragen Veran...
 
Der Test Manager ist tot - lang lebe der Test Master
Der Test Manager ist tot - lang lebe der Test MasterDer Test Manager ist tot - lang lebe der Test Master
Der Test Manager ist tot - lang lebe der Test Master
 
GTD 2013 Adrian Zwingli - Der einsame Tester
GTD 2013 Adrian Zwingli - Der einsame TesterGTD 2013 Adrian Zwingli - Der einsame Tester
GTD 2013 Adrian Zwingli - Der einsame Tester
 
GTD 2013 Stephan Wiesner - Wenn Tester Apps entwickeln
GTD 2013 Stephan Wiesner - Wenn Tester Apps entwickelnGTD 2013 Stephan Wiesner - Wenn Tester Apps entwickeln
GTD 2013 Stephan Wiesner - Wenn Tester Apps entwickeln
 
Agile Trends and Benchmarks 2013 EN
Agile Trends and Benchmarks 2013 ENAgile Trends and Benchmarks 2013 EN
Agile Trends and Benchmarks 2013 EN
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
 
Scrum Rocks, Testing Sucks?! (de)
Scrum Rocks, Testing Sucks?! (de)Scrum Rocks, Testing Sucks?! (de)
Scrum Rocks, Testing Sucks?! (de)
 
Computerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQ
Computerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQComputerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQ
Computerworld: Mehr Kommunikation, bitte! by Stephan Adler SwissQ
 
Introduction Priority Poker (En)
Introduction Priority Poker (En)Introduction Priority Poker (En)
Introduction Priority Poker (En)
 
Einführung Priority Poker (De)
Einführung Priority Poker (De)Einführung Priority Poker (De)
Einführung Priority Poker (De)
 
Swiss Requirements Day 2013 - Vom Spieltrieb zur Systematik
Swiss Requirements Day 2013 - Vom Spieltrieb zur SystematikSwiss Requirements Day 2013 - Vom Spieltrieb zur Systematik
Swiss Requirements Day 2013 - Vom Spieltrieb zur Systematik
 
Netzwoche: Agil versus Wasserfall
Netzwoche: Agil versus WasserfallNetzwoche: Agil versus Wasserfall
Netzwoche: Agil versus Wasserfall
 
Netzwoche: Agile Methoden allein reichen nicht
Netzwoche: Agile Methoden allein reichen nichtNetzwoche: Agile Methoden allein reichen nicht
Netzwoche: Agile Methoden allein reichen nicht
 
SwissQ Testing Trends & Benchmarking 2011
SwissQ Testing Trends & Benchmarking 2011SwissQ Testing Trends & Benchmarking 2011
SwissQ Testing Trends & Benchmarking 2011
 
Digital Marketing - Reduktion von technischen Risiken
Digital Marketing - Reduktion von technischen RisikenDigital Marketing - Reduktion von technischen Risiken
Digital Marketing - Reduktion von technischen Risiken
 
SwissQ Testing Trends & Benchmarks 2012 (Englisch)
 SwissQ Testing Trends & Benchmarks 2012 (Englisch) SwissQ Testing Trends & Benchmarks 2012 (Englisch)
SwissQ Testing Trends & Benchmarks 2012 (Englisch)
 

Agile and Requirements Trends &amp; Benchmarks 2012 (Deutsch)

  • 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