● Responsibilities of a Post Sales BA

○ Requirements Gathering
■ requirements elicitation is the practice of researching and discovering the
requirements of a system from users, customers, and other stakeholders.
○ Making Feature listings
■ Feature listing is a technique used in software development and product
management to identify and document the desired features or
functionalities of a software product or system. It involves creating a
comprehensive list of all the features that the product should have,
typically based on user requirements, market analysis, and stakeholder
input.
○ Wireframing
■ Wireframing is the process of creating a visual representation of a
website, application, or user interface (UI) design. It involves sketching or
creating low-fidelity diagrams that outline the structure, layout, and basic
functionality of the digital product. Wireframes focus on the placement of
elements, navigation flow, and overall user experience, without including
detailed design elements such as colors, typography, or visual aesthetics.
○ Writing User stories
■ A user story is an informal, general explanation of a software feature
written from the perspective of the end user or customer. The purpose of
a user story is to articulate how a piece of work will deliver a particular
value back to the customer.
○ Writing Use Cases
■ It outlines the interactions between users or actors and the system to
achieve a specific outcome.
○ Test cases
■ They are detailed descriptions of specific scenarios or conditions that
need to be tested to ensure that a software system meets its
requirements and functions correctly. Test cases typically include inputs,
expected outputs, and any specific conditions or steps to be followed
during testing.
The software development life cycle (SDLC) is a structured process that guides the
development of software applications. It encompasses a series of phases and activities, from
initial planning and requirements gathering to software deployment and maintenance. Here is an
overview of the typical phases in the SDLC:

● Requirements Gathering: analyzing the requirements of the software. This involves

understanding the needs of the users and stakeholders to define the scope and
objectives of the project.
● Designing
● Development: The actual coding and development of the software take place in this
phase. The development team uses programming languages, frameworks, and tools to
write the code and build the software based on the design specifications.

● Testing: The software undergoes various testing activities to ensure its quality and
functionality. This includes unit testing, integration testing, system testing, and user
acceptance testing. Bugs and issues are identified and fixed during this phase.

● Deployment: Once the software passes all the testing phases, it is deployed to the
production environment or made available to the end-users. This involves activities such
as installation, configuration, and data migration.

● Maintenance: After the software is deployed, it enters the maintenance phase. During
this phase, bug fixes, updates, and enhancements are made as necessary to address
issues that arise in the production environment. This phase ensures the software
remains functional and up-to-date throughout its lifecycle.

Documents:
● Scope Of Work
● FRD
● BRD
● SRS
● User Stories

A functional requirements document (FRD) is a formal document that outlines the detailed
functionalities, features, and capabilities of a software system or application. This document is
made to ensure a clear understanding of what the software should accomplish.
The FRD typically includes the following components:

● Introduction: This section provides an overview of the software system and its purpose. It
includes information about the intended users, business objectives, and high-level
project goals.
 ● Scope: The scope section defines the boundaries and extent of the software system. It
describes the functionalities and features that will be included and specifies what is out
of scope for the current project.
● Functional Requirements: This is the core section of the FRD and details the specific
functionalities and features that the software system should deliver. Each requirement is
typically described using a standardized format, including a unique identifier, a
description of the requirement, and any associated acceptance criteria.
● Use Cases or User Stories: Use cases or user stories provide specific scenarios or
interactions that users will have with the software. These help illustrate how the software
should behave and what actions and outcomes are expected in various situations.

A business requirements document (BRD) basically captures business needs and objectives
for a proposed software system or project.
The BRD typically includes the following components:

● Project Background: This section provides context and background information about
the business problem or opportunity that the proposed software system aims to address.
It may include details about the current processes, challenges, or market trends that
necessitate the project.

● Objectives and Goals: The objectives and goals section outlines the desired outcomes
and benefits that the software system should achieve. It describes the specific business
needs, improvements, or efficiencies that the project aims to deliver.

● Scope and Boundaries: This section defines the scope of the project and clarifies what is
included and excluded. It helps manage expectations and avoid scope creep by clearly
defining the boundaries and limitations of the software system.

