Business Analyst for Beginners: The 6 BABOK Knowledge Areas in One Example
"We need an order tracking page." Is that a need? Not yet: it's a solution. In this business analyst for beginners guide, I follow one change at a made-up online shop from the first request to after launch: what business analysis really is, the 6 core concepts (change, need, solution, stakeholder, value, context), all 6 BABOK knowledge areas in action, the finished requirements with acceptance criteria, and the 5 mistakes beginners make.
Step by step
Business analysis is enabling change
- Business analysis is more than writing documents and taking notes. The BABOK Guide from the IIBA defines it as enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Here we follow one change at a made-up online shop.
Explain like I'm 5: the good travel agent
- Think of a travel agent. A bad one sells you the first beach package. A good one first asks who is coming, your budget and what you enjoy, then shows 2 or 3 trips, and calls when you're back to ask if it was worth it. Find the need, compare options, recommend one, check it delivered.
The six core concepts (BABOK)
- The BABOK Guide's core concept model has 6 ideas: change, need (a problem or opportunity), solution (a specific way to meet a need), stakeholder, value (what something is worth to a stakeholder) and context. All 6 matter equally. When one moves, check the other 5 again.
Six knowledge areas, not six phases
- The 6 knowledge areas say what to do: planning and monitoring, elicitation and collaboration, requirements life cycle management, strategy analysis, requirements analysis and design definition, and solution evaluation. They are not phases. On a real change you move between them.
The request: "We need a tracking page"
- The customer service manager says: we need an order tracking page. That is a solution, not a need, because someone has already picked the answer. Before anything is built, run the request through the 6 core concepts in 3 pairs: the why, the who and where, and the what.
Concepts 1-2: need and value
- The why. Need: in the made-up call log, about 4 in 10 calls ask where an order is, because shoppers hear nothing after paying. Value: agents get time back, shoppers stop worrying and the shop saves on every call avoided. Write value as something you can measure.
Concepts 3-4: stakeholders and context
- The who and where. Stakeholders: shoppers, customer service agents, the warehouse, the courier, the developers and finance. That's 6 groups from one small request. Context: tracking numbers sit in a warehouse spreadsheet, not the order system, and the holiday season starts in 2 months.
Concepts 5-6: solution and change
- The what. Solution: a tracking page is one option. A shipped email with the courier's tracking link, or a text message, are others. Change: it is bigger than a page. The warehouse must save the tracking number in the order system, agents must see it, and the team needs to be shown how it works.
Area 1: planning and monitoring
- Planning and monitoring: plan your own analysis work, not the whole project. The shop works in 2-week sprints, so plan a little, often. Decide who approves requirements (the customer service manager) and where they live (a shared Confluence page). Keep the plan to 1 page.
Area 2: elicitation and collaboration
- Elicitation and collaboration: prepare, run the session, confirm what you heard. A morning sitting with the agents shows something nobody mentioned: for each call, they open the warehouse spreadsheet and read out the tracking number. Play it back to the team and write it up that day.
Area 3: strategy analysis
- Strategy analysis: where you are, where you want to be and how to get there. Today shoppers hear nothing and agents read numbers from a spreadsheet. The future: shoppers see their parcel without calling. Risks: late courier numbers, missing the holiday rush. Strategy: start small.
Area 4: requirements analysis and design definition
- Requirements analysis and design definition: write the requirements, verify them (written right?) and validate them (the right thing?). Option A, a tracking page, takes weeks and shoppers must come and look. Option B, a shipped email with the courier link, takes days and reaches everyone. Recommend B first.
Area 5: requirements life cycle management
- Requirements life cycle management: trace each requirement to the need, keep it current, prioritise it and get it approved. With MoSCoW, the tracking number in the order system is a Must have. Sales asks for text messages too, so you assess cost, delay and value. It becomes a Won't have this time.
Area 6: solution evaluation
- Solution evaluation: after the shipped emails go live, measure the value you wrote down. 6 weeks later, calls asking where an order is fall from 4 in 10 to under 2 in 10 (made-up numbers). Economy post parcels have no tracking number, so you recommend a delivery estimate at checkout for them.
Worked example: from request to requirements
- The result: the problem, the goal (fewer calls) and 3 requirements: save the courier's tracking number on the order when it ships, email the shopper the tracking link within 1 hour of dispatch, and show agents the number on the order screen. Each gets acceptance criteria. The tracking page is out of scope.
The whole change on one page
- The whole change: a 1-page plan with the customer service manager approving, a morning with the agents that found the spreadsheet, a strategy to start small, 3 requirements, 2 options and 1 recommendation, then calls more than halved. The economy post finding sends you back to strategy.
Where it lives: the tools
- Typical homes for the work: the plan and requirements on a Confluence page, each requirement as a Jira story with its ID, priority and a link to the need, the current and future process as a BPMN diagram, and the before-and-after numbers in a spreadsheet. The habit matters more than the tool.
5 beginner mistakes
- 5 beginner mistakes: treating the request as the requirement, treating the knowledge areas as phases, only talking to the person who asked, having no way to measure value, and stopping at launch.
Recap
- Recap: business analysis enables change by defining needs and recommending solutions that deliver value to stakeholders. Think with the 6 core concepts, and use the 6 knowledge areas as a toolbox you keep coming back to, not as phases. Always ask what need sits behind the request.
Common mistakes
- Treating the request as the requirement. "We need a tracking page" is a solution. Ask what problem sits behind it. Here, shoppers can't see where their order is, so they call.
- Only talking to the person who asked. List every stakeholder group and watch the real work. The warehouse spreadsheet only came to light by sitting with the agents, not by interviewing the manager.
- Value you can't measure. Write value as a number you can check later, such as the share of calls asking where an order is. Without it, you can't show the change worked or spot gaps like economy post.
- Mixing up verify and validate. Verify checks that a requirement is clear and well written. Validate checks that it really meets the need. A neatly written requirement can still be the wrong one.
When a business analyst uses this
When a manager asks for a specific feature on your first project, run the request through the 6 core concepts before writing anything. Name the need, the stakeholders, the context and a value you can measure, then bring 2 or 3 options to a workshop instead of a spec for the first idea.
Questions people ask
Does a business analyst need to know coding?
Usually not. Most business analyst work is finding needs, writing requirements and checking value. SQL and spreadsheet skills help in data-heavy roles.
What should a beginner business analyst learn first?
Start with the 6 BABOK core concepts and the 6 knowledge areas, then practise writing requirements with acceptance criteria. Common tools include Jira, Confluence, BPMN diagrams and spreadsheets.
Is there a business analyst certification for beginners?
Yes. The IIBA, which publishes the BABOK Guide, offers the Entry Certificate in Business Analysis (ECBA) for people new to the field.
