Here are clean, professional, interview-ready notes on SDLC (Software Development
Life Cycle).
SDLC (Software Development Life Cycle)
What is SDLC?
SDLC is a structured process used to design, develop, test, deploy, and maintain
software in a systematic way.
Simple Definition:
SDLC is a step-by-step process to build high-quality software in a planned and organized
manner.
Why SDLC is Important?
• Improves software quality
• Reduces development cost
• Helps in project planning and control
• Reduces risks and failures
• Ensures customer requirements are met
Phases of SDLC (Very Important)
1. Requirement Analysis
• Understand customer needs
• Gather functional and non-functional requirements
• Create SRS (Software Requirement Specification)
Example:
User wants a login system, payment system, admin panel.
2. System Design
• Convert requirements into system architecture
• Design:
o High-Level Design (HLD)
o Low-Level Design (LLD)
• Decide technologies, database, UI
Example:
3-tier architecture: UI, Business Logic, Database
3. Implementation (Coding)
• Developers write code
• Follow coding standards
• Unit testing by developers
Example:
Writing backend APIs and frontend code
4. Testing
• Verify and validate software
• Find bugs and defects
• Types:
o Unit Testing
o Integration Testing
o System Testing
o Acceptance Testing
Example:
Check login, signup, payment flow
5. Deployment
• Release software to production
• Make it available to users
Example:
Deploy web app on cloud server
6. Maintenance
• Bug fixing
• Performance improvement
• Feature updates
Example:
Add new payment method, fix security bugs
One-Line Interview Definition:
SDLC is a systematic process that defines all phases involved in developing, deploying,
and maintaining software.
SDLC Models (High Interview Weightage)
You should also know these models:
• Waterfall Model
• V-Model
• Incremental Model
• Spiral Model
• Agile Model
Quick Interview Questions
Q: Why is SDLC needed?
A: To develop software in a controlled, planned, and high-quality manner.
Q: What is SRS?
A: Software Requirement Specification document that contains complete system
requirements.
Here are professional, simple, and interview-ready notes on the most important SDLC
models, especially Waterfall vs Agile, which are very frequently asked.
Waterfall Model
What is Waterfall Model?
Waterfall is a linear and sequential SDLC model where each phase must be completed
before moving to the next.
Phases (In Order):
1. Requirement Analysis
2. System Design
3. Implementation (Coding)
4. Testing
5. Deployment
6. Maintenance
Key Characteristics:
• One phase after another
• No going back easily
• Documentation heavy
• Customer involved only at start
Advantages:
• Simple and easy to understand
• Good for small, fixed-requirement projects
• Easy to manage
Disadvantages:
• Not flexible
• Changes are difficult and costly
• Late testing
• High risk if requirements change
Use Case:
Government projects, small academic projects
Interview One-Liner:
Waterfall is a sequential model where each phase is completed before the next begins.
Agile Model (Very Important for Interviews)
What is Agile Model?
Agile is an iterative and incremental model where software is developed in small parts
(iterations or sprints).
Key Characteristics:
• Frequent customer feedback
• Continuous testing
• Flexible to change
• Working software delivered frequently
Agile Concepts:
• Sprint (2–4 weeks)
• Daily stand-up meetings
• Product backlog
• Incremental delivery
Advantages:
• Easily handles changing requirements
• Early delivery of working software
• High customer satisfaction
• Lower risk
Disadvantages:
• Less documentation
• Difficult to estimate time and cost
• Needs experienced team
Use Case:
Startups, web apps, mobile apps, fast-changing requirements
Interview One-Liner:
Agile is an iterative model that delivers software in small increments with continuous
customer feedback.
Waterfall vs Agile (Very Important Table)
Feature Waterfall Agile
Iterative &
Approach Sequential
Incremental
Flexibility Rigid Flexible
Customer
Low High
Involvement
Requirement
Difficult Easy
Changes
Testing After coding Continuous
Delivery One time Frequent
Documentation Heavy Light
Risk High Low
Fixed Changing
Best For
requirements requirements
Other Important SDLC Models (Know
Names)
V-Model
• Extension of Waterfall
• Testing phase for each development phase
• Verification and Validation
Incremental Model
• Software developed in small increments
• Each increment adds new features
Spiral Model
• Risk-driven model
• Combines waterfall + prototyping
• Good for large, high-risk projects
Common Interview Questions
Q: Which model is best?
A: Depends on project type and requirements.
Q: Why Agile is preferred today?
A: Because it supports changing requirements and faster delivery.
Below are short, professional, exam/interview-style one-line to two-line definitions for
all major Software Testing Types. These are perfect for quick revision.
Software Testing Types — Short Definitions
Based on Testing Level
Unit Testing
Testing individual functions or modules to ensure they work correctly. Usually done by
developers.
Integration Testing
Testing interaction between combined modules to check data flow and interface issues.
System Testing
Testing the complete integrated system as a whole to verify end-to-end functionality.
Acceptance Testing (UAT)
Testing done by client or end users to confirm the system meets business requirements.
Based on Knowledge of Code
Black Box Testing
Testing without knowledge of internal code, based only on inputs and expected outputs.
White Box Testing
Testing with knowledge of internal code structure, logic, and paths.
Grey Box Testing
Testing with partial knowledge of internal implementation.
Based on Purpose
Regression Testing
Re-testing existing features after changes to ensure no new bugs are introduced.
Smoke Testing
Basic testing to check whether the build is stable for detailed testing.
Sanity Testing
Quick testing of specific functionality after a small change.
Performance Testing
Testing system speed, scalability, and stability under different loads.
Load Testing
Testing system behavior under expected normal load.
Stress Testing
Testing system behavior under extreme load beyond normal capacity.
Volume Testing
Testing system performance with a large amount of data.
Endurance (Soak) Testing
Testing system performance over a long period of time.
Specialized Testing
Security Testing
Testing to find vulnerabilities and ensure data and system are protected.
Usability Testing
Testing how easy and user-friendly the system is for end users.
Compatibility Testing
Testing software on different browsers, devices, and operating systems.
Installation Testing
Testing whether software installs and uninstalls correctly.
Recovery Testing
Testing how well the system recovers from crashes or failures.
Alpha Testing
Internal testing done by organization before releasing to users.
Beta Testing
External testing done by real users before final release.
Very Short One-Liners for Interview
• Unit Testing: Tests individual code units
• Integration Testing: Tests combined modules
• System Testing: Tests full system
• UAT: Client approval testing
• Black Box: No code knowledge
• White Box: With code knowledge
• Regression: Re-test after changes
• Smoke: Build stability check
• Sanity: Specific feature check
• Load: Normal load testing
• Stress: Beyond limit testing
• Security: Find vulnerabilities
Black Box Testing vs White Box Testing
(Very Important)
Black Box Testing
Definition:
Black Box Testing is a testing technique where the tester does not know the internal code
or logic and tests the system based on inputs and expected outputs.
Focus:
Functionality and behavior of the system.
Characteristics:
• No knowledge of source code
• Based on requirements and specifications
• Tests what the system does, not how
Examples:
• Login with valid/invalid credentials
• Check error messages
• UI and form validation
Techniques Used:
• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table Testing
Advantages:
• User perspective testing
• No programming knowledge required
• Finds missing functionality
Disadvantages:
• Limited coverage of internal logic
• Cannot test internal paths
White Box Testing
Definition:
White Box Testing is a testing technique where the tester has full knowledge of internal
code, structure, and logic.
Focus:
Internal code structure and logic.
Characteristics:
• Requires programming knowledge
• Tests how the system works internally
• Covers statements, branches, and paths
Examples:
• Testing all if-else conditions
• Loop testing
• Path coverage testing
Techniques Used:
• Statement Coverage
• Branch Coverage
• Path Coverage
Advantages:
• High code coverage
• Finds hidden logical errors
• Optimizes code
Disadvantages:
• Requires technical skills
• Cannot detect missing requirements
Black Box vs White Box (Comparison
Table)
Feature Black Box Testing White Box Testing
Code
Not required Required
Knowledge
Focus External behavior Internal logic
Based On Requirements Code
Tester QA/Testers Developers
Coverage Functional coverage Code coverage
System, Acceptance
Used In Unit Testing
Testing
Finds Missing functions, UI bugs Logic errors, dead code
Programming
Skills Needed Domain knowledge
knowledge
Grey Box (Short Note)
Grey Box Testing is a combination of black box and white box testing, where tester has
partial knowledge of internal code.
Interview One-Liners
• Black Box tests what the system does.
• White Box tests how the system works internally.
• Black Box focuses on functionality.
• White Box focuses on code logic.
What is a Use Case Diagram?
A Use Case Diagram is a UML diagram that shows how users (actors) interact with a
system and what functions (use cases) the system provides.
Simple Definition:
A Use Case Diagram represents functional requirements of a system from the user’s
point of view.
Why Use Case Diagram is Important?
• Understand system requirements clearly
• Identify system functionalities
• Show interaction between users and system
• Helpful for communication with clients
• Used in requirement analysis phase
Main Components (Very Important)
1. Actor
Represents a user or external system that interacts with the system.
Examples:
• Customer
• Admin
• Bank Server
• Payment Gateway
Symbol: Stick figure
2. Use Case
Represents a function or service provided by the system.
Examples:
• Login
• Withdraw Cash
• Place Order
• Make Payment
Symbol: Oval
3. System Boundary
Defines the scope of the system.
Example:
A rectangle with system name inside
ATM System, Library Management System
4. Association
Shows interaction/communication between actor and use case.
Symbol: Simple line
Special Relationships (Interview Important)
1. Include (<<include>>)
Used when one use case always uses another use case.
Meaning:
Mandatory reuse of functionality.
Example:
Place Order <<include>> Make Payment
Meaning:
Whenever Place Order happens, Make Payment must happen.
2. Extend (<<extend>>)
Used when one use case optionally extends another.
Meaning:
Optional behavior.
Example:
Login <<extend>> Forgot Password
Meaning:
Forgot Password happens only if user forgets password.
3. Generalization
Used to show inheritance between actors or use cases.
Example:
User
→ Admin
→ Customer
Admin and Customer are specialized types of User.
Simple Example: ATM System
Actors:
• Customer
• Bank Server
Use Cases:
• Insert Card
• Enter PIN
• Withdraw Cash
• Check Balance
• Print Receipt
Relationships:
• Withdraw Cash <<include>> Enter PIN
• Print Receipt <<extend>> Withdraw Cash
Key Points for Interview
• Use Case Diagram shows what system does, not how it is implemented
• It is used in requirement analysis phase
• It focuses on functional requirements
• It does not show internal logic or data flow
One-Line Interview Answers
• A Use Case Diagram shows interactions between users and system functionalities.
• Actors represent users or external systems.
• Use cases represent system functions.
• <<include>> is mandatory reuse.
• <<extend>> is optional behavior.
Common Interview Questions
Q: Difference between Include and Extend?
A: Include is mandatory, Extend is optional.
Q: Does use case diagram show internal logic?
A: No, it only shows external functional behavior.
Q: In which SDLC phase is use case diagram used?
A: Requirement Analysis and System Design.
Functional vs Non-Functional
Requirements (Very Important)
Functional Requirements
Definition:
Functional Requirements define what the system should do. They describe the features
and functions of the system.
Focus:
System behavior and operations.
Examples:
• User can login with username and password
• User can make payment
• Admin can add/delete users
• System should generate monthly report
• User can search products
Characteristics:
• Describe system services
• Directly related to business logic
• Can be tested using functional testing
• Answer the question: What does the system do?
Interview One-Liner:
Functional requirements specify the functions and features of the system.
Non-Functional Requirements
Definition:
Non-Functional Requirements define how the system should work. They describe quality
attributes and constraints.
Focus:
System performance, quality, and limitations.
Examples:
• System should respond within 2 seconds
• System should handle 10,000 users concurrently
• System should be available 99.9% of the time
• System should be secure (encryption, authentication)
• System should be scalable
• System should be user-friendly
Characteristics:
• Describe system quality
• Indirectly related to business logic
• Affect user experience and system reliability
• Answer the question: How well does the system work?
Interview One-Liner:
Non-functional requirements specify the quality and performance of the system.
Functional vs Non-Functional (Comparison
Table)
Functional Non-Functional
Feature
Requirements Requirements
Meaning What system does How system works
Focus Features & services Quality & constraints
Examples Login, payment, report Performance, security
Type Business logic System quality
Testing Functional testing Performance, security testing
User Visible Directly Indirectly
Measurement Usually yes/no Measurable metrics
Change
Moderate High
Impact
Common Categories of Non-Functional
Requirements
Very important to remember:
• Performance (response time, throughput)
• Scalability
• Reliability
• Availability
• Security
• Usability
• Maintainability
• Portability
• Compatibility
Simple Memory Trick
Functional = Function (Features)
Non-Functional = Nature (Quality)
Interview Examples (Good to Say)
Functional:
"The system should allow users to reset password."
Non-Functional:
"The system should reset password within 3 seconds and be available 24/7."
SRS (Software Requirement Specification)
— Interview & Exam Notes
What is SRS?
Definition:
SRS is a formal document that describes complete functional and non-functional
requirements of a software system.
Simple Definition:
SRS is a document that clearly defines what the software should do and how it should
behave.
Purpose of SRS
• Acts as an agreement between client and developer
• Provides clear understanding of requirements
• Helps in design, development, and testing
• Reduces ambiguity and misunderstanding
• Acts as a reference throughout SDLC
Contents of SRS (Very Important)
Typical IEEE SRS structure:
1. Introduction
• Purpose of document
• Scope of system
• Definitions, acronyms, abbreviations
2. Overall Description
• Product perspective
• Product functions
• User characteristics
• Operating environment
• Design constraints
• Assumptions and dependencies
3. Functional Requirements
• Detailed system functions
• Use cases
• Business rules
4. Non-Functional Requirements
• Performance
• Security
• Reliability
• Availability
• Usability
• Scalability
5. External Interface Requirements
• User interfaces
• Hardware interfaces
• Software interfaces
• Communication interfaces
6. System Features (Optional)
• Feature-wise detailed description
Characteristics of a Good SRS (Interview Important)
A good SRS should be:
• Correct
• Complete
• Consistent
• Unambiguous
• Verifiable
• Modifiable
• Traceable
Advantages of SRS
• Reduces development errors
• Improves project planning
• Helps in cost and time estimation
• Helps testers create test cases
• Avoids scope creep
Disadvantages of SRS
• Time-consuming to prepare
• Hard to change once finalized
• Requires strong communication
SRS vs Design Document (Short)
Design
SRS
Document
What to build How to build
Customer Developer
focused focused
Requirement
Design phase
phase
One-Line Interview Answers
• SRS is a document that specifies all software requirements.
• SRS acts as a contract between client and developer.
• SRS defines what the system should do, not how.
Very Common Interview Questions
Q: In which phase is SRS prepared?
A: Requirement Analysis phase.
Q: Who prepares SRS?
A: Business analysts, system analysts, with client and developer input.
Q: Is SRS a technical document?
A: It is semi-technical, understandable by both client and developers.
Verification vs Validation (Very Important)
Verification
Definition:
Verification is the process of checking whether the product is being built correctly
according to specifications and design.
Simple Meaning:
Are we building the product right?
Focus:
Process-oriented
When:
During development (before execution)
How:
• Reviews
• Inspections
• Walkthroughs
• Design reviews
• Code reviews
Characteristics:
• No code execution required
• Static testing
• Ensures correctness of process and documents
Example:
Reviewing SRS document for correctness.
Validation
Definition:
Validation is the process of checking whether the correct product is being built to meet
user needs.
Simple Meaning:
Are we building the right product?
Focus:
Product-oriented
When:
After development (during execution)
How:
• Functional testing
• System testing
• Acceptance testing
Characteristics:
• Code execution required
• Dynamic testing
• Ensures user requirements are met
Example:
Testing login feature to see if user can login successfully.
Verification vs Validation (Comparison
Table)
Feature Verification Validation
Are we building the right
Meaning Are we building it right?
thing?
Focus Process Product
Type Static testing Dynamic testing
Code
No Yes
Execution
Done By QA + Developers Testers + Users
Examples Reviews, inspections Testing, UAT
Specification/design
Finds Functional bugs
errors
Phase Throughout development After coding
One-Line Interview Answers
• Verification checks documents and design.
• Validation checks actual working software.
• Verification is static testing.
• Validation is dynamic testing.
Simple Memory Trick
Verification = Verify documents
Validation = Validate working product