The Waterfall methodology is a linear, sequential Software Development Life Cycle (SDLC) model where progress flows downwards through distinct phases—much like a cascading waterfall. In a pure Waterfall framework, each phase must be fully completed, documented, and signed off before the next phase begins.
For Business Analysts (BAs), the Waterfall model places a heavy emphasis on upfront requirement gathering, exhaustive documentation, and rigorous baseline approval before any code is written.
What Is the Waterfall Model in SDLC?
Introduced by Winston W. Royce in 1970, the Waterfall model is the traditional approach to software engineering and project management. It relies on a plan-driven structure where project scope, timeline, and cost are defined early in the development process.
Unlike Agile methodologies—which deliver software in iterative, incremental sprints—Waterfall delivers the complete software product at the end of the entire lifecycle.
6 Sequential Phases of the Waterfall Methodology
Key Advantages & Disadvantages
| Pros | Cons |
| Simple to manage due to its rigid structure. | Difficult to change once a phase is finished. |
| Clear milestones and well-defined deliverables. | High risk because testing only happens at the end. |
| Disciplined approach where everything is documented. | No working software until late in the life cycle. |
| Ideal for short projects with fixed requirements. | Not suitable for complex or long-term projects. |
1. Requirements Analysis & Elicitation
The Business Analyst leads this phase by gathering business rules, functional needs, and technical constraints from key stakeholders.
Core Artifacts: Business Requirements Document (BRD), Functional Requirements Document (FRD), and Software Requirements Specification (SRS).
BA Goal: Obtain formal stakeholder sign-off on the complete requirement baseline.
2. System Architecture & Design
System Architects and Software Engineers translate functional requirements into technical designs.
Core Sub-phases: High-Level Design (HLD) defining system architecture/data models, and Low-Level Design (LLD) detailing class diagrams, database schemas, and API contracts.
3. Implementation (Coding)
Developers build the actual software code based strictly on the approved design specifications. Individual modules are written and unit-tested during this phase.
4. Verification & Testing
Quality Assurance (QA) engineers test the integrated system against original requirements. Business Analysts assist with User Acceptance Testing (UAT) to confirm the solution meets business needs.
Core Activities: Integration testing, system testing, regression testing, and UAT sign-off.
5. Deployment & Release
Once the software passes all quality gates and business sign-offs, it is deployed to the production environment for end users.
6. Maintenance & Operations
Post-release support where bugs are patched, server infrastructure is maintained, and minor patches or software enhancements are managed.
Role of a Business Analyst in a Waterfall Project
In Waterfall projects, the Business Analyst acts as the primary author of system scope and the central bridge between business leaders and technical teams.
Leading Elicitation Workshops: Conducting Joint Application Development (JAD) sessions and stakeholder interviews.
Authoring Detailed Specifications: Writing exhaustive BRDs, FRDs, and Use Case specifications.
Managing Traceability: Creating a Requirement Traceability Matrix (RTM) to map every requirement to test cases and design elements.
Change Control Management: Evaluating formal Change Requests (CRs) if business requirements shift mid-project.
Facilitating UAT: Creating test scenarios, writing acceptance criteria, and guiding business users through testing.
Advantages and Disadvantages of Waterfall
Advantages
Clear Structure & Predictability: Fixed scope, clear milestones, and explicit deadlines facilitate upfront budgeting and resource scheduling.
Comprehensive Documentation: Detailed specifications ensure full domain knowledge transfer if team members leave.
Defined Sign-off Gates: Clear quality control checkpoints prevent scope ambiguity during execution.
Easier Management for Fixed-Bid Projects: Ideal when vendors operate under strict contractual budgets and timelines.
Disadvantages
Inflexible to Change: Requirements are locked early; introducing changes later requires formal, costly Change Requests.
Late Customer Feedback: Stakeholders do not see working software until late in the testing phase.
High Risk of Requirement Misalignment: If initial assumptions are flawed, defects are discovered late in deployment.
Delayed Value Delivery: Business value is realized only at the very end of the project lifecycle.
Waterfall vs. Agile: Key Differences for BAs
| Feature / Aspect | Waterfall Methodology | Agile Framework (Scrum / Kanban) |
| Approach | Linear, sequential, plan-driven | Iterative, incremental, value-driven |
| Requirements | Defined completely upfront | Refined continuously in backlogs |
| BA Documentation | Comprehensive BRDs, FRDs, and SRS | User Stories with Acceptance Criteria |
| Change Management | Strict Change Control Board (CCB) process | Highly adaptable; continuous backlog refinement |
| Testing Phase | Dedicated phase following coding | Continuous testing within every sprint |
| Stakeholder Feedback | Early during requirements, late at UAT | Continuous feedback at Sprint Reviews |
| Value Delivery | Delivered once at project completion | Delivered incrementally every 2–4 weeks |
When Should You Use the Waterfall Model?
While Agile is common in modern software development, Waterfall remains the preferred choice under specific project constraints:
Strict Regulatory & Compliance Projects: Banking, healthcare, and government projects where extensive audit trails and formal documentation are legally required.
Fixed-Scope & Fixed-Budget Contracts: Client engagements with strict budgets and precise deliverables.
Firmly Established Technologies & Clear Scope: Projects where requirements are fully understood upfront and unlikely to change mid-development.
Hardware & Infrastructure Integrations: Core system upgrades where physical hardware constraints dictate strict sequence.
Real-World Scenario: Core Banking Payment System Upgrade
Client: National Commercial Bank
Project: Upgrading the Core Interbank Payment Processing Engine to support ISO 20022 compliance standards with strict zero-downtime and regulatory deadlines.
Why Waterfall? Strict regulatory mandates, zero tolerance for transactional error, complex multi-system mainframe integrations, and fixed audit requirements.
Phase-by-Phase Execution in Action
1. Requirements Phase (The BA in Lead)
What happens: The BA conducts Joint Application Development (JAD) sessions with Compliance Officers, Treasury Managers, and Security Engineers.
BA Output: The BA writes a 150-page Business Requirements Document (BRD) and Functional Requirements Document (FRD) detailing ISO 20022 message formats (PAIN, PACS, CAMT) and mapping rules.
Sign-off Gate: Stakeholders, Risk Committees, and Compliance Leads sign off on the baseline requirements document. Scope is officially locked.
2. System Design Phase
What happens: Solution Architects translate the approved FRD into High-Level Design (HLD) architecture diagrams and Low-Level Design (LLD) schema contracts for the payment gateway.
BA Role: The BA maintains the Requirement Traceability Matrix (RTM) to ensure every requirement in the signed-off FRD maps to a specific architectural component.
3. Implementation Phase (Coding)
What happens: Developers build the payment parser engine strictly adhering to the signed-off LLD specs.
Scenario Event: A stakeholder requests adding an instant SMS notification for high-value transfers mid-coding.
Waterfall In Action: The BA initiates a formal Change Control Process. The BA logs a Change Request (CR), assesses the impact (adds $15,000 to budget and 2 weeks to schedule), and submits it to the Change Control Board (CCB) for formal approval before any code is modified.
4. Verification & Testing Phase
What happens: QA executes unit, system, and regression test suites.
BA Role: The BA coordinates User Acceptance Testing (UAT) with the Bank’s Treasury Operations team. The BA verifies test scripts against the original RTM to ensure 100% functional compliance and zero missing edge cases.
5. Deployment Phase
What happens: After formal UAT sign-off and regulatory audit checks, the release management team deploys the new payment engine to production during a scheduled weekend maintenance window.
6. Maintenance Phase
What happens: The application enters post-implementation support. The BA hands over functional documentation and troubleshooting runbooks to the L2/L3 support teams.
🎥 Watch the Complete Video Tutorial
Discover how the Waterfall Methodology works and why it remains relevant for many projects today. This video covers every phase of the Waterfall model, its advantages, disadvantages, real-world use cases, and how it compares with modern Agile development methodologies.
Frequently Asked Questions
What is waterfall SDLC?
Waterfall Model is a sequential model that divides software development into different phases. Each phase is designed for performing specific activity during SDLC phase. It was introduced in 1970 by Winston Royce.
Is SDLC waterfall or agile?
In Agile process, requirements can change frequently. However, in a waterfall model, it is defined only once by the business analyst. In Agile Description of project, details can be altered anytime during the SDLC process which is not possible in Waterfall method
What is difference between SDLC and waterfall model?
Different phases of the SDLC model are Requirement, Design, Implementation and Testing. Waterfall model is one of the most popular SDLC models. … This model has different deliverables from each phase.In a waterfall model, each step follows in a sequential manner without overlapping or iterative steps.
Why waterfall model is best?
Advantages of waterfall model
This model is simple and easy to understand and use. It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process. In this model phases are processed and completed one at a time.
Is waterfall iterative?
In traditional, full waterfall development, a team does all of the analysis for the entire project first. … This is an iterative waterfall process, not an agile process. Ideally, in an agile process, all types of work would finish at exactly the same time
Why should I use waterfall methodology?
The advantages of waterfall development are that it allows for departmentalization and control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.
What are the disadvantages of waterfall model?
Disadvantages of waterfall model:
Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. No working software is produced until late during the life cycle. High amounts of risk and uncertainty.
Business Analysis Career Path – Knowledge Hub
Below is the structured Knowledge Area matrix connecting core business analysis skills and deliverables.
| Knowledge Area | Deep-Dive Article | Why It Matters for a Business Analyst |
| Business Analysis & Strategy | Business Analysis in Digital Marketing | Explains how BAs align marketing tech stacks, campaign tracking, and customer conversion funnels with business goals. |
| Business Analysis Templates & Examples | Provides essential downloadable templates (BRD, FRD, RTM, Use Case) to standardize documentation across projects. | |
| Cost Benefit Analysis Techniques | Demonstrates how to evaluate financial ROI, payback periods, and feasibility before committing development resources. | |
| Agile & Delivery Metrics | Sprint Burndown Chart | Teaches how to track sprint progress, monitor team velocity, and identify scope creep early in Agile iterations. |
| How to Create Burndown Chart in Jira | Step-by-step practical guide on configuring custom Jira boards, estimation fields, and burndown reports for daily standups. | |
| Software Development Lifecycles (SDLC) | Waterfall Methodology / Model | Comprehensive guide on linear SDLC phases, upfront baseline documentation, and managing formal Change Control Boards. |
| Spiral Life Cycle Model | Details how to apply risk-driven development, prototyping, and iterative loops for high-risk enterprise software projects. | |
| Domain Deep Dives (FinTech & Banking) | Enhanced Customer Due Diligence (EDD) | Details AML/KYC compliance workflows, risk-scoring models, and regulatory requirements for high-risk customer onboarding. |
Waterfall is a linear, sequential model where all requirements are defined upfront and software is released at the end of the project. Agile is an iterative model where software is developed and delivered in small, functional increments (sprints) with continuous feedback.
Because development phases do not overlap, downstream teams rely entirely on documentation produced in earlier phases to build, test, and maintain the software accurately.
Yes, but changes must go through a formal Change Management Process. The BA assesses the impact on budget, scope, and timeline before submitting it to a Change Control Board (CCB) for approval.
The primary deliverable is a fully signed-off Business Requirements Document (BRD) or Functional Requirements Document (FRD), along with a Requirement Traceability Matrix (RTM).
🎁 Become a Better Business Analyst
Join 1,200+ Business Analysts learning every week.
Get instant access to:
📘 FREE Business Analyst Templates
🎯 Interview Preparation Guides
🚀 Agile & Scrum Tutorials
🤖 AI for Business Analysts
📈 Career Growth Tips
100% Free • No Spam • Unsubscribe Anytime
Hello Pallavi,
That you for these many details for Business Analysts. I really appreciate your work which is very easy and understandable. I would like to understand in detail for documentation like BRD and SRS. Please share your thoughts in that and make detailing for documentation like how it should be prepared.
Thanks.
Thanks for visiting my blog and your valuable feedback.
I will try to explain in details in coming Articles, now I got one more topic to write article.
Thanks:
Difference between BRD and FRD
Documents prepared by the Business Analyst during the SDLC
Hello Pallavi,
Thatnk you for these many details for Business Analysts. I really appreciate your work which is very easy and understandable. I would like to understand in detail for documentation like BRD and SRS. Please share your thoughts in that and make detailing for documentation like how it should be prepared.
Thanks.
Thank you for your valuable feedback.
HI Sure, Please reach me on my email.
Email: bacareers.in@gmail.com