Industrial Attachment Program (IAP) Report

Software Requirements

Specification

For

IAP Evaluation Portal

Prepared by:

Abhinav Garg (101303004)

Akshit Arora (101303012)

Arush Nagpal (101303034)

Chahak Gupta (101303041)

Thapar Institute of Engineering and Technology University, Patiala

25th February, 2016

Software Requirements Specification for IAP Evaluation 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 Project Scope ................................................................................................................................... 2 1.5 References ........................................................................................................................................ 2 1.5 Feasibility Analysis ......................................................................................................................... 2

2. Overall Description ..................................................................................................................4 2.1 Product Perspective ......................................................................................................................... 4 2.2 Product Features .............................................................................................................................. 4 2.3 User Classes and Characteristics ..................................................................................................... 6 2.4 Operating Environment .................................................................................................................... 6 2.5 Design and Implementation Constraints .......................................................................................... 6 2.6 User Documentation ........................................................................................................................ 7 2.7 Assumptions and Dependencies ...................................................................................................... 7

3. System Features ........................................................................................................................7 3.1 Student, Faculty and Industry Mentor Registration ......................................................................... 7 3.2 Student, Faculty and Industry Mentor Login ................................................................................... 8 3.3 Student Assessment Upload ............................................................................................................ 9

4. External Interface Requirements .........................................................................................10 4.1 User Interfaces ............................................................................................................................... 10 4.2 Hardware Interfaces ....................................................................................................................... 10 4.3 Software Interfaces ........................................................................................................................ 10 4.4 Communications Interfaces ........................................................................................................... 11

5. Other Nonfunctional Requirements .....................................................................................11 5.1 Performance Requirements ............................................................................................................ 11 5.2 Safety Requirements ...................................................................................................................... 11 5.3 Security Requirements ................................................................................................................... 11 5.4 Software Quality Attributes ........................................................................................................... 12

6. Technological Requirements .................................................................................................12

Appendix 1: Faculty and Industry Mentor evaluation form ...................................................13

Appendix 2: Industry feedback form .........................................................................................14

Appendix 3: Student emergency contact form and joining report .........................................15

Revision History

Name Date Reason For Changes Version

Software Requirements Specification for IAP Evaluation Portal Page 1

1. Introduction

1.1 Purpose

In every college/university, students undergo 6-months of industrial training in their pre-final or

final year of Bachelors of Engineering. All the records need to be maintained by the university about

the students, companies in which they are undergoing training and also the feedback from the

industry process. All of this work is done manually. As the number of students in the university are

increasing per year, this work is becoming cumbersome. Also the juniors face difficulty in getting

prior information about the companies their seniors joined which may help them securing internship

in good companies. Departments are not able to provide them full help as records are sometimes

misplaced. The primary objective of the portal is to give the university management a tool to help

them manage the student training data as well as give university students access to past training

records along with contact information of their seniors. The automation of records of training

semester will simplify the arduous task of manual maintenance. It aims at providing the students and

teachers with the facility of submission, guiding, feedback and grading them online. Also the

industry mentors would be able to provide feedback of the intern's performance.

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

https://web.cs.dal.ca/~hawkey/3130/srs_template-ieee.doc

1.3 Intended Audience and Reading Suggestions

The primary audience include the students going out for 6 month industrial training, faculty

members and industry mentors allotted to those students. The personal data of all the students, their

performance report during training period can be accessed from anywhere at any time giving the

user the convenience of not going through the manual procedure of accessing records. The faculty

and industry mentors will be able to evaluate the students (based on rubrics provided in the

https://web.cs.dal.ca/~hawkey/3130/srs_template-ieee.doc


knowledge base of the website) and the students in turn, would be able to submit joining,

intermediate and final reports online through the website. There will be individual record

maintained for each student on the server will be kept for easy access to faculty members and

mentors. Record of all the pass outs will also be available to all the students for consultation. Pass

out students will be able to comment about the industry environment and their living conditions that

would serve as a reference for the students that would be going the forthcoming year.

1.4 Project Scope

The website is currently being prepared for Thapar University's Mechanical Department but it can

be extended to any number of departments in any college or university that works under the same

structure. Thus, it can be scaled up to serve as the default training portal for the whole university. It

would ease the process of maintaining and accessing performance records of students undertaking 6

month industrial training. It will also ease the process of evaluating student’s performance by the

faculty members and mentors and help in reducing human error. The proposed system will keep all

the data in place avoiding the risk of loss of any kind and act as future reference for the students.

Since the system will link the administrator, student, faculty and the industry mentor, there will be

no need for manually keeping records.

1.5 References

[1] "IEEE," [Online]. Available:

http://www.csc.villanova.edu/~tway/courses/csc4181/srs_template-1.doc.

1.6 Feasibility Analysis Operational Feasibility

If the web-application is developed and implemented in an efficient manner, it will be

widely used across the university 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.

