Some people believe the only specialists needed to create a software are developers, or engineers, as they are the ones who write the code and make the client’s dreams come true. However, in reality,
What Does a Business Analyst Do?
In a software development project, the business analyst is the intermediary between client and the development team, helping the two sides to 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.
Evaluate customer request
In general, a business analyst begins working on the customer’s request at the pre-sale stage, or 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 suit best for the client and even scope of work. To do this, the business analyst should have a clear understanding of what obstacles business need to overcome and give them an appropriate solution that can resolve this hard work. 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.
Elicit Requirements
Eliciting solution requirements is a very important part of the work as a business analyst. The success of the whole project largely depends on how well requirements are understood and documented before the development process. Requirements dictate the functionality that the solution needs to solve the clients’ and end-users’ specific goals, as well as the standards that the system must comply with. When a business analyst starts gathering requirements, they should consider three main questions:
How can 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 that is relevant to the solution
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.
Analyze requirements and approve them
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 like, 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 another.
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 foundation 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 these pre-development tasks are complete, the business analyst continues to play a critical role on the software team, staying in touch with the clients about the progress as well as evolving requirements or receiving 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, document each task 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.