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

1. SwissQ Requirements Trends &
Benchmarks Switzerland 2012
Where are we now – where are we going to?

2. TABLE OF CONTENTS SwissQ Requirements Trends & Benchmarks 2012 2
3 EDITORIAL
4 TRENDWAVE 2012
5 KEY MESSAGES
6 PROJECTS
7 QUALITY
8 EFFORT
9 MATURITY LEVEL AND SUCCESS FACTORS
10 ORGANIZATION AND TRAINING
11 AGILE REQUIREMENTS ENGINEERING
12 CHALLENGES
13 TOOLS
14 FRAME OF SURVEY
15 TESTING AND AGILE

3. EDITORIAL SwissQ Requirements Trends & Benchmarks 2012 3
“The only constant in the universe is change.”
Over 2500 years ago, Heraclitus from Ephesus already hit the nail right on the head. In order for you to have an overview of these changes
and to be able to systematically shape the process of change, SwissQ created the “Requirements Trends & Benchmarks Report“ at hand. The
report is based on a survey completed by over 300 participants from the Swiss IT Community. In addition, we also personally interviewed
numerous IT decision makers from various companies, branches, and regions about the current trends. From this developed a representative
overview about the current state of Requirements Engineering (RE) in Switzerland in the year 2012 and an outlook on the most important
future trends. Let yourself be surprised by the interesting results.
Also in Switzerland, only 35 % of all projects are finished in scope, in time and It leads to discontent with the RE if this prioritization is not or only insufficiently
in budget. These results approximate to the international situation as published carried out (30 % believe the maturity level of their RE to be weak or very weak).
in the “Chaos Report“ by the Standish Group. The situation has improved slightly Here lies the task of the requirements engineers (or the business analysts,
compared to previous surveys but still a majority of the projects are threatened by product owners, etc.) to use appropriate methods to get the estimates from the
failure. The reasons are many and varied. stakeholders.
The systematic analysis of stakeholders for example – who, by the way, are a Another reason for insufficient RE is the inappropriate use of tools. Most res-
central source for requirements – seems to be a necessary evil instead of a success pondents (>85 %) still use Microsoft Office for RE tasks. It is obvious that the
factor for many respondents. Around 1/3 does not invest any time into this traceability poses the biggest challenge here (see p.12). Integrated tools, so called
analysis as the stakeholders are assumed to be a given. It is therefore not application lifecycle management tools are increasingly important as proposed
surprising that almost 70 % are not or only somewhat satisfied with the elicitation solutions. Sooner or later, the tools question for an efficient process support in RE
of requirements. The insight that the stakeholder analysis is important for the will become a focus because of the increasing complexity and range of functions
success of the project doesn‘t seem to be really established, it only came in in of applications.
fifth place in the poll. So it seems only logical that ever changing or growing
requirements for the system are named as the a reason for insufficient As Heraclitus already noted, the world is in constant motion. With the SwissQ
requirements by over 75 % of all respondents. Trend Wave® (well-known from the Testing Trends & Benchmarks) you can see
the changes in the RE market. Together with other results from this report they are
The missing business value of requirements – In addition to insufficient a guide through this storm of changes. This report will therefore be published on
requirements – poses a problem for over 50 % of the respondents. This is very a regular basis in the future. In that sense, SwissQ wishes you many interesting
surprising especially since agile methods have been introduced in businesses long insights and hopes you enjoy the reading.
ago (75 % of all respondents have already worked with agile methods) and the
focus on business value is a central element of agile projects. Meanwhile, tested
techniques are on the market – such as for example “Priority Poker“ by SwissQ –
which can efficiently prioritize requirements according to their business value.

4. TRENDWAVE 2012 SwissQ Requirements Trends & Benchmarks 2012 4
INTRODUCTION GROWTH MATURITY DECLINE
PRIORITY
RE Processes/Roles RE Pools
IREB CPRE FL Use Case Specifications
ALM Tools RE Mgmt Tools
MoSCoW
Phrase Templates
Prioritization
Requirements Modeling
RE Workshops
Agile RE
Business Value Reviews
Planguage
IREB CPRE AL
IIBA CBAP
Acceptance Test Driven Development (ATDD)
RE Outsourcing
TIME
INTRODUCTION – This topic has been GROWTH – This topic is more and MATURITY – Most companies are DECLINE – The topic has already been
identified and some companies are more accepted and many companies working on the implementation implemented by most of the
deploying initial implementations. are considering it. The first tools are or have already completed it. The companies, with the exception of
However, it cannot be foreseen being developed and consultancy knowledge of this topic is often individual latecomers. Often, there
whether this trend will positively firms offer services for the same. widespread, resulting in sub-topics is no more added value in acquiring
advance and whether testing will be Often risks are associated due to being raised. further knowledge in these areas,
considerably influenced. limited implementation experience. since it will become obsolete shortly.

