Some people believe the only specialists needed to create some are software developers, or engineers, as they are the ones writing the code that makes the ordering client’s dreams come true. However, in reality, there is a huge gap between the ordering client and the programmers, and a third party is required to properly bridge that gap. This isn’t not because the clients and developers are unwilling to communicate, but because they’re thinking on very different levels. The ordering client thinks about the big picture of their business and the goals the software modernization will help them achieve, while the engineer’s job, on the other hand, 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 a specific column in the specific database and more.
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.” So let us 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 walk through 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. 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 ordering customer is facing that the new solution is supposed to fix. Using this information as a baseline, the business analyst draws up the “Vision and Scope” document, which outlines business goals and priorities, the main functionality of the new solution, and the stakeholders. This work 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 the work of a business analyst. The success of the whole project largely depends on how well requirements are understood and documented before the development work begins. Requirements dictate the functionality the solution will need to solve the clients’ and end users’ specific goals, as well as the standards or conditions that the system should comply with. 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 domain or the specific company need to 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. The business analyst might also spend some time on-site at the premises of the ordering customer in order to study and document the business processes the solution is meant to support or complement.
To systematize the obtained information, the business analyst may model business processes though 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 the 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 that all requirements are possible to bring to fruition considering the planned resources and the timeline. 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 Software Requirements Specification (SRS), and it serves as a base for planning the entire development process. SRS contains the descriptions of all functionalities and options that the end product will contain. 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 as well as evolving requirements or additional feature requests. The business analyst is also on call in case the developers need any further elaboration of initial requirements. As the business analyst gathers new information, they add it to the backlog of developer task, 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.
