Day-1 Agenda
Who is Business Analyst?
Role of Business Analyst
What does Business Analyst do?
Skills for BA
Who is Business Analyst
A Business Analyst is a person who processes, interprets and documents
requirements.
Business analysts (BAs) are responsible for bridging the gap between IT and
the business .
Role of Business Analyst.
A primary job responsibility of Business Analyst is to
Communicate with all stakeholders
Analyze the requirements
Validate the requirements.
Involve throughout the implementation Process
Explain the requirement to implementation Team
Resolve queries related to requirement and expected features
Handling change requests and performing impact analysis
To validate the developed solution before handing over to the customer
What does Business Analyst do?
A primary job responsibility of Business Analyst is to communicate with all
stakeholders & to
elicit, analyze and validate the requirements for changes to business
processes, information systems, and/or policies.
Understand what business does and how it does
Determine how to improve existing business processes
Identify the steps or tasks to support the implementation of new features
Analyze the impact of implementing new features
Skills for BA
Communication- Verbal & Written
Project management tools like Jira, Confluence
Documentation tools like Excel, Word, Visio
Knowledge of SDLC
Functional knowledge
Basics of SQL, APIs, Database
Day-2 Agenda
Software Development Life cycle
Phases of SDLC
Software Development Methodologies
Different phases of Software Development Lifecycle:
Phases of SDLC
[Link] :
In the Planning phase, project leaders evaluate the terms of the project.
Ex: Budget, Timelines , Goals, Resource Planning etc .
Planning should clearly define the scope and purpose of the application.
2. Requirements elicitation & specification
The requirements phase identifies the functionality, Business flow, and other
characteristics which the product must satisfy for it to be acceptable to the
customer.
Business Analyst uses most suitable elicitation techniques.
Once the requirement is clearly understood, Requirement is documented by
BAs. This document should be reviewed/approved by the customer and also
should be thoroughly understood by the implementation team.
3. Design
Based on the Requirement documents software architecture will be
designed.
The Design phase models the way a software application will work. Some
aspects of the design include : Architecture and technical aspects
4. Software Development
The Software design is translated into source code. All the components of the
software are implemented in this phase.
This is the actual writing of the code.
A small project might be written by a single developer, while a large project
might be broken up and worked by several teams.
5. Testing
Testing starts once the coding is complete and the modules are released for
testing.
In this phase, the developed software is tested thoroughly and any defects
found are assigned to developers to get them fixed.
It’s critical to test an application before making it available to users.
Different parts of the application should also be tested to work seamlessly
together.
This leads to a higher product quality without any defects.
6. Deployment
Once the product is tested, it is deployed in the UAT env.
Post UAT, build is deployed into production.
User guide is provided to help customers with the new functionality/changes
update.
7. Maintenance
After the deployment of a product on the production environment,
maintenance of the product is done.
As part of Maintenance Team works on production defects and change
requests.
Commonly used Software Development Methodologies
Waterfall methodology
Agile methodology
Waterfall model
Referred to as a linear-sequential life cycle model.
In a waterfall model, each phase must be completed before the next phase
can begin and there is no overlapping in the phases.
When Waterfall is used-
- Requirements are fixed,not changing frequently
- Requirements are very well known, clear
- Technology is fixed/stable
- Project duration is short
Advantages of Waterfall Model-
- Suited for smaller projects where requirements are well defined
- Documentation is done at every stage
- One Phase is done at a time so easy to manage.
- Project completely depends on project team
Disadvantages of Waterfall Model-
- Minimum client interaction
- Each phase can be started after completion of previous phase only
- Not desirable for complex projects where requirement changes frequently
- Testing comes late in the development process, errors identified at last
moment is a risk to project
- Documentation can be time consuming
- Product is available at the end of the life cycle only for customer
review/feedback
Agile Software Development
The Agile methodology is a way to manage a project by breaking it up into
several iterations.
It involves constant collaboration with stakeholders and continuous
improvement at every stage.
Once the work begins, teams cycle through a process of planning, executing,
and evaluating.
Continuous collaboration is vital, both with team members and project
stakeholders.
Some situations where the use of Agile is most appropriate are
Continuous delivery Needed.
Quick to Market
Project is big and complex
Advantages of agile-
Continuous development helps to achieve faster delivery of the software.
Customer and Implementation team interact regularly
Customer involvement & continues feedback
Late changes in the requirement can be handled
Disadvantage is agile-
Not useful for small development projects
Cost is slightly high if the project is small
Difference
Test Scenario Template
Test BA
TestScen Component/ Priori Description/Test Stat Execute Review/Comm
ario Id Module ty Summary us d By ents
Verify search
results using
TS_01 Search Bar P1 search field Pass ok
Day 4- Defect Life Cycle, RTM, Agile introduction, Agile Values
Agile Concepts
Agile Introduction and Core Values
Agile Introduction
The Agile methodology is a way to manage a project by breaking it up into
several iterations.
It involves constant collaboration with stakeholders and continuous
improvement at every stage.
The ultimate value in Agile development is that it enables teams to deliver
value faster, with greater quality.
Scrum is the most widely used Agile methodology
Core Values of Agile
Day 5 Agile ceremonies, Scrum Roles
Agile Concepts
Scrum
Scrum ceremonies
Scrum
Scrum is an agile development methodology used in the development of
Software based on an iterative.
Scrum is timeboxed and incremental process
Roles in Scrum
Scrum master – Keeper of the Process
Product Owner -owner of the requirements
Dev Team –Developers, Testers, Business Analyst
Scrum Ceremonies
Key scrum ceremonies:
Sprint planning.
Daily scrum.
Sprint review.
Sprint retrospective.
Sprint Planning
This ceremony is the Scrum Team's first step for sprint success.
Who ?
The Development Team, the Scrum Master, and the Product Owner. All of
them make up the Scrum Team.
When?
At the beginning of each sprint.
For how long?
One to two hours per week of iteration — or sprint ⏱️— should be enough. So,
if you're planning a two-week sprint, your Sprint Planning should last 2-4
hours. And considering that a sprint is usually no longer than one month, this
event shouldn't last longer than eight hours.
Daily Scrum
All members of the Development Team should inform everyone else about
how work is going.
What I did yesterday?
What I will do today?
What are the impediments?
Who ?
The Development Team (Mandatory), the Scrum Master, and the Product
Owner(Optional).
When?
Daily
For how long?
Not More than 15 minutes .
Sprint Review
Once the sprint’s work is done, it’s time to showcase it and gather feedback.
Team demonstrate what work the development team did throughout the
sprint to collect the feedback.
Who ?
The Development Team, the Scrum Master, and the Product
Owner. Optionally, management, customers, and other external stakeholders
go to these meetings
When?
At the end of the sprint
For how long?
One hour per week of the sprint. This means that in the case of a one-week
sprint, the Sprint Review should last one hour.
Sprint Retrospective
To improve what went wrong throughout the iteration and repeat what went
well.
Teams comes up with action plan to avoid the process problems in the next
sprint.
Who ?
The Development Team, the Scrum Master, and optionally the Product
Owner.
When?
At the end of a sprint.
For how long?
Forty-five minutes per week sprint .
Day 6- Scrum Master Accountabilities
Scrum Master
Accountabilities
What is Scrum Master Accountable for?
The Scrum Master is accountable for establishing Scrum as defined in the
Scrum Guide.
Scrum Master does that by helping everyone understand Scrum theory and
practice, both within the Scrum Team and the organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness.
Scrum Master and Scrum Team
Scrum Master serves the Scrum Team in several ways:
Coaching the team members in self-management and cross-functionality;
Helping the Scrum Team focus on creating high-value Increments that meet
the Definition of Done;
Causing the removal of impediments to the Scrum Team’s progress; and,
Ensuring that all Scrum events take place and are positive, productive, and
kept within the timebox.
Scrum Master serves the Product Owner in several ways:
Helping find techniques for effective prioritization
Helping the Scrum Team understand the need for clear and concise Product
Backlog items;
Facilitating stakeholder collaboration as requested or needed.
Scrum Master serves the Organization in several ways:
Leading, training, and coaching the organization in its Scrum adoption;
Planning and advising Scrum implementations within the organization;
Helping employees and stakeholders understand the best approach for
complex work
Removing barriers between stakeholders and Scrum Teams.
Scrum Master serves the Organization in several ways:
Leading, training, and coaching the organization in its Scrum adoption;
Planning and advising Scrum implementations within the organization;
Helping employees and stakeholders understand the best approach for
complex work
Removing barriers between stakeholders and Scrum Teams.
Day 7 Requirement Elicitation Techniques
Requirement Gathering
Requirement Elicitation &Techniques
Requirement status
The first and basic phase of software development life cycle
is requirements gathering. They give clear, concise and agreed set of
customer needs.
In order to bridge the gap between business and technical Team, the
business analysts must fully understand the business needs within the given
context.
Requirement Hierarchy
Business Requirements − High-level statement of business need or goal
of project.
Stakeholder Requirements − These are requirements that describe the
needs or problems of the stakeholders to implement a solution.
Solution Requirements − They describe a solution of how the stakeholder
wants to implement the business and stakeholder requirements. They are
often divided into sub-categories:
[Link] Requirements − Functional requirements describe the
scope, functionality, behavior of the product, and connection to other
systems that the d evelopers must build into the product.
2. Non-Functional Requirements- Non-functional requirements
define the system’s quality characteristics, Constraints or standards that the
system must have or comply with.
3. Transition Requirements − Requirements to make transition
from old to new system.
Requirement Elicitation Techniques
Requirement elicitation is the practice of researching and discovering the
requirements of a system from users, customers, and other stakeholders.
Most Common Requirements Elicitation Techniques
Brainstorming.
Interviewing stakeholder.
Focus Group/SME.
Document Analysis.
Existing system analysis.
Prototyping
Brainstorming
This technique is used to generate new ideas and find a solution for a
specific issue. The members included for brainstorming can be domain
experts, subject matter experts. Multiple ideas and information give you a
repository of knowledge and you can choose from different ideas.
This session is generally conducted around the table discussion. All
participants should be given an equal amount of time to express their ideas.
Interviewing stakeholder
This is the most common technique used for requirement elicitation.
Interview techniques should be used for building strong relationships
between business analysts and stakeholders. In this technique, the
interviewer directs the question to stakeholders to obtain information.
If the interviewer has a predefined set of questions then it’s called a
structured interview.
If the interviewer is not having any particular format or any specific
questions then it’s called an unstructured interview.
Focus Group
By using a focus group, you can get information about a product, service
from a group. The Focus group includes subject matter experts. The
objective of this group is to discuss the topic and provide information
A focus group typically consists of 6 to 12 members
Benefits:
You can get information in a single session rather than conducting one to
one interview.
Active discussion with the participants creates a healthy environment.
Drawbacks:
It might be difficult to gather the group on the same date and time.
Day 8 Requirement Validation Techniques SMART
What is Requirement Validation?
It’s a process of ensuring the specified requirements meet the customer's
needs.
It’s concerned with finding problems with the requirements.
These problems can lead to extensive rework costs when they are
discovered in the later stages, or after the system is in service.
The cost of fixing a requirements problem by making a system change is
usually much greater than repairing design or code errors.
Because a change to the requirements usually means the design and
implementation must also be changed and re-tested.
SMART Technique
Specific
A Specific requirement is
It is clear and non-ambiguous
It is consistent and uses the same terminology throughout
It is short and simple
Validate if a requirement is specific by asking following questions to
requirements:
What?
Why?
Who?
Where?
How?
Avoid words like “some”, “several”, “many”. Always be exact, precise and
binary ( wherever applicable; yes/no, true/false)
eg. Requirement - The download should begin in 4
It should have a unit; 4 seconds, 4 milliseconds, etc
eg. Requirement - A file needs to be sent
You need to explain:
When it needs to be sent
Where it needs to be sent
How it needs to be sent
Measurable
Requirement should be measurable in two ways:
Completion of a requirement should be a measure of progress towards a goal
The requirement completion itself should be measurable. You should be able
to prove whether the requirement was met or not during development,
testing, and real-time.
Validate if a requirement is Measurable by asking following questions to
requirements:
How much?
How Many?
How will I know when it is accomplished?
Eg. Requirement: The response time should be very fast. That isn’t
measurable.
The response time should be 2 seconds from the time the request was first
sent
Eg. Requirement: The Database entry is done : Measuable
Eg. Requirement: A confirmation dialogue box displayed: Measuable
Attainable
Do feasibility and a sanity check on requirement based on:
Technical expertise
Scope of the project
Budget
Validate if a requirement is Attainable by asking following questions to
requirements:
Is there a theoretical solution to the problem? : Review it during
soultion design phase and accept or reject it based on feasibility
Is the requirement previously done? : If yes, then find out how, what,
when, budget, duration, etc to replicate it in the current project. If no, then
find out the reason whether it was because it was never asked for or because
there were constraints or feasibility issues.
Are there any known constraints? (environmental, physical, etc) : If
yes what are those?
Eg. Requirement: Client want the chair to vibrate every time there is a
notification on the screen based on the 5D technology.
The expertise, scope, and budget don’t allow for it hence it is unattainable
and the requirement will be dropped.
Eg. Requirement: The response time to a request should be less than 1
millisecond.
The server location is very remote hence it not feasible hence it is
unattainable and the requirement will be dropped.
Reasonable
Validate the effort is worth the requirement.
This feature is an extension of the Attainable attribute covered
previously.
Validate if a requirement is Reasonable by asking following questions to
requirements:
Is it worthwhile?
Is the timing right?
Does this match our other efforts/needs?
Eg. Requirement: A user has to empty closed-lead record every week.
Whether you should automate this process?
Currently this is manual process where user selects records and moves them
into another directory. It takes user 10 seconds a week ~9 mins a year
The automating this process takes 20 hours to build.
It will take ~133 years to achieve break even.
So dont proceed
Eg. Requirement: If you classify a requirement as a "nice-to-have" and it
requires an unreasonable amount of time to complete then you may drop it.
Traceable
You should be able to track changes, dependencies and impacts of
the requirements throughout.
The Requirement should incude:
Originators: You want to know the origin of this requirement. If this is a
standalone requirement or a sub-requirement and the origin of this
requirement is another requirement i.e. the originator requirement.
Assumptions: You want to mention the assumptions associated with the
requirement that would be useful when it would be later designed or
developed.
Business Justifications: why the business needs this requirement
Dependencies on other requirements: There may be a requirement for a
report which is dependent on another feature in the system.
Importance: You want to know the priority of the requirements.
Day 9- Requirement Prioritization Technique
Requirement prioritisation techniques with example
MoScoW Technique
This method uses four priority groups: MUST have, SHOULD have, COULD
have, and WON'T have.
With this technique, BA can prioritise requirements in a collaborative fashion.
The acronym represents the following
MUST (Mandatory)
SHOULD (Of high priority)
COULD (Preferred but not necessary)
WON’T (Can be postponed and suggested for future execution)
Ranking Technique
When you rank requirements on an ordinal scale, you give each one a
different numerical value based on its importance.
For example, the number 1 can mean that the requirement is the most
important and the number n can be assigned to the least important
requirement, n being the total number of requirements.
This method works best when you are dealing with a single stakeholder as it
can be difficult to align different stakeholders’
Day 11- Estimation Techniques
BRD & FRD
Requirement Estimation techniques
Requirement Estimation
Estimation is the process for estimating the effort required to complete a
user story in the product backlog.
This effort is usually measured with respect to the time it will take to
complete that user story, which, in turn, leads to accurate sprint planning.
Estimation is done by the entire team during Sprint Planning Meeting.
Some of the most popular Agile estimation techniques:
Planning Poker
T-Shirt Size Estimation
Planning Poker is an agile estimating and planning technique that is
consensus based. To start a poker planning session, the product owner reads
an agile user story or describes a feature to the estimators.
Each estimator is holding a deck of Planning Poker cards with values like 1,
2, 3, 5, 8, 13. which is the sequence we recommend. The values represent
the number of story points, ideal days, or other units in which the team
estimates.
The poker planning process is repeated until consensus is achieved or until
the estimators decide that agile estimating and planning of a particular item
needs to be deferred until additional information can be acquired.
T shirt Sizing
T-shirt Sizing is one of the Story points sizing technique to estimate user
story usually used in agile projects. It's a relative Estimation Technique.
Rather than using a number of planning pokers, here, Items are classified
into t-shirt sizes: XS, S, M, L, XL.
With T-shirt measuring, the development team is made a request to evaluate
whether they think a story is extra-small, small, medium, large, extra-large.
What is BRD and FRD
BRD (Business Requirement Document):
BRD describes a company’s high-level goals they’re trying to achieve or
needs they’re trying to fulfill by creating a product.
FRD (Functional Requirement Document):
FRD document is a detailed and structured requirements document that
contains the “functional requirements” and “non-functional requirements”.
The Business Requirement Document (BRD) describes the high-level
business needs whereas the Functional Requirement Document (FRD)
outlines the functions required to fulfill the business need.
Comparison: BRD and FRD
BRD And FRD Document content
Day 12- What is epic, user story and acceptance criteria with
example
Handling Requirements
Writing User Stories
Epics and User Stories
An epic is a body of work that can be broken down into specific user stories.
It represents high level view of the feature/functionality.
A user story is an informal, general explanation of a software feature written
from the perspective of the end user .
The purpose of a user story is to articulate how a piece of work will deliver a
particular value back to the customer.
Project
INVEST
A good user story should be:
“I” ndependent –
The story is not dependent on other stories getting done.
“N” egotiable
The story prompts but doesn’t prescribe a solution.
“V” aluable
The story makes clear the benefit it delivers the users.
“E” stimable
The story gives the development team enough detail to
estimate the size of the story.
“S” mall
smallest piece of work that will deliver useful software.
“T” estable
The story is clear enough that you can assess if the story is
done.
User Story Format and Example
As a [type of user],
I want to [perform some task]
so that I can [achieve some goal]
As a cyclist, I want to track the location of my friends so that I can join
them on rides.
As an existing customer , I want to login to the train Reservation App so
that I can book my tickets
Acceptance Criteria
They are a set of conditions a user story should satisfy to be considered as
done.
Acceptance criteria should be written from a user's perspective
Format:
Given that [Precondition/ Prerequisite],
when [some action is carried out],
then [a set of observable outcomes should occur].
Example:
Given that the cyclist wants to ride with friends,
when they check the map view
then show them the location of other cyclists in their social network.
Example- User story with Acceptance Criteria
Login Functionality
Flow:
Positive flow -User > Login >Right Credentials >Home Page
Negative Flow User > Login > Wrong Credentials > Incorrect
Username/Password> Back to Login page
Case Study-2: Bank Account Summary
Customer logs In into system
Selects “view summary” option on home page
If current balance is greater than 0 then system displays balance and
transaction details
If current balance is less than or equal 0 then system displays error
message- “ Due to less balance transaction details cannot be fetched, please
connect with cust care on 1800 *****”
Day 16 UML
UML: Use Cases & Activity Diagrams
What is UML
Unified Modeling Language (UML) is a general purpose modelling
language.
The main aim of UML is to define a standard way to visualize the way a
system has been designed.
It is quite similar to blueprints used in other fields of engineering.
We use UML diagrams to portray the behavior and structure of a system.
What is Use Case Diagram
The purpose of a use case diagram in UML is to demonstrate the different
ways that a user might interact with a system.
Use Case Diagrams are used to depict the functionality of a system or a part
of a system.
They are widely used to illustrate the functional requirements of the system
and its interaction with external agents(actors)
A proper use case diagram depicts a high-level overview of the relationship
between use cases, actors, and systems.
What is Activity Diagram
We use Activity Diagrams to illustrate the flow of control in a system.
We can also use an activity diagram to refer to the steps involved in the
execution of a use case.
We model sequential and concurrent activities using activity diagrams.
We basically depict workflows visually using an activity diagram.
An activity diagram focuses on condition of flow and the sequence in which it
happens.
We describe or depict what causes a particular event using an activity
diagram.
Day 18 19 API SQL
Database Concepts
SQL
Most Important SQL Queries
SQL
Structured Query Language
SQL is a stusctured language for storing, manipulating and retrieving data in
databases.
SQL is used to communicate with a database.
SQL statements are used to perform tasks such as update data on a
database, or retrieve data from a database.
Every table is broken up into smaller entities called fields.
SQL Basic Commands
Most Important SQL Queries
SELECT
WHERE
AND OR NOT
LIKE
ORDER BY
DISTINCT
API
API is the acronym for Application Programming Interface,
Application Programming Interface (API) is a software interface that
allows two applications to interact with each other without any user
intervention.
More specifically an API is a program that takes requests, tells a system what
needs to be done, then returns a response.
Real time Examples: Booking a movie ticket, Booking a flight ticket,
eCommerce Payment
Day 20 Power BI Introduction
Table of Contents
What is Power BI?
Why Power BI?
Features of Power BI
Advantages Of Power BI
Disadvantages Of Power BI
What is Power BI use for
Who uses Power BI
Power BI for Business Analysis
Power BI Alternatives
Reports, Dashboards & Visualization
Versions of Power BI
What is Power BI?
Power BI is a business analytics service provided by Microsoft that lets you
visualize your data and share insights. Power BI is a technology-
driven business intelligence tool for analyzing and visualizing raw data to
present actionable information. It converts data from different sources to
build interactive dashboards and Business Intelligence reports. Which helps
an organization to make data-driven decisions.
Bridge the gap between data and decision making
Power-BI
As you see below, we have some sales data in an excel sheet. Using this
data, Power BI helps you build different charts and graphs to visualize the
data.
Why Power BI?
Following are the reasons why Power BI is so popular and needed in the BI
domain:
Access to Volumes of Data from Multiple Sources
Power BI can access vast volumes of data from multiple sources. It allows
you to view, analyze, and visualize vast quantities of data that cannot be
opened in Excel. Some of the important data sources available for Power BI
are Excel, CSV, XML, JSON, pdf, etc.
2. Interactive UI/UX Features
Power BI makes things visually appealing. It has an easy drag and drops
functionality, with features that allow you to copy all formatting across
similar visualizations.
3. Exceptional Excel Integration
Power BI helps to gather, analyze, publish, and share Excel business data.
Anyone familiar with Office 365 can easily connect Excel queries, data
models, and reports to Power BI Dashboards.
5. Turn Insights into Action
Power BI allows you to gain insights from data and turn those insights into
actions to make data-driven business decisions.
6. Real-time Stream Analytics
Power BI will enable you to perform real-time stream analytics. It helps you
fetch data from multiple sensors and social media sources to get access to
real-time analytics, so you are always ready to make business decisions.
Features of Power BI
Power BI Desktop
Power BI Desktop is free software that you can download and install, and it
allows you to build reports by accessing data easily. For using Power BI
desktop, you do not need advanced report designing, or query skills to build
a report.
Stream Analytics
Power BI's primary advantage is its support stream analytics. From factory
sensors to social media sources, Power BI assists in real-time analytics to
make timely decisions.
Multiple Data Sources
Support for various data sources is one of the vital features of Power BI. You
can access various sources of data such as Excel, CSV, SQL Server, Web
files, etc. to create interactive visualizations.
Custom Visualization
While dealing with complex data, Power BI's default standard might not be
enough in some cases. In that case, you can access the custom library of
visualization that meets your needs.
Advantages Of Power BI
User-friendly interface: Power BI has an intuitive interface allowing users to
visualize and analyze data easily.
Data integration: Power BI allows users to easily integrate data from various
sources, including Excel, SQL Server, and cloud-based sources like Azure and
Salesforce
Customizable dashboards: Users can create customized dashboards and
reports to display data in a way that is meaningful to them.
Real-time data: Power BI supports real-time data processing, which means
users can view up-to-date data in their dashboards and reports.
Collaboration: Power BI allows users to share their dashboards and reports
with others, making collaborating on data analysis projects easy.
What is Power BI used for?
Creating reports and dashboards that
present data sets in multiple ways using
visuals
Connecting various data sources, such as
Excel, onsite data warehouses, and cloud-
based storage, and transforming them into
business insights.
Turning data into different visuals, including
pie charts, KPIs, combo charts, bar and
column charts, and ribbon charts and many
other options
Providing company-wide access to data,
data visualization tools, and insights in
order to create a data-driven work culture
Easily connect to, model, creating memorable
reports personalized with your KPIs and brand.
Get fast, AI-powered answers to your business
questions
Who uses Power BI?
Power BI is used by a wide range of industries and organizations, including
healthcare, finance, retail, and manufacturing. Users of Power BI applications
include professionals who need to analyze and visualize data.
In fact, the platform is intentionally designed so non-technical users can
easily create reports, manipulate data, and perform in-depth data
analysis operations. Nonetheless, some of the most common analyst
positions that use the platform on a daily basis include the following :
Business analysts
Business intelligence analysts
Supply chain analysts
Data analyst
Power BI in Business Analysis
Business Analyst must be proficient in the application of certain tools &
technologies to effectively carry out their job duties.
You must be proficient in using Microsoft Office applications , modelling tools
such as Visio to create diagrams & flowcharts, project management tools like
JIRA.
To effectively perform Business Analysis, there are more tools should be
handy like data analysis & modelling techniques.
You should be able to use this knowledge to identify trends, patterns in the
data & to develop hypotheses about how these trends will impact the
business.
Also, you must be proficient in using this tool to communicate your findings
to stakeholders in an impactful way
Power BI alternatives
While Microsoft’s Power BI is one of the most popular business intelligence
platforms, it’s not the only one out there. As you’re exploring BI solutions for
your workplace or future career, then, you might also consider exploring
some common alternatives to Power BI, such as:
Tableau
Domo
Yellowfin
Qlink Sense
SAP Business Intelligence
Reports
A Power BI report is one or more pages of visualizations, graphics, and text.
All of the visualizations in a report come from a single semantic model.
Designers build reports and share them with others; either individually or as
part of an app. Typically, Business users interact with reports in Reading
view.
Dashboards
A dashboard represents a customized graphical view of some subset of the
underlying semantic model(s). Designers build dashboards and share them
with business users; either individually or as part of an app. If a business
user is given permissions to the report, they can build their own dashboards
too. A dashboard is a single canvas that has tiles, graphics, and text.
Dashboards can look similar to a report page. Just a few of the differences
are that dashboards have a natural language query field in the upper left
corner, and when you select a visual tile, you are transported to the
underlying report or URL or query. For more explanation, see Reports versus
dashboards.
Visualizations
Visualizations (also known as visuals) display insights that Power BI discovers
in the data. Visualizations make it easier to interpret the insight, because
your brain can comprehend a picture quicker than it can comprehend a
spreadsheet of numbers.
Just some of the visualizations you'll come across in Power BI are waterfall,
ribbon, tree map, pie, funnel, card, scatter, and gauge.