5. KEY MESSAGES SwissQ Requirements Trends & Benchmarks 2012 5
1 Only 25 % of all respondents think
their requirements engineering is
good or excellent. The most
important improvement measure
named is the standardization of
2 Top strategic goals in 2012 are
Agile Requirements Engineering
and Business Process Driven
Requirements. Agility is on the
rise here as well.
3 Modelling requirements and
defining acceptance criteria are
named as the most important
success factors.
requirements processes and tools.
4 Requirements Engineering has a low
priority in companies or is even
regarded as a necessary evil
according to almost half of all
respondents.
5 The professional image of a
Requirements Engineers / Business
Analyst seems to be established
on the market. This is also partly
due to the training that has been
6 More and more is being invested
into the collaboration between
Business and IT, and into the
training and the standardization
of requirements processes.
standardized by IREB in the past All this at the cost of outsourcing
five years. and the building of organisational
Requirements Engineering units.
7 Over 36 % do not check their
requirements for need whereas
functionality and feasibility are
checked by more than 80%.
8 Over 2/3 invest less than a day in
the stakeholder analysis. This is
surprising since the stakeholder
analysis is generally considered
an important success factor.
9 Misunderstandings in commu-
nication and the ever changing
requirements for the complete
system are the key reasons for
insufficient requirements.

6. PROJECTS SwissQ Requirements Trends & Benchmarks 2012 6
Project Type
70 % of all projects are new developments or updates of an existing
software.
>50 %
of the respondents describe the starting situation of their
projects as satisfying or insufficient related to
12 %
8% New development Estimation
Planning
39 % Update of existing
software Definition of requirements
10 % Migration Realistic expectations
Implementation of
standard software
31 % Operation, support,
maintainance, re-design
Project Success
Just over a third of all projects are finished with the expected functionality,
within the expected timeframe and within budget.
Project Size (in Swiss Francs)
40 %
51 %
35.1 %
30 %
40 %
39.2 % 25.1 %
20 %
18.1 % 17.5 %
20 % 10 %
4.1 %
10.8 % 0 %
Project Proj. finished Proj. finished Project Project
finished in with budget with major extended / stopped
0 % time, budget and / or time functional rescheduled
up to 1 Mio up to 20 Mio more than and overruns changes
20 Mio functionality

7. QUALITY SwissQ Requirements Trends & Benchmarks 2012 7
Classic Mistakes in Requirements Acceptance Criteria for Requirements
Linguistic mistakes are still the most commonly named problem in
requirements. It is very surprising that despite agile methods on the
In over Over
rise the missing business value remains a problem in (too) many cases.
Language mistakes:
incomprehensibility,
17.0 % 57.5 % 25.5 %
80 %
Requirements are checked for
36 %
of all respondents rarely or
ambiguousness,
unquantifiability functional accuracy, feasibility never check requirements for
and completeness. their need.
Content mistakes:
wrong facts, 15.1 % 58.5 % 26.4 %
incompleteness
Logical mistakes:
inconsistency, 12.0 % 49.1 % 38.9 %
redundancy
Reasons for Insufficient Requirements
Systematic mistakes:
missing business value/ 5.8 % 46.2 % 48.1 %
benefit for the project
Misunderstandings in communication 12.3 % 65.1 % 22.6 %
0 % 20 % 40 % 60 % 80 % 100 %
Growing or changing requirements
always often rarely/never of whole system
20.4 % 56.5 % 23.1 %
Formulations too abstract
(need more details, be more clear) 19.8 % 50.9 % 29.2 %
New insights
(pilot operation, prototype, etc.)
8.7 % 49.0 % 42.3 %
Missing business In Changes in boundary conditions
75 %
value is a problem (prioritization, etc.) 11.1 % 43.5 % 45.4 %
in more than
50 %
Feasibility wrongly assessed 26.7 % 70.5 %
of the projects,
Changes in stakeholder structure 23.6 % 73.6 %
linguistic mistakes
of all projects. in requirements are
0 % 20 % 40 % 60 % 80 % 100 %
a problem.
always often rarely/never

