SDLC and Software Development Methodology: Waterfall Model

SDLC and Software Development Methodology: Waterfall Model

Learning Objectives

After studying this lesson, students should be able to explain SDLC, describe the phases of the Waterfall Model, identify the deliverables of each phase, and evaluate the advantages and disadvantages of Waterfall for different software projects.

1. Introduction to SDLC

Software Development Life Cycle (SDLC) is a structured process used to plan, analyze, design, develop, test, deploy, and maintain a software system.

SDLC provides a systematic approach to software development so that the final product meets user requirements, satisfies quality standards, and is completed within the planned time and budget.

For example, if a university wants to develop a Student Attendance Management System, the development team must understand the requirements, design the system, write the code, test the software, and deploy it for teachers and students.

Objectives of SDLC

• Understand and document user requirements.
• Develop reliable and maintainable software.
• Control development costs and schedules.
• Reduce technical risks and development errors.
• Ensure software quality through systematic testing.
• Make software maintenance and future improvements easier.

2. Phases of SDLC

Phase 1: Planning and Feasibility Study

The project team identifies the problem, defines project objectives, estimates costs and resources, and evaluates whether the project is feasible.

Example: A university decides to replace paper-based attendance records with a digital system.

Phase 2: Requirements Analysis

Analysts collect and document functional and non-functional requirements from users and stakeholders.

Example: Teachers need to record attendance, students need to view attendance records, and administrators need to generate reports.

Phase 3: System Design

The team prepares the system architecture, database schema, user interfaces, UML diagrams, and module specifications.

Phase 4: Implementation (Coding)

Developers translate the design into executable code using programming languages, frameworks, and database technologies.

Phase 5: Testing

The team tests the software to identify defects and verify that the system satisfies its requirements. Testing may include unit, integration, system, and acceptance testing.

Phase 6: Deployment

The software is installed and made available to users. Activities may include server configuration, database setup, data migration, and user training.

Phase 7: Maintenance

The team fixes defects, improves performance, applies security updates, and adapts the software to changing requirements.

3. Software Development Methodology

A software development methodology is an organized approach that defines how a development team plans, designs, builds, tests, and delivers software.

Common software development methodologies include:

• Waterfall Model
• V-Model
• Iterative Model
• Incremental Model
• Prototyping Model
• Spiral Model
• Agile Methodology
• DevOps-oriented development

Each methodology has its own strengths and limitations. The selection depends on requirements, project risks, budget, schedule, complexity, and user involvement.

4. Waterfall Model

4.1 Definition

The Waterfall Model is a traditional software development methodology in which development activities are organized into sequential phases. Each phase is generally completed and reviewed before the next phase begins.

It is called the Waterfall Model because the process flows downward from one phase to another, similar to water flowing over a series of steps.

The model emphasizes upfront planning, clearly documented requirements, formal reviews, and controlled changes.

4.2 Waterfall Model Diagram

1. Planning and Feasibility

↓

2. Requirements Analysis

↓

3. System Design

↓

4. Implementation (Coding)

↓

5. Testing

↓

6. Deployment

↓

7. Maintenance

Figure: Sequential flow of the Waterfall Model.

In the traditional Waterfall approach, phases follow a predefined sequence. Earlier phases can be revisited when necessary, but doing so may require additional time, approval, and rework.

4.3 Phase 1: Planning and Feasibility Study

The project manager and stakeholders establish the project scope, objectives, budget, schedule, and resource requirements.

Key activities:

• Define the problem and project objectives.
• Identify stakeholders.
• Estimate costs, time, and resources.
• Evaluate project feasibility.
• Prepare the initial project plan.

Deliverable: Project proposal or feasibility report.

4.4 Phase 2: Requirements Analysis

The analyst collects and documents the requirements of students, teachers, administrators, and other stakeholders.

Functional requirements describe what the system must do. Examples include:

• Teachers can log in securely.
• Teachers can record attendance by course and section.
• Students can view their attendance records.
• Administrators can generate attendance reports.

