Software Engineering

Term Project Assignment Sequence

Team:
Alina Fatima-5000000271
Sania Siddique-5000000330
Umm e farwa-5000000336
Department: BS AI ,3rd semester Section B
Phase 1: Project Initiation & Abstract
Objective:

The project's core idea at a high level and establish its purpose.

Selected System:

Student Record System (SRS)

Abstract :

Managing student information manually often leads to inefficiencies, data loss, and difficulty in
retrieving records. The proposed Student Record System (SRS) aims to automate the process of
storing, managing, and retrieving student data efficiently. This system will maintain
comprehensive records including student personal details, academic performance, attendance,
and course enrollment information. The SRS will provide an easy-to-use interface for
administrators, teachers, and students to access or update information as required. By digitalizing
the record-keeping process, the system will reduce paperwork, minimize errors, and enhance
data accuracy.

The primary objective of the project is to create a centralized platform where all student-related
information can be securely stored and easily retrieved when needed. The intended users include
school and university administrators, teachers, and students who require quick access to
academic records. The significance of this project lies in its ability to improve institutional
efficiency, save time, and ensure better management of educational data through automation and
digital integration.

Phase 2: Introduction & Feasibility Study

Objective:

A detailed background and justification of the project’s viability.

1. Introduction

Problem Statement:

Many educational institutions still rely on manual or semi-digital systems to maintain student
data such as personal details, attendance, grades, and course information. This process is time-
consuming, prone to human error, and makes it difficult to retrieve or update records efficiently.
Managing student information manually also increases the risk of data loss and duplication.
Proposed Solution:

The Student Record System (SRS) will serve as a centralized digital platform that automates
the entire process of managing student records. It will allow authorized users—such as
administrators, teachers, and students—to add, view, and update information securely. The
system will include modules for student registration, attendance tracking, grade management,
and report generation. This will make data handling faster, more accurate, and more reliable.

Project Scope and Key Objectives:

 To automate and digitalize the student record management process.

 To store all student-related data in a centralized database.
 To ensure secure and quick access to information.
 To minimize paperwork and human errors.
 To provide an efficient way to generate and manage reports.

Stakeholders:

 Administrators: Manage student information and generate reports.

 Teachers: Update attendance and academic performance.
 Students: View personal academic records and progress reports.
 IT Staff: Maintain and support the system.

2. Mini Feasibility Study

Technical Feasibility:

The system can be developed using technologies such as Java (for front-end and back-end
logic), MySQL (for the database), and Swing or JavaFX (for the user interface). These tools
are widely available, easy to use, and suitable for academic-level projects. The system can run on
any standard computer or laptop with Java installed.

Economic Feasibility:

Since the project uses open-source technologies, the cost of development is minimal. The
benefits—such as reduced paperwork, time savings, and improved data management—far
outweigh the development and maintenance costs. The system can also be expanded or upgraded
without major expense.

Operational Feasibility:

The intended users (teachers, administrators, and students) will find the system easy to use
because of its user-friendly design. Proper training can be provided to staff to ensure smooth
adoption. Users are likely to accept the system as it simplifies their daily work and improves
record accuracy.
Learning Outcome:

Through this project, students learn how to conceptualize a real-world software system, define its
objectives, and analyze its technical, economic, and operational feasibility before
implementation.

Phase 3: Software Specification (Requirements Engineering)

Objective:

This phase focuses on identifying functional and non-functional requirements, modeling system
interactions, and writing a user story for core functionality.

1. Requirements Elicitation & Listing

A. Functional Requirements

These describe what the SRS will do. Requirements are derived from the problem statement,
scope, and proposed solution.

1. Student Management

1. The system shall allow administrators to register a new student by entering personal
details (name, age, address, contact info).
2. The system shall allow administrators to edit or update existing student information.
3. The system shall allow authorized users to delete or deactivate a student record.
4. The system shall allow users to search for a student using student ID, name, or class.

2. Attendance Management

5. The system shall allow teachers to mark student attendance for each class or course.
6. The system shall generate attendance reports for individual students.
7. The system shall calculate attendance percentage automatically.

3. Academic Performance / Grades Management

