Business Analyst Guide: Workflow and Core Skills

Business analysis is the process of gathering and analyzing data to make recommendations that help an organization achieve its business goals. It is not just about high-level recommendations — it also involves designing concrete, technical action steps to make those recommendations real. The business analyst (BA) is who carries this out: identifying problems, clarifying requirements, and bridging the business and technology sides to improve efficiency and reduce costs.

What a BA actually does

Day-to-day BA work includes identifying and prioritizing the organization's functional and technical needs; analyzing large data sets with SQL and Excel; compiling charts and data visualizations; creating financial models that support business decisions; understanding business strategies, goals and requirements; planning enterprise architecture; and performing forecasting, budgeting and variance analysis. BAs often work across the hierarchy, communicating findings and helping implement changes.

In one sentence: the BA is the translator between "business language" and "technology language."

What a concrete project looks like

A concrete example helps. Say an e-commerce team notices checkout completion dropping from 61% to 52% and the owner wants to know why. A BA does not guess; the work is broken down:

  1. Pull funnel metrics for each checkout step (add to cart → enter checkout → fill address → pay) and find where the drop-off is worst.
  2. Interview support agents for real customer feedback and group the causes into price, shipping, or flow friction.
  3. Compare competitor checkout flows and build a gap list.
  4. Turn findings into requirements: shorten the form, support guest checkout, show shipping costs earlier — each with a priority.

This "data + interviews + comparison + documentation" loop is the BA job in miniature.

The standard BA workflow

Following the requirements lifecycle in the IIBA BABOK, BA work can be summarized in five phases:

  1. Understand context and stakeholders: clarify business goals, pain points and stakeholders; run a stakeholder analysis to see who influences and who is affected.
  2. Elicit requirements: collect raw requirements through interviews, workshops, surveys and document analysis — the same methods covered in user research methods.
  3. Analyze and model: turn fuzzy requirements into structured models using process modeling, gap analysis and data modeling.
  4. Specify: consolidate findings into requirements documents such as a BRD or PRD for design and development.
  5. Validate and manage: confirm with stakeholders that requirements are understood correctly, then manage later changes — see requirements change management.

Common requirements documents

Different phases produce different documents; do not mix them up:

Document Full name Audience Focus
BRD Business Requirements Document Decision-makers / stakeholders Why build, business value
PRD Product Requirements Document Design / dev / QA What to build, feature details
FRD Functional Requirements Document Dev / QA Logic and rules
SRS Software Requirements Specification Dev / QA System-level and non-functional constraints
User Story User Story Agile team One-line need from the user's view

Choosing elicitation methods

Method When it fits Cost
One-on-one interviews Deep motivation and pain points Medium
Workshops Multi-party alignment, consensus High
Surveys Large samples, quantitative preferences Low
Prototype validation Verify interaction and feasibility Medium
Document / data analysis Existing systems and data Low

Core skills

Coursera summarizes the skills a BA should have:

  • Business acumen: a solid understanding of finance, accounting and business principles helps surface operational issues and how to address them.
  • Communication: a BA must present ideas clearly and convincingly, verbally and in writing, across upper management and other teams.
  • Data analysis: familiarity with Tableau, Excel and BI tools, with some SQL as a plus; gathering, tracking and analyzing metrics is central to the role.
  • Methodologies: depending on the industry, familiarity with agile business analysis, Six Sigma, or Rational Unified Process helps.
  • Industry expertise: different industries have different needs and challenges; industry background is a strong differentiator.

Certifications and career path

Entry usually requires at least a bachelor's degree (about 70.5% of BAs hold one), then progression through practice and certification. Common certifications include the IIBA's entry-level ECBA, experienced CCBA and advanced CBAP, plus the PMI-PBA from PMI. Median total pay for business analysts in the US is about $107,000 (Glassdoor), and the US Bureau of Labor Statistics projects faster-than-average growth (about 9% for 2024-2034) for related roles such as management analyst.

Small teams do not necessarily need a dedicated BA — a product manager, founder, or even an operator can play the "mini-BA" role: run a stakeholder analysis, gather requirements systematically, and write things down clearly. That alone significantly reduces rework.

A mini-BA week

  • Monday: confirm goals and priorities with the owner; list stakeholders.
  • Tuesday and Wednesday: interview 3-5 key users and organize raw requirements.
  • Thursday: draw the current process, marking gaps and opportunities.
  • Friday: write a one-page requirement list (with priorities and acceptance criteria) and walk stakeholders through it.

FAQ

  • How do I prevent scope creep? Every change goes through "record impact → estimate effort → stakeholder sign-off"; do not let the scope quietly grow.
  • What if stakeholders disagree? Lead with data, then trade-offs, and finally pull the decision-makers into one meeting.
  • How detailed should documents be? Judge by "someone else can pick it up and execute," not by word count.

16IDC perspective

For site-building and SaaS teams, the value of BA thinking is translating business goals into executable requirements before building. Even without a dedicated BA, self-check against the workflow "understand context → elicit → model → specify → validate and manage." For more requirements-analysis methodology, see the Requirements Analysis category; for everyday collaboration and productivity tooling, see the Business Tools category. When turning customer-side requirements into reality, the Customer Service Platform Guide is also worth a look.

Source: https://www.coursera.org/articles/business-analyst
Reference: IIBA BABOK Guide https://www.iiba.org/career-resources/a-business-analysis-body-of-knowledge/