Non-functional requirements describe the expected quality and constraints of the system, such as security, reliability, usability, and response time.

Deliverable: Software Requirements Specification (SRS).

4.5 Phase 3: System Design

The development team translates requirements into a technical design. Activities may include:

• System architecture design.
• Database design.
• User-interface design.
• UML diagrams.
• Module and component design.
• Security and access-control design.

For example, the attendance database may contain STUDENT, COURSE, SECTION, ENROLLMENT, and ATTENDANCE tables.

Deliverable: System design document, database schema, and interface specifications.

4.6 Phase 4: Implementation (Coding)

Developers implement the approved design using the selected technologies.

A university attendance system could use:

• Frontend: HTML, CSS, and JavaScript.
• Backend: Java and JSP.
• Database: Oracle Database.
• Database connectivity: JDBC.

Developers implement authentication, attendance entry, attendance calculation, and report-generation features.

Deliverable: Implemented software modules and source code.

4.7 Phase 5: Testing

The testing team verifies whether the implemented software satisfies the documented requirements.

Testing Type	Purpose	Example
Unit Testing	Test individual components.	Verify attendance calculation.
Integration Testing	Test interactions between modules.	Verify that attendance records save correctly to Oracle.
System Testing	Test the complete system.	Verify the full attendance workflow.
Acceptance Testing	Confirm that user needs are met.	Teachers verify the attendance process.

Defects are documented and corrected. Major problems may require the team to revisit earlier requirements or design decisions.

Deliverable: Test reports and a verified software build.

4.8 Phase 6: Deployment

After successful testing and approval, the software is installed in the production environment.

Deployment activities may include server configuration, database setup, user account creation, data migration, and user training.

Deliverable: Operational software available to its intended users.

4.9 Phase 7: Maintenance

After deployment, the team supports the system throughout its operational life.

• Corrective maintenance: Fixing defects.
• Adaptive maintenance: Adapting to new environments or regulations.
• Perfective maintenance: Improving performance or usability.
• Preventive maintenance: Reducing the likelihood of future problems.

For example, the university may request a feature that automatically alerts students when their attendance falls below a specified threshold.

Deliverable: Software updates, patches, and maintenance documentation.

5. Characteristics of the Waterfall Model

1. Sequential development: Activities generally follow a predefined order.
2. Defined requirements: Requirements should be sufficiently clear before detailed design and implementation.
3. Documentation-oriented: Major phases produce documents or formal deliverables.
4. Phase reviews: Outputs are reviewed before moving forward.
5. Controlled changes: Changes to approved requirements may require formal review and rework.
6. Planned testing: Testing is commonly emphasized as a distinct phase, although quality assurance should begin earlier.
7. Milestone-based management: Progress is tracked through phase completion and approval.

6. Advantages of the Waterfall Model

• Easy to understand and manage.
• Clear phases, responsibilities, and deliverables.
• Supports detailed documentation.
• Facilitates milestone-based progress tracking.
• Suitable when requirements are stable and well understood.
• Useful where formal approvals and traceability are important.

7. Disadvantages of the Waterfall Model

• Changes can be expensive after requirements and design have been approved.
• Working software may not be available until relatively late.
• Users may discover misunderstood requirements during testing.
• Late discovery of major defects can cause substantial rework.
• It offers less flexibility when business needs change frequently.
• It is less suitable for projects with high uncertainty or rapidly evolving requirements.

8. When Should the Waterfall Model Be Used?

The Waterfall Model may be appropriate when:

• Requirements are clear, stable, and well documented.
• The technology and architecture are well understood.
• The project has a clearly defined scope.
• Formal documentation and approvals are necessary.
• Changes are expected to be limited.
• The project team can plan the work reliably in advance.

It may be less appropriate when requirements are uncertain, users need frequent releases, or experimentation is essential.

9. Practical Case Study: Student Attendance Management System

Scenario: A university wants to replace its paper-based attendance process with a web-based system.

