COMSATS University Islamabad (CUI)

Software Requirement Specification

(SRS DOCUMENT)

for

Final Year Project Allocation and Evaluation According to

NCEAC Rules
Version 1.0

By
Saira Atta

CIIT/FA21-BCS-132/VHR

Shahnaz Bibi

CIIT/FA21-BCS-158/VHR

Supervisor
Muhammad Abdullah

Bachelor of Science in Computer Science

(2021-2025)
 Revision History
Name Date Reason for Changes Version
Initial Draft 2024- Met with supervisor to review project require- 0.1
Meeting 10-29 ments and scope. Revised objectives to align with
feedback and updated project timeline.

i
 Application Evaluation History
Comments (by committee) Action Taken

Supervised By
Muhammad Abdullah

Signature
ii
 TABLE OF CONTENTS

List of Figures v

List of Tables vi

1 Introduction 1
1.1 System Overview . . . . . . . . . . . . . . . . . . . . . 1
1.2 Purpose of the System . . . . . . . . . . . . . . . . . . 2

2 Description 3
2.1 Project Perspective . . . . . . . . . . . . . . . . . . . . 3
2.2 Project Scope . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Project Functionality . . . . . . . . . . . . . . . . . . 4
2.4 Users and Characteristics . . . . . . . . . . . . . . . . 5
2.5 Operating Environment . . . . . . . . . . . . . . . . . 7
2.6 FlowChart diagram . . . . . . . . . . . . . . . . . . . . 10

3 Specific Requirements 11
3.1 Functional Requirements . . . . . . . . . . . . . . . . . 11
3.1.1 User Authorization . . . . . . . . . . . . . . . . 11
3.1.2 Student Dashboard . . . . . . . . . . . . . . . . 11
3.1.3 Supervisor Profile . . . . . . . . . . . . . . . . . 12
3.1.4 Project Selection . . . . . . . . . . . . . . . . . . 12
3.1.5 Real-Time Notifications . . . . . . . . . . . . . . 12
3.1.6 Communication and User Experience . . . . . . 12
3.2 Behaviour Requirements . . . . . . . . . . . . . . . . . 13
3.2.1 Use-case Diagram: . . . . . . . . . . . . . . . . . 14
3.3 Use Case Diagram Description . . . . . . . . . . . . . 15
3.3.1 1. Actors . . . . . . . . . . . . . . . . . . . . . 15
3.3.2 2. Use Cases . . . . . . . . . . . . . . . . . . . 15
3.3.2.1 Student Use Cases . . . . . . . . . . . . 15
3.3.2.2 Supervisor Use Cases . . . . . . . . . . . 16
3.3.2.3 Committee Member Use Cases . . . . . . 16
3.4 External Interface Requirements . . . . . . . . . . . . 17
3.4.1 User Interfaces . . . . . . . . . . . . . . . . . . . 17
3.4.2 Software Interfaces . . . . . . . . . . . . . . . . . 26

iii
4 Non-Functional Requirements 27
4.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4 Data Encryption . . . . . . . . . . . . . . . . . . . . . 28
4.5 Availability . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6 Cross-platform Compatibility . . . . . . . . . . . . . . 28
4.7 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 28
4.8 Maintenance . . . . . . . . . . . . . . . . . . . . . . . 28
4.9 Error Handling . . . . . . . . . . . . . . . . . . . . . . 29
4.10 Check . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Design Description 30
5.1 System Design . . . . . . . . . . . . . . . . . . . . . . 30
5.2 High level Design . . . . . . . . . . . . . . . . . . . . . 33
5.2.1 Sequence Diagram . . . . . . . . . . . . . . . . . 33

iv
LIST OF FIGURES

2.1 FlowChart of Project Allocation and Evaluation . . . . 10

