1

Survey respondents this year closely matched last years respondents in terms of company size, with the majority working for companies with more than 1,000 employees.

The industries represented in the 2010 survey match those of the 2009 survey closely, with finance, insurance, business services, and IT services highly represented.

As with the 2009 survey, the majority of respondents represent firms based in North America, although respondents representing European firms grew from 9% to 12%, and those representing Australian firms grew from 7% to 9%.

Research shows that the business analyst role comes with a variety of titles. Survey results show senior business analyst and business analyst titles being most common, but 8% of the survey respondents manage other business analysts, systems analysts, or requirements engineers. The business systems analyst title is also common, and many respondents are consulting business analysts.

The 2009 survey showed 66% of respondents reporting to IT and 34% reporting into the business almost identical to the 2010 survey results. For BAs that report into IT, we see a slight increase in BAs reporting into centralized BA teams or the project/program management office, which is likely due to the increased focus on business analysis skills and practices.

The 2009 survey showed 66% of respondents reporting to IT and 34% reporting into the business almost identical to the 2010 survey results. For BAs that report into the business, we dont see much change in functional reporting structure, although for the first year, we included an enterprise/business project management office as an option, and 10% report into that business function.

10

In the 2009 survey, 46% responded that there were more BAs at their company than in 2008. In 2010, that number grew to 49%. This is consistent with the increased emphasis weve seen on business analysis skills and practices. Because defects injected early in the development process (including requirements defects) cost exponentially more to fix postdeployment, organizations are investing in business analysis and requirements improvements and apparently increasing the number of BAs in their development shops.

11

12

Respondents to the 2010 survey had nearly the same educational background as those who responded in 2009. 47% of BAs earned a bachelors degree, with 29% also holding one or more masters degrees. Most studied business, followed closely by computer sciences. 33% of respondents took different paths, studying a variety of specialties like liberal arts, engineering, and science, demonstrating that BAs dont necessarily need business and/or technology backgrounds they can come from other backgrounds and with the right soft skills learn about the business and technology environments.

13

In addition to education, many business analysts are taking advantage of certifications from IIBA and other training providers. (Since the survey design, IIBA has planned to launch a new certification: The Certification of Competency in Business Analysis [CCBA].) The majority of respondents do not hold any of the listed certifications; discussions with clients indicate that many are still creating development plans for their business analysts and waiting to see how the training and certification market develops over time before making investments.

14

As demonstrated in the 2009 survey, todays BAs have a lot of experience performing business analysis. Nearly 75% of them have more than 5 years of experience as a BA. In 2009, 72% had more than 5 years of experience.

15

As with the 2009 survey, we see that BAs have worked in many different roles. This year is the first that we included Consultant as an option, and survey results show that 41% of current business analysts have been consultants in the past. Discussions with clients indicate that consultants can be strong business analysts, because they are accustomed to working in different industries and with diverse technologies. The top eight former roles live in the application development and delivery family, with a surprising 30% of BAs having been developers and 27% having been quality assurance professionals. And 52% have served in business roles, like subject matter experts, power users, business function managers, and line of business managers, demonstrating the importance of business acumen for todays BAs.

16