● Stakeholder Analysis: The stakeholder analysis identifies and describes the key
stakeholders involved in the project. It includes information about their roles,
responsibilities, and expectations, helping ensure that their perspectives and needs are
considered during the project.

The Business-Level: analyzing the business process (work flows and operations)
The Information-Level: how data and information is stored and maintained

A Software requirements specification ( SRS ) document describes the intended purpose,

requirements and nature of a software to be developed. It also includes the yield and cost of the
software.
PROBLEMS FACED WITHOUT A BUSINESS ANALYST

If a business analyst is not deployed in a project, several problems may arise:

● Unclear Business Requirements: Business analysts play a crucial role in gathering,

analyzing, and documenting business requirements. Without their involvement, there is a
higher likelihood of unclear or ambiguous requirements, leading to misunderstandings
and misaligned expectations between stakeholders and the development team. This can
result in rework, delays, and a final product that does not meet the business needs.

● Lack of Stakeholder Alignment: Business analysts act as a bridge between

stakeholders and the development team, ensuring that everyone's perspectives and
needs are considered. Without a business analyst, there is a risk of inadequate
stakeholder engagement and poor alignment between business goals and the software
solution. This can result in a product that fails to address critical business needs or lacks
support from key stakeholders.

● Inefficient Project Planning: Business analysts contribute to project planning by

defining project scope, identifying risks, and establishing project goals. Their absence
can lead to inadequate planning, unclear project objectives, and challenges in estimating
project timelines, resources, and costs. This can result in project delays, budget
overruns, and overall project inefficiencies.

● Limited Business Process Understanding: Business analysts are responsible for

analyzing and documenting existing business processes, identifying improvement
opportunities, and proposing solutions. Without their expertise, there may be a lack of
understanding of current processes and an inability to identify potential process
improvements or automation opportunities. This can hinder the development of an
effective software solution that aligns with business workflows.

● Reduced Communication and Collaboration: Business analysts facilitate

communication and collaboration between stakeholders, development teams, and other
project members. They act as a liaison, ensuring that requirements are clearly
communicated, questions are addressed, and feedback is incorporated. Without a
business analyst, communication gaps can arise, leading to misunderstandings, delays,
and decreased collaboration among project participants.

● Limited User Experience Focus: Business analysts consider user needs and
expectations when defining requirements and designing the user experience. Their
absence may result in a lack of focus on user experience, leading to a subpar interface,
decreased usability, and lower user satisfaction. This can impact the adoption and
success of the software system.
‘AS IS’ AND ‘TO BE’ PROCESS MODELS
as-is maps where your processes are and to-be maps where you want them to be. The as-is
phase outlines the current state of your processes and any gaps or issues with the current
mode of operation. Once you have that mapped out, you can enter the to-be phase of process
management.

What is a RAID log?

A RAID log is a form that project managers use to list and monitor potential risks, assumptions,
issues, and dependencies related to the project as well as to identify possible mitigation options.
Each team member typically has access to this RAID log, but only certain members may have
the ability to make adjustments as necessary. Project managers can assign different team
members to various challenges to make sure everything is taken care of properly.

What does RAID stand for?

RAID stands for Risks, Assumptions, Issues, and Dependencies, which represent the various
components of the project management technique. RAID is a project management style that
managers use to identify potential challenges within the project and to develop options to
resolve these issues. Project managers often use a RAID project management template to
record, monitor, and update these potential challenges.

Requirement Traceability Matrix (RTM) is a document that maps and traces user
requirements with test cases. It captures all requirements proposed by the client and
requirement traceability in a single document, delivered at the conclusion of the Software
development life cycle. The main purpose of Requirement Traceability Matrix is to validate that
all requirements are checked via test cases such that no functionality is unchecked during
Software testing.

Use Case diagram

- A use case diagram is a visual representation of the interactions between actors (users
or external systems) and a system.
- A use case diagram is a graphical depiction of a user's possible interactions with a
system. A use case diagram shows various use cases and different types of users the
system has

Activity diagram
- An activity diagram is a visual representation of the flow of activities or actions within a
system or process.
- It illustrates the sequential and parallel activities, decision points, and the flow of control
between different activities.
Object diagram
- An object diagram is a visual representation of a system at a specific point in time,
showing the objects and their relationships.
- It provides a snapshot of the objects and their attributes and associations in a given
scenario.

