Business Analysis
Overview
Business analysis (BA) is about business problems and identifying business needs so solutions can be developed — not IT change for its own sake. The BA is a communicator who talks to clients, end users, and stakeholders, tells the story of the change, and produces clear, conflict-free documentation. Core focus: prioritise stakeholder requirements, record everything, and maintain a goal-driven focus.
BA Principles
From the discipline’s textbook framing:
- Root cause, not symptoms
- Business improvement, not IT system change
- Options, not solutions
- Feasible contributing requirements, not meeting every request
- The entire business change lifecycle, not just requirement definition
- Negotiation, not avoidance
Two overarching approaches: the holistic approach and the Agile philosophy.
The BA workflow
- Identify stakeholders — direct (seeking a solution to their problem) and indirect (benefit from the project’s success). Justify who’s who.
- Elicit requirements — interviews (open vs closed questions, stay flexible, don’t “plant seeds” or bias), focus groups/workshops, shadowing and scenarios. Record everything. See Stakeholder Analysis.
- Model the requirements — User Stories, and Use Case & Swim Lane diagrams.
- Validate — confirm a stated problem is real (one voice isn’t a problem; understand why).
- Make the case — a business case with options and recommendations.
Requirements
- Functional requirements — what the product must do (its features and functions), e.g. “catalogue artworks with artist, title, medium.”
- Non-functional requirements — how the system should do it / its properties: performance, usability, scalability, security, maintainability, responsiveness. These affect the system as a whole.
Business case
Where findings are presented, a course of action is proposed, with time, effort, and money. Structure: introduction, executive summary, current situation (the problem), options, cost/benefit analysis, impact & risk assessment, recommendations, appendices.
- There is always Option Zero — do nothing / maintain the status quo.
- Cost/benefit distinguishes tangible (touchable) from intangible (knowledge, skill) value.
- Risk assessment covers identification, impact, probability, mitigation, and ownership.
- Frameworks referenced for situation analysis: PESTLE, POPIT, McKinsey 7S.
“A great project with a bad business case will most likely fail.”
Relationships
- Stakeholder Management and Role Clarity — who owns and decides
- Agile and Team Processes — user stories and iterative delivery
- Databases — data modeling (ERD) turns requirements into schema
- Product-Market Fit — requirements should trace to a real need