Students will be able to submit documents online and find fellow interns in their city.

The faculty will be able to contact the industry mentors easily through the online interface.

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 web technologies are sufficient to create an efficient website that can be easily

accessed across various devices. The technologies used will be a combination of different

frameworks of different languages and the developers have sufficient expertise to create the

website.

The available personnel as well as users will have basic knowledge of working with a

website/application.

Economic Feasibility

The website will assist online storage of data which can later be printed for offline access,

thereby reducing the costs.

The online communication will reduce the communication costs between the industry

mentors and the faculty assisting the student.

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 softwares 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 - The website would use open source software, licensing issues will be

minimum.

The templates used will be licenced under the MIT Licence which allow free usage for

personal as well commercial purposes.

2. Overall Description

2.1 Product Perspective

The IAP Evaluation portal is a completely new self-contained product in the existing system of

Thapar University. This will be developed from the scratch and all the website functions are

currently handled manually.

2.2 Product Features

The website will have four kinds of users which are the student, the administrator (IAP

Coordinator), the faculty member and the industry mentor. Their major functions are described as

under:


Administrator:

Validating student’s training details

Full access management.

Allocating cities to faculty

Allotting faculty mentors to students

Start or end the grading procedure

Add more students or faculty to system, and maintain the system

Students:

Registering on website with their training details.

Updating their training details timely.

Uploading their joining report, goals reports, midway report, emergency contact details and

final report timely.

Receive feedback from the students and faculty.

Mentor:

Registering on website.

Uploading Final assessment timely.

Updating details of students working on them.

Communicate with the faculty mentor of the student.

Faculty:

Registering on website.

Uploading assessment and grade the students timely.

Choosing city preferences.

Communicate with the industry mentors

General Audience:

View the trainings undergone by students in the previous years.

View the past companies for training purpose.


2.3 User Classes and Characteristics

Students undertaking 6 months summer training: Role of students in the system involves

maintaining the training records corresponding to their ID.

Faculty: Managing, evaluating students' performance on the basis of the reports and industry

mentor's feedback.

Industry Mentor: Evaluating student on the basis of his performance in the training period and

providing feedback for the same.

Administrator: Linking student to faculty members and managing the website. Manipulating

and cross verification of student records.

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. The website will be made responsive so that it works on any device.

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. System Features

3.1 Student, Faculty and Industry Mentor Registration

3.1.1 Description and Priority

The task of registration of the three main users of the system is dealt in this feature.

Every user will have their own username and password. If this feature fails, we might

end up getting the user into wrong situation altogether.

3.1.2 Stimulus/Response Sequences

Stimulus: The user is unregistered and submits personal details.

Response: User is registered and can sign in using password provided through

the registered email.

Stimulus: The user is unregistered and enters incorrect confirmation password

while registering.

Response: Display an error message.

2.1.3 Functional Requirements


REQ-1: For student, the required details are: Roll Number, Branch, Full Name, E-

mail, Phone number, Company and City of internship. Also an emergency

contact form will be filled by the student. An example form is mentioned in

appendix 3 at the end of the SRS.

REQ-2: For faculty, the required details are: Initials, Full Name, and Designation

REQ-3: For industry mentor, the required details are: Code provided by student,

username, E-mail

REQ-4: After any of the above users have signed up, a random password will be

generated and sent to their respective e-mail. This will serve as e-mail

validation and clicking on the link in the e-mail, the user will be redirected

to password panel where they can set their password themselves. After that,

dashboard will be accessible.

3.2 Student, Faculty and Industry Mentor Login


This feature is required to give all the registered users to their respective dashboards,

where they can perform relevant tasks (Example for student: updating emergency

contact details, for faculty: update city preferences, for industry mentor: update

student evaluation marks, for admin: approving student details for further processing).


Stimulus: The user is logged out and dashboard is inaccessible. They fill-in

their username and correct password (used in the sign-up phase).

Response: User redirected to their respective dashboard.

Stimulus: The user is unregistered and tries to sign in. Or the user is

registered and puts incorrect username / password.

Response: Display an error message.



REQ-1: For student, the tasks they can do with their dashboard are: edit personal

details, submit their respective company and city details, upload their

reports timely (joining report, goals report, emergency contact details,

midway report and final report) and edit password.

REQ-2: For faculty, the tasks they can do with their dashboard are: upload

assessment of every student assigned to them, edit personal details and set

city preferences.

REQ-3: For industry mentor, the tasks they can do with their dashboard: upload

assessment details of every student working under them.

REQ-4: After any major change is made by student, industry or faculty a

notification is generated for relevant users.

3.3 Student Assessment Upload


This feature is required to compute the final assessment of student from industry

mentor and faculty.


Stimulus: The reports and company details are submitted by student

Response: Faculty / Industry mentors submit the evaluation details.


REQ-1: For faculty, the evaluation form needs to be submitted. And example report

has been mentioned in Appendix 1 at the end of the report.

