Software Development Life Cycle (SDLC): Methodologies and Requirements Engineering

SS3 Term 1 • Week 1

About 45 minutes

Welcome to Senior Secondary 3 Computer Studies! Over your years of study, you have mastered foundational hardware, software applications, database engineering, and programming algorithms.

Now, in SS 3, you transition from writing isolated programs to Professional Systems Engineering. How do engineering teams build massive, mission-critical platforms—such as the Nigerian Inter-Bank Settlement System (NIBSS), hospital management systems, or air traffic control software—without collapsing into chaos, missed deadlines, or security failures?

They follow the Software Development Life Cycle (SDLC). In this lesson, we study SDLC methodologies, compare Waterfall with Agile/Scrum, and learn Requirements Engineering.

Learning Outcomes

By the end of this lesson, you will be able to:

Map the six universal phases of the Software Development Life Cycle.
Evaluate the trade-offs between the Waterfall Model and Agile Frameworks.
Classify requirements into Functional Requirements and Non-Functional Requirements.
Author formal User Stories with measurable Acceptance Criteria.

Key Vocabulary

Term	Technical Definition
SDLC	Software Development Life Cycle; a structured engineering process used to plan, create, test, deploy, and maintain software systems.
Waterfall Model	A linear-sequential software methodology where each phase flows strictly into the next with heavy upfront documentation.
Agile Methodology	An iterative, collaborative approach to software development focused on rapid releases, customer feedback, and continuous adaptation.
Functional Requirement	A statement defining a specific behavior, calculation, data manipulation, or feature that the software must execute.
Non-Functional Requirement	A specification describing system quality attributes, operational limits, or constraints (security, latency, scalability, uptime).
Product Backlog	A prioritized list of features, bug fixes, and technical tasks maintained by an Agile team.

The Six Universal Phases of the SDLC

Every professional software project proceeds through six fundamental stages:

┌────────────────────────────────────────────────────────────────────────┐
│               THE SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)               │
└────────────────────────────────────────────────────────────────────────┘
  1. Feasibility & Planning  ──> Economic, legal, technical feasibility analysis
             │
  2. Requirements Analysis   ──> SRS document, stakeholder interviews, user stories
             │
  3. Architecture & Design   ──> Database schemas (ERD), system flowcharts, UI wireframes
             │
  4. Implementation (Coding) ──> Writing production source code and unit tests
             │
  5. Verification & Testing  ──> Integration testing, security audits, UAT
             │
  6. Deployment & Maintenance──> Production release, cloud hosting, bug patching

Methodology Showdown: Waterfall vs. Agile Scrum

Different projects require different development methodologies:

1. The Waterfall Model (Predictive & Structured)

Concept: Conceived by Winston Royce in 1970. Work cascades downward like water over a cliff: Planning $\rightarrow$ Requirements $\rightarrow$ Design $\rightarrow$ Implementation $\rightarrow$ Verification $\rightarrow$ Maintenance.
Strengths: Clear milestones, exhaustive documentation, predictable costs if requirements never change.
Weaknesses: Inflexible. If a flaw in requirements is discovered during testing at month 9, fixing it requires rewriting designs and code at tremendous financial loss.
Best For: Highly regulated safety-critical systems (e.g., flight control firmware, medical radiation devices).

2. The Agile / Scrum Framework (Adaptive & Empirical)

Concept: Codified in the 2001 Agile Manifesto. Software is delivered in rapid, 2-to-4-week iterations called Sprints.
Strengths: Working software is demonstrated to stakeholders every two weeks. Feedback is incorporated immediately.
Weaknesses: Scope creep if customer continuously adds features without budget discipline; less upfront formal architecture documentation.
Best For: Web apps, mobile apps, SaaS startups, and enterprise business solutions.

Waterfall:
[Requirements] ──> [Architecture] ──> [Development] ──> [Testing] ──> [Release (Month 12)]

Agile (Continuous Sprints):
[Sprint 1 (2 wks)] ──> Working Mini-Release 1
[Sprint 2 (2 wks)] ──> Working Mini-Release 2 (Tested & Feedback Incorporated)
[Sprint 3 (2 wks)] ──> Working Mini-Release 3 ...

Requirements Engineering: Functional vs. Non-Functional

Before writing a single line of Python, C++, or SQL, systems analysts must define what the system must do:

Functional Requirements (WHAT the system does):

"The portal must allow candidates to submit their JAMB registration number and print an admission letter."
"The inventory system must deduct item stock when a point-of-sale receipt is printed."
"The system must send a 6-digit one-time password (OTP) via SMS when a user logs in from a new IP address."

Non-Functional Requirements (HOW WELL the system does it):

Performance / Latency: "Search results must render in less than 500 milliseconds for a database of 2,000,000 records."
Security: "All stored student passwords must be salted and hashed using Argon2 or bcrypt. Plain text passwords are prohibited."
Availability / Uptime: "The school portal must achieve 99.9% uptime during the 3-week semester exam registration window."
Scalability: "The database must support 10,000 concurrent user sessions without exceeding 70% CPU utilization."

