Business Analyst's Role on Requirements
There should be no doubt that the business analyst within large or small scale projects, should have the greatest impact on the product's
requirements and downstream software requirements. The business analyst will get the overall direction and strategy from the stakeholder (e.g. CEO, external customer, VP of product) but
the business analyst will then run with the strategy and break high level objectives into the more detailed business requirements. They should define what the system will look like, how will it perform,
what are the high level features and requirements in each release.
Below are some important distinctions of the business analyst, to help shape their role.
What kind of impact is all of this having on the skills required of the business analyst? The business analyst acts as a bridge between the business and IT, translating the business's needs into a form that can be understood by the system developers (business requirements and use cases), as well as explaining to the business how it can take advantage of the capabilities of IT.
The term 'business analyst' means different things in different organisations. To some, the business analyst's job is specifically limited to defining information, usually in terms of IT system requirements. For an increasing number of organizations, however, the business analyst has a wider role that examines the environment in which the IT system operates, to ensure that the identified requirements are justified. In the terms used in this article, the business process defines the context for the requirements definition. I believe it is preferable to think in wider rather than narrower terms - it is more and more difficult to separate the definition of the to-be process from the underlying IT support. This approach is supported by the definition of the business analyst's role in the latest version of the Skills Framework for the Information Age (SFIA), which includes 'initiating and influencing enterprise-wide business process analysis'.
The increased breadth of the business analyst's role also reflects the evolving nature of the projects with which they are involved. There are very few projects involving IT alone. IT is now regarded as an enabler of business change rather than a provider of business benefits directly. It is the business change that is enabled by IT that results in the business benefits. As a consequence, the IT development work is seen as part of a larger business change programme. The focus of the business case shifts, therefore, from the IT development to the business change.
This greater responsibility now facing the business analyst implies an upgrading of their skills. At the very least, business analysts will have to be proficient at producing process models, and explaining the use cases of the business. It is heartening that the ISEB Business System Development Diploma scheme (3) has recently introduced a Modelling Business Processes Certificate. These mechanical skills are, however, only the starting point. If business-IT alignment is to really take place, the business analyst will need to act as a consultant, advising the business on how they can improve their processes. Inevitably this will involve measurement of a number of elements, including the existing processes, the expected performance of new processes, a comparison of actual against planned, and benchmarking against external organisations. That leads further into benefits management and realisation. The business analyst needs a range of both business and technical competencies - communication skills, business knowledge and political savvy as well as an appreciation of IT capabilities and the discipline necessary to carry through change built around new technology.
As stated above, the business analyst will act as a condoit between IT and the business. What this means is that the business analyst must successfully fully capture the requirements and make sure they are translated to understandable documentation for the full project team. The life-cycle documentation includes the following.
1. Assisting with the Business case
2. High level feasibility
3. Gathering of the requirements
4. Designing and/or reviewing test cases
5. Processing change requests
6. Tracing the requirements during implementation (traceability matrix)
7. Manage scope
8. Acceptance, Installation, deployment
Once the project is defined and feasibility established in sections 1 and 2, the business analyst ventures into the requirements gathering and requirements management phase. To adequately cover all areas of documentation could cover a full book, so the focus for this article will just be items 3 through 6 in the documentation steps above.
There is no one defined way to become a Business Analyst. Often the Business Analyst has a technical background, whether having worked as a programmer or engineer, or completing a Computer Science degree. Others may move into a BA role from a business role - their status as a Subject Matter Expert and their analytical skills make them suitable for the role. Business analysts often grow further into other roles as Project manager or consultant.
A Business Analyst does not always work in IT-related projects, as Business Analyst skills are often required in marketing and financial roles as well.
Business Analyst's work in different industries such as Finance, Banking, Insurance, Telco, Utilities, Entertainment, Internet and others. It is common that BAs switch between industries. The Business Domain subject areas BAs may work in include workflow, billing, mediation, provisioning and customer relationship management. The Telco industry has mapped these functional areas in their eTOM (Telecommunications Operational Map) model.
Many people often look at the role of a business analyst as someone with strong interpersonal skills and strong communication skills, or as a position where “soft” skills are more necessary than a technical background. For the most part this is true. A good business analyst will spend a large part of their day performing documentation tasks by documenting various system artifacts.
What most people don’t know, until they become a business analyst, is that the role is largely procedural, task-oriented and mundane. Yes I said, it, go ahead and sue me for saying it. It’s definitely a mundane position. If you get right down to it, the core mission of the business analyst is to translate general or rough business ideas into detailed functional requirements that can be used by the engineering team to execute on. As an analyst, you typically are managed by the project manager who may bark orders at you to create lots of documentation, some unnecessary. Why does this happened? CYA – Yes, to “cover thy ass” of the project manager to prove that all of the appropriate documentation was available.
In one nightmare position working at the Capital Group, I found myself at many requirements meetings where I’d be listening to the engineers and the product managers discuss what they thought the system should do. The project manager, working at the time had the nerve to make gestures at the business analyst with her fingers making a “scribbling” gesture in the air, basically telling them to write down everything.
A great business analyst can think at a high level and "get" the objectives of the business, is able to decipher and break down the primary use cases from the edge cases, and knows how to prioritize the most important business requirements that should be delivered first. At the same time, the business analyst should be able to get into the weeds and attend bug scrub meetings, go to design meetings to make sure engineers actually understand what they are building.
In many ways, the business analyst and the product manager will have many of the exact same responsibilities -- wireframing, requirements management, understanding traceability between business and software requirements, acting as point person between business and tech. The fundamental difference is in accountability and ownership. The product manager "owns" the product, makes key decisions about the product and releases, owns the metrics, communicates on outcomes and next steps.
The business analyst may own just a subset of those roles of the product manager and will be less proactive and have less ownership. So the business analyst should aspire to act as a product manager and should welcome a conversation from their boss that sounds like, "You're doing an awesome job and you're taking ownership, but you don't need to do all of these things." One can make the argument that being overly proactive can work against you, but in the long run having more ownership and responsbility will better serve your career. Many people often look at the role of a business analyst as someone with strong interpersonal skills and strong communication skills, or as a position where “soft” skills are more necessary than a technical background. For the most part this is true. A good business analyst will spend a large part of their day performing documentation tasks by documenting various system artifacts.