3.1 Use-case Diagram of the system . . . . . . . . . . . . . 14
3.2 Home Page of the UI . . . . . . . . . . . . . . . . . . . 17
3.3 Login Page of Student . . . . . . . . . . . . . . . . . . 18
3.4 Login Page of Supervisor . . . . . . . . . . . . . . . . . 19
3.5 Login page of Committee members . . . . . . . . . . . 20
3.6 Students group member selection Page of the UI . . . . 21
3.7 Project selection Page of the UI (Part 1) . . . . . . . . 22
3.8 Project selection Page of the UI (Part 2) . . . . . . . . 22
3.9 Supervisor Selection Page of the UI . . . . . . . . . . . 23
3.10 Supervisors Dashboard Page of the UI . . . . . . . . . 24
3.11 Committee members Dashboard Page of the UI . . . . 25
5.1 System Architecture . . . . . . . . . . . . . . . . . . . 30
5.2 Context diagram(DFD Level 0) of FYP management . 31
5.3 Context diagram(DFD Level 1) of FYP management . 32
5.4 Context diagram(DFD Level 2) of FYP management . 32
5.5 Sequence Diagram of the System . . . . . . . . . . . . 34

v
LIST OF TABLES

3.1 Behavioral Requirements . . . . . . . . . . . . . . . . . 13

3.2 Tools And Technologies . . . . . . . . . . . . . . . . . 26

vi
 Chapter 1

Introduction

The goal of this project is to create a software platform called ”Project

Allocation & Evaluation as per NCEAC Rules,” which would make
it easier for academic institutions to administer final-year projects.
These projects require the coordination of students, supervisors, and
committee members, which is a complex task. By adhering to the
National Computing Education Accreditation Council’s (NCEAC)
standards, this platform guarantees that project allocation, super-
vision, and evaluation are carried out efficiently and in compliance
with applicable legal requirements [7].

1.1 System Overview

This system offers a structured approach for running projects, cre-
ating better communication and transparency through all parties in-
volved. It is very advantageous for institutions like COMSATS Uni-
versity, the main characteristic being position-based access control—
that is, the restriction of access to those elements required for each
1
CHAPTER 1.

user’s position, such as supervisors, committee members, and stu-

dents [1]. This feature is imperative to the security aspect, as it
guards against any form of unauthorized access to ensure only those
parts of the system are accessed when users wish to. Lastly, with the
system’s provision for real-time notices on projects selected, arrange-
ments made in supervision, and evaluation status, all the parties have
up-to-date information and are well covered.

It streamlines the task of project assignment, assures that super-

visory workload is equally divided, and accommodates tracking of
full projects. Advanced project filtering, submission tracking, feed-
back mechanism for supervisors, and dynamic analytics dashboard
are features offered. With automation of much manual work, this
system minimizes administrative work load and, therefore, brings an
easier experience for both students and supervisors alike with regard
to committee members [3].

1.2 Purpose of the System

The main aim of this project is to have just one, central place to
have the final-year projects managed by institutions such as COM-
SATS University simplified to ensure a secure authentication system.
This will also provide the friendly interfaces and easy integrations[6]
with other systems used in the institution, making every academic
event experience more convenient by strictly adhering to NCEAC
standards. Thus, it shall give rise to an efficient and clear system
that would make the interactions and proper workflow of project
management by all parties contributing to it.

2 SRS BSCS
 Chapter 2

Description

2.1 Project Perspective

A Web-based Tool to Simplify and Automate Final Year Project
Management According to NCEAC Rules. It’s a tool designed to fa-
cilitate management of the final year projects according to NCEAC
standards within an institution [9]. It allows institute like COM-
SATS University to ease the procedures for assigning projects, super-
vision, and assessment to ensure less manual handling and enhanced
efficiency.

The system comes with a role-based interface, giving students, super-

visors and committee members secure access to some functionalities.
Students can filter projects based on difficulties and type of tech-
nology, and supervisors can communicate real-time with each other
through the system.

3
CHAPTER 2.

2.2 Project Scope

It comprehensively encompasses functionalities towards successfully
managing final-year projects across academic institutions within the
defined scope, particularly based on NCEAC norms. The system
allows the efficient assignment, supervision and review of projects
that address, ideally, the intricacies behind supervisory coordination
among students and committee members.

