I have seen Business and System Analysts (SAs) get involved in various ways throughout the SDLC process. On one hand, Systems Analysts join forces with Business Analysts to gather business requirements and are required to approve the business requirements specification (BRS). The two work as a team with the business to understand the process, develop process flows (as-is and to-be), and document what the end product needs to accomplish. Asking questions on how certain steps of a manual business process are required to fit into an automated process can help address concerns that sometimes end up being raised too late in the game. On the other hand, a Systems Analyst is not involved in the business requirements phase at all but is expected to gather system requirements after the BRS is complete. The Systems Analyst has no control over how the requirements are captured or knowledge of the existing business process. He/she is essentially starting from scratch when it comes to not only understanding the as-is and to-be process but also finding gaps in the information provided to document accurate system requirements. Most often, they are forced to ask questions that later require updates to the BRS and cause delays in the delivery of system requirements documentation.
In addition, some Systems Analysts are heavily involved in the review and finalization of test scenarios to ensure that the proper functionality is being tested without over-testing or wasting time and effort toward testing minor details, like the word “cancelled” being spelled with one “l” or two. Sometimes, Systems Analysts are even required to provide approval to system test cases and work very closely with the UAT (User Acceptance Testing) Manager of the project to ensure the minimum functionality necessary to perform the business process is being demonstrated to the user. Finally, Systems Analysts sometimes also work closely with the Training & Education manager, or sometimes they are the Training managers. This ensures the user is being properly trained to do his/her job and perform the business process that he/she is responsible for, which is the whole reason for that particular project in the first place.
However, on many occasions, Systems Analysts are required to understand everything about the process being built inside an application but are not involved in half the phases of the project. This reality becomes more confusing when we consider that the development team seeks guidance from the SAs when it comes time to develop the solution. Further, the test team seeks guidance from and asks questions of the same SAs when testing the application. The business teams also work on a daily basis with the SAs to make sure the proper system requirements are being captured. Then, why are these same teams and users not required to involve SAs when it comes time to complete their respective work? At the end of the day, the SA becomes a crucial part of the implementation. Why are these essential participants left in the dark?
