CAMPUS RECRUITMENT

MANAGEMENT SYSTEM
Table of Contents
1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Product Scope
1.5 References
2. Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Classes and Characteristics
2.4 Design and Implementation Constraints
2.5 User Documentation
2.6 Assumptions and Dependencies
3. External Interface Requirements
3.1 User Interfaces
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communications Interfaces
4. System Features
4.1 System Feature and Priority Matrix
4.2 Functional Requirements
5. Other Nonfunctional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
5.5 Business Rules 20
 INTRODUCTION
1.1 PURPOSE OF CAMPUS RECRUITMENT MANAGEMENT SYSTEM :-
• The primary purpose to develop this system is to optimize the recruitment process
for college. Besides, the qualified applicants could be sort by this system based on
their qualifications and company requirements. Based on the applicants skills and
areas of interest , the company suitable or the company in which he/she is going
to place can be predicted. Another purpose of the software is to facilitate the
student (in the college) and the company to register and communicate with
placement office.
1.2 DOCUMENT CONVENTIONS :-
The font used in this document is Tw Cen MT having size 16 . The text is made bolt
for the highlighting purpose so that it can be easily differentiated. In this document,
Every functionality is equally important and every requirement has its own priority.
1.3 INTENDED AUDIENCE AND READING SUGGESTIONS :-
The document is meant for the student of the college, the company and the admin will
operate the system. this document will server as a reference document for the project
management and development team who will analyze, design and implement the system.
1.4 PRODUCT SCOPE :-
Campus Recruitment System enables the user to have the typical recruitment facilities and features at
their disposal. It resolves the typical issue of manual staffing processes and activities into a controlled
and closely monitored work flow in the architecture of the application. The objective of this
application is to serve as a common meeting ground for jobseekers and company, locally. This kind of
system is specifically designed for organization to help in solving staffing problems and managing
human resource department activities at higher degree of optimization.

1.5 References :-
The Document refers to the following assignment submitted:
Assignment 1
 Overall Description
2.1 PRODUCT PERSPECTIVE :-
In the “campus recruitment system”, we will be having a user interface for the admin ,
student and company . The user can log in to their account. depending on the user , the
utilities will be decided. the student can login to their respective account and can
apply for the respective.
2.2 PRODUCT FUNCTION :-

The below DFD clearly shows various process associated with the project and
how the data flows between the entities and database. the student can create
the account. if the account is already present then he/she can search for the
available jobs, can view the jobs and also apply for the jobs. further he/she
can update the details, can change the password etc.
The company can create the account. if the company already have an account
then the company can post the job and can also view how many candidates
have applied for the jobs of that company.
The admin can manage the student and the company. admin validates the
account of the student. admin validates the account of the company. admin can
also remove company and the student if found any discrepancy. admin
manages all activities of company and student.
PRODUCT FUNCTION :-
2.3 USER CLASSES AND CHARACTERSTICS :-
The actors and use cases are clearly shown in below use-case diagram.
In software and systems engineering, a use case is a list of actions or event steps typically defining the
interactions between a role (known in the unified modeling language as an actor) and a system to
achieve a goal. the actor can be a human or other external system. in systems engineering use cases
are used at a higher level than within software engineering often representing missions or stakeholder
goals. the following are the actors who perform the use cases as stated above: s.no actor name
description / actor’s role 01 admin manage students & companies. 02 student apply for jobs, view job
status & search jobs. 03 company post jobs & view applications of students.
The following section describes the Use Cases with Pre and Post Conditions :-
2.4 DESIGN AND IMPLEMENTATION CONSTRAINTS :-
The following design and implementation constraints are applicable for the campus recruitment
system:
1. The system is designed to be the cross platform supportable. the system is supported on a wide
range of hardware and any android platform which is having any version of android built into the
system. this application is being developed using android studio; hence it is extremely portable.
2. To prevent multiple students of the same specialty to log-in onto same company portal. request, a
workflow system needs to be designed which routes the company vacancy requests to students.
3. System is expected to store maximum 64gb of data.
4. Initially system will be available on android system with versions greater than 5.1. then the system
will be available for even iOS mobiles and even on pcs and laptops.
5. In order to assist students for selecting a company and preparing for interview for that company ,
a machine learning algorithm will be designed and trained on a training data-set to predict which
skills will be required for students and also if student is eligible for company, this algorithm will
continue to be trained on previous recorded data sets of students to improve the quality of
predictions.
6. The database shall be maintained by admin and who have not logged in for last 1 year would
get archived onto a parallel database. restoring of students data is beyond the scope of the project
and would need to be managed by admin.
7. As the system is supposed to be used by students and company as well, care needs to be taken
from a usability perspective in terms of font sizes and ease of system usage.
8. Also UI is made with particular animations so that company can find it good for uploading jobs
and interact with students. even more and more companies and students use this app is the aim.
2.5 USER DOCUMENTATION :-
The following documents shall be prepared:
1. Installation guide.
2. User manual for end users.
3. Even video tutorials of installation of campus recruitment will be provided as DVD.