2.3 Project Functionality

1. Project Allocation: The system allows for an efficient project
assignment process, enabling students to select projects based
on their interests and skills. Supervisors can view and approve
project assignments in real-time, ensuring an equitable distri-
bution of supervisory workload.

2. Role-Based Access Control: Position-based access control

ensure that users, whether a student, supervisor and committee
member access only the functionalities relevant to their roles.
This model safeguards sensitive information from unauthorized
access.

3. Real-Time Communication: The features enable students

and supervisors to communicate directly while working on the
project to facilitate close collaboration and timely feedback[5].

4. Monitoring and Evaluation: The supervisor and committee

members can get the access to the dashboard for knowing how
a project is moving on, allowing effective tracking of project
status, evaluation, and even providing mechanisms for feedback.
It all helps support informed decision-making with improved
accountability.

4 SRS BSCS
CHAPTER 2.

5. Automated Notifications: The platform sends real-time no-

tifications regarding project selections, supervision arrangement,
and evaluation statuses, ensuring all stakeholders are informed
and up-to-date.

2.4 Users and Characteristics

Based on ”Project Allocation & Evaluation as per NCEAC Rules,”
the following are the key users and their characteristics:

• Students:

– Characteristics: Principal end-users for the students are

to select their projects, track progress, and submission.
This means there has to be an interface of the system that
will filter making a selection of student’s projects based on
the level of hardness, technology etc. Students should be
made feasible with real-time communication sending notifi-
cations and provision to get feedback.

– Role: Students will use the system to choose and submit

projects, follow up on supervisor’s feedback and communi-
cate for clarification and guidance[1].

• Supervisors:

– Characteristics: Supervisors monitor and oversee the stu-

dent projects; they provide feedback to guide students along
their project milestones. They require functionalities for
communication, real-time project updates, and an orga-
nized method of assessing and reviewing the submissions
of the projects.

– Role: Project allocation by Supervisor, monitoring the

progress made by students, providing structured feedback,
5 SRS BSCS
CHAPTER 2.

and evaluating the consequences of the project in regards

to NCEAC criteria.

• Committee Members:

– Characteristics: The committee members ensure projects

undergo final evaluations and acceptability for being aca-
demically acceptable. Members will require the Availabil-
ity of all project information, evaluation form, and grading
tool.

– Role: They utilize the system in reviewing, assessing, and

formally evaluating projects against criteria established with
adherence to NCEAC standards.

6 SRS BSCS
CHAPTER 2.

2.5 Operating Environment

The system operates in a flexible and scalable environment to ensure
it meets all the requirements of its users. The key aspects of the
operating environment are as follows:

• Hardware Requirements:

– Server Specifications: Reliable server infrastructure is

required for the system to handle backend processing, API
inquiries, and real-time interactions[5]. The system spec-
ifications include multi-core processors, 16GB or more of
RAM for best performance, and SSD for data storage for
efficient data transfer.

– Storage: Hundreds of megabytes must be used to store

user profiles, project data, and historical documents. SSDs
are advised for quicker data recovery.

– Network: This means ensuring that a stable, high-speed

internet connection is there to support data transferred
flawlessly and real-time updates and reliable user interac-
tions, especially when usage becomes peaked.

• Software Specifications:

– Operating System: In addition to providing access from

the main client operating systems, such Windows and ma-
cOS, the server infrastructure will employ Windows to en-
sure optimal performance.

– Frontend Development: The frontend uses JavaScript

with React.js and Tailwind CSS to create a responsive and
user-friendly interface. This setup supports dynamic page

7 SRS BSCS
CHAPTER 2.

rendering and achieves the platform’s usability and acces-

sibility goals.

– Backend Development: The backend part involves the

use of Python whereby this project uses Django with Django
REST Framework in developing safe RESTful API end-
points, providing authentications, along with controlling
access roles and features in management.

