SRS for Ph.D. Student Portal (C.S.E.D., Thapar University)

Software Requirements Specification for Ph.D. Student Portal Page i
Software Requirements
Specification
For
Ph.D. Student Portal
Version 1.0 approved
Prepared by :
Abhinav Garg (101303004)
Chahak Gupta (101303041)
Akshit Arora (101303012)
Date: 31/08/2015

Software Requirements Specification for Ph.D. Student Portal Page ii
Table of Contents
Table of Contents.......................................................................................................................... ii
Revision History............................................................................................................................ ii
1. Introduction..............................................................................................................................1
1.1 Purpose ........................................................................................................................................ 1
1.2 Document Conventions ............................................................................................................... 1
1.3 Intended Audience and Reading Suggestions.............................................................................. 1
1.4 Product Scope.............................................................................................................................. 1
1.5 Bibliography................................................................................................................................ 1
1.6 Feasibility Analysis ..................................................................................................................... 2
2. Overall Description..................................................................................................................3
2.1 Product Perspective ..................................................................................................................... 3
2.2 Product Functions........................................................................................................................ 3
2.3 User Classes and Characteristics ................................................................................................. 3
2.4 Operating Environment ............................................................................................................... 3
2.5 Design and Implementation Constraints...................................................................................... 4
2.6 User Documentation.................................................................................................................... 4
2.7 Assumptions and Dependencies .................................................................................................. 4
3. External Interface Requirements ...........................................................................................4
3.1 User Interfaces............................................................................................................................. 4
3.2 Hardware Interfaces..................................................................................................................... 4
3.3 Software Interfaces...................................................................................................................... 5
4. System Features .......................................................................................................................5
5. Other Nonfunctional Requirements.......................................................................................7
5.1 Performance Requirements.......................................................................................................... 7
5.2 Safety Requirements.................................................................................................................... 7
5.3 Security Requirements................................................................................................................. 7
5.4 Software Quality Attributes......................................................................................................... 7
5.5 Business Rules............................................................................................................................. 7
6. Technological Requirements...................................................................................................8
Revision History
Name Date Reason For Changes Version

Software Requirements Specification for Ph.D. Student Portal Page 1
1. Introduction
1.1 Purpose
In every university and college students and teachers records are maintained. It is being done
manually in many cases by filling out spreadsheets on computer or through some paper work. And if
the number of records to be maintained are huge in numbers it becomes a cumbersome and time
consuming process. Apart from this it is waste of human time and skills along with inevitable
human errors. This automation project deals with automating the records of PhD students. The
"Ph.D. Student Portal" aims at providing the faculty with the facility of maintaining the record of all
the students' performance in a few clicks, students' with their full PhD profile saving time and
minimizing human efforts. It would lead to a manifold improvement in the efficiency of student’s
record activities, thereby reducing the possibility of human errors. This tool would prove to be
instrumental in reducing the overhead for updating and calculation time for the clerical staff.
1.2 Document Conventions
The document covers the conventions as described by IEEE SRS template. The template standards
are published in “IEEE Standards Collection,” and can be downloaded from [1]
1.3 Intended Audience and Reading Suggestions
The primary objective is to have a dedicated website for the PhD student’s records which can be
accessed from anywhere at any time giving the user the convenience of not going through the
manual procedure of accessing records. Each student's semester wise performance along with the
thesis, presentation, assigned teachers' shall be accessible on website. There will be individual
folders of each student on the server where each student's mark sheet, thesis, presentation will be
kept for easy access to teachers and evaluators. Record of all the pass outs will also be available.
1.4 Product Scope
The website is currently being prepared for Thapar University's Computer Science Department but
it can be extended to any number of departments in any college or university which works under the
same structure. It would ease the process of maintaining and accessing records. Also it will help in
reducing human error. The proposed system will keep all the data in place avoiding the risk of loss
of any kind. Also as most of the work will be automated there'll be no need of manual entry
operators.
1.5 Bibliography
[1] "IEEE," [Online]. Available:
http://www.csc.villanova.edu/~tway/courses/csc4181/srs_template-1.doc.

1.6 Feasibility Analysis
Operational Feasibility
 If the website/application is developed and implemented in an efficient manner, it will be
widely used across various universities where records are maintained manually on paper or
on spreadsheet.
 There will be no resistance from the users as it is a project for the benefit of users. It is a
time saving and easy way for the user to find the required records related to Ph.D.
programme.
 It provides simple interface for the users to operate.
Technical Feasibility
 The project we are undertaking can be easily accomplished with the current equipment
(mobile phones/laptops) do not require any more equipment.
 No new software technology required and existing one can be brought into use.
 The available personnel as well as users will have basic knowledge of working with a