1. Planning: Approve the project scope, budget, schedule, and development resources.
2. Requirements: Finalize attendance entry, course-wise records, role-based access, and reports with stakeholders.
3. Design: Prepare the Oracle database schema, JSP page structure, access controls, and system architecture.
4. Coding: Develop login, attendance entry, attendance calculation, and reporting modules.
5. Testing: Verify login permissions, duplicate attendance prevention, data accuracy, and report generation.
6. Deployment: Install the application on the university server and train teachers and administrators.
7. Maintenance: Fix operational issues, update security controls, and implement approved changes.

Important Observation: If the university changes attendance rules after the database and application design are approved, the team may need to revise requirements, design, code, and tests. This illustrates why changes can be costly in a traditional Waterfall project.

10. Waterfall Model vs. Agile Methodology

Criteria	Waterfall	Agile
Development Approach	Sequential phases.	Iterative and incremental.
Requirements	Preferably stable upfront.	Can evolve during development.
Customer Feedback	Often concentrated around reviews and milestones.	Frequent throughout development.
Delivery	Commonly a major release after planned phases.	Frequent working increments.
Change Management	Formal and potentially costly.	Designed to accommodate change.
Documentation	Often extensive and phase-based.	Documentation tailored to project needs.
Best Suited For	Stable, well-defined projects.	Projects requiring learning and frequent feedback.

Neither methodology is universally superior. The appropriate choice depends on project requirements, risks, constraints, and stakeholder expectations.

11. Common Misconceptions About Waterfall

• Misconception: Once a phase is completed, it can never be revisited.
  Correction: Earlier phases can be revisited, but doing so may require approval, additional time, and rework.
• Misconception: Testing only means running the software after coding.
  Correction: Although testing is commonly a dedicated phase, test planning, reviews, and quality assurance should begin earlier.
• Misconception: Waterfall is suitable for every large project.
  Correction: Requirement stability, uncertainty, risk, and change frequency matter as well as project size.
• Misconception: Agile does not require planning or documentation.
  Correction: Agile projects also need planning, documentation, testing, and control; they organize these activities differently.

12. Review Questions

1. What does SDLC stand for?
2. What is a software development methodology?
3. Describe the seven phases of the Waterfall Model.
4. What is the purpose of an SRS document?
5. Differentiate between functional and non-functional requirements with examples.
6. Explain two advantages and three disadvantages of the Waterfall Model.
7. Why can late requirement changes be costly in Waterfall?
8. Compare the Waterfall Model and Agile methodology.

13. Classroom Activity / Assignment

Scenario: A university plans to develop an online course registration system.

1. Identify the seven SDLC phases for this project.
2. Write five functional and three non-functional requirements.
3. Identify the main deliverable of each Waterfall phase.
4. Explain two advantages and three disadvantages of using Waterfall for this project.
5. Suppose the university changes its registration policy during implementation. Explain how the Waterfall team should handle the change.

Expected Learning Outcome: Students should be able to explain SDLC, describe the Waterfall phases and deliverables, evaluate its strengths and weaknesses, and select a development methodology based on project characteristics.

Introduction to Systems, Information Systems, System Components, and the Role of a System Analyst

This tutorial introduces the basic concepts of systems, information systems, system components, and system analysis. Practical examples and a Student Attendance Management System case study are included to connect theory with real-world applications.

Learning Outcomes

After completing this tutorial, students should be able to:

• Define a system and explain its major characteristics.
• Identify the major components of a system.
• Explain input, processing, output, feedback, and control.
• Define an information system and describe its components.
• Differentiate data from information.
• Explain the responsibilities of a system analyst.
• Apply system analysis concepts to a practical case study.

1. What Is a System?

A system is a collection of related components that work together to achieve a common goal. These components may include people, procedures, data, hardware, software, and other resources.

A system receives inputs, performs activities, and produces outputs. Its components interact with one another to achieve the intended objective.

Example: A university can be considered a system. Students, teachers, administrators, classrooms, academic rules, and information systems work together to support teaching, learning, examinations, and graduation.

Examples of Systems

