Business Analysis Manual V9.0 - Core Vocabulary

Comprehensive vocabulary flashcards covering the core business analysis concepts, frameworks, deliverables, modelling standards, and interview terminology from the Business Analysis Manual V9.0.

Information Technology (IT)

The development and use of computer systems to solve business problems and meet business needs.

Business Analysis

The practice of understanding a business problem or opportunity, defining what needs to change, and making sure the change that gets delivered actually addresses the problem.

Three Parts of Business Analysis Practice

1. Understanding the problem rather than the symptom. 2. Defining what needs to change across processes, policies, roles, or systems. 3. Ensuring the delivered change demonstrably works.

Non-IT Business Analysis Work

High-value analysis initiatives that involve no software development, focusing entirely on process improvement, organizational structure, operating procedures, policies, or supplier arrangements.

Primary Accountabilities of a Business Analyst

The quality, clarity, and completeness of the analysis; ensuring requirements are unambiguous, traceable, and agreed; producing current and future state models; and verifying the solution satisfies business needs.

Project Deliverables a BA Contributes to Without Owning

Scope boundaries (approved by the Sponsor/board), the business case (owned by Sponsor), solution architecture (owned by technical leads), backlog priorities (owned by Product Owner), and business benefits (owned by operational units).

Responsibilities Outside the Business Analyst Remit

Project schedule, plan, and budget (owned by the Project Manager), line management and supplier resourcing, and overall commercial accountability for organizational outcomes.

BA vs. Project Manager Focus

The Project Manager asks 'Will we deliver it on time and budget?' and owns schedule, cost, and risk; the Business Analyst asks 'What is needed, and why?' and owns analysis, requirements, and solution alignment.

BA vs. Product Owner Focus

The Product Owner asks 'What is most valuable next?' and decides backlog priority; the Business Analyst asks 'What is needed, and why?' and focuses on detailing, refining, modeling, and verifying requirements.

Four Shapes of Business Analysis Work

1. New systems built from scratch. 2. Enhancements to existing systems in use (the majority of work). 3. Process improvement without software. 4. Migration, integration, or decommissioning.

Eight Core BA Competencies

Elicitation; requirements analysis and documentation; structured analysis; object-oriented and Agile analysis; data analysis; testing and validation; change and adoption support; and business process improvement.

Foundational Skill Behind All BA Competencies

Questioning and active listening, because the vast majority of requirements failures stem from unprobed assumptions and listening failures rather than technical shortcomings.

The BA Way of Thinking

Five key habits: ask why repeatedly, separate the problem from the solution, assume no process is perfect and no single person has the full picture, understand current state before designing the future, and translate bidirectionally between business and technical teams.

What Developers Need from a Business Analyst

Unambiguous acceptance criteria, rapid feedback on build edge cases, and someone available to answer business logic questions promptly.

What Solution Architects Need from a Business Analyst

Explicit non-functional requirements (such as availability, performance, and accessibility), integration touchpoints, and expected data volumes.

Recommended Fast-Start BA Strategy on a New Project

Produce a visible, imperfect artifact rapidly (such as a problem statement, stakeholder map, or draft AS-IS model) and invite stakeholders to correct it, rather than spending weeks quietly reading background documents.