Business, Projects and Management
Business analysis and requirements
Business analysts work between the people who have a problem and the people who will build the solution, and their job is to make sure both are describing the same thing. That means finding out what is really needed, writing it down so it can be tested, and later checking whether the delivered change did what the business wanted. It is the discipline most projects discover they needed once it is too late to add.
Why this topic exists: Elicitation, requirements life cycle, strategy analysis, solution evaluation: BABOK v3's six knowledge areas, the discipline between the business and the build (SFIA Change analysis).
Most failed systems were built correctly to the wrong requirement. Business analysis exists to catch that before the build rather than after launch. The analyst investigates how the business works today, what it is trying to change and why, and turns that into requirements precise enough for designers and developers to act on and for testers to check. In agile teams the same work happens in smaller pieces, often as user stories and backlog refinement, but it does not disappear.
The six knowledge areas
- Planning and monitoring the analysis: deciding how analysis will be done on this piece of work, with whom, and how its own quality will be judged.
- Elicitation and collaboration: interviews, workshops, observation and document review, then confirming with people that what was heard is what they meant.
- Requirements life cycle management: tracing each requirement from its source to the solution, keeping the set current, and handling changes and approvals.
- Strategy analysis: describing the current state, the desired future state, the gap between them and the risk of crossing it.
- Requirements analysis and design: modelling, specifying and prioritising requirements, then weighing solution options against them.
- Solution evaluation: checking whether what was delivered produces the value it was meant to, and what holds it back.
SFIA files the same ground under change analysis, next to feasibility assessment, business modelling, the analysis of a business situation and user acceptance testing, a reminder that an analyst's work runs from before a project exists to after it ends. Process models in BPMN, data models and prototypes are the most common techniques. None is compulsory, and the choice depends on who has to read the result. Analysts in regulated industries lean on formal specifications; those in product teams lean on examples and sketches.
Write the test with the requirement
A requirement nobody can test is an opinion. For each one, note how someone will know it has been met: a number, a scenario, an example of correct output. If you cannot, the requirement is not finished, and the conversation that finishes it is cheaper now than during acceptance testing.
Where the role goes next
The beginner's mistake is recording what stakeholders ask for rather than what they need. People describe solutions, a new report, an extra field, another approval step, and the analyst's job is to ask which problem each one solves, because the answer is often a different and smaller change. From analysis, careers lead towards product management, where the analyst's questions become decisions about value, towards architecture, or towards change management. IIBA runs a certification ladder for analysts, not yet covered on these pages; CAPM includes business analysis frameworks in its outline, which makes it a reasonable first credential for analysts who work inside projects. Analysts who stay in the role become the people others call when a project has lost track of why it exists.
Next to this topic
- Project management fundamentalsCharter, scope, schedule, cost, risk and stakeholders: the predictive vocabulary of PMBOK 7's performance domains and the PMP ECO's Process domain, tested by CAPM, PMP, PRINCE2 and IPMA.
- Agile, Scrum and KanbanThree accountabilities, five events, three artefacts and the empirical pillars of the 2020 Scrum Guide; Kanban's flow; the PSM and PSPO exams and PMP's agile half.
- Product managementDiscovery, roadmaps, prioritisation, metrics and the product owner's accountability: where business analysis, agile and strategy meet (Scrum Guide's Product Owner; SFIA Product management; PSPO).
- Organisational change and transformationMaking a change stick in an organisation is its own discipline (SFIA Change planning: organisational change management and enablement; PMBOK's stakeholder and uncertainty domains).
- Leadership and people managementRunning a team: delegation, feedback, performance, hiring, motivation (SFIA People management; PMP's People domain; Udemy's largest business shelf).
- Business strategy and planningBusiness models, competitive position, planning and the numbers behind a decision (SFIA Strategic planning; Udemy Strategy; the business model canvas).
- Operations, Lean and Six SigmaProcesses, quality and waste: Lean, Six Sigma's DMAIC and the belts, supply chain and operations management (SFIA Business process improvement; Udemy Operations).
- Entrepreneurship and small businessStarting and running a small business: idea to model, funding, legal basics, first customers (Udemy Entrepreneurship; the site's own small-business and freelance readership).
- Sales and negotiationProspecting, discovery, closing, key accounts and negotiating: the revenue side of every business (Udemy Sales; SFIA Selling).
- Business communication and presentingWriting, presenting, meetings and public speaking: the skill every other business skill is delivered through (Udemy Communication; SFIA Relationships and engagement).
- Freelancing and independent workBriefs, statements of work, day rates, retainers and scope creep: how independent work is scoped, priced and agreed (the site's freelancing concepts and the /freelance/ silo).
Concepts to know
Glossary entries with the reason each one matters here.
- Project Scope
Analysis decides what the scope should be.
- User Story
The agile shape of a requirement.
- Stakeholder Management
Elicitation is stakeholder work.
Certifications that test it
Vendor exams and free certificates; facts, cost and the preparation path are on each page, and the certifications hub has them all.
Frequently asked
- Do business analysts need to code?
- No, though reading a data model or writing a simple SQL query helps, especially on data-heavy change. The core skills are questioning, modelling and precise writing. An analyst who can sketch the data behind a process earns more trust from developers than one who cannot.
- Business analyst or data analyst: which job is which?
- The difference lies in the raw material. A data analyst works with data to answer questions and build reports, which belongs to data visualisation and BI. A business analyst works with people to define a change. Job adverts confuse the titles, so read the duties rather than the heading.
- How does business analysis work in an agile team?
- Continuously and in thinner slices. The analyst often helps the product owner refine the backlog, writes and splits stories with acceptance criteria, and explores the next items while the team builds the current ones. The six knowledge areas still apply; the documents simply get shorter.
Courses in the directory
131 courses are filed here; the top 6 by our ranking, details and the provider link on each course page.
Last reviewed 26 September 2026 · Getting Digital