System	Input	Processing	Output
Library System	Book and member details	Book issue and return processing	Issue records and due dates
Banking System	Account and transaction details	Transaction validation and balance updates	Transaction confirmation
University Examination System	Student registration and marks	Eligibility checks and grade calculation	Results and grade sheets
Traffic Control System	Vehicle flow and sensor data	Traffic monitoring and signal control	Traffic signal changes

Characteristics of a System

• Organization: Components have a defined structure or arrangement.
• Interaction: Components communicate or work with one another.
• Interdependence: One component may depend on another component.
• Integration: Components operate together as a unified whole.
• Objective: A system exists to achieve one or more goals.
• Boundary: The boundary defines what is included within the system.
• Environment: External conditions and organizations may affect the system.

2. Major Components of a System

A common way to understand a system is through its input, processing, and output. Feedback and control help the system evaluate its performance and operate according to defined rules.

Input

→

Processing

→

Output

Feedback: Information about results or performance.

Control: Rules and actions used to guide or correct system operations.

Figure 1: A simplified input–process–output model.

1. Input

Data, resources, or requests entering the system.

Example: A student's ID and course code.

2. Processing

Activities that transform inputs into useful results.

Example: Checking whether a student is registered for a course.

3. Output

The information, service, or product generated by the system.

Example: An attendance record or report.

4. Feedback

Information used to evaluate performance and identify problems.

Example: A report showing low attendance.

5. Control

Rules and checks that help ensure the system operates correctly.

Example: Only authorized teachers can submit attendance.

6. Boundary and Environment

The boundary defines the system's scope; the environment includes external influences.

Example: University policies and network availability.

Open and Closed Systems

An open system exchanges information, resources, or energy with its environment. A university, for example, interacts with students, employers, families, and regulatory bodies.

A closed system is modeled as having little or no exchange with its environment. Completely closed systems are uncommon in real organizations, so this term is often used as a simplified analytical model.

3. What Is an Information System?

An Information System (IS) is an organized combination of people, procedures, data, and technology used to collect, process, store, and distribute information. Information systems support daily operations, coordination, control, and decision-making.

An information system is not just a computer program. People and procedures are essential because they determine how data is collected, checked, interpreted, protected, and used.

Components of an Information System

Component	Description	University Example
People	Users and professionals who interact with the system	Students, teachers, administrators, IT staff
Hardware	Physical devices used for input, processing, storage, and output	Computers, servers, scanners
Software	Programs that perform tasks and manage information	Attendance application and database software
Data	Recorded facts processed into useful information	Student ID, course code, attendance status
Procedures	Rules and instructions describing how tasks are performed	Steps for taking attendance and correcting errors
Networks and Communication	Connections that allow data to move between users and systems	Campus LAN, Wi-Fi, internet

Data Versus Information

Data consists of recorded facts. Information is data organized or processed so that it becomes meaningful for a particular purpose.

Raw Data	Information	Possible Decision
Present, Present, Absent, Present, Absent	Attended 3 of 5 classes; attendance is 60%	Review the attendance policy and follow up if necessary
Individual sales transactions	Monthly sales summary	Restock products with high demand
Individual examination marks	Course result sheet and grade distribution	Identify learning gaps and support students

Important: Incorrect, incomplete, duplicated, or outdated data may produce misleading information. Good decisions depend on reliable data.

Types of Information Systems

Type	Purpose	Example
Transaction Processing System (TPS)	Records routine daily transactions	Course registration or fee payment
Management Information System (MIS)	Produces regular summaries and reports	Monthly attendance report
Decision Support System (DSS)	Supports analysis of alternatives and decisions	Comparing alternative class schedules
Executive Information/Support System (EIS/ESS)	Provides high-level information for strategic oversight	University performance dashboard
Office Automation System	Supports communication and office activities	Email and shared calendars
Knowledge Management System	Captures and shares organizational knowledge	Teaching-resource portal

These categories can overlap. A modern university platform may provide several information-system functions within one integrated service.

4. System Analysis and System Design

System analysis is the process of studying a problem, understanding the current system, identifying user needs, and specifying what a proposed system should do.

