Applied Use Case: Modern Cloud-Based Course Registration
To understand these concepts, we will follow a single project through the entire Systems Development Life Cycle (SDLC). Scenario: The university needs a new, highly available Course Registration Data Pipeline that can handle heavy traffic spikes during enrollment week without crashing.
Phase 1: Systems Planning & Project Management
1. SWOT Analysis (Strategic Planning)
graph TD
S["STRENGTHS
• Dedicated faculty and staff
• Strong academic reputation
• Reliable campus network and technology"] --- W["WEAKNESSES
• Some legacy administrative systems
• Limited technology and development budget
• Inconsistent documentation and processes"]
O["OPPORTUNITIES
• Expand online and hybrid programs
• Improve student services with automation
• Use analytics to support student success"] --- T["THREATS
• Competition from online universities
• Cybersecurity and data privacy risks
• Declining enrollment and changing demographics"]
S --- O
W --- T
style S fill:#ead9b8,stroke:#008fd5,stroke-width:2px
style W fill:#b8c9dc,stroke:#008fd5,stroke-width:2px
style O fill:#c5d0ca,stroke:#008fd5,stroke-width:2px
style T fill:#c9bdd9,stroke:#008fd5,stroke-width:2px
2. Gantt Chart (Project Scheduling)
gantt
title Registration System Development Timeline
dateFormat YYYY-MM-DD
section Planning
Req Gathering :a1, 2026-08-24, 7d
Risk Assessment :a2, after a1, 3d
section Analysis
DFD & UML Modeling :a3, after a2, 7d
section Design
ERD & DB Normalization :a4, after a3, 7d
UI/UX Wireframing :a5, after a3, 5d
section Implementation
Cloud Architecture :a6, after a4, 10d
DevSecOps Pipeline :a7, after a6, 7d
3. PERT Chart (Critical Path Analysis)
graph LR
A((Start)) -->|3 days| B(Req. Gathering)
B -->|2 days| C(UI Design)
B -->|4 days| D(Database Design)
C -->|5 days| E(Frontend Dev)
D -->|6 days| F(Backend Dev)
E --> G{Integration}
F --> G
G -->|3 days| H((Deployment))
style D stroke:#ff0000,stroke-width:3px
style F stroke:#ff0000,stroke-width:3px
style G stroke:#ff0000,stroke-width:3px
4. Risk Management Matrix
| Risk Identification |
Probability |
Impact |
Mitigation Strategy |
| Server overload during enrollment spikes |
High |
Critical |
Implement auto-scaling cloud instances and a load balancer (e.g., Nginx). |
| Data loss during migration |
Low |
Critical |
Automated continuous backups in PostgreSQL and pre-launch dry-runs. |
Phase 2: Systems Analysis & Requirements
5. Traditional Waterfall Methodology
graph TD
A[1. Requirements Analysis] -->|Freeze Requirements| B[2. System Design]
B --> C[3. Implementation / Coding]
C --> D[4. Testing / QA]
D --> E[5. Deployment]
E --> F[6. Maintenance]
classDef phase fill:#e6f2ff,stroke:#00509e,stroke-width:2px;
class A,B,C,D,E,F phase;
6. Agile Scrum Workflow
graph LR
PB[(Product Backlog)] --> SP[Sprint Planning]
SP --> SB[(Sprint Backlog)]
SB --> Sprint{1-4 Week Sprint}
Sprint -->|Daily Scrum| Sprint
Sprint --> Review[Sprint Review]
Review --> Release((Shippable Increment))
Review --> Retro[Sprint Retrospective]
Retro -.->|Adapt & Improve| PB
classDef agile fill:#fff3cd,stroke:#e6b800,stroke-width:2px;
class PB,SB,Sprint,Review,Retro agile;
7. Context Diagram - Level 0 Data Flow Diagram
graph LR
Student((Student)) -->|Course Request| System[0: Course Registration System]
System -->|Schedule Confirmation| Student
System -->|Fetch/Update Records| DB[(Student & Course Database)]
Faculty((Faculty)) -->|Submit Grades| System
8. UML Use Case Diagram (Corrected)
flowchart LR
%% Actors
Student((Student))
Admin((Admin))
%% Use Cases
UC1([Search Courses])
UC2([Register for Course])
UC3([Process Payment])
UC4([Manage Catalog])
%% Relationships
Student --- UC1
Student --- UC2
UC2 -. "<< includes >>" .-> UC3
Admin --- UC4
%% Styling
classDef actor fill:#f9f9f9,stroke:#333,stroke-width:2px;
classDef usecase fill:#e6f2ff,stroke:#00509e,stroke-width:2px;
class Student,Admin actor;
class UC1,UC2,UC3,UC4 usecase;
Phase 3: Systems & Data Design
9. Entity-Relationship Diagram (ERD)
erDiagram
STUDENT {
int StudentID PK
string FirstName
string LastName
}
COURSE {
string CourseCode PK
string Title
int Credits
}
ENROLLMENT {
int EnrollmentID PK
int StudentID FK
string CourseCode FK
string Semester
}
STUDENT ||--o{ ENROLLMENT : registers
COURSE ||--o{ ENROLLMENT : contains
10. Data Dictionary & Data Normalization
- 1NF (First Normal Form): Eliminate repeating groups. Ensure every column is atomic (e.g., splitting "Name" into "FirstName" and "LastName").
- 2NF: Remove partial dependencies. Every non-key attribute must depend on the entire primary key.
- 3NF: Remove transitive dependencies. (e.g., Don't store "Professor Name" in the Course table if it solely depends on "Professor ID").
11. User Interface (UI) Principles
- Affordance & Intuition: Buttons should look clickable; critical actions (like "Drop Course") should have confirmation dialogues.
- Responsive Design: The UI must function flawlessly on mobile devices, as 60%+ of students register via smartphones.
- Accessibility (a11y): Implement high-contrast modes and screen-reader compatibility (WCAG compliance).
12. Level 1 Data Flow Diagram (DFD) - Course Registration System
flowchart LR
Student((Student)) -->|Course request| P1[1. Validate Student & Enrollment Request]
Faculty((Faculty/Admin)) -->|Schedule updates| P1
P1 -->|Student and course data| D1["D1
Student Master File"]
P1 -->|Course offerings| D2["D2
Course Catalog"]
P1 -->|Request approved| P2[2. Check Course Availability]
P2 -->|Seat availability| D2
P2 -->|Enrollment status| Student
P2 -->|Create enrollment| P3[3. Create Enrollment Record]
P3 -->|Enrollment data| D3["D3
Enrollment Records"]
P3 -->|Updated seat count| D2
P3 -->|Confirmation| Student
P3 -->|Schedule status| Faculty
classDef actor fill:#f3f3f3,stroke:#333,stroke-width:2px;
classDef process fill:#e6f2ff,stroke:#00509e,stroke-width:2px;
classDef store fill:#fff3cd,stroke:#d4a017,stroke-width:2px;
class Student,Faculty actor;
class P1,P2,P3 process;
class D1,D2,D3 store;
13. Data Dictionary for Course Registration System
| Data Element |
Type |
Length / Format |
Description |
| StudentID |
Integer |
9 digits |
Unique identifier assigned to each student. |
| StudentName |
String |
Up to 50 chars |
Student’s full name. |
| CourseCode |
String |
8 chars |
Unique code for each course, such as ISYS406. |
| CourseTitle |
String |
Up to 100 chars |
Official title of the course. |
| Credits |
Integer |
1–4 |
Number of credit hours for the course. |
| Semester |
String |
e.g., Fall 2026 |
Academic term in which the student enrolls. |
| SeatAvailable |
Integer |
0–50 |
Current number of seats still open in a course. |
| EnrollmentStatus |
String |
Approved / Waitlist / Rejected |
Result of the student’s enrollment request. |
14. Process Flowchart: Validate Student and Enrollment Request
flowchart TD
S([Start]) --> A{Student exists?}
A -->|No| B[Student not found]
B --> R1([Reject])
A -->|Yes| C{Course exists?}
C -->|No| D[Course not found]
D --> R2([Reject])
C -->|Yes| E{Student already enrolled?}
E -->|Yes| F[Duplicate enrollment]
F --> R3([Reject])
E -->|No| G{Seats available?}
G -->|No| H[Course is full]
H --> R4([Reject])
G -->|Yes| I[Create enrollment record]
I --> J[Update seat count]
J --> K[Send approval confirmation]
K --> R5([Accept])
classDef decision fill:#fff3cd,stroke:#d4a017,stroke-width:2px;
classDef action fill:#e6f2ff,stroke:#00509e,stroke-width:2px;
classDef terminal fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;
class A,C,E,G decision;
class B,D,F,H,I,J,K action;
class R1,R2,R3,R4,R5 terminal;
15. Structured English: Validate Student and Enrollment Request
IF a student ID is not found in the student master file THEN
REJECT the enrollment request
DISPLAY "Student not found"
ELSE IF the course code is not found in the course catalog THEN
REJECT the enrollment request
DISPLAY "Course not found"
ELSE IF the student is already enrolled in that course THEN
REJECT the enrollment request
DISPLAY "Duplicate enrollment"
ELSE IF the number of available seats is zero THEN
REJECT the enrollment request
DISPLAY "Course is full"
ELSE
CREATE an enrollment record
UPDATE the course seat count
SEND an approval confirmation to the student
ACCEPT the enrollment request
END IF
16. Decision Table: Validate Student and Enrollment Request
| Rule |
Student Exists? |
Course Exists? |
Already Enrolled? |
Seats Available? |
Action |
| 1 |
No |
— |
— |
— |
Reject; student not found |
| 2 |
Yes |
No |
— |
— |
Reject; course not found |
| 3 |
Yes |
Yes |
Yes |
— |
Reject; duplicate enrollment |
| 4 |
Yes |
Yes |
No |
No |
Reject; course is full |
| 5 |
Yes |
Yes |
No |
Yes |
Accept; create enrollment and update seat count |
17. Decision Tree: Validate Student and Enrollment Request
flowchart TD
Start([Start]) --> A{Student exists?}
A -->|No| B[Reject: Student not found]
A -->|Yes| C{Course exists?}
C -->|No| D[Reject: Course not found]
C -->|Yes| E{Already enrolled?}
E -->|Yes| F[Reject: Duplicate enrollment]
E -->|No| G{Seats available?}
G -->|No| H[Reject: Course is full]
G -->|Yes| I[Create enrollment record]
I --> J[Update seat count]
J --> K[Send approval confirmation]
K --> L([Accept request])
classDef decision fill:#fff3cd,stroke:#d4a017,stroke-width:2px;
classDef action fill:#e6f2ff,stroke:#00509e,stroke-width:2px;
classDef terminal fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;
class A,C,E,G decision;
class B,D,F,H,I,J,K action;
class L terminal;
18. UML Activity Diagram: Validate Student and Enrollment Request
flowchart TD
A([Start]) --> B[Receive enrollment request]
B --> C{Student exists?}
C -->|No| D[Reject request: student not found]
D --> Z([End])
C -->|Yes| E{Course exists?}
E -->|No| F[Reject request: course not found]
F --> Z
E -->|Yes| G{Already enrolled?}
G -->|Yes| H[Reject request: duplicate enrollment]
H --> Z
G -->|No| I{Seats available?}
I -->|No| J[Reject request: course is full]
J --> Z
I -->|Yes| K[Create enrollment record]
K --> L[Update seat count]
L --> M[Send approval confirmation]
M --> N([Accept request])
classDef decision fill:#fff3cd,stroke:#d4a017,stroke-width:2px;
classDef action fill:#e6f2ff,stroke:#00509e,stroke-width:2px;
classDef terminal fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;
class C,E,G,I decision;
class B,D,F,H,J,K,L,M action;
class Z,N terminal;
Phase 4: Implementation, Architecture & QA
19. Client/Server Cloud Architecture
graph TD
Client[Client Web/Mobile App] -->|HTTPS Requests| LB{Nginx Load Balancer}
LB --> Web1[AWS EC2 App Server 1]
LB --> Web2[AWS EC2 App Server 2]
Web1 --> API[Automated Data Pipeline]
Web2 --> API
API --> DB[(PostgreSQL Master DB)]
DB --> Replica[(PostgreSQL Read-Replica)]
20. DevSecOps & Quality Assurance (QA)
graph LR
Code[1. Code Commit] --> Build[2. Build & SAST Testing]
Build --> QA[3. Automated QA/Unit Tests]
QA --> Deploy[4. Deploy to AWS]
Deploy --> Monitor[5. Continuous Monitoring]
style Build stroke:#00509e,stroke-width:2px
style QA stroke:#00509e,stroke-width:2px
- SAST (Static Application Security Testing): Code is scanned for vulnerabilities (like SQL injection flaws) before it even runs.
- Automated Pipelines: Tools trigger automated testing immediately when a developer commits code, preventing regression bugs in the enrollment logic.