– Database Management: PostgreSQL is chosen based on

the high reliability, data integrity and support for handling
complicated queries necessary for managing data in relation
to users and projects.

– Real-Time Communication: WebSockets and Django

Channels are employed for real-time notifications that can
further fetch status updates in the project or the availabil-
ity of the supervisor at once.

• Security and Privacy:

– Access Control: Strong authentication and authorization

mechanisms assure that systems remain accessible with-
out penetration, implementing role-based access controls
for data privacy and permissions control according to the
user’s roles.

• User Environment:

– Accessibility: Web browsers like Chrome, Edge can have

access to user interface.

– Device Compatibility: In order to provide responsive

8 SRS BSCS
CHAPTER 2.

experience to Students, Supervisors and Committee Mem-

bers, the system is designed for compatibility with desk-
tops, laptops, tablets and mobile phones.

9 SRS BSCS
CHAPTER 2.

2.6 FlowChart diagram

Figure 2.1: FlowChart of Project Allocation and Evaluation

10 SRS BSCS
 Chapter 3

Specific Requirements

3.1 Functional Requirements

The following given tasks are the functional requirements of proposed
system.[4]

3.1.1 User Authorization

Manage roles and access for students, supervisors and committee

members. It provides secure login with role-based authentication,
password hashing, and OTP/email authentication. Role-Based Ac-
cess Control (RBAC) grants permissions based on roles.

3.1.2 Student Dashboard

Each student have their profile, and they can select there group mem-
ber according to their availability and can select projects according
to their interest level and also view supervisors profile and can send
request according to their availability.

11
CHAPTER 3.

3.1.3 Supervisor Profile

Each supervisor will have a profile that details their availability, re-
search field, and academic background. They are capable of manag-
ing projects and updating profiles. Students select a supervisor, and
their availability is modified based on workload limitations.

3.1.4 Project Selection

It provides functionality to filter and search by complexity and tech-

nology stack of a project. Once selected, the project is unavailable for
others, so this creates unique functionality for that specific project.

3.1.5 Real-Time Notifications

WebSocket for real-time updates; email and SMS notifications re-

garding project status, approvals, and Supervisor availability.

3.1.6 Communication and User Experience

There will be a chatbot that will help in engaging the students with
the supervisor through a communication platform along with pro-
viding responsive design on all types of devices.

12 SRS BSCS
CHAPTER 3.

3.2 Behaviour Requirements

Table 3.1: Behavioral Requirements

Requirement Description and Use Cases Actors

User Authentica- Log in/authenticate users (students, All users
tion and Autho- supervisors, committee members, man-
rization agers). Each role has specific access.
Use Cases: User login/logout, Role-
based dashboard, OTP/email verifica-
tion [4].
Project Selection Students view, filter, and select Students, Super-
and Allocation projects; selected projects are locked. visors
Use Cases: View project list, Filter
projects, Select project, Confirm selec-
tion, Allocate supervisor.
Supervisor Profile Supervisors’ profiles (availability, Supervisors,
Management fields, background) are viewable to Students
students. Use Cases: Update and View
supervisor profile.
Real-Time Notifi- Instant notifications on project status, All users
cations approvals, and deadlines. Use Cases:
Receive updates, Status change notifi-
cations, Supervisor availability.
Proposal Tracking Committee and supervisors track and Students, Super-
and Evaluation evaluate proposals with deadlines and visors, Commit-
statuses. Use Cases: Submit proposal, tee Members
Track status, Evaluate proposal.

13 SRS BSCS
CHAPTER 3.

3.2.1 Use-case Diagram:

Figure 3.1: Use-case Diagram of the system

14 SRS BSCS
CHAPTER 3.

3.3 Use Case Diagram Description

This use case diagram describes interactions among the various user
roles of a system and their corresponding functionalities [2]. It con-
solidates all the use cases into four primary user groups: Students,
Supervisors and Committee Members. Here is an exhaustive list of
each actor along with their use cases:

3.3.1 1. Actors

• Students

