Assume that you are assigned responsibility of developing an Online Admission System (OAS)for a University.

Assume that you are assigned responsibility of developing an  Online Admission System  (OAS)for a University. OAS  will have  all necessary fields that are essential for obtaining necessary  information from the applicant, scrutiny, and recommending  admission. After Application Form for Admission issubmitted, the  data in the    various needs to be validated by OAS regarding  eligibility, existence of PINCODE etc. Appropriate e-mail should be  sent to student acknowledging the submission of admission form  online. Make necessary assumptions.

For developing OASas specified above,

SRS of Online Admission System of University

1.    Introduction

1.1    Purpose

The Purpose of this document is to describe the Student Admission and Tracking System which will be used to automate the student admission process and other forms that the student submits for a particular request. It will also allow in the management of various programs that are offered by the ISE department. This Application’s Overall purpose is to make the student admission process and other form processing easier and also help manage programs offered by this department more efficiently. This document defines and describes the operations, interfaces, performance, and quality assurance requirements of the Student Admission and Tracking System.

1.2    Document Conventions

SATS – Student Admission and Tracking System

1.3    Intended Audience and Reading Suggestions

This document is intended for, developers, project managers, users, testers, and documentation writers. Rest of the document describes the software in more detail. This document is divided into the following sections:

·         the overall description section where, the perspective of the product, its features, user constraints, operating environment and  design and implementation constraints are described. 

·         System features, where major system features are described.

·         External interface requirements including, user Interfaces, hardware interfaces, software interfaces and communication interfaces are described.

1.4    Project Scope

SATS will be used to fully automate the student admission process. It will allow the faculty members and department coordinators to make the decision online without going through the traditional paper work. The system administrator will be able to manage the staff and the programs offered in the department online through this application by fully automating the process.

1.5    References

·         Use case Diagrams

·         Use case Descriptions

2.    Overall Description

2.1    Product Perspective

The applications is designed to automate the existing paper based student admission system and the overall staff management system in the ISE department of George Mason University. This the first time an automate student, staff and program management system will be used in the ISE department. This is intended to minimize the delay in the paper process and also in the better management of student, staff and program‘s records.

2.2    Product Features

ISE department offers two Masters programs and 5 certificate programs. The system will provide features to automate the student’s admission process into these programs. It will allow the students to fill various forms online and also allow faculty members and coordinators to make the decision online. The system will provide features to automate the process to create/update/delete various programs in the department. The system will provide a way to manage the staff and the decision committee in various programs offered by the department.

2.3    User Classes and Characteristics

The various user classes that will be using this product are:

Students: this class of users will be using the system to fill various forms and place requests.

Since the users will be applying for higher studies in the field relate to computers, they will have a basic knowledge and experience with various web based applications. Since filling the forms does not require much technical expertise it will be very easy for this class of users to use the sytem.

Faculty Members/ Department Coordinators: Faculty members and department coordinators will be having a good knowledge of the computer systems and also the operating environment in which these systems are working in the department. In order to use the system, the faculty members should be familiar with various form processes.

System Coordinator: The system administrator, which will be one of the department members, should be familiar with the department structure and functioning of the department. He/she must also be very well familiar with all the process in the department.

2.4    Operating Environment

The application can be run on desktop computers provided to the faculty and staff using internet explorer 5.0/higher or Netscape 5.0 or higher. The application run on the university tomcat server which a unix based environment. The application will be interacting with a backend database system, in this case an oracle server installed on the department computer system. The desktop computer from which the application is accessed should be running on windows 2000 or XP environment and the servers should be running on unix environment.

2.5    Design and Implementation Constraints

The system should be developed using tomcat server and oracle as a backend database. This is because the ISE department uses tomcat as the web server and oracle for the database. The faculty members and system administrators will be able to maintain the system efficiently as they are already experienced in it. Since tomcat server is used so the web pages should be designed as Servlet of JSP pages using Java as the programming language. Windows based environment should be used for documentation. Rational rose should be used to develop the design and analysis models for the system. After the system is deployed the department will be responsible for maintaining it.

2.6    Assumptions and Dependencies

If the user decides to change the database from Access to oracle or mysql. Then the following need to be done in order for the product to work

·         Change the database connection string wherever database is accessed

·         Tables and column names should be same as  used in the Access database

3.    System Features

This section describes the functional requirements of the system. This is organized into three major categories based on the users and various services provided for each of them. The categories are: Student features, faculty/Coordinator features, System Administrator features.

3.1    Student Features

These are the various Features provided for the Students of ISE department

3.1.1   The System shall allow the students to request the change in degree requirement courses

3.1.2   The System shall allow the students to request for change of degree

3.1.3      The System shall allow the students to request for transfer of credits from another institution or GMU non degree courses.

3.1.4      The System shall allow the student to request a plan of study for his/her Master’s degree program. (in this case SWE and IS).