REQ-2: For industry mentor, the evaluation form needs to be submitted. And

example report has been mentioned in Appendix 2 at the end of the report.

REQ-3: When final student evaluation forms have been submitted by both faculty

and industry mentor, admin is notified and student's final evaluation can be

locked and approved.


4. External Interface Requirements

4.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:

Login Page: Meant for opening up administrator, faculty, mentor and student interface

Training details: options for editing the details of the training undertaken by the student.

Documents: options for uploading the joining report, emergency details, goals report

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.

Mentor panel: evaluating students performance and providing feedback for the same

Settings: Administrator settings manipulation.

4.2 Hardware Interfaces

IAP portal is a website that can be accessed from any device be it a computer desktop, laptop,

tablets, phones or any other device having a NIC (Network Interface Card).

4.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.4 Communications Interfaces

The students are required to send request through email to the administrators for editing their

training details. Mentors and faculty members can send email to each other to discuss about students

performance.

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.

• A validation link will be send to the registered users.

• 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 training details, editing user profiles etc.

• PHP functions should be used to prevent the users from entering malicious queries into the

database.


• Various security attacks like CSRF, session forgery and cross server scripting attacks will be

prevented using secure PHP coding practices.

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

Thapar Connect 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 i.e. 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.

Frameworks:

PHP frameworks like CodeIgniter will be used for faster and modular web development.

JavaScript Libraries like Typeahead.js, tablesorter.js, jquery.js, printit.js will be used for modularity

and ease of accessibility.

HTML and CSS frameworks like Bootstrap will be used for responsive view of the website.


7. APPENDICES

Following are some resources gathered by the time at the time of requirement analysis from the client. APPENDIX – 1 Faculty and industry evaluation rubrics and form.


APPENDIX – 2 Industry mentor evaluation form.


APPENDIX – 3 Student Emergency Contact form and Joining Report.

Use Case Diagram

Class Diagram

Sequence Diagram

Activity Diagram

Swimlane Diagram

Collaboration Diagram

DFD Level 0

DFD Level 1

DFD Level 2

ER Diagram

Component Diagram

Deployment Diagram

State chart Diagram

Structure Chart

TEST REPORT

Module: Random Password Generation

Test Type: Unit Testing

Test Technique: White Box Testing

Input: N/A

Actual Output: Random Password

Expected Output: Random Password

Test Result: PASS

Module: Encrypting Password



Input: User Password

Actual Output: Hashed Password

Expected Output: Hashed Password

Test Result: PASS

Module: Sending Email



Input: Random Password with message

Actual Output: Mail Sent

Expected Output: Mail Sent

Test Result: PASS

Module: Student logs in the system


Test Technique: Black Box Testing

Input: Registration Id = abc , password = xyz

Actual Output: Invalid email

Expected Output: Invalid email

Test Result: PASS




Input: Registration Id = , password =

Actual Output: Fields are required

Expected Output: Fields are required

Test Result: PASS




Input: Registration Id = [email protected] , password = xyy

Actual Output: Incorrect Password

Expected Output: Incorrect Password

Test Result: PASS

Module: Student Registers on the system



Input: Student submits his/her details into the system

Actual Output: Successfully Registered and password is emailed

Expected Output: Successfully Registered and password is emailed

Test Result: PASS

Module: Forgot Password

Test Type: Integration Testing

Test Technique: Bottom Up Approach

Input: Student enters his/her email id into the system

Actual Output: Link to change password along with one time activation code sent on mail

Expected Output: Link to change password along with one time activation code sent on mail

Test Result: PASS

Module: Submit Joining, intermid and final reports


Test Technique: Bottom Up Approach

Input: Student uploads document on the portal

Actual Output: Link to change password along with one time activation code sent on mail

Expected Output: Link to change password along with one time activation code sent on mail

Test Result: PASS

Based on flow graph

Number of predicate nodes = p = 5

Number of paths = p+1 = 6

Number of test cases = 6

Module: Submit Joining reports


Test Technique: Top Down Approach

Input: Joining reports for all the enrolled companies submitted

Actual Output: You have already submitted the files

Expected Output: All the files are submitted

Test Result: PASS




Input: form is not submitted

Actual Output: User interface for Uploading file

Expected Output: Form for uploading file is visible

Test Result: PASS




Input: Form is submitted without selecting file

Actual Output: Choose a valid file

Expected Output: Ask the user to select a valid file

Test Result: PASS




Input: A valid file is selected but network error occurred

Actual Output: Some error occurred

Expected Output: Some error occurred

Test Result: PASS




Input: A valid file is selected and submitted

Actual Output: File successfully uploaded

Expected Output: File successfully uploaded

Test Result: PASS



Test Technique: Top down Approach

Input: A valid file is submitted but not uploaded due to some network error

Actual Output: Some error occurred. Please try again!

Expected Output: Some error occurred

Test Result: PASS

Flow Diagram: