1. What are the advantages and disadvantages of the Waterfall Model?
The Waterfall Model is the oldest and simplest approach to building software. The idea is that the whole project moves through a fixed sequence of phases, one after another, and each phase has to finish completely before the next one begins. The name comes from the way the work flows downward, like water falling over a series of ledges — once it drops off one ledge, it cannot flow back up.
+----------------------+
| Requirements |
+----------+-----------+
|
v
+----------------------+
| Design |
+----------+-----------+
|
v
+----------------------+
| Implementation |
+----------+-----------+
|
v
+----------------------+
| Testing |
+----------+-----------+
|
v
+----------------------+
| Deployment |
+----------+-----------+
|
v
+----------------------+
| Maintenance |
+----------------------+The six phases are requirement analysis, system design, implementation, testing, deployment, and maintenance. In requirement analysis, the team gathers what the customer wants and writes it into a document called the SRS. In design, those requirements are turned into a technical blueprint. Then developers write the code, the finished system is tested, released to the user, and finally maintained.
The model’s biggest strength is that everything is clear and measurable. Each phase produces a concrete deliverable, so a manager always knows exactly where the project stands. Documentation is thorough because every phase is formal. Testing happens on a complete, well-defined product, so the testing effort is easy to plan.
The model’s biggest weakness is that it is rigid. If the customer realizes halfway through coding that a requirement is wrong, the team cannot just patch it. They have to go back to an earlier phase and redo the work, which is slow and expensive. The customer also does not see anything working until the very end, so a fundamental misunderstanding discovered late can be catastrophic. That makes Waterfall a bad fit for projects where requirements are unclear or likely to change.
Requirements
|
v
Design
|
v
Coding
|
v
Testing
|
v
Deployment
|
v
Maintenance
^
|
No easy return
to earlier phaseWaterfall works best when the requirements are stable, complete, and well understood up front, and when the technology is familiar. Government contracts, safety-critical systems, and projects with a fixed specification are classic examples.
2. In which phase of the SDLC is the Software Requirement Specification (SRS) document created?
The SRS is created during the Requirement Analysis phase, which is the second phase of the SDLC, right after the feasibility study and before any design or coding work.
Feasibility Study
|
v
+----------------------+
| Requirement Analysis |
| |
| Elicitation |
| ↓ |
| Analysis |
| ↓ |
| SRS Creation |
| ↓ |
| Customer Sign-off |
+----------+-----------+
|
v
Design
|
v
CodingBefore this phase, the team only has a rough idea of what the customer wants. Requirement Analysis turns that rough idea into a precise, written agreement between the customer and the developers.
The work happens in steps. First comes elicitation, where requirements are collected from stakeholders through interviews, surveys, workshops, and studying any existing systems. Next comes analysis, where those requirements are checked for ambiguity, contradictions, and gaps. Then everything is written up as the SRS document. Finally, the customer reviews and signs off on it, which officially approves what will be built.
The SRS is a big deal because it becomes the reference point for the entire rest of the project. It captures three main kinds of content:
- Functional requirements describe what the system must do. For example, “a user must be able to reset a forgotten password using a registered email address.”
- Non-functional requirements describe how well the system must do it. For example, “the login page must respond within two seconds” or “customer data must be encrypted.”
- Constraints and assumptions describe the limits the team is working under, such as the target hardware, budget, and any legal restrictions.
SRS
|
+----------+----------+
| | |
v v v
Functional Non-Functional Constraints
Requirements Requirements & Assumptions
| | |
+----------+----------+
|
v
Project Reference
|
+----------+----------+
| | |
v v v
Design Development TestingEvery later phase depends on this document. Designers use it to build the architecture, developers use it to write code, and testers use it to design their test cases. If the SRS is wrong or incomplete, everything built on top of it is wrong too. A requirement that is missed here might be ten times more expensive to add later, which is why so much care goes into this phase.
3. What is the core philosophy of the Agile methodology in SDLC?
The core philosophy of Agile is simple: deliver value in small pieces, get feedback constantly, and adapt to change instead of fighting it.
+-------------------+
| Product Backlog |
+---------+---------+
|
v
+-------------------+
| Sprint Planning |
+---------+---------+
|
v
+-------------------+
| Sprint |
| Build + Test |
+---------+---------+
|
v
+-------------------+
| Working Software |
+---------+---------+
|
v
+-------------------+
| Customer Feedback |
+---------+---------+
|
v
Adapt
|
+----------+
|
v
Next SprintTraditional models like Waterfall assume that requirements can be fully known at the start and will stay stable. In reality that rarely happens. Markets change, customers discover what they really want only after seeing something working, and competitors force new priorities. Agile accepts this reality. It treats change as normal rather than as a failure of planning.
Agile works in short, fixed-length cycles called sprints, usually two to four weeks long. At the start of a sprint, the team picks a small set of features to build. At the end of the sprint, those features are finished and working. The customer then looks at what was built and gives feedback, and that feedback shapes the next sprint. Nothing gets built for months in the dark — the customer sees real, working software regularly.
Sprint 1 Sprint 2 Sprint 3
+---------+ +---------+ +---------+
| Plan | | Plan | | Plan |
| Build | ---> | Build | ---> | Build |
| Test | | Test | | Test |
| Review | | Review | | Review |
+---------+ +---------+ +---------+
^ ^ ^
| | |
+--- Feedback ---+--- Feedback ---+The Agile Manifesto, written in 2001, sums up the mindset in four values:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
A handful of the twelve principles behind the Manifesto are worth remembering. Deliver working software frequently. Welcome changing requirements, even late in development. Have business people and developers work together daily. Use working software as the primary measure of progress. And reflect regularly on how to become more effective, then adjust.
The contrast with Waterfall is sharp. Waterfall plans everything up front and resists change; Agile plans a little at a time and embraces change. Waterfall delivers once at the end; Agile delivers every sprint. Waterfall involves the customer at the start and end; Agile keeps them involved throughout. Waterfall produces heavy documentation; Agile produces just enough.
Waterfall:
Plan --> Design --> Build --> Test --> Release
|___________________________________________|
Big Delivery
Agile:
Plan --> Build --> Test --> Review
^ |
|_________________________|
Continuous FeedbackIn short, Agile is a philosophy of learning and adapting. It works because it keeps the feedback loop short, which means problems are caught while they are still cheap to fix.
4. What is the primary risk-driven feature of the Spiral Model?
The defining feature of the Spiral Model is that it puts risk analysis at the center of every iteration. It is the one classic SDLC model built entirely around the idea of identifying, analyzing, and resolving risk continuously, rather than hoping it never shows up.
+----------------+
| Planning |
+-------+--------+
|
v
+----------------+
| Risk Analysis |
+-------+--------+
|
v
+----------------+
| Engineering |
+-------+--------+
|
v
+----------------+
| Customer |
| Evaluation |
+-------+--------+
|
v
Next Loop
|
+---------> PlanningThe model is drawn as a spiral. Each loop of the spiral is one iteration of the project, and the spiral grows outward as the project progresses. Every loop passes through the same four phases: planning, risk analysis, engineering, and customer evaluation.
Customer Evaluation
|
v
+-----------+
/ \
/ Engineering \
/ \
| Risk Analysis |
\ /
\ Planning /
\ /
+-----------+
|
v
Next IterationIn the planning phase, the team sets the objectives for this iteration, lists the alternatives, and notes any constraints. In the risk analysis phase, the team looks hard at what could go wrong — cost overruns, schedule slips, technical uncertainty, users rejecting the system — and evaluates each risk’s likelihood and impact. Where a risk is serious and uncertain, the team builds a small prototype to test the idea cheaply. In the engineering phase, the product for this iteration is actually designed, built, and tested. In the customer evaluation phase, the customer reviews the result and decides whether to take another loop around the spiral.
The reason risk analysis is the heart of the model is that it stops disasters early. In Waterfall, a project can run for months and then fail completely because nobody examined the risks. The Spiral Model checks for danger at every turn. If a risk is too severe, the project can be stopped or redirected before large amounts of money have been burned.
Iteration 1
|
+--> Identify Risk
|
+--> Analyze Risk
|
+--> Reduce Risk
|
+--> Build & Test
|
+--> Customer Review
|
v
Iteration 2
|
+--> Identify Risk
|
+--> Analyze Risk
|
+--> Reduce Risk
|
+--> Build & Test
|
+--> Customer Review
|
v
...This makes the Spiral Model expensive to run. Every loop involves analysis, review, and customer involvement, which takes time and produces lots of documentation. But for large, complex, high-risk projects — defense systems, aerospace, large enterprise builds — that cost is worth paying, because the cost of failure is far higher. For small, low-risk projects, all that analysis is overkill.
5. What does the V-Model (Validation and Verification Model) emphasize?
The V-Model emphasizes a direct, one-to-one connection between every development phase and a corresponding testing phase. The idea is that testing should be planned from the very beginning, alongside development, instead of being bolted on after coding finishes.
The model is drawn as a V. The left side goes down through the development phases, the bottom point is coding, and the right side goes back up through the testing phases.
Development Testing
----------- -------
Requirement Analysis -----------------> Acceptance Testing
\ /
\ /
System Design -----------------------> System Testing
\ /
\ /
High-Level Design ---------------> Integration Testing
\ /
\ /
Low-Level Design ----------------> Unit Testing
\ /
\ /
\ /
\ /
\ /
CodingThe key idea is the mapping between the two sides. Requirement analysis maps to acceptance testing. System design maps to system testing. High-level design maps to integration testing. And low-level design maps to unit testing.
Requirements <------> Acceptance Testing
System Design <------> System Testing
High-Level Design <------> Integration Testing
Low-Level Design <------> Unit Testing
|
v
CodingSo while the team is still defining requirements, it is already planning the acceptance tests. While it is doing system design, it is planning the system tests. By the time coding is finished, the test plans for every level are already written and waiting, which means testing can begin immediately.
Each testing phase verifies the output of its matching development phase. Unit testing checks that each individual module works. Integration testing checks that modules work correctly together. System testing checks that the whole system satisfies its requirements. Acceptance testing checks that the system meets the customer’s actual needs.
The big advantage over Waterfall is that testing starts much earlier in the planning. Defects are caught closer to where they were introduced, which makes them cheaper to fix. The model still shares Waterfall’s core weakness, though — it is sequential and rigid, so it suits projects with stable, well-defined requirements but struggles with changing ones.
6. What is the fundamental difference between Verification and Validation?
The difference comes down to two questions. Verification asks “Are we building the product right?” Validation asks “Are we building the right product?” One checks that the product matches its specification; the other checks that the product satisfies the user.
SOFTWARE QUALITY
|
+----------+----------+
| |
v v
Verification Validation
| |
v v
"Building the "Building the
product right?" right product?"
| |
v v
Specification User Needs
& Documents & BehaviorVerification is about conformance. It checks the intermediate work — documents, designs, and code — against what was specified, without running the software. It is mostly static work: walkthroughs, code reviews, and inspections. The idea is to catch errors of implementation, where the work does not match what was agreed. For example, checking that the login screen matches the approved design document is verification.
Validation is about value. It runs the actual software and checks it against the user’s real needs. It is dynamic work: executing the system, running test cases, and letting real users try it. The idea is to catch errors of expectation, where even a product built perfectly to spec still does not help the user. For example, having real users try the login flow and judging whether it is genuinely easy for them is validation.
Verification
|
+--> Reviews
+--> Inspections
+--> Walkthroughs
|
v
No software execution required
Validation
|
+--> Execute software
+--> Run test cases
+--> User evaluation
|
v
Actual software is evaluated| Verification | Validation | |
|---|---|---|
| Question | Are we building the product right? | Are we building the right product? |
| Checks | Conformance to specification | Satisfaction of user needs |
| Approach | Static: reviews, inspections | Dynamic: execution, testing |
| When | Throughout development | At the end, on the finished product |
A good way to remember it is to think of building a house. Verification checks that the walls are straight and match the blueprint. Validation asks whether you actually want to live there. Both matter, and they answer different questions — a product can pass every verification review and still fail validation if the original specifications were wrong.
7. Why is the ‘Maintenance’ phase considered a critical part of the SDLC?
Maintenance is critical because it is where most of a software product’s lifetime cost and effort actually goes. Releasing the software is not the end of the story — it is the beginning. For years afterward, the product has to be fixed, updated, adapted, and improved, and all of that is maintenance.
Development Lifecycle
Requirements
|
v
Design
|
v
Development
|
v
Testing
|
v
Deployment
|
v
+----------------------+
| Maintenance |
| |
| Fix --> Adapt |
| ^ | |
| | v |
| Improve <- Prevent |
+----------+-----------+
|
+---- Continuous LifecycleMaintenance work comes in four types. Corrective maintenance fixes defects that users report, like a crash on the payment page. Adaptive maintenance changes the software to fit a changed environment, like a new operating system version or a new regulation. Perfective maintenance adds improvements and new features, like a dark mode or a faster report. Preventive maintenance strengthens the code to avoid future problems, like refactoring messy code or adding missing tests.
Maintenance
|
+-----------------+-----------------+
| | |
v v v
Corrective Adaptive Perfective
Fix defects Fit new changes Improve system
|
v
Preventive
Avoid future bugsWhy does maintenance end up costing so much? Because the environment never stops moving. New operating systems are released, security threats evolve, laws change, and users keep asking for more. A product that is never maintained quietly decays — it becomes slow, insecure, and incompatible with modern platforms, and eventually users abandon it.
There is also a simple arithmetic reason. Building the software might take a year, but a successful product is maintained for many years. Even a modest monthly maintenance effort, accumulated over five or ten years, easily exceeds the original development cost. That is why serious organizations budget for maintenance from day one rather than treating it as an afterthought.
Initial Development
|
v
Release
|
v
+---------------+
| Maintenance |
+-------+-------+
|
+-------+-------+
| | |
v v v
Fix Adapt Improve
| | |
+-------+-------+
|
v
Long Product LifeThe key idea is that release day is a milestone, not a finish line. How well the product is maintained determines whether it thrives for a decade or decays within a year.
8. Which SDLC model is best suited for projects where requirements are highly volatile and change frequently?
The Agile Model is the clear choice for volatile requirements, because it is designed around exactly that situation. Its short iterations, continuous feedback, and openness to change make it the natural fit.
Changing Requirement
|
v
+------------------+
| Update Backlog |
+--------+---------+
|
v
+------------------+
| Plan Sprint |
+--------+---------+
|
v
+------------------+
| Build + Test |
+--------+---------+
|
v
+------------------+
| Customer Review |
+--------+---------+
|
v
Feedback
|
+--------------------+
|
v
Update BacklogAgile handles change easily because the plan is only ever fixed for a few weeks at a time. Each sprint is short, so when requirements change, the change simply becomes a new item for the next sprint. Nothing is locked in for months, so nothing needs to be ripped up when priorities shift.
The customer reviews working software at the end of every sprint. That means misunderstandings surface quickly, while they are still cheap to fix, rather than being discovered at the very end of the project. And the Agile Manifesto explicitly welcomes changing requirements even late in development — it treats change as an opportunity to deliver better value, not as a disruption.
Waterfall:
Requirements --> Design --> Code --> Test --> Release
|
+---- Change ----> Expensive Rework
Agile:
Backlog --> Sprint --> Working Software
^ |
| v
+------- Feedback <-----+The other models struggle with change for structural reasons. Waterfall locks requirements in at each phase, so a change means redoing completed work. The V-Model derives its test plans from the requirements, so changing requirements invalidate the plans. The Big Bang Model has no structure at all, so it just becomes more chaotic as changes pile up.
Agile is not a magic answer everywhere, though. It needs customers who are willing to give feedback every sprint, small self-organizing teams, and an environment where light documentation is acceptable. Projects that require heavy upfront approval, like some compliance-regulated work, may still do better with a plan-driven model. But when requirements are genuinely volatile, Agile is both the textbook answer and the industry norm.
9. What is the main objective of the Prototyping Model?
The main objective of the Prototyping Model is to clarify what the customer actually wants by building a quick, simplified, working version of the system and letting them react to it. The prototype is not the final product — it is a communication tool.
Rough Requirements
|
v
+-------------------+
| Build Prototype |
+---------+---------+
|
v
+-------------------+
| User Evaluation |
+---------+---------+
|
v
+-------------------+
| Collect Feedback |
+---------+---------+
|
v
+-------------------+
| Refine Prototype |
+---------+---------+
|
+-------------------+
|
v
User Evaluation
|
Repeat Until
Requirements ClearThe reason prototyping exists is that many customers cannot describe what they want in the abstract. They only really know what they want once they see something working. A prototype turns a vague idea into something tangible that they can click, explore, and complain about.
The process is a loop. First the team gathers a rough idea of the requirements. Then it builds a quick prototype covering the key screens and flows. Then users try it and give feedback — this is wrong, that is missing, this flow is confusing. The team revises the prototype and shows it again, and the loop repeats until the requirements settle down. Only then is the full system built properly.
+----------------------+
| Rough Requirements |
+----------+-----------+
|
v
+----------------------+
| Quick Prototype |
+----------+-----------+
|
v
+----------------------+
| User Feedback |
+----------+-----------+
|
v
+----------------------+
| Refine Requirements |
+----------+-----------+
|
+------------------+
|
v
Requirements Clear
|
v
Final DevelopmentThere are two kinds of prototypes. A throwaway prototype is built quickly, evaluated, and then discarded — it exists purely to discover requirements. An evolutionary prototype is refined again and again until it gradually turns into the actual product.
Throwaway:
Idea --> Prototype --> Feedback --> Discard
|
v
Build Final System
Evolutionary:
Idea --> Prototype --> Refine --> Refine --> Final Product
^ | |
+----------+----------+The advantages are real. Requirements end up clearer and more accurate because they are based on something concrete. Misunderstandings get caught early, when fixing them is cheap. And because users are involved throughout, they tend to accept the final product more readily.
There are also pitfalls. Users may mistake the prototype for the finished product and be disappointed when the real version takes longer and looks less polished. Without discipline, the revision loop never ends and the project stalls. And because prototypes focus on looks and flow, they can hide performance and security issues that only appear at full scale.
The model is the right choice when requirements are unclear, when there is no existing system to reference, or when the customer simply cannot articulate what they need.
10. What is the purpose of a Feasibility Study in the initial stages of SDLC?
A feasibility study is a go/no-go check done at the very start of a project, before significant money or time is spent. It asks whether the project is worth pursuing at all, and it looks at that question from several angles at once.
Project Idea
|
v
+-----------------+
| Feasibility |
| Study |
+--------+--------+
|
+----------+----------+
| | |
v v v
Technical Economic Operational
| | |
+----------+----------+
|
+----------+----------+
| | |
v v v
Schedule Legal Analysis
| | |
+----------+----------+
|
v
Go / No-Go
DecisionIt fits early in the SDLC, as one of the first activities of requirement analysis. Only if the study confirms the project is viable does full requirement gathering go ahead.
The classic way to remember the dimensions is the acronym TELOS. Technical feasibility asks whether the team has the technology, tools, and skills to build it. Economic feasibility asks whether the benefits justify the costs — will the project make or save enough money. Operational feasibility asks whether the system will actually work within the organization’s daily routines and whether users will accept it. Schedule feasibility asks whether it can be completed within the required time. Legal feasibility asks whether it complies with laws, regulations, and contracts.
TELOS
|
+---------------+---------------+
| | | | |
v v v v v
T E O S L
Technical Economic Operational Schedule Legal
| | | | |
+-------+-------+-------+-------+
|
v
Feasibility Report
|
v
+--------+--------+
| |
v v
GO NO-GO
Start/reshape Abandon/rethinkConsider a company evaluating a new automated billing system. The team would check whether their existing stack can handle automated billing, whether the system will pay for itself within a reasonable period, whether the finance team will actually use it, whether it can ship before the fiscal year end, and whether it complies with tax and data-protection rules.
The study matters because it prevents wasted effort. Plenty of projects are technically possible but financially absurd, or technically feasible but operationally unworkable, or simply illegal. Catching any of those problems before committing resources is far cheaper than discovering them halfway through development.
The output of the study is a feasibility report that lays out the findings for each dimension and gives a clear recommendation. That report becomes a key input to the decision to start the project, reshape it, or abandon it.
Premium Content
Unlock Top 10 Placement Questions - Part 1 and all premium lessons with a subscription.
From ₹199.99/year — See plans