CS 231: Software Engineering › Lesson 1 of 10

Software Development Life Cycle (SDLC)

Lesson 1 · OKSTEM College · AS Computer Science

What is the SDLC?

The Software Development Life Cycle is a structured process for planning, creating, testing, and deploying software. All major methodologies — Waterfall, Agile, Spiral — implement the same phases in different orders and iterations.

PhaseGoalKey artifact
PlanningScope, resources, scheduleProject plan, feasibility report
RequirementsWhat the system must doSRS (Software Requirements Spec)
DesignHow the system will do itArchitecture docs, UML diagrams
ImplementationWrite codeSource code, code reviews
TestingVerify correctnessTest plans, bug reports
DeploymentRelease to productionRelease notes, CI/CD pipeline
MaintenanceBug fixes, enhancementsPatches, updated docs

Waterfall vs. Agile

Waterfall

Sequential phases. Each phase must complete before the next begins. Requirements are locked early.

Agile

Iterative cycles (sprints, usually 2 weeks). Requirements evolve; working software is delivered frequently.

Agile Manifesto (2001): Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

Functional vs. Non-Functional Requirements

Functional requirements define what the system does: "Users can log in with email and password."

Non-functional requirements (NFRs) define how well it does it:

Practice Problems

Problem 1 — Classify Requirements

Classify each as Functional (F) or Non-Functional (NFR):
a) "The system shall send a password reset email within 30 seconds."
b) "Users can create, edit, and delete posts."
c) "The API must respond in under 200ms for 99th percentile requests."

a) Both! Sending the email = Functional; the 30-second constraint = NFR (performance). b) Functional — describes what users can do. c) NFR — performance constraint on an existing function.

Problem 2 — Agile Sprint Planning

Your team has a 2-week sprint and capacity of 40 story points. You have these backlog items: Login (8pts), Dashboard (13pts), Search (8pts), Export PDF (5pts), User Profile (8pts), Dark Mode (3pts). Which items fit in one sprint?

Step 1: Sort by priority (assume this order is priority order).
Step 2: Add points until you exceed 40.
Login(8) + Dashboard(13) + Search(8) + Export PDF(5) = 34 pts. Add User Profile(8): 34+8=42 — over capacity. Sprint includes Login, Dashboard, Search, Export PDF, and Dark Mode(3) = 37 pts (fits). User Profile moves to next sprint.

📋 SDLC Phase Visualizer

Knowledge Check

In the Waterfall model, when is testing performed?

That describes Agile/TDD, not Waterfall.
Testing at the start doesn't make sense — there's no code yet.
Correct — Waterfall tests after all code is written.
Testing before code exists would be acceptance criteria, not testing.
📖 Quick Recap

In Waterfall, testing is a distinct phase that happens after implementation. Agile integrates testing throughout each sprint.

📖 Quick Recap

The beginning phase is Planning/Requirements. Testing requires implemented code to verify.

📖 Quick Recap

You cannot test software that hasn't been written. In Waterfall, testing follows implementation.

Which of the following is a non-functional requirement?

This describes a feature (capability) — a functional requirement.
Correct — this is a performance (non-functional) constraint.
This describes behavior of a feature — functional.
Feature description = functional requirement.
📖 Quick Recap

Functional requirements describe what the system does. NFRs describe quality attributes: speed, reliability, security, scalability.

📖 Quick Recap

What the login form does is functional. How fast it responds or how secure it is would be NFRs.

📖 Quick Recap

Password reset is a capability/feature. NFRs would be: 'Reset email delivered within 60 seconds' or 'Token expires in 15 minutes'.

A key advantage of Agile over Waterfall is:

Agile values 'working software over comprehensive documentation'.
Fixed-price contracts are easier with Waterfall's upfront scope definition.
Correct — iterative sprints provide early value and accommodate evolving requirements.
Agile involves extensive planning — just in shorter cycles (sprint planning, backlog refinement).
📖 Quick Recap

The Agile Manifesto explicitly deprioritizes exhaustive documentation. Waterfall typically produces more formal documentation.

📖 Quick Recap

Agile's flexible scope makes fixed pricing difficult. Waterfall's locked requirements allow upfront cost estimation.

📖 Quick Recap

Agile planning is continuous: sprint planning, daily standups, retrospectives. It's not less planning, just more adaptive planning.

What does the 'M' in SMART requirements stand for?

Modular is a design principle, not a SMART criterion.
Correct — SMART requirements must be verifiable with objective criteria.
Maintained is about upkeep, not a SMART quality.
Modifiable describes requirements that can change — not a SMART quality.
📖 Quick Recap

SMART = Specific, Measurable, Achievable, Relevant, Time-bound. Measurable means you can verify when the requirement is met.

📖 Quick Recap

SMART: Specific, Measurable, Achievable, Relevant, Time-bound. Each letter has a specific meaning for writing good requirements.

📖 Quick Recap

SMART ensures requirements are well-defined and testable. Modifiable is a different quality (important but not part of SMART).

Technical debt refers to:

Hardware costs are capital expenses, not technical debt.
Deleted code leaves no future burden; technical debt accumulates from poor existing code.
Correct — like financial debt, technical debt accrues interest (slows future work).
Outdated docs is one form of technical debt but not the complete definition.
📖 Quick Recap

Technical debt is a software metaphor. It's the future rework cost of choosing a fast but poor solution now.

📖 Quick Recap

Technical debt is code that exists but was written in a way that will slow future development. Deleted code is simply gone.

📖 Quick Recap

Outdated documentation is a symptom. Technical debt broadly covers all forms of accumulated shortcuts: messy code, missing tests, outdated deps, poor architecture.

Next →