1.

INTRODUCTION:
1.1. Purpose
This Software Requirements Specification provides a complete description of all the
functions and constraints of the Training and Placement System, developed for the
college training and p l a c e m e n t c e l l . T h e e x p e c t e d a u d i e n c e o f t h i s d o c u m e n t
i n c l u d e s f a c u l t y m e m b e r s i n t h e Department of T.P.O., the software developer and
students needing placements in campus.
1.2. Scope of Project
T h e Tal e n t Ac q u i s i t i o n O n l i n e P o r t a l i s u s e d t o g r a d e m u l t i p l e - c h o i c e
c o n t e n t e x a m i n a t i o n s g i v e n t o a l l incoming freshmen in the college. Based on test
results, the system makes recommendations for course placement and produces a number
of different reports for various campus stakeholders. The system is designed replace a
previous system created and used manually by T.P.O. staff. The previous system has proved
very valuable for its intended purpose but has an awkward user interface, requires
programming to make minor changes and relies on the academic mainframe
c o m p u t e r. I t m u s t a l s o p r o v i d e t h e i n f o r m a t i o n r e g a r d i n g w h i c h c o m p a n i e s
h a d v i s i t e d t h e campus or are going to visit, with their complete required
information. It must also be used to retrieve the information regarding students which are
eligible for placements. The revised system must have at least all the functionality of
the previous system with some noted problems corrected and an enhanced ability to
easily produce new reports on demand.
1.3. Overview of Document
This document contains two descriptions. The first is designed to be understandable
to faculty m e m b e r s i n t h e D e p a r t m e n t o f p l a c e m e n t c e l l . I t l i s t s a l l t h e
f u n c t i o n s performed by the system and the constraints under which it is to operate.
Included are screen f o r m a t s f o r t h e u s e r i n t e r f a c e .
2. OVERALL DESCRIPTION:
1

The Placement System utilizes information from the College Database and from a Test
Scanner t o a c c o m p l i s h i t s g o a l . C o m m u n i c a t i o n i s c u r r e n t l y t h r o u g h t h e f i l e
s ys t e m o f t h e C o l l e g e Academic Computer (Tiger). Most printing is done with
the local file system but very large reports are printed remotely on Tiger.
2.1. System Environment
The Talent Acquisition Online Portal is embedded in a larger system involving several College
systems. In this section, we describe this environment. The PS Administrator requests CRN data
files and freshmen data files from the College Database when needed. These are sent in text
format to the pre-test account on Tiger (Remote File System). Student answer sheets and other
information are scanned and a text file with the test answers is sent to the pre-test
account on Tiger. (This file must then be converted into a standard text file format on Tiger.)
The Administrator uses FTP to move these files to the file system of the PC (Local File
System) where the Placement System software is located. All grading and report generation
is done on this PC with reports in text files stored in its file system. Most reports are
printed on a printer networked directly with this PC. One large file is sent via FTP
to Tiger, formatted there, and printed on the printer attached to T i g e r. O n e f i l e i s
p u t o n d i s k a n d d e l i v e r e d p h ys i c a l l y t o t h e R e g i s t r a r f o r u p l o a d i n g t o t h e
University Database System Environment

2.2. Product Perspective

Functional Requirements are those that refer to the functionality of the system, i.e., what services
i t w i l l p r o v i d e t o t h e u s e r. N o n - f u n c t i o n a l ( s u p p l e m e n t a r y ) r e q u i r e m e n t s
p e r t a i n t o o t h e r information needed to produce the correct system and are detailed
separately. For complete management of the Placement Cell enabling the placement officer,
Students and the potential employer to seamlessly interact.

2.2.1. Survey Description

2

 The Administrator uses the Initialize (not shown) to clear the current database for a new master.
They uses access directly to update academic majors, placement recommendations, test versions
and answer keys.
The Administrator uses load data file to add/ update a file of semester CRNs with course
information, instructors and companies.
The Administrator uses Load Student to add/update a file of persistent (nontesting) student information to the System.
The Administrator uses Load Test File to add a file of student test data to the System.
The Administrator uses Report Session to generate test results for all students since
the last session was reported.
The Administrator uses Create General Reports to generate various reports on all students in the
database.
The Administrator uses archive (not shown) to store one years students before initializing for
the next year.

2.2.2. Brief Description

The system is prepared for use for an academic year. Usually done in June when the previous
group of freshmen has become sophomores. Initial Step-By-Step Description Before this use
case can be initiated; the Administrator has already archived any previous years students.
1. The Administrator selects New from the File menu.
2. The system reports completion.
2.3. Non-Functional Requirements
3

