Software Requirement Specification 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. Scope of Project The Placement System is used to grade multiple-choice content 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 computer. It must also provide the information regarding which companies 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. 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 ( t h e c u s t o m e r s ) . 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 . T h e s e c o n d i s a l i s t o f a l l t h e c o n s t r a i n t s o n a n d f u n c t i o n s performed by the system in full detail to define the product fully for the software developer. The two lists of functions are crossreferenced to allow easy comparison. Overall Description: 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 y s 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 Placement System (PS) 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 put on disk and delivered physically to the Registrar for uploading to the University Database System Environment 2.2. Functional Requirements Definition Functional Requirements are those that refer to the functionality of the system, i.e., what services it will provide to the user. Non-functional (supplementary) requirements 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, this module should Cover all activities beginning from pre-placement talks, interviews, automated CV generation, and other placement activities

Survey Description The Administrator uses the Initialize (not shown) to clear the current database for a new mester. S/he uses Access directly to update academic m a j o r s , p l a c e m e n t recommendations, test versions and answer keys. The Administrator uses Load Data File to add/update a file of semester C R N ' s w i t h course information, instructors and companies. The Administrator uses Load Student to add/update a file of persistent (non-testing) 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 studentsin the database. The Administrator uses Archive (not shown) to store one years s t u d e n t s b e f o r e initializing for the next year.

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 yearsstudents.1. The Administrator selects New from the File menu.2. The system reports completion 2.4. Non-Functional Requirements 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 ( atmost 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 3.3. Detailed Non-Functional Requirements 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 see section 2.4. Software Standard: Every function will have a cancel option if logically permissible. Cancel will restore to a previous safe system state. Network Interface: Need access to Tiger for FTP and Telnet capabilities.

Code Standards: Each code module fully documented using departmental standards