Business analysis as a discipline came into existence when the need for implementing a change in the existing systems or new systems arose to create solutions from a business perspective rather than a technology perspective. A business analyst acts as a bridge between business and technology. In simple words, business analysis ensures that the solution meets the business needs irrespective of the technology used for the implementation.
The method of business analysis is used to validate that the business requirements are simple enough for implementation without compromising the business needs. The journey starts from defining the need for the change where a business analyst team goes through a process of identifying the need for the change by analysing the existing system, end-users’ inputs, and business managers’ inputs. This process helps to identify key business needs and improve the overall business model of the organization.
The first phase starts with complicating the requirements. Let me explain this subsequently. During this phase of eliciting the requirements, a business analyst tries and gathers as much information as possible to make a clear picture of the changes required. For example, as a business analyst you receive a new requirement from business managers or stakeholders that the system needs a new webpage for customer information.
A business analyst is required to complicate the requirements and identify all the other additional details, including
- What type of customer information?
- Does it have an element of data protection?
- Do we need to go through any regulatory approval?
- What would be the user load for the webpage?
- What are the security aspects of the webpage?
- Is there a specific type of user accessing the webpage?
- Where does the webpage need to be implemented?
- Does the webpage need to support multiple platforms?
- And the list goes on…
By doing the above exercise of complicating the requirement, a business analyst builds a clear and exhaustive picture of the change. This initiates the process of building artefacts, such as Feasibility Study, Vision Document, Business Process Mapping Document, RFPs, Context Diagrams, FSDs, BRDs, and NFRDs. The set of documents changes based on the type of project or the parties involved. For example, as a business analyst, you would create additional documents, such as a request for proposal and evaluation scoring matrix when the work is outsourced to a third party.
This initiates the third phase of converting these changes/requirements into a simple palatable form for technical teams with or without the technical architect’s involvement, but it is always advised to involve technical architects at some point to ensure that the technical approach goes hand in hand with the business requirements. This can be done by creating swim lane diagrams, use cases, context diagrams, user stories, interface specifications, data mapping documents, and flow charts. The set of artefacts changes based on the type of project. For example, when an agile project is more focused on user stories, then all other artefacts become supporting documents. A waterfall project uses cases, rather than user stories.
By exercising this process of taking a simple change and complicating it and then again simplifying the complex change using different artefacts, business analysts make sure that the exact and complete business needs are conveyed to the technical development teams. This is not the end of the involvement of business analysts, but rather just the start. Business analysts make sure that the implementation done by the team agrees with the business needs communicated. This is achieved by working with test managers and helping them create test strategies and test scenarios. At the same time, business analysts help the team by resolving their queries and resolving the technical blocks by using different artefacts such as options, paper and query logs.
Business analysts work with several teams and act as the pivotal point during the deployment phase of the project. This includes creating overview documents and training guides, as well as supporting the technical writers in defining and creating outward-facing documents such as UI guides and FAQs.
Business analysis has become an integral part of the software implementation process. A proper business analysis exercise saves numerous efforts which might be required at a later stage of implementation due to a possible misalignment between business needs and technical implementation.
