System Requirements Specification for Placement

Management System
1. INTRODUCTION
1.1 Purpose

This SRS is prepared to evolve as the development of the software product processes. The
purpose of this document is to give description about the system, its requirements with respect
to consumers. The proposed system will be used to provide a detailed overview of the product,
its parameters and goals. It defines how our client, team and companies see the products and
its functionalities. It also assists the SDLC Model.

1.2 Document Conventions

This document is formed using IEEE template for System Requirement Specifications (SRS)
documents. Headings are in bold capital letters and wherever necessary, diagrams are
provided.

1.3 Product Scope

This System will be a Web Placement Activity Management System for the students, company
and Training and Placement Officer (Admin). This system will be designed to maximize the
productivity by providing tools to assist in automating the student feedback, company feedback
and information processing which would otherwise have to be performed manually.

More specifically, the system would store all the academic as well as personal details of the
students who wish to be placed and the companies who offer jobs to the students. The details
maybe deleted or modified to keep the information up to date. Also, notifications would be
sent to the companies about the profile, eligibility criteria to the students during the selection
process.

1.4 Product Functions

● The student will register himself/herself and will have a unique identity.
● Students can update their profiles and add details to their profiles to make it unique.
● Companies can view Student Profiles and notify their eligibility criteria and other details
to them.
● Companies can publish the results on the site and students can view them.
● Selected students can ask queries and companies decide their salary.
● Students have an access to the schedule of tests and interviews.
● Companies answer to the queries of selected students.
2. Overall Description
2.1 Product Perspective

The proposed system shall be developed using pooled System Architecture and will be
compatible with Microsoft Windows Operating System. The product aims at activity
collaborative resource pooling and problem-solving using peer-to-peer learning. This is a self-
centered product and its data is restricted to its users and secured.

2.3. User Classes and Characteristics

1. Student

● New student has to sign up or register using complete details.

● They can submit the resume and update their profile information
● They can register for a particular company.

2. Administrator

● The Admin has the supreme power of the application.

● Admin provides approval to the student and corporate registration
● Admin is responsible for updating and maintaining the whole system.
● Admin has the responsibility of notifying the company of the applicants.
● Admin has to notify the students regarding any change in procedures or selection
process.

3. Company

● The Company has to notify the Admin or the Placement Officer.

● The Company has to sign up/register initially.
● The company shortlists the students that meet up to its expectations.

2.4 Operating Environment

Operating System: Windows

Database: MySQL

2.5 Design and Implementation Constraints

1. Application Functionality- The application through which the students take the services
should be well-functioning, error-free and easy to understand.
2. Time- No time lag to be witnessed during the service.

3. Management of a huge database

4. Security and Safety

5. Internet Connectivity

6. Investment

7. Large data storage capacity

8. Considerable RAM size for smooth working

9. Maintenance and timely updating.

10. Credible analysis of students’ feedback

3. EXTERNAL INTERFACE REQUIREMENTS

3.1 User Interfaces

● Login- To allow the users to view his details and updates regarding placements,
company details in his profile.
● Placed or not-To check final results.
● Company Details-To maintain Company Details.
● Student List- Available to Company for details.
● Decide Salary- To maintain a record of salary.

3.2 Hardware Interface

Device should be enabled with internet.

3.3 Software Interface

● The project supports all types of web browsers.

● All the student details are highly secured and privacy is maintained.
4. SYSTEM FEATURES
4.1 Login

Following credentials will be asked-

For users:

● User ID
● Email ID
● Password

For Admin:

● Admin ID
● Password

4.2 Register

For Students: Students need to upload the following details-

● Academic Results
● Age
● Courses undertaken
● Email ID
● Contact Number
● Extracurricular Activities
● Responsibilities undertaken

For Companies:

● Eligibility Criteria
● Positions and packages offered in the past
● Previous examination details

4.3 Updating

Students can update their courses and projects to make their profile look more attractive.

4.4 Company Details

Companies will provide the forms for placement and students will enroll into them. Later the
schedules will be provided to the eligible students.
4.5 Results

Company will upload the results after the final exams and interviews and the students will be
able to view them.

5. OTHER NON-FUNCTIONAL REQUIREMENTS

5.1 Performance Requirements

-The physician software should be able to support at least three simultaneous users.

-95% of the transactions shall be processed in less than one second.

-Data should be backed up and secured every quarter hour.

-System should be operable 24×7 and accessible in real time.

5.2 Safety Requirements

The database may get crashed or damaged due to some viruses or operating system
requirements. Therefore, it is necessary to have backup for your data. UPS/Inverter facility
should be there in case of power failure.

5.3 Security Requirements

-System will secure databases.

-No editing or modification of anything except personal information.

-Separate account for admin and user so that no one else can access the database except the
admin.

5.4 Software Quality Attributes

-Availability: Checking that the system has always something to function and generates a pop-
up error message in case of component failure.

-Usability: Checking that the system is easy to handle and navigates in the most expected ways
with no delays.
-Functionality: Checking that the system provides the right tools for editing questions
databases, creating session tests and analyzing them.

5.5 Business Rules

-The software is college specific and no other organization can use it without legal proceedings.

-All the users enrolled and facilities registered are necessarily from the host college only.