• Supervisors

• Committee Members

3.3.2 2. Use Cases

3.3.2.1 Student Use Cases

• View List of Projects: This affords the student an opportu-

nity to view all the projects that he or she would be interested
in.

• Select Projects: This allows students to select projects that

could interest them.

• View Supervisor Profiles: This affords a student an opportu-

nity to look at supervisor profiles so they can select the project
of their choice.

• View Status of Submission: The status of submitted project

could be viewed by students.

• Login: Students logged into the system to access their account

and the functionalities available to them.

15 SRS BSCS
CHAPTER 3.

3.3.2.2 Supervisor Use Cases

• Login: Managers log in to the system for access to their func-

tionality.

• Allocate Assessments: Managers can send assessments to

student submissions.

• Grading: The superintendent shall grade the submitted project

or provide remarks on it.

• View Online Submission: The review of online submissions

of projects from students by supervisors.

3.3.2.3 Committee Member Use Cases

• Login: Committee members log in to the system in order to

access their functions.

• Manage Titles: They can create, edit, or remove project titles

available for students.

• Allocate: Committee members can allocate projects to super-

visors or manage panels.

• View Marking: They can see the evaluations made by super-

visors on student projects.

• View Important Announcements: Committee members can

view important announcements that would be important to
their work or of relevance to the students. [6]

16 SRS BSCS
CHAPTER 3.

3.4 External Interface Requirements

3.4.1 User Interfaces

• Home Page

Figure 3.2: Home Page of the UI

This is the home page of our Final Year Project (FYP) ti-
tled ”Project Allocation and Evaluation According to
NCAEC Rules”. The page features a responsive navigation
bar with buttons for Home, About Us, Contact Us, and
Login.

The home page provides an overview of the main actors/users

involved in the project:
Students: Details about their roles and functionalities.
Committee Members: Information on their tasks and re-
sponsibilities.
Supervisors: Highlights of their supervisory duties and capa-
bilities.

17 SRS BSCS
CHAPTER 3.

• Role base Login pages

Below is the Login page of Student:

Figure 3.3: Login Page of Student

This is the login page for students, where they can enter the
following details:
Name: The student’s full name.
Roll Number: The unique roll number assigned by the uni-
versity.
University Email: The official email address provided by the
university.
Password: A secure password for account authentication.

18 SRS BSCS
CHAPTER 3.

Below is the Login page of Supervisor:

Figure 3.4: Login Page of Supervisor

This is the login page for supervisors, which includes the follow-
ing features:
Supervisor ID: A unique identifier for each supervisor.
Email: The supervisor’s official email address.
Password: A secure password for authentication.

After entering these details, the supervisor can successfully log

in to access their account.

19 SRS BSCS
CHAPTER 3.

Below is the Login page of Committee member:

Figure 3.5: Login page of Committee members

This is the login form designed specifically for committee mem-

bers, allowing them to securely access their accounts. Commit-
tee members are required to provide the following credentials:
Committee ID: A unique identifier assigned to each commit-
tee member.
Email: The registered email address of the committee member.
Password: A secure password for authentication.

The form is user-friendly and ensures that only authorized mem-

bers can log in. Upon successful authentication, committee
members are redirected to their dedicated dashboard to manage
their tasks and responsibilities efficiently.

20 SRS BSCS
CHAPTER 3.

• Student Dashboard

Figure 3.6: Students group member selection Page of the UI

The figure above illustrates the Student Dashboard displayed

after a student successfully logs in. This dashboard provides the
following functionalities:

Filter Students: Students can select their Semester,

Department, and Batch Number. Based on these se-
lections, a filtered list of students is displayed, including
their roll numbers and statuses.
Send Request: Each student in the filtered list has an
option to send a group membership request. Once a re-
quest is sent, it appears in the Pending Requests section
below.
Accept Requests: The student who receives the request
can accept it. Once accepted, the request moves from the
Pending Requests section to the Accepted Requests
block.

21 SRS BSCS
CHAPTER 3.