Class Diagram
- A class diagram is a visual representation of the structure and relationships among
classes in an object-oriented system.
- It illustrates the attributes, methods, and associations of the classes.

Payment Gateways used in india

- Paytm
- Razorpay
- Paypal
- CCAvenue
- EaseBuzz
- Cash Free
- Bill Desk

Scope creep is the uncontrolled expansion of a project's requirements, features, or

deliverables, without adjusting the time, cost, or resources accordingly.

A Work Breakdown Structure (WBS) - It is breaking down a project into smaller, manageable
components called work packages. It organizes the project work into a structured framework,
making it easier to plan, execute, and control the project. Each level of the WBS represents an
increasing level of detail.

In app purchases vs payment gateway

Hybrid & Native tech stack

-Native with major hardware complicity & Hybrid with low

In-App Purchases:
When an app offers in-app purchases, it means that you can buy additional content, features, or
virtual items directly from within the app itself. For example, in a gaming app, you might have
the option to purchase extra lives, special weapons, or unlock new levels. In-app purchases are
typically handled by platforms like Apple's App Store or Google Play Store, which have
integrated payment systems. When you make an in-app purchase, the payment is processed
through your app store account, and the app developer receives a portion of the revenue.
Payment Gateways:
Payment gateways, on the other hand, are services that handle online payments for various
businesses, including those that operate outside of mobile applications. They enable the
processing of transactions by securely transmitting payment information between the customer,
the app or website, and the bank or financial institution. Payment gateways work as
intermediaries, ensuring that the transaction details are securely transmitted and processed.
They support various payment methods like credit cards, debit cards, and sometimes digital
wallets.

To summarize, in-app purchases specifically refer to the ability to buy additional content
or features within a mobile application, while payment gateways are broader services
that facilitate online payments for various businesses, including those operating outside
of apps.

Functional Requirements Document (FRD) Components:

● Introduction: Provides an overview of the document, its purpose, and the intended
audience.
● Scope and Objectives: Defines the boundaries of the project and outlines the specific
goals and objectives of the software system being developed.
● Functional Requirements: Describes the specific functions and features of the software
system, including both high-level and detailed requirements. This section typically
includes functional use cases, user stories, and any necessary business rules.
● Non-Functional Requirements: Covers requirements that are not directly related to the
system's functionality but are essential for its successful operation. This includes
performance, security, reliability, scalability, usability, and other quality attributes.
● User Interfaces: Specifies the user interface design, including wireframes, mockups,
and user interaction details.
● Data Requirements: Defines the data entities, their attributes, relationships, and any
data constraints or validation rules.
● System Interfaces: Describes the external systems or services that the software system
needs to interact with and defines the interface requirements for seamless integration.
● Reporting and Analytics: Outlines the reporting and analytics capabilities required by
the system, including the types of reports, data visualization requirements, and any
specific analytics or data processing needs.
● Constraints and Assumptions: Documents any known constraints, limitations, or
assumptions that may impact the design or implementation of the software system.
● Glossary: Provides a list of key terms and their definitions to ensure a common
understanding of terminology within the document.

Business Requirements Document (BRD) Components:

 ● Executive Summary: Provides a high-level overview of the project, its objectives, and
the business need it aims to address.
● Project Background: Describes the context and background information about the
business problem or opportunity that the software system intends to solve or exploit.
● Business Objectives: Clearly states the business goals and objectives that the
software system should help achieve.
● Stakeholder Analysis: Identifies the key stakeholders involved in the project and their
roles, responsibilities, and expectations.
● Current Business Process: Analyzes and documents the existing business processes
and workflows, highlighting any pain points or areas for improvement.
● Proposed Solution: Describes the proposed solution to address the business needs,
including the high-level system architecture, technology considerations, and any external
dependencies.
● Business Rules: Defines the specific business rules, policies, regulations, or standards
that the software system should adhere to.
● Project Scope: Clearly defines the boundaries and limitations of the project, outlining
what is included and excluded from the scope.
● Risks and Assumptions: Identifies potential risks, uncertainties, assumptions, and
dependencies associated with the project.
● Project Timeline and Deliverables: Outlines the project timeline, major milestones, and
the expected deliverables at each stage.
● Budget and Resource Requirements: Specifies the estimated budget, resource
requirements, and any financial considerations associated with the project.