System design translates the requirements into a plan for how the proposed solution will be structured and implemented.

System Analysis	System Design
What problem needs to be solved?	How will the solution work?
Who are the users and stakeholders?	What interfaces and screens are needed?
What information is required?	How will data be stored and related?
What rules and constraints apply?	What architecture and technologies should be used?
What must the system accomplish?	How will the components be organized?

5. The Role of a System Analyst

A system analyst studies an organization's needs and helps define an appropriate information-system solution. The analyst connects organizational stakeholders with the technical team.

The role is not limited to programming. It includes asking questions, studying workflows, identifying problems, documenting requirements, evaluating alternatives, and supporting implementation.

Main Responsibilities of a System Analyst

1. Understand the problem: Identify current difficulties, goals, constraints, and reasons for change.
2. Identify stakeholders: Determine who uses, manages, supports, or is affected by the system.
3. Gather requirements: Use interviews, surveys, observation, workshops, and document analysis.
4. Analyze current processes: Identify bottlenecks, repeated work, risks, and data-flow problems.
5. Define requirements: Document the functions and quality standards the system must satisfy.
6. Evaluate feasibility: Consider technical, economic, operational, schedule, and legal constraints.
7. Model the solution: Use appropriate diagrams and models to represent processes, data, and system behavior.
8. Communicate with stakeholders: Confirm that requirements are accurate and understandable.
9. Support testing and implementation: Help ensure that the delivered solution meets agreed requirements.
10. Support improvement: Review feedback and identify opportunities for future enhancements.

Functional and Non-Functional Requirements

Type	Meaning	Attendance System Example
Functional	A service or behavior the system must provide	A teacher can record attendance for a class.
Functional	A required operation or rule	The system calculates attendance percentages.
Non-functional: Security	A quality or constraint related to protection	Only authorized users can change attendance records.
Non-functional: Performance	Expected responsiveness or capacity	An attendance list loads within an agreed time.
Non-functional: Usability	Ease of use and accessibility	The interface works on common mobile and desktop browsers.
Non-functional: Reliability	Consistent and dependable operation	Saved records remain available after a system restart.

Important Skills for a System Analyst

• Communication: Explain technical and non-technical ideas clearly.
• Analytical thinking: Break complex problems into manageable parts.
• Requirements elicitation: Ask relevant questions and confirm users' actual needs.
• Modeling and documentation: Represent processes, data, and rules accurately.
• Technical knowledge: Understand databases, software, networks, and security.
• Problem-solving: Compare alternatives and help resolve conflicting requirements.
• Ethics and privacy awareness: Protect sensitive information and consider access controls.

System Analyst Versus Programmer

System Analyst	Programmer / Developer
Focuses on understanding needs and defining requirements.	Focuses on implementing software functionality.
Works closely with users, managers, and technical teams.	Works closely with analysts, designers, testers, and developers.
Produces requirement documents, models, and recommendations.	Produces source code, tests, and software components.
May contribute to design, testing, and implementation.	May help clarify requirements and design decisions.

In practice, these responsibilities may overlap, especially in small development teams.

6. Case Study: Student Attendance Management System

Imagine that a university department records attendance on paper. Teachers submit attendance sheets to the office, staff calculate percentages manually, and students may find it difficult to check their records.

The department wants a digital system that makes attendance recording, review, and reporting more efficient.

Problem Statement

The existing process may take considerable time and create risks of missing, inconsistent, or incorrectly calculated records. A digital solution should help authorized users record, review, and report attendance accurately.

Stakeholders

• Students: Need to review their attendance records.
• Teachers: Need to record attendance and make authorized corrections.
• Department administrators: Need course-wise, section-wise, and student-wise reports.
• IT administrators: Need to manage user accounts, backups, and availability.
• Department management: Needs reliable summaries to support academic decisions.

Example Functional Requirements

1. The system shall allow authorized users to sign in.
2. The system shall allow a teacher to select a course, section, and class date.
3. The system shall display registered students for the selected class.
4. The system shall allow the teacher to record each student's attendance status.
5. The system shall prevent duplicate attendance entries for the same student and class session unless an authorized correction process is used.
6. The system shall calculate attendance totals and percentages.
7. The system shall generate student-wise, course-wise, and section-wise reports.
8. The system shall record important changes when an audit trail is required.