8. EFFORT SwissQ Requirements Trends & Benchmarks 2012 8
RE Effort in Proportion to Total Project Effort The Most Important Sources for RE
There is no clear tendency when measuring the RE effort compared to the As expected, customers and users are the most important source for
total project effort. Depending on the project, a lot or very little is being requirements.
invested in RE.
25 %
23.5 % Sponsors/
20 % Customers
19.6 % and Users
17.6 % Existing Product/
15 %
15.7 %
14.7 %
51 % Software Regulations &
21 % Legal
Requirements
Designers &
Developers Others
10 %
14 % 6 %
8 %
6.9 %
5 %
2.0 %
0 %
< 5 % 5- 10 - 15 - 20 - 30 - above
Effort for Stakeholder Analysis
10 % 15 % 20 % 30 % 50 %
2/3 of all respondents invest less than a day in the stakeholder analysis.
RE effort proportional to total project effort
6.3 %
No effort because it‘s a given
50 %
37.3 %
Less than 1 man-day
30.9 %
1-5 man-days
of the respondents use less than 15 %
More than 5 man-days
of the total project effort for requirements
engineering.
25.5 %

9. MATURITY LEVEL AND SUCCESS FACTORS SwissQ Requirements Trends & Benchmarks 2012 9
Maturity Level of RE in Projects Most Important Success Factors
Onlyl 1/4 of the respondents rate their RE as good or excellent. The modelling of requirements and the compiling of acceptance criteria are the
most important success factors in RE.
Compilation of
25.5 % 43.6 % 22.7 % 8.2 % acceptance criteria Structured
reviews
Modeling of
Good/excellent Medium Weak Very weak requirements
Clean
stakeholder analysis Use of defined
RE processes
Satisfaction Measures for Quality Improvements
The process of eliciting and analysing requirements is barely satisfactory Well trained employees and the establishment of standardized processes are the
but the biggest problems seem to lie in managing them. most important measures to improve the RE quality.
Internal/further education and training 28.2 % 50.9 % 20.9 %
Analyse 35.5 % 46.4 % 18.2 %
Establishment of standard RE processes 42.3 % 36.5 % 21.2 %
Establishment of internal 36.4 % 38.3 % 25.2 %
31.2 % 48.6 % 20.2 % templates/standards
Elicit
Establishment of standard tools 33.0 % % 34.9 % 32.1 %
Verify 22.0 % 50.5 % 27.5 % Specific recruiting of RE/BA 16.2 % 48.6 % 35.2 %
Defined specialist career for RE/BA 26.2 % 24.3 % 49.5 %
Document 30.0 % 38.2 % 31.8 % Systematic IREB training 11.9 % 29.7 % 58.4 %
Employment of external specialists 25.0 % 69.2 %
Manage 17.4 % 36.7 % 45.9 %
Systematic IIBA training 7.1 % 85.9 %
0 % 20 % 40 % 60 % 80 % 100 % 0 % 20 % 40 % 60 % 80 % 100 %
Satisfying Medium Unsatisfying Planned Done Not planned

10. ORGANIZATION AND TRAINING SwissQ Requirements Trends & Benchmarks 2012 10
Who Executes RE? Trainings
The role of the Requirements Engineer is recognized and will be assigned with The IREB® CPRE Foundation Level seems to be part of the standard repertoire
the appropriate tasks regardless of the company size. of RE/BAs. The future focus lies with the IREB® CPRE Advanced Levels and the
Business Analysis, as well as with Agile RE.
I already have it It is planned In the not too distant future No issue
Requirements
Engineer Product
63 % 18 % 17 %
Manager / IREB® CPRE (Foundation Level)
40 % Product Project
Owner Leader Developer
Tester
24 % 20 % 12 % None Agile Requirements Engineering 11 % 19 % 43 % 28 %
4 %
IREB® CPRE (Advanced Level Elicitation & 2 % 27 % 43 % 29 %
Consolidation)
Prestige of Requirements Engineering
IREB® CPRE (Advanced Level Requirements 21 % 42 % 37 %
At least 2/3 of the respondents recognize the value of Requirements Engineering. Modeling)
But those 17% who believe that RE is a necessary evil or even completely
superfluous show the need for development in this area.
Project Management (IPMA, PMI, ...) 21 % 12 % 23 % 44 %
2.7 %
Certified Product Owner 21 % 6 % 25 % 48 %
14.5 % 8.2 % Strategic for
company success
Important factor for IIBA CBAP (Certified Business Analysis 17 % 31 % 50 %
reliable software Professional)
20.9 % Low priority
Certified Scrum Master 18 % 8 % 20 % 53 %
53.7 % Necessary evil
Certified IT Process and Quality Manager 13 % 6 % 17 % 65 %
Unnecessary
0 % 20 % 40 % 60 % 80 % 100 %