This dashboard simplifies the process of group formation by

providing an intuitive and efficient interface for managing group
membership requests.

Project Selection process:

Figure 3.7: Project selection Page of the UI (Part 1)

Figure 3.8: Project selection Page of the UI (Part 2)

Figure 3.7 and Figure 3.8 illustrate the project selection process
in the UI.
22 SRS BSCS
CHAPTER 3.

Figure 3.7: Either a group can select a project from the cat-
egories predefined by the committee and supervisor, based on
their interest levels, or they can propose their own project. If
the group has an idea for a project, they can share it in a doc-
ument format, ensuring that the Functional Requirements and
Non-Functional Requirements are clearly mentioned in the doc-
ument.

Figure 3.8: Displays the list of projects according to the cate-

gory selected by the group. Once a group applies for a project,
that project is disabled, preventing other groups from applying
for it.

Figure 3.9: Supervisor Selection Page of the UI

This is the supervisor selection page of the user interface where

students in a group can select supervisors from the displayed list.
Students can view the availability of supervisors, send requests
to them to become their supervisor, and also view detailed pro-
files of the supervisors.

23 SRS BSCS
CHAPTER 3.

• Supervisor Dashboard

Figure 3.10: Supervisors Dashboard Page of the UI

This shows the Supervisors Dashboard where supervisor can

view and edit there profile and also view the Groups list of
students and can accept there requests also assign tasks to the
members of accepted groups and evaluate them.

24 SRS BSCS
CHAPTER 3.

Figure 3.11: Committee members Dashboard Page of the UI

This UI design shows the Committee members Dashboard where

they can view supervisors list as well as Student Group lists
aand can create Evaluation panels and allocate them.

25 SRS BSCS
CHAPTER 3.

3.4.2 Software Interfaces

Table 3.2: Tools And Technologies

Tools Version Rationale

VS Code 1.60 Code editor for develop-
ment
Figma 1.100.2 Mockups Creation
pgAdmin 5.0 Database management and
query execution
Overleaf 4.2 Documentation
MS PowerPoint 2019 Presentation
Technology Version Rationale
Python 3.9 Backend programming lan-
guage
Django REST Frame- 3.12 RESTful API development
work
PostgreSQL 13 Relational database man-
agement
HTML5 5 Structure and content lay-
out
Tailwind CSS 2.0 Responsive interface styling
React.js (Vite) 17.0 Frontend developmnet
JavaScript ES6 Core language for frontend
logic
WebSockets 13 Real-time communication
protocol

26 SRS BSCS
 Chapter 4

Non-Functional Requirements

4.1 Features
The platform loads in 2 seconds, and thus, projects can be set up
and reviewed quickly. This includes optimized front-end assets and
server-side processing for faster updates.

4.2 Scalability
It will have to manage 5000 users at a time for ensuring the smooth
working of a large university like COMSATS University by means of
load balancing and scalable architecture [8].

4.3 Security
Ensure 99.9% uptime with no breaks in access at any point, even
considering students, faculty, and committee members at any time,
especially when learning occurs.

27
CHAPTER 4.

4.4 Data Encryption

Data has to be encrypted for transit as well as storage, conforming
to the policy of the University and NCEAC. The system has also to
ensure role-based security access controls that provide data access
by students, supervisors, and administrators.

4.5 Availability
It is interactive with an interface involving little training effort and is
user-friendly, hence very easy to navigate from selection of projects
through the evaluation process to reporting tools [8].

4.6 Cross-platform Compatibility

Since different students and employees use different browsers on dif-
ferent devices, your accessibility solution should work consistently
across major browsers.

4.7 Data Integrity

Apply data transactions to ensure that you have constant and ac-
curate data for the project, especially in critical tasks such as those
involving project assignments and estimates.

4.8 Maintenance
The developers should have a sample code base from which the plat-
form is updated and/or further improved.

28 SRS BSCS
CHAPTER 4.

4.9 Error Handling

