Business analysts help ensure that software developers build applications that meet user needs, whether the developers are building an application from scratch or customizing an off-the-shelf solution. To do that, they bridge the enterprise IT department and the business units.\n\nThe International Institute of Business Analysis (IIBA), a nonprofit professional association, considers the business analyst \u201can agent of change,\u201d writing that business analysis \u201cis a disciplined approach for introducing and managing change to organizations, whether they are for-profit businesses, governments, or non-profits.\u201d\n\nThe IIBA says the BA role can also have a number of other titles, including business systems analyst, systems analyst, requirements engineer, process analyst and enterprise analyst.\n\nCore responsibilities\n\nIdentifying and then prioritizing technical and functional requirements tops the business analyst's list of responsibilities, says Bob Gregory, a professor at Bellevue University and the academic program director for the business analysis and management degree program at the Bellevue, Neb., university.\n\n\u201cElicitation of requirements and using those requirements to get IT onboard and understand what the client really wants, that\u2019s one of the biggest responsibilities for BAs. They have to work as a product owner, even though the business is the product owner,\u201d Gregory says.\n\nBAs engage with business leaders and software users to understand the business process that the software will enable and how the software should operate to improve efficiencies in that process and to add value. They must articulate those ideas but also balance them against what\u2019s technologically feasible as well as financially and functionally reasonable.\n\n\u201c[They need to ask:] What do the systems need to do, how do they do it, who do we need to get input from, and how do we get everyone to agree on what we need to do before we go and do it? The BA\u2019s life revolves around defining requirements and prioritizing requirements and getting feedback and approval on requirements,\u201d says Jeffrey Hammond, vice president and principal analyst with the advisory and research firm Forrester Research.\n\nBAs also identify integration and compliance points, explains Kelly Emo,director of product and solutions marketing for application lifecycle and quality at HPE Software.\n\nEffective BAs are skilled communicators who are also able to foster collaboration.\n\n\u201cYou\u2019re often going to find folks who want different things, so BAs have to bring them to some sort of consensus so you don\u2019t have something that looks like a Swiss Army knife. They have to get everyone moving in the same direction,\u201d Hammond says.\n\nHe adds: \u201cAnd I find a little out of the box thinking is required. It\u2019s really hard to get everyone on the same page, and it requires creativity to come up with a solution that\u2019s not the obvious one.\u201d\n\nEvolving role, responsibilities\n\nThe responsibilities of the business analyst are changing, as the role evolves to meet the increased speed that business needs from its software development efforts. Enterprise IT departments are moving more of their development from a classic waterfall methodology, where BAs gather user requirements upfront and then hand them off to developers, to development processes that are more iterative and continuous, following agile and DevOps methodologies.\n\nThese changes have prompted some organizations to expand the responsibilities of their BAs so that they\u2019re accountable for successfully gathering and presenting user requirements and serving as liaisons between business units and IT as well as the successful adoption of new software applications.\n\nTo that end, many organizations measure their BAs not on the number of requirements they identified but rather on how well those requirements meet the users\u2019 needs, whether the new software meets business needs, how well the software is being used, and the users\u2019 satisfaction with the application, Hammond says.\n\n\u201cThose are the things you measure a product manager on, so we do see organizations adopt the product manager title,\u201d Hammond adds, noting that it tends to happen more frequently when a BA-type position sits within a digital business unit instead of within the IT department.\n\nIn his April 2016 report Develop Customer-Centric Applications Like The Pros Do , Hammond recommends replacing business analysts with product managers, writing \u201cproduct managers are also ultimately responsible for getting functionality right and meeting customer demands for convenience, so there\u2019s a stronger sense of accountability for functional decision-making.\u201d\n\nHe explains in an interview: \u201cIt\u2019s less the title and more the makeup of the person that\u2019s important there. You can\u2019t just take BAs and say you\u2019re product manager; you have to have people willing to accept that level of responsibility.\u201d\n\nNew tools, timing\n\nEmo says BAs working in such a manner use new tools for identifying needs. They\u2019re increasingly using real-time user data and analytics programs to identify user trends, successful functions and potential user adoption problems with the applications.\n\n\u201cOne of the key values in the concept of the BA moving into being a product owner, as the whole line between IT and digital and software development and business shifts, is that this role has become more and more exciting,\u201d Emo adds.\n\nGiven the expanding list of responsibilities put on the position, some organizations also have created product managers who work with BAs or who have teams of BAs reporting to them, Hammond says.\n\nSimilarly, the expansion and the faster, more iterative pace of software development has changed the timing of the BA\u2019s involvement with a given development project.\n\nA BA working in a classic waterfall development environment is still more heavily involved at the front end, when he or she will gather, analyze and prioritize user requirements before handing those off to developers and then moving on to another software development project, experts say. Meanwhile, BAs working on a more agile project generally stay with the project through implementation and even through multiple releases.\n\nOrganizations often assign BAs to several projects at a time if the projects are small enough, or they may assign a BA to a single project if it\u2019s complex. Hammond notes that organizations also assign multiple BAs to very large software development projects.\n\nHowever, some IT departments today are not involving their business analysts in all in-house application development projects, Emo says.\n\nShe says organizations are less likely to assign BAs to development work on the new class of applications such as mobile marketing apps and apps for temporary sales promotions \u201cbecause they\u2019re operating very lean or doing DevOps.\u201d\n\n\u201cIt\u2019s all happening very rapidly in continuous delivery mode, and it\u2019s data driven and not [driven by] lengthy requirement documents. What I see today, especially in the digital first applications, like digital e-commerce, it\u2019s not the traditional business analyst involved.\u201d\n\nOn the other hand, BAs are almost universally used for the development of back-office applications and core business software products, where identifying and documenting requirements is particularly critical, Emo says.\n\n\u201cA lot of those applications are under a lot of regulations, so [organizations] need that BA interface to document and ensure compliance,\u201d she says.