General Third Party API’s

Payment Gateways:
● PayPal API
● Stripe API
● Braintree API
● Square API

Social Media Integration:

● Facebook Graph API
● Twitter API
● Instagram API
● LinkedIn API

Mapping and Geolocation:

● Google Maps API
● Mapbox API
● OpenStreetMap API
 ● Bing Maps API

Email and Messaging:

● SendGrid API
● Twilio API
● Mailchimp API
● Mandrill API

Cloud Storage and File Hosting:

● Amazon S3 API
● Google Cloud Storage API
● Dropbox API
● Box API

Machine Learning and AI:

● Google Cloud AI API
● Microsoft Azure Cognitive Services API
● IBM Watson API
● OpenAI API

Weather Data:
● OpenWeatherMap API
● Weatherbit API
● AccuWeather API
● Dark Sky API

Authentication and Authorization:

● OAuth 2.0 API (used by various providers like Google, Facebook, etc.)
● Auth0 API
● Okta API
● Firebase Authentication API

Analytics and Tracking:

● Google Analytics API
● Mixpanel API
● Segment API
● Amplitude API

Image and Video Processing:

● Cloudinary API
● Amazon Rekognition API
● Google Cloud Vision API
 ● Microsoft Azure Computer Vision API

Thing to cater for Requirement

1️⃣ Understand the Real Purpose: To provide an effective upgrade, it's crucial to identify the true
motivations behind the customer's desire for change. Knowing their goals ensures we align our
solutions with their needs.

2️⃣ Focus on Project's Goodness: Rather than being solely driven by time and cost, prioritize
what is truly beneficial and ideal for the project. Opt for solutions that optimize project outcomes
and deliver long-term value.

3️⃣ Offer Multiple Options: Presenting customers with at least two genuine solutions enables
them to make an informed decision. Provide a cost-effective, time-efficient option alongside the
higher-end solution, catering to diverse requirements.

4️⃣ Tailor the Pitch: Customizing the pitch to suit the customer's conditions, stage, budget,
stature, and position is essential. Conduct thorough customer due diligence to understand their
specific needs and expectations.

Scrum is an agile framework for managing and delivering complex projects, particularly in
software development, but it can be applied to various other fields as well. It was originally
formalized by Ken Schwaber and Jeff Sutherland in the early 1990s and has since become one
of the most popular and widely adopted agile methodologies.

Key elements of Scrum:

Product Owner: Represents the stakeholders and defines the project's vision. Responsible for
prioritizing the product backlog items.

Scrum Master: Facilitates the Scrum process, helps the team stay focused, and removes
impediments.

Development Team: Self-organizing and cross-functional group responsible for delivering the
product increment.

Product Backlog: An ordered list of all features, enhancements, and bug fixes that make up
the project's requirements.
Sprint Backlog: The subset of product backlog items that the development team commits to
deliver during a sprint.

Increment: The sum of all the product backlog items completed during a sprint, along with all
previous increments. It represents the latest version of the product.

Sprint: A time-boxed period (usually 2-4 weeks) during which the development team works to
complete the committed items from the sprint backlog.

Sprint Planning: A meeting at the beginning of the sprint where the team plans the work to be
done in the upcoming sprint.

Daily Scrum (Daily Standup): A brief daily meeting where the team synchronizes activities and
plans for the next 24 hours.

Sprint Review: A meeting at the end of the sprint to demonstrate the increment and gather
feedback from stakeholders.

Sprint Retrospective: A meeting at the end of the sprint where the team reflects on its
performance and identifies improvements.

Transparency: All aspects of the project should be visible and understandable to everyone
involved.

Inspection: Progress should be regularly assessed and evaluated to detect variances and
adapt accordingly.

Adaptation: If the project veers off track or new information emerges, the team should adjust
their plans and approach.