Business analysts are increasingly sought after in the information technology field: we can explain this trend in part by the general growth in business software spending (which more than doubled between 2009 and 2019*), but this is not the only factor. It is also because IT companies are increasingly realizing the importance of the business analyst in a software development initiative.
You are a client of a software development company (preferably Uzinakod…), and you wonder how a business analyst can bring value to your project? Are you a Developer or QA Analyst, and want to know how the business analyst will fit into your team and interact with you? Or maybe you’re just curious? This article is for you!
Business Analyst… Isn’t That the Person Who Handles Project Documentation?
Not exactly. Documentation for a software development project can take many forms (functional specifications, code documentation, test cases, user guides, etc.) and everyone involved in a software project is in fact called upon to maintain some form of documentation at their own level.
That said, the documentation produced by the business analyst (in whatever form) must be accessible to a wide audience: the client, who needs to make sure their requirements have been identified, and the developers, quality assurance analysts and other members of the delivery team who must fully understand said requirements. Writing skills are therefore an important asset for an analyst.
In short, the analyst must write documentation well, but they are far from being the only person involved in the project to write something other than code!
Requirements? What Are They, Exactly?
The requirements are essentially the objectives and criteria that the software and each of its functionalities must meet from the client’s point of view.
There are different levels of requirements:
- Business requirements: the business objectives that we want to fulfill with the functionality. These objectives are a function of the client’s process and their context in general.
- Functional requirements: The set of actions/activities that the functionality must allow the user to perform, as well as the expected results.
- Performance, security or user experience criteria that the functionality must meet (average response time, number of simultaneous users, etc.), which are called “non-functional requirements.”
As a Client, Do I Need to Know All These Things Already Before I Talk to a Business Analyst?
Not at all! Defining requirements is primarily a discovery process, for both the analyst and the client. It is not uncommon for clients to learn a great deal about their processes and/or the software they are currently using while talking to the business analyst.
The heart of defining requirements is understanding your current processes and issues. However, it happens often that current processes are undocumented, and based on the experience and knowledge of certain players. It also happens that when the client already has a business application in place, their team adapts to certain rules and behaviors of the application rather than the other way around. The analyst thus plays the role of an investigator who goes in search of business needs by detecting clues and avenues for improvement in the elements the client describes.
In this context, it is strongly recommended that you involve the actors who use your processes in the analysis activities, to ensure that their reality is taken into account.
As a Developer or QA Analyst, How Will I Interact with the Business Analyst?
Throughout the development process, the business analyst acts as an intermediary between the client and the other members of the delivery team (developers, quality assurance, etc.): first, by collecting and transmitting the client’s requirements to the team, but also by acting as the client’s spokesperson during the development of functionalities, ensuring that they correspond to the requirements and context of the users. The analyst may additionally be called upon to participate in the definition of the solution, or even create mock-ups or prototypes of the functionality.
The business analyst also assists the team in identifying the main usage scenarios, in order to orient the quality assurance tests by focusing on the most frequent and/or most critical scenarios.
Is the Business Analyst Also Present in an Agile Project?
Big question. The short answer is: yes! Agile development does not mean a total absence of documentation, and even less that the business analyst has no role to play in the project. And besides, as we have seen before, the analyst intervenes in each phase of the development cycle as an intermediary between the team and the client.
The long answer? Coming in a future article!
Conclusion
The business analyst is a multi-faceted player during a software development project. Their main role is to be the bridge between the client and the delivery team. On the client side, the analyst must understand the context, challenges and needs of the client.
On the development side, the analyst translates these needs into functional requirements, and acts as the client’s spokesperson in the more detailed definition of functionalities.
By turns investigator, interpreter, representative and overseer, the business analyst is a key player who has a global vision of the project and establishes the link between the various stakeholders of a software development initiative.
**
Visit our Careers page and come on board!
*Source: Statista
