SOFTWARE ENGINEERING
Comprehensive Guide to Key Methodologies and Concepts
1. Waterfall Model vs Spiral Model
Waterfall Model Spiral Model
Follows a linear, sequential approach where Follows an iterative, risk-driven approach
phases flow downwards like a waterfall. represented as a spiral.
Risk analysis is minimal or absent. Risk analysis is a core component of every
phase.
Best suited for small projects with well- Best suited for large, complex, and high-risk
defined, clear requirements. projects.
Rigid structure; difficult to accommodate Highly flexible; accommodates changes at
changes once a phase is complete. the start of each new iteration.
2. Waterfall Model vs Agile Model
Waterfall Model Agile Model
Sequential design process. Iterative and incremental design process.
Requirements are fixed at the beginning of Requirements are expected to evolve
the project. dynamically throughout the project.
Testing is done after the "Build" phase is Testing is performed concurrently with
entirely complete. development in short sprints.
Customer involvement is high at the Continuous customer involvement and
beginning and end, but low during feedback are required.
development.
3. Spiral Model vs Agile Methodology
Spiral Model Agile Methodology
Focuses heavily on identifying and mitigating Focuses on rapid delivery of functional
risks early. software and customer collaboration.
Iterations (loops) can take months or years, Iterations (sprints) are short, typically lasting
emphasizing thorough planning. 1 to 4 weeks.
Documentation is comprehensive and Documentation is kept lightweight in favor of
rigorous at each stage. working software.
Costly to implement, usually reserved for Cost-effective and adaptable, suitable for
enterprise-scale or critical systems. projects of all sizes.
4. Functional vs Non-Functional Requirements
Functional Requirements Non-Functional Requirements
Defines what the system must do (features, Defines how the system performs (qualities,
behavior, capabilities). constraints, standards).
Examples: "User must be able to log in", Examples: "Page must load in under 2
"System must generate a report". seconds", "System must handle 10,000
users".
Captured in Use Cases, User Stories, or Data Captured in Quality Attributes (Performance,
Flow Diagrams. Security, Usability, Reliability).
Mandatory for the system to work. Crucial for user satisfaction and system
viability.
5. User Requirements vs System Requirements
User Requirements System Requirements
Written from the user's perspective, Written from the developer's perspective,
describing the services the system will detailing the software's exact functions.
provide.
Described in natural language without Described using structured language,
technical jargon. models, and technical specifications.
Intended audience: End-users, clients, and Intended audience: Software engineers,
business managers. developers, and system architects.
6. SRS vs SRD
Software Requirements Specification Software Requirements Document
(SRS) (SRD)
A comprehensive standard document (e.g., Often used as a general term for any
IEEE 830) defining complete software document capturing software requirements.
behavior.
Contains detailed functional, non-functional, May be a higher-level summary or precursor
interface, and performance specs. to the formal SRS.
Highly structured, technically precise, acts as Can vary in structure depending on the
a strict contract for developers. organization's naming conventions.
7. Requirement Elicitation vs Requirement Analysis
Requirement Elicitation Requirement Analysis
The process of gathering information from The process of structuring, evaluating, and
stakeholders and users. refining the gathered information.
Techniques include interviews, surveys, Techniques include modeling, prototyping,
brainstorming, and observation. and resolving requirement conflicts.
Output: Raw lists of needs, notes, and user Output: Structured, prioritized, and validated
stories. requirement models.
8. Design Process vs Design Quality
Design Process Design Quality
The sequence of steps taken to create the The set of characteristics that determine if the
software architecture and components. design is "good" or maintainable.
Involves activities like architectural design, Evaluated using metrics like cohesion,
interface design, and database design. coupling, modularity, and abstraction.
Action-oriented (the "doing"). Attribute-oriented (the "result").
9. Architectural Styles vs Architectural Patterns
Architectural Styles Architectural Patterns
High-level, broad structural organization of a Specific solutions to recurring design
system (e.g., Client-Server, Microservices). problems within a given context (e.g., MVC).
Defines the overall vocabulary and More localized; helps in structuring specific
component types for the whole system. subsystems or interactions.
Strategic and foundational. Tactical and implementational.
10. Black-Box Testing vs White-Box Testing
Black-Box Testing White-Box Testing
Testing without knowledge of the internal Testing with full knowledge of the internal
code or system logic. source code and logic.
Focuses on input and expected output Focuses on internal paths, loops, branches,
(functional behavior). and statements.
Performed mostly by Software Testers or QA Performed mostly by Software Developers.
teams.
Also known as behavioral or opaque-box Also known as structural, clear-box, or glass-
testing. box testing.
11. Verification vs Validation
Verification Validation
Answers: "Are we building the product right?" Answers: "Are we building the right product?"
Checks if the software conforms to its Checks if the software meets the actual
specification and design. needs and expectations of the user.
Activities: Reviews, walkthroughs, Activities: Actual execution and testing of the
inspections (static testing). software (dynamic testing).
12. Unit Testing vs Integration Testing
Unit Testing Integration Testing
Tests individual, isolated modules or Tests the interaction and interfaces between
functions. multiple combined modules.
Aim is to ensure each unit works perfectly in Aim is to find defects in the communication
isolation. and data flow between units.
Performed first, usually by the developer who Performed after unit testing, often using stubs
wrote the code. and drivers.
13. Integration Testing vs System Testing
Integration Testing System Testing
Checks how integrated modules work Checks how the entire, fully integrated
together. system performs as a whole.
Focuses on interface and data-flow errors. Focuses on meeting end-to-end functional
and non-functional requirements.
Precedes system testing. Follows integration testing, preceding
acceptance testing.
14. Testing vs Debugging
Testing Debugging
The process of finding defects or bugs in the The process of locating the root cause of the
software. bug and fixing it.
Can be planned, designed, and executed Is a reactive, unpredictable process based on
systematically. test results.
Performed by Testers and Developers. Performed exclusively by Developers.
15. Reactive Risk Strategy vs Proactive Risk Strategy
Reactive Risk Strategy Proactive Risk Strategy
Dealing with risks only after they have Identifying and planning for risks before they
occurred ("Firefighting"). occur.
Focuses on mitigation and damage control. Focuses on avoidance, preparation, and
contingency planning.
Usually results in higher costs and project Reduces costs, stress, and ensures
delays. smoother project execution.
16. Risk Identification vs Risk Analysis
Risk Identification Risk Analysis
The process of discovering, recognizing, and The process of assessing the likelihood and
documenting potential risks. impact of identified risks.
Answers: "What could go wrong?" Answers: "How bad will it be, and how likely
is it?"
Results in a raw list or register of risks. Results in prioritized risks sorted by severity,
often using risk matrices.