3.1.5      The System shall allow students to fill in the self evaluation form online and store in their records for all the available master and certificate programs that the student is enrolled in. ( in this case SWE, IS, EC certificate, Information security certificate, SWE certificate, information engineering certificate.)

3.1.6      The system shall allow the student to request for a change in change his/ her academic status.

3.1.7      The System shall allow the student to request to take courses elsewhere outside GMU.

3.2  Faculty/Coordinator Features     

3.2.1      The System shall allow the faculty (Student Advisor) to Accept or reject change in degree requirement courses requested by a student.

3.2.2      The System shall allow the Department Coordinator to Accept or reject Change of degree requested by a student

3.2.3      The System shall allow the faculty to accept or reject the students request to transfer credits from another institution or GMU non degree.

3.2.4      The system shall allow the department coordinator to verify the decision taken by the faculty member on student’s request to transfer credits and accept or reject it.

3.2.5      The system shall allow the Department Dean to verify the decision taken by the faculty member and the department coordinator on student’s request to transfer credits and accept or reject it.

3.2.6      The System shall allow the faculty member (student advisor) to accept or reject the plan of studies requested by the student.

3.2.7      The System shall allow the Department Coordinator to accept or reject student’s self evaluation for a program and suggest any required courses to be taken.

3.2.8      The system shall allow the Faculty member to accept or reject change in academic status ( drop any course after the last day to drop courses is over) requested by a student.

3.2.9      The system shall allow the Faculty member (Student’s Advisor)  to accept or reject the student’s request to allow him/her to take courses elsewhere outside GMU.

3.2.10   The System shall allow the Department Coordinator to verify the decision taken on Student’s request to take courses elsewhere by faculty member and accept or reject it.

3.2.11   The system shall allow the Department Dean to verify the decision taken on the Student’s request to take courses elsewhere by faculty and department coordinator and accept or reject it.

3.2.12   The system shall allow the Faculty member to review the student’s application for admission into a program and comment on it.

3.2.13   The system shall allow the Department coordinator to review the comments made by the faculty member on an applicant’s application and accept or reject him/her into the program requested.

3.2.14   The system shall allow the faculty member and department coordinator to view the applicant’s image files such as the transcripts and recommendation letters etc.

3.3       System Administrator Features

3.3.1      The System shall allow the system administrator to create student’s application by entering the information given by the student in the admission application into the database

3.3.2      The System shall allow the system administrator to create a student user.

3.3.3      The system shall allow the system administrator to create a staff user (including faculty member, department coordinator and a Department chair and associate dean)

3.3.4      The system shall allow the system administrator to store applicant’s image files consisting of the applicant’s transcripts, recommendation letters etc.

3.3.5       The system shall allow the system administrator to find a particular user in the SATS database.

3.3.6      The system shall allow the system administrator to update user information or deactivate a user from SATS database.

3.3.7      The System shall allow the system administrator to update/modify student’s information.

3.3.8      The system shall allow the system administrator to update foundation courses for a program

3.3.9      The system shall allow the system administrator to create a new degree program in the department

3.3.10   The system shall allow the system administrator to update the existing degree program in the department.

3.3.11   The system shall allow the system administrator to create or update guidelines for standardized tests such as GRE, TOIFEL

3.4       General Features

3.4.1      The system shall allow the a decision letter to be generated when a decision is made on an application or form submitted by a student.

3.4.2      The system shall run pending reports when ever a student makes a request form or when a form accepted by a staff member has to passed on to another staff member for a decision.

3.4.3      The system shall allow a person to log into the SATS and depending on the user type, appropriate menu is displayed.

4.    External Interface Requirements

4.1    User Interfaces

The following are the guidelines to be followed in designing user interface for the web pages.

• Horizontal green bar on the top
• Link to George Mason University main page
• Link to ISE main page
• Title of the page (centered, Title case, Dark Green colored, size <h3>
• Font – Arial, 2pt(size), black,
• Copy rite in the bottom of the page

Ø  for an example template please refer to the Sats_template.html

4.2    Software Interfaces

Software will be developed on the windows 2000 and windows xp environment. Members of the project team have experience with J2EE based web technologies, Access/Oracle Database and UML/Visio tools. ISE department, which is the customer of the software also uses Tomcat server, which is the java based web sever and oracle as the backend database. Based on the experience and knowledge of the development team, and the requirements of the customer, following technologies will be used in the software development.

Software	Version
Rational Rose	2000
Access	2000
JDK	1.3
ODBC
Visio	2000
Tomcat	4.2
Oracle	8i
Forte (sun one studio)
Dreamweaver	MX
Homesite	MX

Appendix A: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams.>

Appendix C: Issues List

< This is a dynamic list of the open requirements issues that remain to be resolved, including TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.>