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)

Engineering