Introduction
Some people believe the only specialists needed to create custom software are developers, or engineers, as they are the ones writing the code that makes the client’s dreams come true. However, the truth is that the gap in expertise between the client and the programmers is so wide that a third party is required to intermediate. This isn’t not because the clients and developers are unwilling to communicate but because they’re thinking on very different levels. The client thinks about the big picture of the business and the goals that software modernization will help them achieve, while the engineer’s job is to think about the minute details of how the software is supposed to work and how to realize the desired functionality, including everything from where the system is supposed to pull data from to how to name each specific column in the database.
In short, the developer is focused on the question of how while the ordering customer is more concerned with what for, which means that, if they were to try to communicate directly with one another, they would likely come to a deadlock more often than not. To avoid this issue—and to ensure that what the developers develop matches what the clients need—we have a wonderful role in the software development world called “business analyst.” Let’s take a look at what this specialist does.
What Does a Business Analyst Do?
In a software development project, the business analyst is the intermediary between the ordering client and the development team, helping the two sides understand each other better. This specialist “translates” the business information on the client’s goals and vision into specific requirements for the developers to follow. This role includes several key components, and we’ll explore five of them.
Customer Request Evaluation
As a general rule, a business analyst begins working on the customer’s request at the pre-sale stage, when the client first approaches a software development company. In this stage, a business analyst teams up with a sales manager and technical specialists to help determine what type of solution would work best for the client and the scope of work that may be required. To do this, the business analyst should have a clear understanding of what specific business challenge the customer is hoping the new solution will fix. Using this information as a baseline, the business analyst draws up the “Vision and Scope” document, which outlines the business’s goals and priorities, the main functionality of the new solution, and the primary stakeholders. This step ensures the client and the vendor are on the same page before any work begins.
Requirements Elicitation
Eliciting solution requirements is a very important part of a business analyst’s job, as the success of the whole project largely depends on how well requirements are understood and documented before the development work begins. The list of requirements dictates the functionality the solution will need to achieve the clients’ and end users’ specific goals, as well as the standards or conditions with which the system should comply. When a business analyst starts gathering requirements, they should consider three main questions:
- How will the business profit from the new solution?
- What is important to the end users?
- What distinctive characteristics of the industry or company should be taken into account?
To gather requirements, the business analyst usually needs to be in direct communication with client-side stakeholders, who could be company owners and managers, project sponsors, users, and/or field experts. The business analyst might also employ other methods, such as user polls or questionnaires, to identify key requirements, and they might also spend some time on-site with the customer in order to study and document the business processes the solution is meant to support or complement.
To organize all this information, the business analyst may model business processes through graphical means like diagrams, tables, and maps. Business analysts often use Business Process Management Notation (BPMN) and Unified Modeling Language (UML). BPMN allows analysts to graphically depict complex business processes and all their components—such as order processing in retail—as chains of events and conditions. This model then allows both parties to identify opportunities to automate those processes.
Requirements Analysis and Approval
When the list of requirements is ready, the business analyst discusses them with the team, including the project manager, development engineers, designers, and quality assurance engineers. Using their own experience, these specialists may point out discrepancies or gaps in the requirements. Once those are rectified, it is important to make sure it’s actually possible to bring all requirements to fruition under any predetermined resource or time constraints. Then, the team works together to determine how functionalities should be prioritized. Together with the software architect or the lead developer, the business analyst might further sort the requirements into subsystems. Once all of this is complete, the business analyst takes the requirements to the ordering customer for approval.
Prototyping
In order for the customer to better envision how the end product will look and feel, the business analyst might prepare a prototype of the user interface. The business analyst does not design the future product but creates mockups of screens that show its main functionalities. Programs such as Sketch, Axure, and Atomic allow analysts to create interactive prototypes of applications that include imitations of clickable buttons and allow users to go from one screen to the next.
Software Requirements Specification
The document that lists all the requirements the business analyst has created is called the “Software Requirements Specification” (SRS), and it serves the foundation for planning the entire development process. The SRS contains descriptions of all functionalities and options that will make up the end product. If a product is in a strictly regulated domain such as healthcare or insurance, the document will also take into account industry standards and regulations.
Even after all of these pre-development items are complete, the business analyst continues to play a critical role on the software team, staying in touch with the ordering customer about progress, evolving requirements, or additional feature requests. The business analyst is also on call in case the developers need any further details or clarification regarding the initial requirements. As the business analyst gathers new information, they add it to the backlog of developer tasks, documenting each item and tracking the progress of the project overall.
In short, while the client is an expert in their business and the software engineers are experts in development, the business analyst plays a key role in closing the gap between the two and ensuring that both parties are working toward the same vision.