8. The system shall allow teachers to enter marks or grades for assignments, quizzes, and
exams.
9. The system shall generate grade reports for each student.
10. The system shall allow students to view their academic performance securely.
4. Course Enrollment

11. The system shall allow administrators to assign students to courses or subjects.
12. The system shall allow teachers to view a list of students enrolled in their courses.

5. Authentication & Authorization

13. The system shall require users (administrators, teachers, students) to log in using valid
credentials.
14. The system shall provide different access levels based on user roles
(Admin/Teacher/Student).

6. Report Generation

15. The system shall generate printable reports for attendance, grade records, and student
profiles.
16. The system shall allow exporting reports in PDF or Excel formats (if included in scope).

B. Non-Functional Requirements

These define how well the system performs its functions.

1. Usability

1. The system interface shall be simple and easy to navigate for all types of users.
2. The system shall provide clear error messages when invalid inputs are entered.
3. The system shall allow first-time users to perform basic operations without training.

2. Reliability

4. The system shall ensure that all stored data is backed up periodically.
5. The system shall maintain data consistency during concurrent user access.
6. The system shall have minimal downtime to ensure continuous operation.

3. Performance

7. The system shall retrieve student records within 2 seconds of a search request.
8. The system shall support simultaneous access by at least 20 users without performance
degradation.
9. The system shall process attendance marking within 1 second per entry.

4. Security

10. The system shall encrypt all sensitive data (passwords, student information).
 11. The system shall restrict unauthorized access through role-based permissions.
12. The system shall log all user activities such as editing or deleting records.

2. Diagram

✔ Actors

 Administrator
 Teacher
 Student

✔ Main Use Cases

 Login
 Manage Student Records
 Manage Attendance
 Manage Grades
 Manage Course Enrollment
 View Student Information
 Generate Reports
2. DETAILED DESCRIPTIONS
Use Case 1: Login

Actor: Administrator, Teacher, Student

Precondition: User is registered in the system.
Main Flow:

1. User enters username and password.

2. System validates the credentials.
3. System grants access according to user role.
Alternate Flow:
– If credentials are invalid, system displays an error message.
Postcondition: User is logged in and can access authorized features.

Use Case 2: Manage Student Records (Admin)

Actor: Administrator
Preconditions: User must be logged in as Admin.
Main Flow:

1. Admin opens “Student Management” module.

2. Admin chooses to add, update, delete, or search student.
3. Admin enters or modifies required data.
4. System saves changes and updates database.
Alternate Flows:
– Invalid data → system displays an error.
Postcondition: Student record is successfully stored or updated.

Use Case 3: Manage Attendance (Teacher)

Actor: Teacher
Precondition: Teacher is assigned to a course.
Main Flow:

1. Teacher selects a course.

2. System displays enrolled students.
3. Teacher marks present/absent.
4. System saves attendance data.
Alternate Flow:
 – If network/storage fails → system shows an error.
Postcondition: Attendance for that day is saved.

Use Case 4: Manage Grades (Teacher)

Actor: Teacher
Precondition: Teacher is logged in and has access to course records.
Main Flow:

1. Teacher selects a course.

2. Teacher enters marks/grades for each student.
3. System calculates total and stores data.
Alternate Flow:
– Invalid marks entered → system displays input error.
Postcondition: Grades saved and reflected in student performance records.

Use Case 5: View Personal Academic Records (Student)

Actor: Student
Precondition: Student must be logged in.
Main Flow:

1. Student opens profile/dashboard.

2. System displays grades, attendance, and course info.
3. Student downloads or prints report if needed.
Postcondition: Student views up-to-date academic data.

Use Case 6: Generate Reports (Admin/Teacher)

Actor: Administrator / Teacher

Precondition: User is logged in.
Main Flow:

1. User selects report type: attendance, grades, student profile.

2. System retrieves data.
3. System displays formatted report.
4. User downloads/prints the report.
Postcondition: Report successfully generated.
Use Case 7: Manage Course Enrollment (Admin)

Actor: Administrator
Precondition: Student and course already exist.
Main Flow:

1. Admin selects a student.

2. Admin selects course(s) to enroll.
3. System updates course enrollment table.
Postcondition: Student is enrolled in selected course.

3. User Story (Based on core functionality)

User Story 1: Student Search

As an administrator,
I want to search for a student using their name or ID,
so that I can quickly access or update their academic and personal information.

