The explosion of digitalization boosted the speed at which businesses adopted technology in their daily processes. The adoption rate today is almost three to four times high when compared to the pre-pandemic period.

As with technology, one solution does not solve every problem. Hence, the business houses hire software architects who can build applications to automate their working procedures and enable remote collaborations. 

Bridging the gap between businesses and the technology is the Business Analyst; one who understands the business requirements and can sync them with the technical counterpart. The blog covers topics from a BA’s role and responsibilities at different levels to technical documents and special terms they should know.

Business Analysis at different stages.

• Pre-Project: The pre-sales BA is responsible for gathering initial level requirements. This stage includes steps: analyzing the currently deployed systems, creating a problem statement, conducting market and competitor research, preparing business cases, vendor assessment, etc. 

• During Project: Once the client comes on board, the information & technology BA synchronizes the development team efforts and ensures that everyone is on the same page. The to-do list for this phase includes: eliciting business requirements from stakeholders; creating requirements documents (BRD, SRS, FRD, etc.); outlining the proposed system functionalities, features and rules; providing support to the testing and development team; ensuring continuous quality testing and identifying improvements, etc.

• Post-Project: After system deployment, the main task is regarding support and maintenance. It is common for the client and end-users to face issues in the application; hence, prompt post-deployment services are crucial. The BA’s job in this phase: assess the reported bugs and issues, understand problems faced by users, create a list of recommended new features or functionalities, look for growth opportunities, etc.

BA (Post-Sales) Document Responsibilities

Under Waterfall Methodology

• Process Models and Design Document: This document includes analyzing the current state/processes, identifying problem and improvement areas, and recommending a future course of action.
• BRD: The Business Requirement Document consists of information like the problem statement, the possible solutions, and a macroscopic outline of the features the application will have. BA creates this document, and the users are the Product Manager, Product Owner, and Client. For a detailed description of BRD, please refer to the blog on tips to write the perfect business requirement document.
• FRD: The Functional Requirement Document concerns itself with the functional aspect of the system or application. The technical team and the BA are the major part of this document as it drills down the technical requirements and tells how the system is expected to function. It is a technical-data-rich document.
• SRS: The Software Requirement Specification outlines the features and behavior of the system or application. It also enlists the functional and non-functional requirements and is less macroscopic (or more detailed) in nature when compared with a BRD.
• Use Case: This document contains use case diagrams. The key user identification and requirement gathering are part of the deliverable. The BA is also responsible for sketching use scenarios.
• Data Model: Information about conditions and relationships between entities is given.
• UI: It is a crucial deliverable. The BA designs wireframes and mockups that outline a visual representation of the proposed system. The user behavior is also taken into account during the process.
• QA: Activities like test case (preparation and review), creating test strategies/plans, change request documentation, etc. form part of this process.
• Others: Includes but is not limited to user manuals, training materials, data migration models.

Under Agile Methodology

The BA deliverables under a scrum-based project:

• User stories with acceptance criteria based on frequent discussions with the product owner and the team.
• Aid in quality assurance activities by preparing, reviewing, and executing test cases.
• Creating product user manuals, guides, and videos for reference and use of stakeholders.

The Epic Flow & key terms every BA must know.

Epics -> User Stories -> Tasks -> Subtasks

• Epics: It is a large body of work with one common objective. The work is further divided into small user stories, where each user story might contain a business requirement, feature, customer request, etc. Sometimes user stories are complicated. Hence, there is a need to divide them further into tasks and subtasks. It helps to set accountability for each job done/not done and ensures timely delivery of items in the backlog.
• User Stories: These are small descriptions written from the perspective of the user/customer of the application. They describe the feature and the reason behind its inclusion from the user’s perspective.

A user story is written in the format > As a (user), I want (the goal) so that (the reason).

For example, in an application with a Login Page, the user expects to have the Forget Password option. The user story in this case will be: As a user, I want the forget password option so that I can reset the password if I ever forget the original one.

• Acceptance Criteria: Continuing with the Forgot Password example, this option will have some prerequisites or acceptance criteria like the page URL, buttons (forgot password, submit, etc.), error message, and more. A user story is not approved unless it meets the acceptance criteria.

• Definition of Done (DoD): When all possible user stories are approved by a user or a customer, it gets assigned with the DoD status. The flow of DoD is: User story review > UI > HTML > Development > QA > Deploy. The acceptance criteria of each user story are different, but the DoD flow is always the same.
• User Story v/s Use Case: A common confusion occurs between a user story and a use case. The former describes features of the application. Whereas the latter explains how the application will react when an external user triggers an action.

The Agile Methodology

Software product development in today’s time is impossible without the agile methodology because it helps products stay relevant in the dynamic business environment. As per this model, a project should be developed and delivered in phases instead of whole. You can read in detail about the agile methodology here.

There are three parties in this software development model: Product Owner, Scrum Master, and Scrum Team.

• Product Owner is responsible for gathering requirements, task management for the team, and creating/managing the backlog. The owner is also responsible for sprint planning, which means deciding the task log for the sprint.
• Scrum Master is responsible for managing the daily scrum. Questions like what are you doing today, which tasks were completed yesterday, etc, set the agenda.
• The Scrum Team includes all the participants who join the sprint.

For more information on the scrum, sprint and the different components, kindly refer to this blog.

The Lead to Opportunity Model

It is a business generation model followed by some organizations for small accounts. The process starts with identifying business leads. A lead is a demand for services offered by the company, and they can generate from various resources like company website, LinkedIn platform, third-party reference, email campaigns, etc. If there is an identified demand for a service, then it automatically becomes a lead.

Lead > Opportunity

The next step after lead identification is to explore and convert it into an opportunity. The process starts with approaching the client via email and scheduling a call. The aim is to identify the project scope, creating a vision document, drafting a problem statement, outlining the feature list, sharing a reference to similar applications, etc.

Multiple calls and brainstorming sessions later, an application feature list comes to life. The feature list (including the required tech-stack) is given to the client. If the client agrees to the feature list, then a Service Level Agreement (SLA) is drafted. It includes an estimate of man-hours or man-weeks the resources will dedicate to the application and the per hour cost of those resources.

Over to you.

That was all from my end, based purely on my own experience as a Business Analyst. If you think I missed anything or you would like to add resourceful information, please feel free to write at hello@sarvika.com or click here.