11. AGILE REQUIREMENTS ENGINEERING SwissQ Requirements Trends & Benchmarks 2012 11
Use of Agile Techniques Trends in Agile Requirements Engineering
Iterative planning, daily standups and the management of backlogs The high rate of changes in the agile field poses big challenges to many an
are widely used techniques in the agile field. experienced requirements engineer. It does not go far enough to propagate the
product owner as a solution, that would be simply hiding the old under the cloak
Iterative planning
of the new. Agile requirements engineering has to take into account the values
89.6 %
and methods of the agile context. Approaches like the following belong to this:
Daily Standup 82.1 %
Extreme Prioritization (according to business value)
Backlog Management 80.6 %
Continuous planning
Taskboard 75.8 % B
acklog Management (Who‘s responsible? When is it being filled?
Retrospectives
Synchronisation with strategic projects, ...)
72.7 %
TDD and ATDD (Acceptance Test Driven Development)
Burndown Chart 67.2 %
Strong use of iterative RE (quick feedback cycles and adjustments)
Definition of Done 57.8 % More face-to-face communication
Level and sustainability of requirements documentation
Velocity Chart 38.1 %
C
orrect cutting of requirements (business value versus implementation
On-Site Customer 34.8 % in one sprint)
26.6 %
e
tc.
Co-Location
Used
Nothing has changed with the fact though, that the client wants exactly what
Test Driven Dev. (TDD) 20.3 % Planned he imagined at the end of the project. For a “classic“ requirements engineer,
Kanban 15.9 % Not anymore these are known problems. It is now time to adjust the classic methods to the
No issue
agile context in order for “good practices“ not to be lost and still be able to use
Acceptance Test Driven Dev. (ATDD) 11.1 % the method with the light agile approach. SwissQ would be pleased to share its
experiences from various agile projects with you.
0 % 20 % 40 % 60 % 80 % 100 %
3/4
of the respondents already
2/3
of the respondents have
“We often develop a
feature and then can‘t
“The success of a SCRUM
project depends on the
find a user / stakeholder personality of the product
gained experiences with less than two years for it!“ owner.“
agile methods. experience with agile
projects. Project leader Unit manager

12. CHALLENGES SwissQ Requirements Trends Benchmarks 2012 12
Challenges Where do Investments Occur?
The traceability (relationship of RE artefacts to preceding and following The training of employees is still a main priority. Closer collaboration between
artefacts) seems to be the biggest challenge. business and IT is the next big investment topic.
Elicitation of RE in agile
requirements projects Investments Investments Investments
in distributed increase remain constant decrease
teams 30 %
Traceability
41 % Further training for employees 33.0 % 53.8 % 13.2 %
55 %
Closer collaboration between 33.0 % 52.8 % 14.2 %
Business and IT
Standardization of internal
Natural language 25.7 % 60.6 % 13.8 %
RE processes
Requirements
vs. Use Cases
31 % Elaboration / Definition of role of RE 24.3 % 59.8 % 15.9 %
Management
of many
requirements Development of templates and guidelines 22.4 % 60.7 % 16.8 %
(500)
35 % Employment of new RE employees 22.1 % 54.8 % 23.1 %
Non-functional
requirements
Establishment of specific RE Tools 21.9 % 63.8 % 14.3 %
41 %
Establishment of own RE
sections / departments 17.9 % 62.3 % 19.8 %
Outsourcing of
RE activities 11.8 % 48.0 % 40.2 %
0 % 20 % 40 % 60 % 80 % 100 %