It will ensure to give error message in case of problems to trou-
bleshoot and resolve if any problem arise.

4.10 Check
It will keep logs of critical activities such as assignments of projects,
their submission feedback and system for its accountability and trou-
bleshooting [8].

29 SRS BSCS
 Chapter 5

Design Description

5.1 System Design

MVC (Model View Controller) architectural pattern is used for de-
veloping this webapplication.

Figure 5.1: System Architecture

The Level 0 Data Flow Diagram (DFD) provides a high-level overview

of the FYP Allocation and Evaluation System, identifying key ac-
tors and their primary interactions. In this system, the user can log
30
CHAPTER 5.

in to access their profile, manage documents, request funding, view

evaluations, and receive announcements according to there role.

Figure 5.2: Context diagram(DFD Level 0) of FYP management

In DFD Level 1, the system is divided into distinct processes that

show detailed interactions with each role. The Student Account
Management process allows students to log in, manage profiles, up-
load documents, and request funding. The Supervisor Interaction
process includes accessing projects, assessing performance, and man-
aging meetings. Committee members Functions cover performance
monitoring and funding management, while Administration involves
overseeing student and supervisor data, as well as reviewing reports
and projects. Each process flows smoothly to support project allo-
cation and evaluation, adhering to NCEAC rules.

31 SRS BSCS
CHAPTER 5.

Figure 5.3: Context diagram(DFD Level 1) of FYP management

Below is the context diagram (DFD level 2 ) of FYP management

system:

Figure 5.4: Context diagram(DFD Level 2) of FYP management

32 SRS BSCS
CHAPTER 5.

5.2 High level Design

5.2.1 Sequence Diagram

The sequence diagram for the FYP Allocation and Evaluation Sys-
tem shows the interactions and flow of information among the im-
portant components , including student registration, project(task
management), evaluation process and feedback and report genera-
tion.

• Student Registration and Profile management: Students

log in, update their profiles, submit their preferences for projects,
and upload documents.

• Task management: The Committee check all submissions and

preferences, allocate projects and acquaint supervisors.

• Appraisal process : Supervisors check on the progress of a

student and appraise the submissions.

• Feedback and report generation: The Supervisors and the

Committee Members review the reviews in finalizing the feed-
back.

This sequence allows FYP distribution and evaluation processes to be

standardized according to NCEAC guidelines while enabling effective
tracking of the project.

33 SRS BSCS
CHAPTER 5.

Figure 5.5: Sequence Diagram of the System

34 SRS BSCS
 Bibliography

[1] David J. Bryde and Karen Furlong. Project management in

higher education: A study of the challenges and success fac-
tors. International Journal of Project Management, 31(4):577–
587, 2013.

[2] Martin Fowler. UML Distilled: A Brief Guide to the Standard

Object Modeling Language. Addison-Wesley, 3rd edition, 2004.

[3] Gwo-Jen Hwang and Ping Wu. Real-time communication in

project management: A case study. In 2014 IEEE International
Conference on Teaching, Assessment and Learning for Engineer-
ing (TALE), pages 1–6. IEEE, 2014.

[4] Abdul Mohamed and Mohd Azhar Sidi. User authentication and
authorization in web applications: A survey. International Jour-
nal of Computer Applications, 143(1):1–7, 2016.

[5] Roger S. Pressman and Bruce R. Maxim. Software Engineering:

A Practitioner’s Approach. McGraw-Hill, 8th edition, 2014.

[6] Ben Shneiderman and Catherine Plaisant. Designing the user

interface: Strategies for effective human-computer interaction.
Addison-Wesley, 2010.

[7] Ian Sommerville. Software Engineering. Pearson, 10th edition,

2015.

35
CHAPTER 5.

[8] John Stark. Access Control Systems: Security, Identity Manage-

ment and Trust Models. Springer, 2012.

[9] Yan Zhang and Wei Li. Web-based project management tools:
A review. Journal of Software Engineering and Applications,
8(2):58–67, 2015.

36 SRS BSCS