2.6 ASSUMPTIONS AND DEPENDENCIES :-

The key assumptions are:
1. The services is offered for only NITK students. so right now whole system is designed based on only
one college.
2. There will be one authorized student for a particular id. so id will be unique.
3. There will be one authorized company for a particular id. so all ids will be unique.
4. Student can fill maximum 30 application form for jobs in a company.
5. A machine learning algorithm to assist students for selecting a company and preparing for interview
for that company will be implemented to predict which skills will be required for students and also if
student is eligible for that company.
6. The services can be qualified in terms of volumes of data, trends, frequency of updating in order to
give an introduction to the technical system.
 EXTERNAL INTERFACE REQUIREMENTS
3.1 USER INTERFACES :-
The user interface section defines the way various stakeholders interact with the system. all the screens will
be developed to work on android mobile. error messages will appear as a popup on the screen. the
maximum size of error message will be 40 characters. buttons will there to make the navigation simpler.
A first time user of the mobile should see the login screen when he/she will open the android application. If
the user has not registered to the, then he/she should be able to redirect to the sign up page from login
screen. every user should have the profile where he/she can apply for the job. after the creation of
account the user can login to the application and will be able to apply for the jobs.
Similarly, here will be the same option for the login of the company where the company can signup and
login. An Admin should also be log in to the web portal where he/she can administer the system by
managing the student and company using the application. After performing login the user will be able
to see the side menu as shown in the figure below. After performing login by the company the company
will be able to see side menu shown in the second figure below.
After performing login by the admin the admin will be able to see side menu
shown in the figure below.

User can select the particular section and can perform the respective task. There is an option to add the
jobs for the company where the companies can add the vacancies for their companies they have.
3.2 Hardware Interfaces :-
Since the mobile application does not have designated hardware, it does not have any
hardware interface. The hardware connection between the database server and application is
managed by the underlying operating system on the mobile phone.

3.3 Software Interfaces :-

The system is self-contained and no data is supposed to share with the third party. The
communication of the mobile application between the database consist of both reading and
modifying the data, while the communication between the database and the mobile application
consists of only reading operation.

3.4 Communications Interfaces :-

The communication between the different parts of the system is important since they depends on
each other. However, in what way the communication is achieved is not important for the system
and is therefore handled by the underlying operating system for the mobile application.
 System Features
4.1 System Feature and Priority Matrix :-
Following given is the system features and their priority matrix:
4.2 Functional Requirements :-
Following table describes the functional requirement:
Other Nonfunctional Requirements
5.1 Performance Requirements :-
1. The completely separate business logic at admin side from the student
interface ensures good performance.
2. The system exhibits high performance because it is well optimized. The
business logic is clearly separate from the UI.
3. System should be able to scale to many users concurrently.
4. The response time of processes is as follows:
Student Registration max 10 seconds
Company Registration max 15 seconds
Company Job posting max 15 seconds
Student applying for job max 20 seconds
5. System is available 24 by 7.
5.2 Safety Requirements :-
1. Errors will be minimized and an appropriate error message that guides the
user from an error will be provided.
2. Validation of users input is highly essential.
3. The time taken to recover from the error is less than 10 second.

5.3 Security Requirements :-

1. The system is provided a high level of security and integrity of the data
held by the system.
2. Only authorized personnel such as admin can gain access to the to the
private data and only the user with valid username and password is allowed
to view its user page.
5.4 Software Quality Attributes :-
1. The key software quality attributes are Availability, Reliability and usability.
2. As the system is expected to be 24/7 working. High availability is important.
3. A simple but quality user interface is developed to make it easy to understand
and required less training.
4. The error message displayed is more descriptive and can be easily understood.

5.5 Business Rules :-

1. System shall be available only for the particular college.
2. All the users shall access the system using a login/user-id and password. The
login-id/password will be managed in a secured manner.
3. Each student can get recruitment only in one company.
4. Once company selected the candidate, it cannot be rejected otherwise
company will be blacklisted.
5. Each student can have only one account.