User Story 2 (Optional): Entering Grades

As a teacher,
I want to enter the grades of students for each course,
so that their academic performance can be stored and viewed accurately.

User Story 3 (Optional): Viewing Reports

As a student,
I want to view my attendance and grade report,
so that I can track my progress and identify areas for improvement.

Learning Outcome
Through this phase, students gain practical experience in gathering requirements, defining
system behavior clearly, and modeling interactions between users and the system. This helps
them understand the foundation of software engineering before moving toward design and
implementation.
Phase 4: Software Process Model Selection & Justification
Objective:
To select the most suitable software development methodology for the Student Record System
(SRS) and provide a detailed justification based on project requirements, complexity, and
stakeholder needs.

1. Selected Process Model: → Incremental Development Model

2. Justification for Choosing Incremental Development

The Incremental Development Model is the most suitable methodology for the SRS project
based on the nature of the requirements defined in Phase 1–3. Below is the detailed justification:

✓ 1. Stability of Requirements (from Phase 3)

The SRS contains multiple independent modules:

 Student Management
 Attendance Management
 Grades Management
 Course Enrollment
 Authentication
 Report Generation

While the core requirements are stable, each module can be developed and improved
separately.

🔹 Some parts (e.g., grade management or report formats) may require refinement after
stakeholder feedback.
🔹 Incremental development supports updating modules easily without rebuilding the entire
system.

Why incremental works:

It allows you to deliver the system module-by-module, ensuring each requirement set is validated
and refined before adding the next.
✓ 2. Project Size and Complexity
The SRS is moderately complex, involving:

 Role-based access
 Multiple subsystems
 Frequent data interactions
 Data consistency across modules

Developing everything at once (as in Waterfall) increases risk.

Incremental development reduces complexity by dividing the system into manageable chunks:

Increment Module Delivered

1 Authentication + Student Management
2 Attendance Module
3 Grades Module
4 Enrollment Module
5 Report Generation

This modular approach improves clarity, testing, and error isolation.

✓ 3. Need for Early User Feedback

Stakeholders include:

 Administrators
 Teachers
 Students

These users benefit from early prototypes of each module.

With incremental development:

 A basic working version can be delivered early.

 Administrators can test student registration before attendance and grades modules are
built.
 Teachers can validate attendance screens to suggest improvements early on.

This leads to a more user-friendly final system.

✓ 4. Potential for Using Reusable Components
Although SRS is mostly custom-built, some components can be reused:

 Authentication modules
 Database validation routines
 PDF/report templates
 UI elements (forms, tables, search bars)

Incremental development allows such reusable components to be integrated gradually without

redesigning the whole system at once.

✓ 5. Flexibility & Reduced Project Risk

Compared to Waterfall, incremental development offers:

 Less risk of total system failure

 Easy adoption of changes
 Continuous integration and testing
 Better schedule management

This is important because educational institutions often request new features (e.g., transcript
printing, fee module) after initial deployment.

Incremental model allows such additions smoothly.

3. Why Not Waterfall or Reuse-Oriented?

❌ Waterfall Model

Not suitable because:

 Requirements may evolve as users test early modules.

 Waterfall does not support mid-process changes.
 No intermediate working product is delivered until the end.
Given SRS involves multiple user types and dynamic requirements, waterfall is too rigid.

❌ Reuse-Oriented Software Engineering (Component-Based)

Not suitable because:

 SRS modules are mostly custom-made for the institution.

 Limited availability of ready-made reusable components.
 Requires integration of third-party or pre-built components, which may not fit academic
requirements.

Thus, reuse-oriented is unnecessary and adds complexity.

Final Justification Summary

Criterion Incremental Waterfall Reuse-Oriented
Requirement Supports evolving Requires fully stable Only works well if many
Stability requirements requirements components exist
Complexity
Breaks into modules All at once High integration overhead
Handling
Early User
✔ Strong ✖ Weak Limited
Feedback
Reusability Supports internal reuse Not flexible Forced reuse
Overall
⭐ Best Choice Not suitable Less suitable
Suitability