The majority (54%) of business analysts want to continue as business analysts (including business analysts, systems analysts, requirements engineers, and/or business systems analysts), and 31% seek to manage teams of BAs. Interestingly, 16% want to move into a business architect position, a relatively new role that is evolving as business-centric approaches to technology become more common. To gain an understanding of the business architect role, see the October 24, 2008, The Up-And-Coming Business Architect report (http://www.forrester.com/Research/Document/0,7211,46972,00.html) and the September 27, 2010, Business Architects The Strategy Job Is Open report (http://www.forrester.com/Research/Document/0,7211,56854,00.html).

17

18

More than half of respondents claim to be generalist business analysts, having responsibility for a variety of business analysis responsibilities. This closely matches data from the 2009 survey.

19

As with the 2009 survey, todays BAs work on a variety of project types. This year, we included an option for creating a business analysis or requirements center of excellence. 28% of BAs responded that they are involved in that type of initiative, again indicating that organizations are focusing more attention on the business analysts skills and practices. Weve also seen organizations creating communities of practice bringing BAs together to share best practices, templates, and ideas with each other. See the December 9, 2008, Harness The Power Of Your Business Analysts report (http://www.forrester.com/Research/Document/0,7211,47447,00.html).

20

The breakdown of activities reported by respondents of the 2010 survey match the 2009 responses closely. Requirements definition (elicitation, analysis, documentation, and validation) makes up about a third of a BAs normal work week. This aligns with research that indicates getting requirements right early leads to higher project success and saves organizations time and money spent on rework.

21

About a third of organizations still use a waterfall development methodology, but other methods like iterative and Agile have clearly taken hold, as 45% of respondents stated that their organizations use a mix of development methodologies. This is consistent with what clients in a variety of application development roles represent through inquiry, interviews, and advisory work.

22

23

As with the 2009 survey results, communication, collaboration, and analysis topped the list of soft skills BAs need.

24

BAs also need to know a variety of techniques, including interviewing, facilitation, and negotiation techniques. 58% also stated that modeling techniques are critical or very important to business analysts. With an increase in the use of pictorial artifacts, like process diagrams, context diagrams, and use case diagrams, BAs are drawing more pictures and using fewer words to represent software requirements. See the February 3, 2010, Best Practices: Your Ten-Step Program To Improve Requirements And Deliver Better Software report (http://www.forrester.com/Research/Document/0,7211,55592,00.html).

25

In addition to packaged tools, BAs also leverage a variety of frameworks and methodologies to support their analytical processes. The IIBAs BABOK, SWOT, and Agile top the list of frameworks included in todays BA tool kit.

26

App dev pros often debate the need for BAs to have business knowledge and/or technical knowledge. In the 2010 survey, 67% of respondents stated that business domain knowledge was critical or very important, and 58% stated that knowledge of the organizations strategy was also critical or very important. Technology knowledge came in third on the list.

27

With the increased emphasis on improved business analysis and requirements practices has come an increase in the number of information websites and communities that BAs leverage on a regular basis.

28

29

The requirements definition and management tools market has exploded, thanks to an increased recognition of the importance of requirements practices. For a recent market overview, see the June 24, 2010, Right Tools. Write Requirements. Right On! report (http://www.forrester.com/Research/Document/0,7211,56810,00.html), in which we show a categorized snapshot of tools that were used as the basis for a 2010 survey question. This is the first year that we asked survey respondents to tell us what requirements definition and management tools they own or subscribe to but dont use; own or subscribe to and use regularly; or plan to purchase or subscribe to and use. The lengthy list included requirements definition and management tools and on-premise and software-as-a-service (SaaS) offerings. The following slides represent the survey responses. The large number of dont own or subscribe to responses may indicate that BAs and their leaders are focusing more on skills and practices and postponing tool investments until they have stronger practices in place. It may also be a result of the lists length and the questions positioning toward the end of the survey. Readers should keep this context in mind when interpreting the information on the following slides.

30

Requirements definition platform vendors have staked out a new market segment. Functionality isn't equivalent, but Blueprint Requirements Center, eDev InteGREAT Requirements Development Platform, and IBM Rational Requirements Composer provide a wealth of requirements definition functionality, including modeling, creating simulations, requirements authoring, test case creation, and lightweight requirements management. A centralized repository enables teams to work together through collaborative capabilities such as reviewing and commenting.

31

Other tools focus on mockups and simulations, from low to high fidelity, boasting easy-to-use drag-and-drop functionality to create wireframes and screen mockups. These tools also allow you to connect screens together to create interactive simulations. BAs use the artifacts they create in these tools to collaborate with stakeholders to validate screen flows, look and feel, and basic functionality of interaction-focused applications. These tools also communicate requirements to the rest of the development team in an easy-toconsume manner. Tools in this category provide varied functionality. Some tools, including those from iRise, Micro Focus, and Serena Software, target enterprise teams and use a centralized repository for collaboration and integration. Others, including those from Axure, Balsamiq, and Microsoft, focus on enabling a single user to install the tool easily on her desktop or laptop and start creating. See the following slide for survey responses on the use of these standalone tools.

32

In addition to the requirements definition tools charted here, Ravenflow provides tools to help users diagram business processes and use cases and then identify missing or incomplete requirements through a natural language analysis engine. There are several versions of the product, including a Word plug-in, a single-user desktop version, a server-based team version, and a plug-in for IBM Rational Requirements Composer. Ravenflow has also launched a new SaaS version of RAVEN called RAVEN Cloud. With heavy Word integration and support from partnerships with vendors such as IBM Rational, this unique tool can help business analysts get requirements right, but the 2010 survey showed very little current or planned adoption of Ravenflows products.

33

Organizations still need strong requirements management capabilities, and the stalwart vendors with their time-tested tools are still solid. Established vendors, including HP, IBM Rational, Micro Focus, Microsoft, MKS, and Serena, continue to provide robust and reliable requirements management functionality as described in the Q2 2008 Forrester Wave. The basics are all there: capture, baselining and versioning, linking and tracing, and reuse. Many have also enhanced their products to improve usability, trying to avoid becoming the dreaded shelfware thanks to overly complicated user interfaces and processes. These requirements tools also provide functionality for robust integration of requirements with other aspects of the application life cycle, such as development, change management, and testing. BAs also have new choices for managing requirements. While the established vendors command most of the market share, others are getting in on the action. A number of other players offer compelling tool sets that contain most, if not all, of the requirements management functionality that most IT organizations seek. Almost all of the tools, from vendors including Accompa, Gatherspace.com, Jama, Kovair, Polarion, Projectricity, Seapine Software, and workspace.com, also place a strong emphasis on providing requirements management functionality in the cloud available on-demand with a per-user pricing model. According to the 2010 survey, very few respondents were investigating these newer requirements management tools, but we anticipate an increased interest in this newer class of tools.
34

Fully Agile teams can choose from a group of requirements definition and management tools with functionality tailored just for them. These tools, from HP, Rally Software, Serena, and VersionOne, provide purpose-built support for Agile development through functionality such as backlog creation and management, user-story creation, iteration and release planning, and burndown charts. Definition and management come as a package integrated into an Agile ALM platform. All of the tools in this class leverage a centralized repository to support team collaboration, and they come in both on-premise and SaaS flavors. Keep in mind, however, that many of the other requirements tools on the market accommodate multiple development methods and can be used to define and manage requirements in both traditional and Agile environments. If your organization uses Agile methods particularly in combination with other processes don't limit yourself to choosing solely from the purpose-built Agile tools.

35

In the past, many organizations invested in requirements management software, only to see it become shelfware, because it was too cumbersome, and their BAs didnt have the skills to use them or practices in place for them to add real value. As with the 2009 survey, usability and ease of requirements input continue to be among the top considerations when considering investing in requirements definition or management tools. And since BAs are comfortable working in the Microsoft Office environment, they want requirements tools that integrate easily with Microsoft Office tools.

36

In addition to using purpose-built requirements tools, todays strong business analysts take a tool kit approach to defining and managing requirements, acknowledging that the best methods and tools vary based on stakeholder attributes, project type, development methodology, and business value and risk. While Microsoft Office and Visio still top the list of most-used tools, BAs make use of a variety of other tools. The use of collaboration platforms, like Microsoft SharePoint, has increased from 59% in 2009 to 70% today, indicating the increased need for strong team collaboration, as a result of geographic, cultural, and company distribution.

37

38

39