13. TOOLS SwissQ Requirements Trends Benchmarks 2012 13
Tools in Place Tools in the Agile Context
Microsoft tools are still dominating in the field of Requirements The situation is similar when it comes to tools in the agile context. Microsoft
Engineering as more than 80 % of all respondents mentioned Microsoft Office dominates with 68 %. Jira is in second place with 30 %, followed
Office as the most important RE tool. It is followed by far by a tool closely by HP QC/ALM and Open Source Tools.
formerly dedicated to test management – HP QC/ALM – which developed
into an Application Lifecycle Suite where you can also create, document,
and manage requirements.
Own developments
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 %
Others 12 % Inflectra Spira
MS Team Foundation
Server
10 %
Polarion
Atlassian Jira
Sparx Enterprise 6 %
Architect
Own developments 4 %
Polarion 3 %
MKS Integrity 3 %
Serena Dimension RM
Wiki
2 %
2 %
68 %
of the respondents are using
microTOOL In-Step 2 %
Microsoft Office as a requirements
Atlassian JIRA 2 % tool in agile RE.
0 % 20 % 40 % 60 % 80 %

14. FRAME OF SURVEY SwissQ Requirements Trends Benchmarks 2012 14
Industrial Sector Responsibilities
More than 60 % of the respondents work either in the IT or in the More than 50 % of the respondents describe their job with more than one role.
financial sector. Compared to the last years their proportion has decreased,
demonstrating that the subject has arrived in other industries too.
30 %
IT 36.1 %
Finance, Insurance 28.4 %
Manufacturing 7.4 %
20 %
Public and semi-public companies 7.4 %
Traffic and Transportation 5.6 %
Telecommunication 4.0 %
MedTech 3.7 % 10 %
Others 7.4 %
0 % 10 % 20 % 30 % 40 %
IT Employees 0 %
er er A er er er er er
ag ag /B ne ag st ag ne
A bit more than half of the respondents work in companies with more an an er gi an Te an gi
M M ne En M M En
than 500 IT employees. st n gi st ct ts e
Te sio En Te o je en ar
vi ts Pr m ftw
Di en re So
t/ m q ui
en re Re
ui
rtm eq
2001– ... 33.0 % pa R
De
501 – 2000 17.6 %
60 % 33 %
251 – 500 13.6 %
51 – 250 15.4 %
11 – 50 14.2 %
of the respondents mainly of the respondents are
1 – 10 6.2 % work in projects. line managers.
0 % 5 % 10 % 15 % 20 % 25 % 30 % 35 %

15. TRENDS BENCHMARKS REPORTS 2012 FOR TESTING AND AGILE SwissQ Requirements Trends Benchmarks 2012 15
Along with the first edition of the SwissQ Requirements Trends Benchmarks Report, SwissQ publishes the already fourth edition
of the SwissQ Testing Trends Benchmarks Report and as well the first edition of the SwissQ Agile Trends Benchmarks Report,
in 2012. Do you want to know more? You can download the detailed reports with further analyses from www.SwissQ.it.
Trends Benchmarks Trends Benchmarks
Testing 2012 Agile 2012
Cost Savings by Test Automation Main Reasons for the Failure of Agile Projects
Lacking experience with
agile methods
52 %
Corporate culture is not compatible
with agile values 45 %
33.3 %
External pressure to follow a
traditional approach 41 %
Lacking support of line
23.7 % management 38 %
22.6 %
Lacking / insufficient training / coaching 36 %
Lacking interconnections between
organizational units 35 %
10.2 %
7.3 % Lacking team motivation 22 %
2.8 %
Others 12 %
Costs up to 10 % up to 20 % up to 50 % up to 80 % No
increased statement
possible 0 % 10 % 20 % 30 % 40 % 50 % 60 %

16. ABOUT US
SwissQ supports its clients in the development and implementation of IT-solutions and
assures that the end users get the functionality they really need. This is achieved by
unambiguously determining requirements and risk-based testing the implementation.
Our vision is to improve the added value of IT through requirements management and
software testing. Along with providing high-quality services, we pursue this vision
by establishing independent platforms, like the Swiss Testing Day and the Swiss
Requirements Day, which facilitate the exchange of know-how and experiences.
In addition to that we help bright minds to expand their knowledge in our trainings.
© by SwissQ Consulting AG | Stadthaus-Quai 15 | Switzerland-8001 Zürich
www.SwissQ.it | info@SwissQ.it | Phone +41 43 288 88 40 | Fax +41 43 288 88 39
Twitter: @SwissQ | Facebook: swissqconsulting