A large insurance company invested over two million zlotys in a claims handling system. The project lasted eighteen months. The development team delivered exactly what was in the specification. The problem was that the specification did not reflect the real needs of users — claims adjusters needed quick access to client history on a single screen, and instead got an elaborate multi-stage wizard that forced clicking through seven tabs for each case. The system was implemented, but within three months, employees returned to spreadsheets and manual workarounds. The project officially “completed successfully” never actually delivered the value that management expected. Why? Because there was no solid business analysis — no one asked the right questions to the right people at an appropriately early stage.
This scenario is not an exception. According to the PMI Pulse of the Profession report, 35% of IT projects fail due to inaccurate requirements gathering. Standish Group in its CHAOS research has been indicating for years that unclear requirements are the main project risk factor. Business analysis is a discipline that exists to avoid such situations — and to ensure every project starts from understanding real organizational needs, not from assumptions written in a management presentation.
At a glance
What you will learn from this article:
- What business analysis is and what its scope is in the context of IT projects — from organizational strategy to detailed functional requirements
- What role a business analyst plays and how the BABOK framework defines their competencies and areas of action
- Which requirements gathering techniques (interviews, workshops, prototyping, observation) are most effective and when to use them
- How business analysis looks in the Agile approach compared to the classic Waterfall model
- How to measure the value that business analysis brings to an organization, and why investment in this discipline pays off
What business analysis is and what its scope is
Business analysis is a set of practices, tasks, and techniques for identifying business needs and defining solutions that deliver value to stakeholders. This is the definition from BABOK (Business Analysis Body of Knowledge) — a global standard developed by the International Institute of Business Analysis (IIBA). It sounds formal, but in practice it comes down to one thing: business analysis is systematically answering the question “what do we actually need to build and why?”.
The scope of business analysis is much broader than common understanding suggests. It is not only about documenting requirements before project start. Business analysis includes:
- Understanding strategic context — what business goals the organization wants to achieve and how the planned solution fits into this strategy.
- Stakeholder identification — who is involved, who is affected by the change, whose needs must be considered.
- Requirements elicitation — actively obtaining information about needs, expectations, and constraints from stakeholders and other sources.
- Analysis and modeling — structuring gathered information, creating models of processes, data, and business rules. Here, knowledge of BPMN process modeling is directly useful, which allows visualizing workflows in a way understandable to both business and IT.
- Solution specification — transforming business needs into specific requirements that the technical team can implement.
- Validation and verification — ensuring requirements are complete, consistent, testable, and actually address identified needs.
Business analysis does not end when the specification is handed over to developers. It is a continuous process that lasts throughout the project lifecycle — from initial concept, through development, implementation, to evaluating effects and identifying further improvements. In agile projects, the business analyst is even a permanent team member, working daily with developers and the product owner.
The role of business analyst — competencies and BABOK framework
A business analyst is a person who acts as a bridge between the world of business and the world of technology. Their main task is to understand organizational needs and translate them into language understandable to implementation teams — and vice versa, translating technical constraints into business consequences.
BABOK Guide (in current version 3.0) defines six Knowledge Areas that describe the scope of a business analyst’s work:
- Business Analysis Planning and Monitoring — planning analytical activities, defining the approach to analysis, managing analytical work performance.
- Elicitation and Collaboration — requirements gathering techniques and collaboration with stakeholders. This is the foundation on which everything else is based.
- Requirements Life Cycle Management — managing requirements throughout the project lifecycle, tracking changes, maintaining consistency.
- Strategy Analysis — analysis of the organization’s current state, defining the target state, and determining the gap that the solution is to fill.
- Requirements Analysis and Design Definition — structuring, modeling, prioritizing requirements, and designing solutions.
- Solution Evaluation — evaluating the working solution in terms of delivered business value.
In addition to domain knowledge, BABOK also defines Underlying Competencies that an analyst should possess: analytical and critical thinking, communication skills, ability to facilitate and negotiate, knowledge of tools and technologies, business knowledge, and professional ethics.
In practice, a business analyst is not just a “requirements collector”. It is a person who can:
- Ask difficult questions and challenge assumptions that everyone takes for granted.
- Recognize conflicts of interest between stakeholders and propose compromises.
- See the big picture — connect operational needs with strategic goals.
- Communicate effectively with both the CFO and a programmer.
- Identify risk early, before it becomes a problem.
Depending on the organization and project, the role of business analyst can be a dedicated position or a set of responsibilities distributed across several people — product owner, project manager, solution architect. Regardless of the model, analytical competencies must be present in the project team. Their absence is a straight path to the scenario described at the beginning of this article.
Requirements gathering techniques — how to reach real needs
Requirements gathering (elicitation) is not a conversation where you ask a stakeholder “what do you need?”, they tell you, you write it down, and done. If it were that way, we would not need business analysts. People often do not know exactly what they need. They describe solutions instead of problems. They omit what they consider obvious. They focus on current frustrating details instead of key processes.
Therefore, professional elicitation requires a set of complementary techniques. None of them is universal — effectiveness depends on context, stakeholders, and project stage.
Interviews. The most basic, but still one of the most effective techniques. Interviews can be structured (with a prepared list of questions), semi-structured (with a framework scenario but openness to exploration), or unstructured (free conversation). The key to a good interview: preparation, active listening, open questions, and the “5 Why” technique — drilling down to the source of the need. Interviews work best at the beginning of a project when you need to understand context, and with stakeholders at higher levels who do not have time for multi-day workshops.
Workshops. Group sessions with various stakeholders, facilitated by a business analyst. Workshops allow for simultaneously collecting perspectives of many people, identifying conflicts, and working out consensus in real time. Typical formats are: Requirements Workshop, JAD (Joint Application Development), brainstorming sessions, process mapping workshops. Workshops require an experienced facilitator — someone must ensure that a dominant personality does not drown out quieter participants, and the discussion does not go off on tangents.
Prototyping. Creating initial, simplified versions of a solution — from paper prototypes (drawings on paper or board) through wireframes to interactive prototypes in tools such as Figma, Axure, or Balsamiq. Prototypes help stakeholders “see” the solution and express opinions about something concrete, instead of discussing abstract requirements. This is a particularly valuable technique when stakeholders have difficulty articulating needs verbally.
Observation (Job Shadowing). The analyst spends time with users in their natural work environment, observing how they perform their tasks. This reveals information that users cannot describe during an interview — habits, workarounds, inefficiencies that have become so routine that no one notices them. Observation is particularly valuable in process optimization projects, where you need to understand the actual (not theoretical) course of work.
Document Analysis. Review of existing documentation — procedures, regulations, instructions, reports, existing system specifications, helpdesk logs. Documents provide context, reveal business rules, and help identify gaps in processes. Important note: documentation is often outdated, so it must be treated as a starting point, not as a source of truth.
Surveys and questionnaires. Useful when you need to collect information from a large group of stakeholders or users, e.g., in projects concerning systems used by hundreds of employees. They allow for quantitative analysis of preferences and priorities. The disadvantage is the lack of ability to ask follow-up questions.
In practice, a combination of several techniques gives the best results. A typical elicitation cycle is: interviews with key stakeholders at the start, group workshops to detail and validate, prototypes to visualize and verify understanding, observation to discover hidden needs.
Types of requirements — from business vision to implementation details
Not all requirements are equal. One of the key tasks of a business analyst is skillfully distinguishing and managing different levels of requirements. BABOK defines four main types that create a hierarchy — from abstract strategic needs to specific implementation requirements.
| Requirement type | Description | Example | Who is the main source |
|---|---|---|---|
| Business Requirements | Goals and needs of the organization at the strategic level. They answer the question “why are we implementing this project?" | "Shorten claim handling time from 14 to 5 business days” | Project sponsor, board, operations director |
| Stakeholder Requirements | Needs of specific user groups and stakeholders. They describe what individual people must do in the context of the solution | ”The adjuster must have access to complete client history without switching between screens” | End users, process managers, helpdesk |
| Solution Requirements | Detailed description of solution behavior. They are divided into functional (what the system does) and non-functional (how it works — performance, security, availability) | Functional: “The system displays a list of client claims sorted chronologically”. Non-functional: “The page loads in less than 2 seconds” | Business analyst, architect, development team |
| Transition Requirements | Needs related to transitioning from current state to target state — data migration, training, temporary compatibility mechanisms | ”Data from the current system must be migrated with status mapping: old status A = new status X” | Implementation team, administrators, users |
This hierarchy is important because each level results from the previous one. Business requirements justify the project’s existence. Stakeholder requirements describe how particular groups of people will use the solution. Solution requirements define what exactly is to be built. Transition requirements determine how to carry out the change.
A common mistake is starting with solution requirements — “we need a system that does X, Y, Z” — without a clear connection to business requirements. Then it is easy to build a system that does exactly what was asked for, but does not solve the real problem. Another typical problem is omitting transition requirements, which leads to chaos during implementation — data is incomplete, users are untrained, old and new systems run in parallel without clear rules.
Good business analysis ensures complete traceability — from strategic goals, through user needs, to detailed functional requirements. Each requirement should have a clear business justification. If you cannot indicate which business need a given requirement addresses, it is probably unnecessary.
Documenting and managing requirements
Gathered requirements must be documented in a way that is understandable, unambiguous, and useful for all recipients. The documentation format depends on project methodology, organizational culture, and project complexity. There is no one “right” format — what matters is communication effectiveness.
Software Requirements Specification (SRS). Classic, formal document used mainly in the Waterfall approach. Contains a complete description of functional and non-functional requirements, diagrams, business rules, and acceptance criteria. SRS is complete and detailed, but expensive to maintain — every change requires document update, which in dynamic projects becomes a burden.
User Stories. The dominant format in Agile projects. A short description of functionality from the user’s perspective: “As [role], I want [functionality], so that [benefit]”. User stories are supplemented with acceptance criteria that specify the conditions for meeting the requirement. The advantage is simplicity and value orientation. The disadvantage — the need to supplement with additional artifacts (diagrams, business rules) when the story alone is not enough.
Use Cases. Describe the interaction of an actor (user or system) with the system to achieve a specific goal. They contain the main scenario (happy path) and alternative scenarios (exceptions, errors). Particularly useful when you need to precisely describe complex flows with many variants.
Process and data models. BPMN diagrams for modeling workflows, ERD diagrams for modeling data structures, UML diagrams (class diagrams, sequence diagrams, state diagrams) for modeling system behavior. Visual models are invaluable when you need to present complex dependencies in an accessible way. The ability to do process mapping is a key analyst competency here.
Regardless of format, requirements management includes several key practices:
- Unique identification — each requirement has its identifier (e.g., REQ-001, US-042), enabling unambiguous reference to it.
- Prioritization — not all requirements are equally important. Techniques such as MoSCoW (Must, Should, Could, Won’t) help establish implementation order.
- Traceability — connections between requirements of different levels, tests, and solution elements. Allows answering questions: “why are we building this?” and “what will be affected when we change this requirement?”.
- Change management — formal process for evaluating and approving changes in requirements. In Waterfall, it is the Change Control Board, in Agile — backlog refinement and Product Owner decisions.
- Versioning — history of requirements changes, enabling reconstruction of how they evolved over time.
Tools supporting business analysis
A business analyst uses a set of tools that support gathering, documenting, modeling, and managing requirements. Tool selection depends on project scale, methodology, and the organization’s technological ecosystem.
Requirements and project management tools:
- JIRA — the most popular tool for backlog management in Agile projects. User stories, epics, tasks, status tracking — all in one place. Integration with developer tools allows complete traceability from requirement to code.
- Azure DevOps (formerly VSTS/TFS) — an alternative to JIRA in the Microsoft ecosystem, with built-in requirements management, Kanban boards, and reporting.
- Confluence — a tool for creating and organizing project documentation. Ideal for specifications, workshop notes, architectural decisions. Integrates directly with JIRA.
Modeling tools:
- Draw.io / diagrams.net — free tool for creating BPMN, UML, ERD diagrams, flowcharts. Integrates with Confluence and Google Drive.
- Lucidchart — advanced diagramming tool with real-time collaboration capability.
- Enterprise Architect (Sparx Systems) — professional tool for UML, BPMN, ArchiMate modeling. Used in large organizations and highly complex projects.
- Bizagi Modeler — dedicated tool for process modeling in BPMN notation.
Prototyping tools:
- Figma — currently the standard in interface prototyping. Enables creating interactive prototypes, team collaboration, and collecting feedback.
- Balsamiq — tool for quick wireframes with a deliberately sketchy look, which helps focus attention on structure instead of design.
- Miro / Mural — digital boards for workshops, brainstorming, process mapping, creating personas and customer journey maps.
User story and backlog management tools:
- User story mapping — technique for visualizing the backlog in the context of user flow. Tools such as StoriesOnBoard or Easy Agile integrate with JIRA.
- Acceptance criteria — often written in Gherkin format (Given/When/Then) directly in backlog management tools.
Tools are important, but will not replace skills. Excellent requirements specification in JIRA will not save a project if requirements were poorly gathered. Tools support the process — they are not the process.
Business analysis in Agile vs Waterfall
The role of business analysis fundamentally differs depending on the adopted project approach. Neither Agile nor Waterfall eliminates the need for analysis — they only change the way it is conducted.
| Aspect | Waterfall (cascade) | Agile |
|---|---|---|
| Moment of analysis | Dedicated phase at project start (Big Upfront Design) | Continuous, iterative analysis throughout the product lifecycle |
| Level of detail at start | Complete requirements specification before development begins | General vision (epics) + detailed requirements defined iteratively, just before implementation |
| Documentation format | Formal SRS specification, use cases, detailed diagrams | User stories, acceptance criteria, lightweight documentation, living documentation |
| Change management | Formal Change Control Board, changes expensive and reluctantly accepted | Changes are the norm — backlog is prioritized and modified on an ongoing basis |
| Analyst role | Separate role, often outside the development team, passes requirements “over the wall” | Team member, working daily with developers and product owner |
| Requirements validation | Documentation reviews, formal sign-offs | Continuous feedback — demo, acceptance tests, direct communication |
| Risk | High risk that requirements do not match needs — verification only at project end | Lower risk — regular delivery and validation every iteration (1-4 weeks) |
In the Waterfall model, the business analyst most often works intensively at the beginning of the project, creating a complete specification, and then enters the role of “requirements guardian” — ensures changes are controlled and documented. The advantage is clarity and predictability. The disadvantage — rigidity and risk that documentation will not survive confrontation with reality.
In Agile, the business analyst (or person performing this role, e.g., Product Owner) works continuously. Maintains the backlog, conducts refinement sessions, writes user stories for the nearest iterations, and simultaneously analyzes needs several sprints ahead. Documentation is lighter, but this does not mean lack of documentation — formats and level of formalism change, not the need for reliability.
In practice, many organizations use a hybrid approach. Strategic analysis and general solution architecture are defined upfront (Waterfall elements), while detailed requirements and implementation are carried out iteratively (Agile elements). The key is that the chosen model corresponds to project context — regulations, complexity, team size, organizational culture — and is not imposed dogmatically.
Measuring the value of business analysis for the organization
Business analysis is often perceived as a cost — an additional person on the project, additional time for workshops and documentation. This is a perspective that ignores the value this discipline brings. How to measure it?
Reduction of defect repair costs. IBM Systems Sciences Institute research showed that the cost of fixing a requirements error grows exponentially in subsequent project phases. An error detected in the requirements phase costs 1x. The same error detected in the testing phase costs 15x. In the production phase — even 100x. Good business analysis is an investment in detecting problems at the earliest, cheapest stage.
Reduction of scope creep. Clearly defined and agreed requirements with traceability to business goals provide a solid basis for evaluating every scope change proposal. Instead of answering “sure, let’s add it”, the analyst can ask: “which business requirement does this address?” and “what is the opportunity cost?”.
Higher user satisfaction. A solution designed based on solid needs analysis — including observation, prototyping, and iterative validation — has a much higher chance of actual adoption by users. System adoption is not a vanity metric — it is a condition for return on investment.
Faster value delivery. Paradoxically, time invested in analysis shortens project time. Fewer misunderstandings means fewer reworks. Clear acceptance criteria means faster testing. Well-defined priorities mean the most valuable functionalities are delivered first.
Better team communication. Business analysis artifacts — process models, user stories, prototypes, glossary — create a common project language. They reduce the risk that a developer understands a requirement differently than a tester, and a tester differently than a user.
Organizations that treat business analysis as a strategic competency, not an administrative burden, consistently implement projects with higher ROI, lower failure rate, and greater stakeholder satisfaction. It is not a matter of faith — it is a matter of data.
How EITT supports competency development in business analysis
Business analysis is a discipline that cannot be mastered solely from books. It requires practice, mentoring, and continuous improvement. EITT, with a network of over 500 experts and experience from over 2500 completed trainings (average rating 4.8/5), offers comprehensive support for individuals and organizations wanting to develop analytical competencies.
Business analysis training at EITT includes both fundamentals (for people entering the analyst role) and advanced techniques (for experienced practitioners wanting to deepen knowledge in specific areas — process modeling, requirements management in Agile projects, or preparing for IIBA certification). Training programs are designed based on real case studies and workshop exercises, because business analysis is primarily a practical skill.
For organizations planning to build or strengthen an internal team of business analysts, EITT offers closed trainings tailored to industry specifics, applied methodologies, and participant experience levels. This approach ensures that investment in development translates directly into the quality of implemented projects.
Summary — requirements are the foundation, not a formality
Business analysis is not a bureaucratic step in the project process. It is the foundation on which every successful IT project stands. Without clear, well-defined, and managed requirements, the development team works in the dark — it can deliver high-quality code, but will not deliver business value.
Key takeaways from this article:
- Business analysis is a continuous process encompassing the entire project lifecycle — from strategy to evaluation of the implemented solution.
- A business analyst is not a “requirements secretary”, but a strategic link between business and technology.
- Effective elicitation requires a combination of techniques — interviews, workshops, prototypes, observation — selected for context and stakeholders.
- Requirements have a hierarchy: business, stakeholder, solution, transition. Each level must be linked to overarching goals.
- The Agile approach does not eliminate business analysis — it changes its form from a one-time phase to a continuous, iterative process.
- The value of business analysis can be measured: lower defect costs, fewer reworks, higher adoption, faster value delivery.
Investment in business analysis competencies — both individual and at the organizational level — is one of the most effective ways to improve quality and predictability of IT projects. Requirements do not collect themselves and do not document themselves. They need people with appropriate skills, processes, and tools. That is what professional business analysis provides.
Frequently Asked Questions
What is the difference between a business analyst and a product owner?
A business analyst focuses on eliciting, documenting, and managing requirements across the entire project lifecycle, while a product owner is responsible for prioritizing the backlog and maximizing product value. In many Agile teams these roles overlap, but the business analyst typically brings deeper expertise in structured analysis techniques and stakeholder facilitation.
Is BABOK certification necessary to work as a business analyst?
BABOK certification (such as ECBA, CCBA, or CBAP from IIBA) is not a strict requirement but is increasingly valued by employers as proof of structured analytical competencies. It demonstrates familiarity with industry-standard practices and can accelerate career progression, especially when moving between organizations or industries.
How does business analysis differ in Agile versus Waterfall projects?
In Waterfall, business analysis is concentrated in a dedicated phase at the project start, producing comprehensive specifications before development begins. In Agile, analysis is continuous and iterative — the analyst works within the team, refining user stories and acceptance criteria just before each sprint, which allows faster adaptation to changing requirements.
What tools do business analysts use most frequently?
The most commonly used tools include JIRA and Azure DevOps for backlog and requirements management, Confluence for documentation, Figma or Balsamiq for prototyping, and draw.io or Lucidchart for process and data modeling. The specific toolset depends on organizational methodology and project complexity, but the key is choosing tools that support clear communication between business and technical stakeholders.
Read also
- SAS Programming: Data Analysis and Competencies
- What is Transactional Analysis in Negotiations? Definition, Ego States, Techniques, and Business Application
- Training Needs Analysis in Assessment Center Format Using the Royal Garden Business Simulation
Develop your skills
Want to deepen your knowledge in this area? Check out our training led by experienced EITT instructors.