website/application.
Economic Feasibility
 If the website isn’t developed or this project is not undertaken, records will be maintained on
spreadsheets or paper thus increasing the costs.
 Faculty will be benefitted as their time and money will be saved. Also they have to put in
less effort to maintain records as most of the details will be entered by student.
 The hardware and software costs are also minimal as already available soft wares are being
used and just a single computer is enough to develop the system.
 The database being used in the system will be an open source database.
Schedule Feasibility
 The scheduled feasibility of the project is about two months which will include coding and
collection of the database.
 Some environmental factors like unavailability of information or if the person needs more
information about the coding could lead to extending of the scheduled date.
Legal Feasibility
 The making of such an application is a legal process and is culturally acceptable, also the
legal constraints encountered will be negligible.
 Copyright Issues-Mainly open source soft wares will be used so, licensing issues will be
minimum.

2. Overall Description
2.1 Product Perspective
The PPMS is a completely new, self-contained product in the existing system of Thapar University.
This product will help in easy access of PhD student's performance through the Thapar's official
website. As currently teachers currently face the problem of maintaining excel sheets and
maintaining each student's project, thesis, presentation data manually, the product will do all the
above mentioned things automatically by making a separate folder for each student at the server.
Also the accounts can be maintained by students, thus simplifying the cumbersome process.
2.2 Product Functions
The major functions that the PPMS will provide are as under:
Administrator:
 Validating student accounts
 Cross- verification of student details.
 Evaluating performance
Students:
 Registering on website
 Updating their details timely
 Uploading their presentations, thesis they need to submit.
 Choosing subjects.
General Audience:
 View the projects undertaken by the students pursuing PhD in Thapar University.
2.3 User Classes and Characteristics
The potential users for the portal are
1) Students enrolled in Ph.D. program in CSED: Role of students in the system involves
maintaining the database records corresponding to their ID.
2) Administrator: Role of the administrator involves searching, manipulating and cross-validation of
student records.
3) General Audience: It means, anyone accessing the portal website. Only search function is
available to this user.
2.4 Operating Environment
The system will work on Internet thus making it accessible from any platform either mobile or
stationary. A browser is needed to access the Internet which in turn will allow the access to the
particular website.

2.5 Design and Implementation Constraints
Number of hits on website:
Since the website will be deployed on a server, the processing power of the
server will act as a constraint on the number of simultaneous hits that the
website can take. However there is a safe assumption that at a particular time,
even at peak usage, no more than 100 people will visit the site.
Operating Platform:
The portal is a web service. It does not matter which device or operating
system the user uses to access the website. The user only needs a web
browser to access it. Also any front-end framework requirements are being
delivered by content delivery networks. Hence there are no constraints on the
operating platform.
2.6 User Documentation
The software will be accompanied with a user help section integrated in the system itself to make it
easy for new users to understand the functioning of the system. An online video tutorial shall also
be made available at the time of system delivery to further ease the process of system learning.
2.7 Assumptions and Dependencies
The project is based on the assumption that the student regularly inputs valid information into the
system.
3. External Interface Requirements
3.1 User Interfaces
The interface provides a variety of options to the users. It allows the following features:
Student Interface: It opens up after student logs in from General Audience Interface. It will contain
the following major panels:
 Course Work: options for addition / deletion of course work taken up by the student.
 URB Meeting: options for setting up agenda for URB meeting,
 Publications: options for addition / deletion of research publication records.
 Profile: options editing the profile page of the student.
 Settings: Access to various student settings
 Administrator interface: It opens up after administrator logs in from General Audience
Interface
 Student records: Access to student information.
 Faculty Records: access to faculty information.
 URB Scheduling: options to handle URB meetings
 Course scheduling: options to allocate courses to PhD students.
 Settings: Administrator settings manipulation.

General Audience Interface
 Search panel: For searching student records.
 Home page: providing general information about the portal and CSED.
 Login Page: Meant for opening up administrator and student interface
