What Is a Business Analyst?
In short A business analyst helps an organization change for the better: they work out what is really needed and recommend solutions that deliver value to the people involved. The job title varies; the work defines the role.
Based on: IIBA, BABOK® Guide v3, section 2.4.1; IIBA, Global Business Analysis Core Standard; K. Wiegers, J. Beatty, Software Requirements, 3rd ed., ch. 4; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., ch. 1.
On this page
Key ideas#
A role, not a job title#
In the BABOK® Guide, business analysis is the work that makes organizational change possible: working out what the organization needs, then recommending solutions that are worth having for the people affected. The business analyst is the person responsible for that work. The BABOK Guide also treats the analyst as a stakeholder in every business analysis activity: they own the work and sometimes coordinate how other roles contribute to it.
Many people do this work under other titles. IIBA’s Core Standard lists, among others, systems analyst, process analyst, data analyst, product manager or product owner, management consultant and business architect. Wiegers and Beatty add requirements analyst, requirements engineer and IT analyst. The BCS book frames the analyst as an internal consultant who investigates business situations, evaluates options for improvement, defines requirements, and helps the business get value from its information systems.
What the work looks like#
Wiegers and Beatty describe nine typical activities:
- Define the business requirements (why the change is needed).
- Plan how requirements work will be done.
- Identify stakeholders and user classes.
- Elicit requirements.
- Analyze them.
- Document them.
- Communicate them to the people who need them.
- Lead their validation.
- Facilitate prioritization and manage requirements over time.
In BABOK Guide terms, this work spreads across all six knowledge areas: Planning and Monitoring, Elicitation and Collaboration, Requirements Life Cycle Management, Strategy Analysis, Requirements Analysis and Design Definition and Solution Evaluation. How you do it depends on your underlying competencies and on the perspective you work in (agile, BI, IT, business architecture, process management).
Typical work products#
- A problem statement and business objectives, often in a vision and scope document or a business case.
- A stakeholder list or map.
- Current- and future-state process models.
- Requirements in a form the team can use: user stories, use cases, non-functional requirements, business rules, a glossary.
- Acceptance criteria and a prioritized backlog.
- Traceability and a record of changes.
- After launch: metrics showing whether the solution delivers the expected value.
How it differs from neighboring roles#
| Role | Main focus | Where it meets business analysis |
|---|---|---|
| Project manager | Delivering the project: balancing scope, budget, schedule, resources, quality and risk (the BABOK Guide’s description) | Wiegers and Beatty: the project manager communicates about the project, the analyst about the product. |
| Systems analyst | How an IT solution will work: system behavior, data, interfaces | The BCS book treats IT systems analysis as a neighboring area that some organizations merge into an “IT business analyst” role. |
| Product owner | Product value: vision, roadmap, backlog order | In the BABOK Guide’s agile perspective, the analysis role may be played by a product owner, a business analyst or another role. Analysts often act as a proxy product owner. |
| Strategy analyst / business architect | Enterprise direction and structure | The BCS book places strategic analysis mostly outside the analyst role, but expects analysts to understand the strategy they serve. |
When one person combines roles, Wiegers and Beatty stress that these are still two jobs needing different skills.
What sets good analysis apart#
The BCS book lists guiding principles for the role. In short: root causes over symptoms; business improvement over IT change for its own sake; options over a preset solution; feasible requirements over every request; the whole change lifecycle, not just the requirements phase; negotiation over avoiding conflict; and timely answers over perfect ones.
How to apply it#
- Write down your scope. Mark which of the nine activities you own, which someone else owns, and which nobody owns. Unowned activities are risks.
- Separate your hats. If you also manage the project or own the product, keep product questions and project questions apart, and say which hat you are wearing.
- Agree on deliverables early. Name each work product, its audience, its format and its due date.
- Challenge solutions disguised as requirements. Ask what problem a request solves (see Why? What? How?).
- Be creative, openly. Wiegers and Beatty encourage analysts to propose capabilities customers have not thought of, but to propose them for approval, not build them quietly.
Example#
The owner of The Workshop, a fictional chain of 12 bike-repair workshops, says: “We need an app like the big chains have.” The analyst does not start by listing screens. In the first weeks they:
- map stakeholders, from mechanics and front-desk staff to the parts supplier and the outside development team;
- find the underlying problems: front-desk staff spend hours on “is my bike ready?” calls, and parts often arrive late;
- write business requirements such as “customers can check repair status without phoning”;
- model the current booking process;
- leave budget and contract questions to the project manager and keep the product questions.
Pitfalls#
- Acting as a scribe. Recording what people say is not analysis. Ask why, compare sources, look for gaps.
- Blind spots from your background. Wiegers and Beatty note that analysts come from five typical backgrounds: former users, former developers or testers, project managers, subject-matter experts, and new graduates. Former users tend to describe requirements as screens too early. Former developers may lack patience with users.
- Underrating the role. Wiegers and Beatty cite COCOMO II estimates suggesting an experienced analyst can cut project effort by about a third compared with an inexperienced one.
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Section 2.4.1 (the business analyst as a stakeholder); section 11 (agile and IT perspectives).
- IIBA. Global Business Analysis Core Standard. International Institute of Business Analysis. Section “Who is a Business Analyst?”.
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Ch. 4 (the business analyst: tasks, skills, backgrounds).
- D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Ch. 1 (role, scope and guiding principles).