Analytically Speaking

As the art of being a business analyst evolves, we are confronted with very many questions. The advent of AI has already had us in a position to question how we can leverage it for our own success without making us obsolete. I have sat in a meeting and watched seasoned business analysts display fear of being replaced by a machine and there’s been many discourse, to which I have contributed, around how this won’t be the case. When asked what value a business analyst adds, many will list various documents we can produce and although we do more than that, documentation is important. One of the common themes that I’ve encountered is how it is often stated that software engineers do not read documentation – and I’ve wondered why that would be the case. Is the expectation that verbal communication should bare the heavy lifting in this scenario and if so, what would happen in the case where all those involved on a project move on to something else? And what about the scenario where the business analyst takes time off from work and the only thing that can speak to the work is the documentation?

Documentation serves two overarching purposes, the first which is to establish a delivery contract with stakeholders and outline requirements and the second which is for posterity’s sake – a resource to consult which would describe where a requirement came from, what purpose it serves and how the solution would work. A document should be able to stand on its own and require no further clarification on what it was created for. To this end, the question about managing expectations on what the definition of done is on a document comes into play. What are the factors that should be considered? Is it whether the author is technically adept or is it the target audience or is it possible to create an all encompassing artifact?

In my own experience, I venture into the technical solutioning and implementation but in the industry there have been scenarios where there are differing expectations on where a business analyst stops and a software engineer would take over. These boundaries, I think, are up to what is possible or required on a project as well as the skill set and growth aspirations of the business analyst and software engineer alike. In both of these scenarios, AI can be used to bridge the gap between delivery stakeholders. In a previous post, I touched on the use of Github copilot where a business analyst can use it to understand code written by a software engineer and use that to document the “as-is” component to requirements documentation and that this could also foster communication between the business analyst and the software engineer whilst using the same language. The other side of this coin is to go in the opposite direction and use AI to identify the business processes and applications supported by the code. The latter will have more gaps than the former and this is where the ability to make inferences, think laterally and critically would come into play. It is also where it becomes highly critical to embolden communication with the business stakeholders and technical stakeholders alike. Ultimately the result of all of this will be documentation which can inform the next steps and stand on its own, living throughout the implementation of the work through consistent updates.

When it comes to the boundaries of where one should start and stop, it would make sense that the point at which the next steps in implementation are clear, would be where the first boundary of the definition of done can be defined with the rest carrying on as a collaborative effort. It would also be ideal, for ease of reading to separate documentation into different artifacts. The known documents produced by a business analyst are as thus:

1. Business requirements specification which describes high level business goals, the problem statement, project scope and objectives.
   
2. Functional requirements specification which describes the requirements on a feature specific level and contains details pertaining to end user actions and functional rules.
   
3. System requirements specification which would encompass the end to end functionality of the system, it’s interactions with other systems, hardware as well as non functional requirements pertaining to things like system performance as an example
   
4. User stories where each user story can describe either what the analyst will be doing as part of the delivery process or what needs to be done on a functional and non functional level to realise the business requirements.

It is possible to combine elements of each of these documents to produce a document that is fit for purpose. This is entirely where one applies their own mind, taking into consideration what the needs of their stakeholders are. Curiosity and consultation can result in documentation that is referenced and useful to all stakeholders involved and these are things that can be enhanced and sped up by AI but the mind of a curious and meticulous BA can synthesise and create artifacts that can form the building blocks towards successful implementation and delivery of solutions. That said, armed with my curiosity, I’ll continue on in my pursuit of all the awesomeness that comes with being effective on a project as BA and using great documentation and innovative techniques as a part of delivery towards project success.