3.2 Hardware Interfaces
Ph.D. student portal is a website that can be assessed from any device be it a computer desktop,
laptop, tablets, phones or any other device having a NIC (Network Interface Card).
3.3 Software Interfaces
As mentioned earlier the project is a website hence can be accessed from any device. It does not
require any particular operating system to execute. All it needs is just a modern web browser (like
Safari, Firefox, and Google Chrome etc.).
4. System Features
All the features and functions are tabulated below:
No. Features Functionality Description
1. User Signup GUI shall be
required to enter
user’s (both student
and faculty) details.
The homepage would have link to signup
page. The students already registered with
university can sign up using registration
numbers provided by the university. They
can submit their personal details and set the
password to their profile. Only these users
will be able to login on the website in
future.
2. Student
Login
GUI shall be
required to view
student profile after
login
The homepage would have link to a login
page. The students can login with
passwords provided to them. The login will
enable them to view their course details and
the term wise results also. The data will be
retrieved from the relational database at the
backend.
3. Faculty
Login
GUI shall be
required to view
faculty profile after
login
The homepage would have link to a login
page. The faculty members can login with
their credentials. The login will enable them
to view details of students allotted to them
for supervision, student’s regular
performance and details of committee they
are part of.
4. Admin GUI shall be The homepage would have link to a login

login required to view and
edit details of
registered students
and faculty
members.
page. The admin would have the rights to
edit, update and monitor details of students
and other faculty members.
5. Managing
courses
GUI shall be
required to select the
courses for the
programme
undertaken by the
student.
After signing in to their accounts, students
can select the required courses as per the
guidelines of university. Grades
corresponding to all completed courses and
SGPA and CGPA will be updated every
semester.
6. Progress
Information
GUI shall be
required to show the
progress report of
each student
Progress report of a student can be viewed
in tabular format by both students and
faculty members. It will show progress in
percentage after every 6 months.
7. URB
meeting
Option shall be
required to enter the
date of next URB
meeting
Admin will have the right to enter the date
of next URB meeting for each student. This
date will be shown in profile of associated
student and faculty members.
8. Submissions GUI shall be
required for the
students to submit
their work
Students will upload their presentations
after every URB meeting. They will also
upload their thesis work in their profile
which will be viewed by faculty members
for further evaluation.
9. Marks
Updation
GUI shall be
required for the
faculty members to
upload marks.
Faculty members will upload marks of the
students under them after every submission.
The assigned marks and grades will be
shown in student’s profile.
10. Status
update
A section shall be
required to show the
status of completion
of Ph.D. for each
student.
Status of Ph.D. programme undertaken by
student from thesis submitted to thesis
completed and then to Ph.D. completed will
be updated by the admin. This information
will be shown in all the student’s profile
and all the faculty’s profile associated to
that student.
11. Course List GUI shall be
provided to view all
the courses provided
by university
All the courses along with the faculty will
be shown in list form on the website. This
list can be viewed by any non-registered
user.

5. Other Nonfunctional Requirements
5.1 Performance Requirements
• Reliability: Auxiliary storage devices must be available for backing up the data. The internet
connection in the school must be stable most of the time.
• User Interface and Human Factors: The training for using the admin panel is required to be
provided so as to prevent him/her from making errors.
• Availability: The website shall be available, up and running for 24*7 throughout the year except
due to the routine maintenance activities.
5.2 Safety Requirements
There are no specific safety requirements associated with the proposed system. The portal executes on well-
known and commonly used hardware which does not cause any safety hazards.
5.3 Security Requirements
Security is one of the points of concern in this system.
 The password details that are stored in the database should be in encrypted format so that the
data cannot be read directly.
 Only a registered user should be able to access the account and perform various tasks such
as updating the Ph.D. status, editing user profiles etc.
 PHP functions should be used to prevent the users from entering malicious queries into the
database.
5.4 Software Quality Attributes
• Reliability
The portal should provide reliability to the user that the website will run stably with
all the features mentioned above available and executing perfectly. The server on which the
website will be deployed must be able to handle large number of hits on the website.
• Resources
PhD Portal should be designed in such a way that the query of the user can be
fulfilled with minimum number of accesses to the database thus improving speed.
6. Technological Requirements
The project makes use of the following technologies:
 APACHE: It acts as the local server for testing of website during the development phase.

 HTML/CSS/JAVASCRIPT: These languages will be used to develop the front end ie. the
UI of the website. AJAX might also be used to improve the user experience while browsing
the site.
 PHP: It will act as the language for server side scripting. All the interactions with the server
will be done using the code written in PHP.
 Database: RDBMS will be used in the system. PHP MySQL connectivity functions will be
used to link the database to the website.
Appendix A:
Glossary
UI: User Interface
CSS: Cascading Style Sheet
HTML: Hyper Text Markup Language
PHP: PHP Hypertext Preprocessor

SRS for Ph.D. Student Portal (C.S.E.D., Thapar University)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a SRS for Ph.D. Student Portal (C.S.E.D., Thapar University)

Semelhante a SRS for Ph.D. Student Portal (C.S.E.D., Thapar University) (20)

Mais de Akshit Arora

Mais de Akshit Arora (17)

Último

Último (20)

SRS for Ph.D. Student Portal (C.S.E.D., Thapar University)