These are requirements that are not functional in nature, that is, these are
constraints within which the system must work. The program must be self-contained so that it
can easily be moved from one PC to another. It is assumed that Access will be available on the
PC on which the program resides. It is not required that a Visual language be available on that
computer. The database must be small enough when it holds an entire class to be held on one
3.5 disk (at most 1.4 megabytes). This is for backup purposes and for transportability. The
Archive database may be a separate database for size considerations. It will not have to hold
more than four years of student records. The program must be efficient. We require that any
operation other than report generation must be completed with five minutes 100% of the
time. Within any operation, responses to an entry must be done within 15 seconds
100% of the time. Report printing for the session reports must b e c o m p l e t e d w i t h
15 minutes 100% of the time. Report printing for other reports must be
completed within 1 hour 100% of the time.

3. USER INTERFACE SPECIFICATION:

The anticipated users are faculty members in the Department at the College. They have account
son Tiger with which they are familiar. They are familiar with using FTP to move files. They are
comfortable with the concept of a database and will need minimal training to utilize the Access
features to update persistent information about courses, majors and faculty. The system will
have a standard Windows type interface with pull-down menus on a top menu bar and
buttons and text boxes for communications.
These interfaces help the administrators with all the transactional states like Data insertion, Data
deletion and Data updation along with the extensive data search capabilities.

3.3. Detailed Non-Functional Requirements

4

The system should be designed in as a secured system applying security measures.

Special exception handling mechanism should be in place to avoid system errors.

Should be capable of giving access to concurrent users without degrading the system
performance and accept answers.

Sessions of each user should be synchronized with server and duration calculations
should be done according to the server time.

3.4. Hardware/ Software Interface

Hardware: IBM compatible Pentium-based PC with standard or better keyboard, mouse and
monitor. Color monitor is assumed but not required. At least 2M of available disk
memory.
Operating System: Windows that can support Access version used.
Software Needed: Access 98 needed. Visual interface provided by executable file.
Performance: No noticeable delays in performance.
Software Standard: Every function will have a cancel option if logically permissible. Cancel will
restore to a previous safe system state.
Code Standards: Each code module fully documented using departmental standards.

3.4. Product Functions

The proposed system is a web based application and maintains a centralized repository of all the
necessary information. The system allows students to access details of recruitments. The system
allows students to access any recruitment related queries prior before the drive. Recruiters can
access the student details. It is easy for one to access desired information through the welldefined interfaces.
5

4. FUNCTIONAL REQUIREMENTS:
4.1. Description

The systems objectives outlined during the feasibility study serve as the basic from which
the work of system design is initiated. Much of the activities involved at this stage are of
technical nature requiring a certain degree of experience in designing systems, sound
knowledge of computer related technology and through understanding of computers
available in the market and the various facilities provided by the vendors. Nevertheless, a
system cannot be designed in isolation without the active involvement of the user.

The user has a vital role to play at this stage too. As we know that data collected during
feasibility study will be utilized systematically during the system design.

4.2. Criticality

It should, however be kept in mind that detailed study of the existing system is not
necessarily over with the completion of the feasibility study. Depending on the plan of
feasibility study, the level of detailed study will vary and the system design stage will
also vary in the amount of investigation that still needs to be done. This investigation is
generally an urgent activity during the system.

Sometimes, but rarely, this investigation may form a separate stage between feasibility
study and computer system design. Designing a new system is a creative process, which
calls for logical as well as lateral thinking.

4.3. Technical issues

Several development activities are carried out during structured design. They are database
design, implementation planning, system test preparation, system interface specification, and
user documentation.
6

Database Design: This activity deals with the design of the physical database. A key is to
determine how the access paths art to be implemented. All the attributes of students and
company are to be inserted in the database with proper checks and validations.

Program Design: In conjunction with database design is a decision on the programming

language to be used and the flowcharting, coding, and debugging procedure prior to
conversion. The operating system limits the programming languages that will run of the
system. Programming is done in notepad and eclipse.

System and program test preparation: Each aspect of the system has a separate test
requirement. System testing is done after all programming and testing completed the test
on system and program test requirements become a part of design specifications a
prerequisite to implementation.

5. COST:
It is desirable to aim for a system with a minimum cost subject to the condition that it must
satisfy all the requirements. As our system is made of all the softwares that are generally open
source.

6. RISKS:
The only risk with this system is the failure of database. Though system is designed scalable, but
sometimes the SQL server may crash. So, the backup of the database is must.

7. DEPENDENCIES WITH THEIR OTHER REQUIREMENTS:

The server should be automatically started.

The passwords of database should be same as given at the time of installation.