Fundamentals of Business Analysis Part 1 - Types of Business Analyst Roles
This is the first post of a series I am writing on Business Analysis. The source for this content comes from Jeremy Aschenbrenner’s Business Analysis Fundamentals course on Udemy. In this first post, I’ll briefly describe the different types of business analyst roles and provide a concrete example from my own day-to-day responsibilities as an Environmental Informations Specialist at Hatfield.
The Roles of a Business Analyst
Requirements Analyst
Works with project stakeholders to help determine, analyze, and document the requirements for the business. They dig out the needs and wants of the organization for the users which then allows solutions to be crafted. It’s possible for this role to blend in with the Systems Analyst, particularely when they become involved in the functional design of the solutions.
Systems Analyst
Doesn’t participate in requirements gathering process. Rather, takes the pre-determined requirements and works to design and craft a solution. This process involves collaboration with developers to draft a specifications sheet.
Data Analyst
Focuses on data, types of data, and relationships among data elements. This can include documenting the types and structures of the business data model as well as mining the business data for potential opportunities and risks. They also create reporting tools to help managers make business decisions.
User Experience Analyst
Designs the user interface look and interaction. Focus here is on efficiency and ease of use. A key skill of this role is understanding the end-user’s behavior, as it allows development of intuitive UI.
Business Process Analyst
Helps the executives in decision making by modeling and simulating “what-if” scenarios. Creates figures detailing current process workflows in order to help identify areas of potential opportunities and risk. Then creates figures showing future process workflows, which helps executives decide the best path forward.
A Concrete Example
It’s common for a business analyst to shift between the various roles listed above based on the needs of the business at any given time. My experience is no exception to this. My day-to-day responsibilities seem to line up best with the requirements analyst, systems analyst, and user experience analyst, with less time focused on business processes and data (that is, business data. I analyze plenty of environmental data at Hatfield).
As an example, I regularly have conversations with my supervisor over the needs and ultimate goals for Hatfield’s environmental data management software. Sometimes these are off-hand conversations while other times they are planned brainstorming sessions. I then document the salient ideas from these conversations into planning documents, which consist of a list of goals/requirements for the application and projects that we’ll work on to achieve those goals over the next few months. In this way, I perform the duties of a requirements analyst.
Once the list of needs is written, I work on writing spec sheets for each item. This step actually involves three different roles: systems analyst, data analyst, and user experience analyst. Essentially my job here is to write a specifications sheet that outlines the design of a new feature which will be implemented to meet a list of requirements. This includes the systems analyst role of working with developers to determine the specifics of the software (e.g., architectural decisions, API, various code decisions). As a data analyst, I help to design the data model based on my knowledge of the requirements and domain. This model will then be used by the application. Finally, I draft mockups of the UI for the new feature, based on my understanding of the existing software, the typical behavior of the users, and the requirements.