Name: Saboohi Ali
ID : F2024468015
Section : I
Subject : Software Engineering
Submitted to : Dr. Hassnain Kashif
Assignment # 2
Comparison of Scrum, Extreme Programming (XP), and a Traditional Heavyweight
Process (Waterfall)
1. Scrum
Key Characteristics
Iterative and incremental framework.
Work is performed in fixed-length iterations called Sprints (2–4 weeks).
Roles include Product Owner, Scrum Master, and Development Team.
Uses Product Backlog, Sprint Backlog, and Daily Scrum meetings.
Principles
Transparency, inspection, and adaptation.
Empirical process control.
Frequent customer collaboration.
Advantages
Highly flexible and adaptive to changing requirements.
Short delivery cycles ensure faster value.
Improved communication through daily scrums.
Disadvantages
Scope creep possible if not properly controlled.
Requires experienced, self-managed teams.
Documentation may be less detailed.
2. Extreme Programming (XP)
Key Characteristics
Focuses on high-quality code, customer satisfaction, and continuous
improvement.
Practices include pair programming, test-driven development (TDD), continuous
integration, refactoring and small releases.
Principles
Communication, simplicity, feedback, courage, and respect.
Frequent customer involvement.
Continuous testing and integration.
Advantages
Very high software quality and fewer defects.
Raid feedback and continuous testing reduce rework.
Excellent for projects with frequently changing requirements.
Disadvantages
Requires strong discipline and skilled developers.
Pair programming demands more resources.
Can be difficult to scale for large teams.
3. Waterfall Model (Traditional Heavyweight Process)
Key Characteristics
Linear, sequential approach.
Phases: Requirements → Design → Implementation → Testing → Deployment →
Maintenance.
Documentation-heavy.
Principles
Complete and detailed documentation before development.
Each phase must be completed before the next starts.
Strong planning and upfront design.
Advantages
Simple to understand and manage.
Works well for projects with stable requirements.
Clear documentation and progress tracking.
Disadvantages
Very rigid—poor support for changing requirements.
Late delivery of working software.
High risk of finding issues very late.
Comparative Analysis Table
Aspect Scrum Extreme Waterfall
Programming
Approach Iterative, Iterative with Sequential, linear
Incremental strong engineering
practices
Flexibility High Very High Low
Customer Moderate product Very high on-site Low mainly at end
Involvement owner role customer or start
Quality Assurance Regular Sprint Continuous Late testing phase
Reviews testing, CI,
refactoring
Best For Dynamic project, Highly dynamic Stable, well-defined
medium teams projects needing projects
high quality
Main Weakness Require Resource extensive Inflexible to change
experienced team
Documentation Minimal Minimal moderate Extensive
Recommendation
If requirements are uncertain or frequently changing → Scrum or XP is best.
If the project needs high coding quality and continuous testing → XP.
If requirements are stable and well-understood → Waterfall.
Q No. 2
Requirements Specification for a University Management System
1. Functional Requirements (FRs)
The system must provide:
Student-Related
FR1: Student registration and profile management.
FR2: Student enrollment in courses.
FR3: Add/drop course functionality.
FR4: View attendance, grades, transcript, and fee status.
Instructor-Related
FR5: Instructor login and profile management.
FR6: Upload grades, attendance, and course material.
FR7: Manage assigned courses.
Admin-Related
FR8: Manage departments, programs, users, and roles.
FR9: Course scheduling and timetable generation.
FR10: Fee management and financial reports.
System-Related
FR11: Authentication and authorization.
FR12: Generate academic reports and analytics.
2. Non-Functional Requirements (NFRs)
Performance
NFR1: The system must handle 2000+ concurrent users.
NFR2: Page load time should not exceed 3 seconds.
Security
NFR3: All data must be encrypted (in transit and at rest).
NFR4: Only authorized users can access restricted modules.
Usability
NFR5: Interface must be user-friendly and accessible to new users.
NFR6: Mobile and desktop browser compatibility.
Reliability
NFR7: System uptime must be at least 99.5%.
NFR8: Automatic data backup every 24 hours.
Maintainability
NFR9: System modules should support easy updates and integration.
3. Requirements Engineering Activities
1. Requirements Elicitation
Techniques: Interviews, questionnaires, observation, document analysis.
Stakeholders: Students, faculty, admin staff, IT department.
2. Requirements Analysis
Remove conflicts, prioritize requirements, create use cases, data models.
3. Requirements Specification
Create SRS document with detailed FRs, NFRs, diagrams .
4. Requirements Validation
Conduct reviews, walkthroughs, prototyping, test-case mapping.
Ensure each requirement is correct, complete, consistent, traceable.
5. Requirements Management
Manage requirement changes using a change control board .
Maintain traceability matrix.
4. Verification and Validation Plan
Verification (Are we building it right?)
SRS review and inspections.
Check requirements consistency and feasibility.
Model validation.
Validation (Are we building the right system?)
User acceptance testing .
Scenario-based testing using real university cases.
Traceability matrix linking requirements to test cases.