Learning Outcome :
Through this phase, students learn that software development does not follow a
universal method suitable for every project. Instead, selecting an appropriate process
model depends on factors such as requirement stability, system complexity, user
involvement, and reuse potential. By evaluating different models—Waterfall,
Incremental, and Reuse-Oriented—students develop the ability to make informed
methodological decisions. This phase helps students understand how choosing a
suitable development approach directly impacts project success, risk management,
and product quality.
Phase 5: SYSTEM DESIGN
Objective:
To create a high-level system architecture, identify major components, and design a simple user
interface layout based on the requirements specified in earlier phases.

1. Architectural Design
Based on the requirements from Phases 1–3 and the incremental model selected in Phase 4, the
3-Tier Architecture is the most suitable for the Student Record System (SRS).

✔ Why 3-Tier Architecture?

 Separates presentation, logic, and data layers

 Makes maintenance easier when adding modules incrementally
 Supports multiple roles (Admin, Teacher, Student)
 Secure and scalable for institutional systems

High-Level Architecture (3-Tier Model)

+---------------------------+
| Presentation Layer |
| (Java Swing / JavaFX UI) |
+------------+--------------+
|
|
+------------v--------------+
| Application Layer |
| (Business Logic: Java) |
| - Student Management |
| - Attendance Module |
| - Grades Module |
| - Course Enrollment |
| - Authentication |
+------------+--------------+
|
|
+------------v--------------+
| Data Layer |
| (MySQL Database) |
| - Tables for Students |
| - Courses, Grades, |
| Attendance, Users |
+----------------------------+

2. Component Design
Based on the major modules identified earlier, the system is divided into the following key
components:

Component 1: User Authentication Module

Responsibility:

 Verify login credentials

 Assign access levels (Admin/Teacher/Student)
 Maintain secure session handling
 Prevent unauthorized access

Inputs: username, password

Outputs: access granted / denied

Component 2: Student Management Module

Responsibility:

 Add, update, delete, and search student records

 Validate student input data
 Interact with the database to store/update information
 Handle profile viewing for teachers/admins

Features:

 Student registration
 Profile update
 Student search engine

Component 3: Attendance Management Module

Responsibility:

 Display course-wise student lists

 Mark attendance (present/absent)
 Calculate attendance percentage
 Generate attendance reports

Users: Teachers, Admin

Component 4: Grades Management Module

Responsibility:

 Input and store marks/grades

 Calculate totals/percentages
 Generate grade reports
 Allow students to view their academic performance

Users: Teachers, Students

Component 5: Report Generation Module

Responsibility:

 Create printable PDF/Excel reports

 Retrieve and format student profiles, attendance, and grades
 Export reports in chosen formats

This is usually implemented in the final increment of the system.

3. UI/UX WIREFRAME
(Optional but recommended — provided here)

Wireframe: Student Management Screen (Admin View)

This is one of the key screens in the SRS.

---------------------------------------------------------
| STUDENT RECORD SYSTEM (Admin) |
---------------------------------------------------------
| [Search Student: ________ ] (Search Button) |
---------------------------------------------------------
| Student Details: |
| Name: _________________________ |
| Age: ______ |
| Address: _________________________ |
| Contact: _________________________ |
---------------------------------------------------------
| [ ADD ] [ UPDATE ] [ DELETE ] [ CLEAR ] |
---------------------------------------------------------
| Student List (Table): |
| -------------------------------------------------------|
| | ID | Name | Class | Contact | |
| |----|------|--------|---------| |
| | 12 | Ali | 10th | 0300... | |
| | 15 | Sara | 9th | 0311... | |
| ------------------------------------------------------- |
---------------------------------------------------------

User Interaction Flow

1. Admin logs in → System validates credentials.

2. Admin enters a name or ID in the Search Box → List loads matching students.
3. Clicking a student row populates the form fields.
4. Admin can:
o Add a new student
o Update details
o Delete a record
o Clear the form

This flow supports the functional requirements defined earlier.

Learning Outcome
Through this design phase, students learn how to:

 Translate requirements into system architecture

 Break the system into logical components
 Visualize the system structure before coding
 Understand modular development in an incremental model
 Create user-friendly layouts based on user needs

This phase bridges the gap between requirements (WHAT the system must do) and
implementation (HOW the system will be built).

Phase 6: VALIDATION & TESTING STRATEGY

