The SDLC & Methodologies

The System Development Life Cycle

18 min Lesson 1 of 10

The System Development Life Cycle

Every software system — whether it is a clinic appointment app, an e-commerce platform, or a logistics tracking tool — passes through a recognisable set of phases from the moment someone says "we need to build this" to the moment it is decommissioned years later. That journey is captured by the System Development Life Cycle (SDLC).

The SDLC is not a single rigid method. It is a conceptual framework that describes the stages every development effort must address, regardless of whether you follow Waterfall, Agile, or something in between. Understanding it deeply gives you a mental map for knowing where you are, what questions to ask, and what deliverables you should be producing at each stage.

The Five Classic Phases

The traditional SDLC is divided into five phases. In practice these phases often overlap and iterate — but as a conceptual baseline, they are invaluable.

The five SDLC phases form a cycle — maintenance feeds lessons learned back into a new planning phase.

Phase 1 — Planning

Planning answers the most fundamental question: should we build this at all, and if so, how? This phase is often underestimated, but weak planning is the leading cause of project failures.

A feasibility study examines four dimensions:

Technical feasibility — Does the technology exist? Does the team have the skills?
Operational feasibility — Will end users accept and use the system?
Economic feasibility — Do the projected benefits outweigh costs? (A proper Cost-Benefit Analysis)
Schedule feasibility — Can the project be completed within the required timeframe?

Consider a private clinic that wants to replace paper appointment books with a digital booking system. Planning deliverables might include: a project charter naming the sponsor (clinic owner) and stakeholders (reception staff, GPs, patients), a high-level scope statement ("online booking with SMS reminders, integration with the existing billing system"), a rough budget of $45,000, and a 6-month target timeline. Crucially, a feasibility check might reveal that the billing system uses a 15-year-old proprietary format — a technical risk that must be flagged before development starts.

Key idea: The planning phase produces a decision, not code. The output is a project charter and feasibility report that authorise — or cancel — the project. Proceeding without this document means teams build systems that nobody needs or that cannot be funded to completion.

Phase 2 — Analysis

Analysis answers: what exactly must the system do? This is the core domain of the systems analyst. The analyst interviews stakeholders, observes existing workflows, studies existing documents, and transforms fuzzy business needs into precise, testable requirements.

Key activities include:

Requirements elicitation — Interviews, workshops, surveys, observation, document analysis.
Requirements documentation — User stories, use cases, or formal requirement specifications (FRS).
Process modelling — Business Process diagrams (BPM), Data Flow Diagrams (DFDs) of the current system.
Gap analysis — What does the current system do well? Where does it fail?
Requirements validation — Confirming with stakeholders that what was written matches what was meant.

For the clinic system, analysis might uncover that receptionists currently handle 80 appointment calls per day, average 4 minutes each, with a 12% no-show rate costing roughly $6,800/month in wasted slot revenue. These are concrete numbers that justify the project budget and define success metrics — not just a vague "we want to go digital."

Best practice: Always separate what stakeholders say they want from what they actually need. A receptionist who says "I want the system to be faster" actually needs to reduce the time spent on each booking from 4 minutes to under 1 minute. The requirement is a measurable target, not a preference.

Phase 3 — Design

Design answers: how will the system work? It translates requirements into a blueprint that developers can implement. Design operates at two levels:

Logical design — What the system must do, independent of technology. Entity-Relationship diagrams, Data Flow Diagrams for the proposed system, process flows.
Physical design — How it will be built. Database schema, server architecture, API contracts, UI wireframes, network topology, security controls.

For the clinic system, physical design decisions include: a relational database (PostgreSQL) to store appointments, patients, and doctors; a RESTful API layer; a React front-end for reception staff; an SMS gateway integration (Twilio); and a read-replica for reporting so booking queries never slow down report generation.

Good design also explicitly documents constraints and assumptions: "Assume a maximum of 20 concurrent reception users. The system must handle a surge of 500 bookings between 8:00–9:00 AM when the clinic opens." These numbers drive capacity decisions and prevent surprises at launch.

Phase 4 — Implementation

Implementation is where the blueprint becomes working software. It encompasses coding, unit testing, integration, system testing, user acceptance testing (UAT), and deployment.

The analyst's role does not end here. During implementation analysts:

Clarify ambiguous requirements when developers encounter edge cases.
Review test cases to ensure they cover business rules, not just technical paths.
Manage UAT — working with real clinic staff to validate that the built system matches the agreed requirements.
Write user manuals and training materials.
Track scope creep and formally evaluate change requests against the project charter.

Common pitfall: Treating implementation as "the developers take over and analysts disappear." This leads to silent requirement drift — developers make reasonable-sounding assumptions that turn out to be wrong. Analysts must stay available throughout implementation as the guardians of the original requirements.

Phase 5 — Maintenance

Maintenance is the longest phase of any system's life. Once the clinic booking system goes live, it will be extended, corrected, and optimised for years. Maintenance work falls into four categories:

Corrective — Fixing bugs discovered in production (e.g. a timezone bug causing double-bookings during daylight saving changes).
Adaptive — Updating the system to accommodate environmental changes (e.g. a new government regulation requires patient consent timestamps to be stored).
Perfective — Adding new features or improving performance based on user feedback (e.g. adding a patient-facing mobile app after 6 months of staff-only use).
Preventive — Refactoring code and updating dependencies to prevent future problems before they occur.

In practice, maintenance consumes 60–80% of total lifetime software cost. This is why decisions made in the design phase — database normalisation, API versioning, modular architecture — have enormous long-term financial consequences.

Why the Phases Are Not Strictly Sequential

The linear five-phase model is a teaching simplification. In the real world:

Analysis and design overlap — you often design a small piece to validate an unclear requirement.
Implementation reveals gaps in requirements — a developer building a feature realises the analysis missed an important edge case.
Maintenance generates new planning — a performance problem in production triggers a new analysis-and-design cycle for a caching layer.

Methodologies like Agile, Scrum, and Iterative Development formalise these overlaps into explicit short cycles called sprints or iterations — but they all still address the same five concerns: planning, analysis, design, implementation, and maintenance. They differ only in how and in what order and frequency those concerns are addressed.

Each SDLC phase produces concrete deliverables — shown here for a clinic appointment booking system.

The Analyst's Perspective

A systems analyst is most active in the Analysis and Design phases, but the role spans the entire SDLC. In planning, the analyst contributes to feasibility. In implementation, the analyst acts as the requirements guardian and leads UAT. In maintenance, the analyst evaluates change requests and decides whether they are in scope or require a new project cycle.

Understanding the SDLC is not bureaucratic formality. It is the operating model that allows teams of 10, 50, or 500 people to coordinate on a single shared goal — and to know who is responsible for what, at each stage of the journey.