Example Non-Functional Requirements

• Access shall be restricted according to user roles.
• Attendance records shall be protected against unauthorized modification.
• The interface should work on common mobile and desktop browsers.
• Data should be backed up according to an agreed schedule.
• Reports should be generated within an agreed response time under normal usage.

Input–Process–Output Model

Input
Course, date, status

→

Process
Validate and save

→

Output
Records and reports

Figure 2: High-level model of the attendance system.

Questions a System Analyst Should Ask

• Who is authorized to record attendance for each course?
• Can attendance be edited after submission? Who approves changes?
• How should late arrivals, excused absences, or makeup classes be represented?
• Should students see attendance immediately or after teacher confirmation?
• What reports are required, and who can access them?
• What happens if the network fails during a class?
• How long must records be retained, and how will they be backed up?

Key lesson: A system analyst should not begin by selecting a programming language or designing screens. First, the analyst must understand the problem, users, business rules, data, constraints, and success criteria.

7. Overview of the System Development Life Cycle (SDLC)

The System Development Life Cycle describes common activities involved in developing and maintaining an information system. The stages may be performed sequentially or iteratively, depending on the development approach.

Planning

→

Analysis

→

Design

→

Implementation

→

Testing & Maintenance

Figure 3: Simplified SDLC. Real projects may revisit earlier stages based on feedback.

Stage	Main Activity	Typical Deliverable
Planning and Feasibility	Define the problem, scope, resources, risks, and feasibility	Project plan or feasibility report
Analysis	Gather and validate requirements	Requirements specification
Design	Plan architecture, interfaces, data, and controls	Database and interface designs
Implementation	Build or configure the solution	Working application
Testing	Check whether the system meets requirements	Test cases and test results
Deployment and Maintenance	Release, support users, fix issues, and improve the system	Released system and updates

8. Common Mistakes to Avoid

• Assuming that a system is only a computer or software application.
• Confusing raw data with meaningful information.
• Ignoring people, procedures, security, or the organizational environment.
• Designing a solution before understanding the problem.
• Writing vague requirements that cannot be tested.
• Failing to validate requirements with stakeholders.
• Ignoring exceptional situations such as duplicate records or network failure.

9. Quick Revision

1. A system is a set of related components working toward a goal.
2. Input enters the system, processing transforms input, and output is the result.
3. Feedback provides performance information; control helps guide system operations.
4. An information system combines people, hardware, software, data, procedures, and communication networks.
5. Data are recorded facts; information is data organized or processed to be meaningful.
6. System analysis identifies problems and requirements; system design plans the solution.
7. A system analyst connects stakeholders and technical teams and helps define system requirements.
8. Good requirements should be clear, relevant, testable, and validated with stakeholders.

10. Review Questions

Short Questions

1. What is a system?
2. List five characteristics of a system.
3. What is the difference between input and output?
4. Define feedback and control.
5. What is an information system?
6. Differentiate data and information with an example.
7. What is system analysis?
8. What is system design?
9. Who is a system analyst?
10. What is the difference between functional and non-functional requirements?

Analytical and Discussion Questions

1. Explain the components of a system using a university as an example.
2. Describe the components of an information system and explain how they depend on one another.
3. Explain at least six responsibilities of a system analyst.
4. For a Student Attendance Management System, identify five stakeholders and write five functional requirements and three non-functional requirements.
5. Why should a system analyst investigate existing procedures before recommending new software?
6. Explain the major stages of the SDLC with examples.

11. Suggested References

• Kenneth E. Kendall and Julie E. Kendall, Systems Analysis and Design.
• Alan Dennis, Barbara Haley Wixom, and Roberta M. Roth, Systems Analysis and Design.
• Jeffrey A. Hoffer, Joey F. George, and Joseph S. Valacich, Modern Systems Analysis and Design.