Objective:
To define a structured testing plan that ensures the Student Record System (SRS) meets the
functional and non-functional requirements established in earlier phases.

Testing is planned according to the Incremental Development Model, meaning tests are
performed module-by-module as each increment is completed.

1. Testing Strategy
The SRS will be tested through the following four main levels:

1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing (UAT)

Each testing type is described below with examples based on the modules designed in Phase 5.

A. Unit Testing
Unit testing focuses on testing individual functions, classes, or modules from Phase 5.

Objective:

To ensure each component works correctly in isolation.

Tools:

 JUnit (for Java)

 Manual testing for UI components

Key Units to Test:

Module Unit Test Items Example Tests

Authentication Module Login validation function Test valid/invalid credentials, empty fields

Student Management Add/update/delete student Test adding student with missing fields, editing
Module functions updates DB correctly

Test marking present/absent, calculating

Attendance Module Attendance marking function
attendance percentage

Grade entry & calculation

Grades Module Test mark validation, calculate totals correctly
functions

Report Generator Report formatting function Test generating PDF/Excel with sample data

Example Unit Test Case:

Test AddStudent() Function

 Input: Name="Ali", Age=15, Contact="0300-1234567"

 Expected Output: Student added successfully to DB
 Invalid Input Test: If age is negative → Show error message

B. Integration Testing
Integration testing ensures that the individual modules interact correctly with each other.

Objective:

To test communication between components developed in different increments.

Integration Strategy:

Incremental approach, aligned with Phase 4 development plan:

Integration Sequence:

1. Increment 1:
 o Integrate Authentication + Student Management
o Test: After login, admin can register/view students
2. Increment 2:
o Add Attendance Module
o Test: Teachers can view student list + mark attendance
3. Increment 3:
o Integrate Grades Module
o Test: Students marked in attendance show correctly in grade entry list
4. Increment 4:
o Add Course Enrollment Module
o Test: Course enrollment affects attendance/grade lists
5. Increment 5:
o Add Report Generation Module
o Test: Reports combine attendance + grades + student info correctly

Example Integration Test:

Testing Attendance Module + Student Management

 Admin adds students

 Teacher opens attendance → Student list must appear correctly
 Mark presence → Data saved & visible in report module

C. System Testing
System testing checks whether the entire SRS meets all functional and non-functional
requirements defined in Phase 3.

1. Functional System Testing

Based on 16 functional requirements.

Examples:

 Verify Admin can search student by name/ID

 Verify attendance is saved for the correct date
 Verify students can view grades securely

2. Non-Functional Testing
NFR Category Testing Approach Example

Usability UI walkthroughs, user observation Ensure screens are simple and error messages
NFR Category Testing Approach Example

are clear

Performance Load testing with 20+ users Search response ≤ 2 seconds as required

Test data remains consistent during

Reliability Database consistency tests
concurrent access

Credential brute-force prevention, role

Security Teacher cannot access Admin panel
validation

Example System Test:

Performance Test — Search Function

 20 simulated users searching simultaneously

 Expected: Results load within 2 seconds

D. Acceptance Testing (UAT)

Acceptance testing verifies that the system works according to user expectations.

Objective:

To confirm the system meets stakeholder needs (Admin, Teachers, Students).

Users Involved:

 1–2 Administrators
 2 Teachers
 2 Students

Sample Acceptance Test Scenario:

Scenario: Admin Wants to Manage Student Records

1. Admin logs in with provided credentials

2. Navigates to “Student Management”
3. Adds a new student
4. Updates the same student’s email
5. Searches for the student by ID
6. Views the student’s profile
7. Deletes/re-activates a student record
Acceptance Criteria:
✔ Admin can perform all operations without errors
✔ Data updates reflect immediately
✔ No usability issues encountered

Another UAT Scenario: Student Checking Academic Records

1. Student logs in
2. Opens “My Profile”
3. Views attendance % and marks for all courses
4. Downloads academic report

Acceptance Criteria:
✔ Data is accurate
✔ System loads quickly
✔ Report downloads successfully

Learning Outcome
Through this phase, students learn that:

 Testing is not random—it must be planned, structured, and aligned with requirements
 Unit testing ensures code correctness
 Integration testing ensures smooth communication between modules
 System testing validates the complete system behavior
 Acceptance testing ensures the system satisfies real-world users

