I’ve been a software developer and architect for 20 years. I’ve been on projects with more than 100 people all the way down to projects where I was the only one on the team. For better or worse, it’s very normal for a lone developer to also serve as the Business Analyst on a small project. However, for the medium to large projects I’ve been on, one critical element of success has always been the BA.
When most people think of a Business Analyst, they only think of someone who documents requirements, but a good BA serves a far more crucial role for a project team.
Getting to the Heart of the Matter
Requirements gathering is difficult at best, especially when you’re in a room with Subject Matter Experts that can’t agree. Beyond simply trying to understand the business use case, customers will sometimes inadvertently make things harder by “telling you the technical solution.” Unfortunately, in my experience, most of the time this ends up being misleading because customers tend to describe only what they already know and have difficulty imagining anything beyond that. For instance, if they brought you in to replace System A, it’s crazy that they would come to you with a mock screen that looks almost exactly like System A except for a few changes to field names and other minor cosmetic alterations. However, this is exactly what happens over and again. What they miss are the fundamental reasons why System A is failing them. The true challenge for a BA is to be able to cut through the noise and to get to the heart of what will actually help a client to do their job better.
A good Business Analyst will also go far above and beyond simply documenting requirements and will sometimes also include logical data models to illustrate how they envision the data might flow in the application. This doesn’t mean that the technical team will always have to take this verbatim, but it definitely can help the developers to better understand the BA’s vision for how the new system might work.
By User:AutumnSnow – Own work; using DBDesigner, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=4070037
In addition, UI mockups can further illustrate the written requirements. A well-designed mockup can significantly speed up development by helping the architect to understand how the system might work. In my experience, this usually starts a good conversation between the BA and the architect (and maybe even the customer) which will ultimately produce an even better end product.
By Dereckson -Own work, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=28975692
Finally, for complex systems, sometimes process flows are required to show a progression of system events and/or human tasks. Even if the text of the requirements clearly state how the process should work, sometimes a flow chart can better illustrate this.
By Foundation for Public Code – https://github.com/publiccodenet/standard/releases/tag/0.1.2, CC0, https://commons.wikimedia.org/w/index.php?curid=82350717
All these artifacts come together to more effectively communicate requirements to the development team. A good BA will have as close a relationship with the architects and developers as that person has with the business. The finalization of business requirements should be a collaborative effort between the development team and the business with the BA as the intermediary.
The other advantage of having a BA gather requirements rather than foisting this on an architect is the value of another perspective. A Business Analyst is going to look at those requirements and ask if they actually address the customer’s core needs. An architect will usually approach software requirements from a more pragmatic point of view and ask if the solution that the requirements describe is technically feasible with the time and resources at hand. Both of these points of view are valid but both are required to produce mature requirements that will truly benefit the customer in the best way possible.
The Proof is in the Pudding
Since the BA is the person on the project who is usually the most familiar with the requirements, it only makes sense that this person is either fulfilling the QA role (usually for medium-sized projects that don’t have a QA team) or at least serves as a valuable resource for the QA team (usually on larger projects). Not only can the BA be instrumental in creating or validating test plans, but that person can also be helpful in ensuring that the end product works as intended by the requirements.
This is again where that other point of view is helpful. If developers are forced to QA test their own code they will invariably only ensure that the code works properly and doesn’t “explode.” An actual QA tester will create a test plan and will ensure that the code satisfies each of the bullet points on that plan. A business analyst will not only do all of these things but will also ask if the finished product is actually going to satisfy the core original business need.
But That’s Not How They’re Supposed to Use It
For development teams that exist for a long period of time after their code is in production, the Business Analyst can be an invaluable resource for Production Support. The BA can provide useful background and perspective on difficult questions. While the code may be functional, the Business Analyst may be able to see a possibility for improvement based upon how users are actually working with the application. Even with well-developed applications, sometimes the business will end up using the system in ways that nobody envisioned. A BA could be helpful in seeing patterns of use that could be optimized by making changes to the application that may not be seen by the production support and development teams.
Every Symphony Needs a Conductor
I once had a CIO say that developing a new software system is part science and part art form. The Business Analyst is ideally the conductor of that symphony between the business and technical worlds that hopefully produces an end product that may not be what the customer originally envisioned but is precisely what they need to do their job more efficiently. Not only is the Business Analyst critical for ensuring that the initial requirements are solid, but the BA can also help to ensure that the final code is both functional and correctly implements the original intent of the business requirements. Finally, the Business Analyst can spot potential improvements in the code based on how the business actually uses the application once it’s released into a production environment.