Practical Activity: Agile Product Backlog and Story Point Estimation

In this practical activity, you will act as the Lead Systems Analyst for a Nigerian School Bus Tracking Application and construct a formal Agile User Story Backlog with Acceptance Criteria.

Step 1: Create `agile_backlog_tool.py`

# Agile Product Backlog Management Tool
class UserStory:
    def __init__(self, story_id, role, feature, benefit, points):
        self.story_id = story_id
        self.role = role
        self.feature = feature
        self.benefit = benefit
        self.points = points  # Fibonacci estimation: 1, 2, 3, 5, 8, 13
        self.acceptance_criteria = []
        self.status = "Backlog"

    def add_criterion(self, criterion):
        self.acceptance_criteria.append(criterion)

    def display(self):
        print(f"[{self.story_id}] Points: {self.points} | Status: {self.status}")
        print(f"As a {self.role}, I want to {self.feature} so that {self.benefit}.")
        print("Acceptance Criteria:")
        for idx, c in enumerate(self.acceptance_criteria, 1):
            print(f"  {idx}. {c}")
        print("-" * 65)

# Initialize Product Backlog
backlog = []

# Story 1: Parent Notification
s1 = UserStory(
    "US-01", "Parent", 
    "receive an SMS alert when the school bus is within 1 kilometer of my bus stop",
    "I can walk my child to the stop without waiting outside in the rain", 
    5
)
s1.add_criterion("SMS arrives within 30 seconds of bus crossing the 1km geofence boundary.")
s1.add_criterion("Alert displays current bus speed and driver's direct contact number.")
s1.add_criterion("If cellular network fails, a push notification is sent as fallback.")
backlog.append(s1)

# Story 2: Bus Driver Check-in
s2 = UserStory(
    "US-02", "School Bus Driver",
    "tap a student's NFC ID card onto the dashboard tablet when boarding",
    "attendance is marked in real time without paper rosters",
    3
)
s2.add_criterion("Tablet beeps green for registered students; sounds warning buzzer if unregistered.")
s2.add_criterion("Works offline if cellular data drops in transit, queuing scans for sync.")
backlog.append(s2)

# Sprint Planning: Calculate Sprint Velocity
sprint_capacity = 10
total_points = sum(story.points for story in backlog)

print("=== KINSPIRE AGILE SPRINT 1 BACKLOG ===")
for story in backlog:
    story.display()

print(f"Total Backlog Points: {total_points}")
print(f"Sprint Capacity:      {sprint_capacity} points")
if total_points <= sprint_capacity:
    print("STATUS: Sprint scope is healthy! Team can commit to delivery.")

Step 2: Run the Backlog Tool

python agile_backlog_tool.py

Expected Results and Model Output

When you run agile_backlog_tool.py, your terminal will display:

=== KINSPIRE AGILE SPRINT 1 BACKLOG ===
[US-01] Points: 5 | Status: Backlog
As a Parent, I want to receive an SMS alert when the school bus is within 1 kilometer of my bus stop so that I can walk my child to the stop without waiting outside in the rain.
Acceptance Criteria:
  1. SMS arrives within 30 seconds of bus crossing the 1km geofence boundary.
  2. Alert displays current bus speed and driver's direct contact number.
  3. If cellular network fails, a push notification is sent as fallback.
-----------------------------------------------------------------
[US-02] Points: 3 | Status: Backlog
As a School Bus Driver, I want to tap a student's NFC ID card onto the dashboard tablet when boarding so that attendance is marked in real time without paper rosters.
Acceptance Criteria:
  1. Tablet beeps green for registered students; sounds warning buzzer if unregistered.
  2. Works offline if cellular data drops in transit, queuing scans for sync.
-----------------------------------------------------------------
Total Backlog Points: 8
Sprint Capacity:      10 points
STATUS: Sprint scope is healthy! Team can commit to delivery.

Common Mistakes to Avoid

Vague Acceptance Criteria: Writing criteria like "The system should be fast" is untestable. Specify exact thresholds: "Page response time must be under 1.5 seconds on a 3G mobile connection."
Confusing Methodology with Tooling: Jira and Trello are software tools; Agile is a collaborative philosophy and project management methodology. Tools do not make a team Agile if they still follow rigid, waterfall processes.
Skipping Requirements Analysis to Start Coding Immediately: Writing code before defining functional requirements leads to architectural rework, wasted budgets, and scrapped features.

Notebook Summary

The SDLC comprises six phases: Planning, Requirements, Design, Implementation, Testing, and Deployment/Maintenance.
Waterfall is linear and document-driven; Agile/Scrum is iterative, delivering working software increments in 2-to-4-week Sprints.
Functional Requirements specify features and behavior; Non-Functional Requirements specify quality criteria (latency, security, uptime).
User Stories follow the format: As a [role], I want [feature] so that [benefit] and require testable Acceptance Criteria.

Optional Extension Challenge

Write two user stories with acceptance criteria for a Hospital Blood Bank Management System: 1. One from the perspective of a Volunteer Blood Donor. 2. One from the perspective of an Emergency Room Doctor needing rare blood units.