This phase highlights that testing is essential to software quality, not a last-minute activity.

Phase 7: EVOLUTION, PROFESSIONAL & ETHICAL

RESPONSIBILITY
Objective:
To focus on the long-term evolution of the Student Record System (SRS) and examine the
ethical considerations involved in its development and use.
1. Software Evolution Plan
After the initial release of the Student Record System (SRS), educational institutions may request
additional features or improvements based on real-world usage. The following enhancements
reflect typical future needs:

Proposed Enhancement 1: Online Access & Cloud Integration

Description:

Extend the SRS to support:

 Web-based login
 Cloud storage for student records
 Remote access for teachers and students
 Online attendance/grade submission

Reason for Need:

Institutions increasingly require cloud-based platforms for remote education, centralized access,
and backup.

How Incremental Development Supports This:

 New cloud and web interfaces can be added as new increments without modifying the
existing desktop-based modules.
 Existing modules (attendance, grades, login) remain unchanged; only their interfaces
adapt to the new platform.
 Each enhancement (e.g., login API, cloud database sync) can be tested and deployed in
small increments, reducing risk.

Proposed Enhancement 2: Automated Analytics & Performance

Predictions
Description:

Add an analytics dashboard with:

 Attendance trend analysis

 Grade prediction (using simple algorithms)
 Identification of struggling students
  Visual performance graphs

Reason for Need:

Modern educational institutions use data analytics to support academic decisions and early
student intervention.

How Incremental Development Supports This:

 Analytics features can be added as a separate analytics module without changing core
modules.
 Reports module can be extended incrementally to include graphs and prediction results.
 Teachers and admins receive updates without affecting their current workflows.

Why These Enhancements Fit Your Model

Incremental Development Model Strengths:

✔ Allows adding new modules without rebuilding the entire system

✔ Supports evolving requirements, especially in academic environments
✔ Enables user feedback after each increment
✔ Reduces risk when introducing major changes like cloud migration or analytics

Thus, both proposed enhancements naturally fit within the flexible and modular structure created
in earlier phases.

2. Ethical Analysis (Based on ACM/IEEE Code of Ethics)

The Student Record System deals with sensitive educational data such as personal details,
attendance, and grades. This requires strict adherence to professional ethics.

Below are two principles from the ACM/IEEE Code of Ethics applied to your project.
Ethical Principle 1: “Public Interest” (ACM Principle 1)
Ethical Issue:

The SRS stores sensitive information such as:

 Student personal information

 Academic records
 Attendance data

This creates privacy and security risks.

How SRS Upholds This Principle:

1. Data Privacy Protection:

o Role-based access only (Admin/Teacher/Student)
o Students can only view their own information
o No unauthorized disclosure of records
2. Security Measures:
o Password encryption
o Logging user actions to detect misuse
o Secure database connection
3. Transparency:
o Inform users how their data is stored and used
o Obtain permission before exporting or printing sensitive reports

By implementing these measures, the system protects users’ rights and maintains public trust.

Ethical Principle 2: “Product Quality” (ACM Principle 3)

Ethical Issue:

A poorly designed or untested system can:

 Provide incorrect grades

 Lose student data
 Fail during examinations or attendance marking

This can negatively impact students’ educational outcomes.

How SRS Upholds This Principle:

1. Rigorous Testing (as defined in Phase 6):

o Unit, integration, system, and acceptance testing
o Performance testing to ensure fast search and loading
 oReliability testing to prevent data corruption
2. Accurate Functionality:
o Algorithms calculate attendance and grades precisely
o Admins and teachers receive error messages for invalid data
3. Continuous Improvement:
o Feedback from teachers and administrators used to fix issues
o Incremental updates reduce the chance of system-wide failures

By ensuring quality and reliability, the SRS protects students from errors that could affect their
academic progress.

Learning Outcome
Through this phase, students learn that software does not end at delivery. Instead:

 It continues to evolve as user needs grow

 Developers must anticipate future requirements
 Ethical responsibility is as important as technical skill
 Data privacy, transparency, and product reliability must guide every decision

This phase teaches students to think like professional software engineers who prioritize long-
term sustainability and ethical conduct.