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

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.

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 = abc@gmail.com , 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

Industrial Attachment Program (IAP) Report

Industrial Attachment Program (IAP) Report

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to Industrial Attachment Program (IAP) Report (20)

More from Akshit Arora (17)

Recently uploaded (20)

Industrial Attachment Program (IAP) Report