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,
1.
Introduction
1.1
Purpose
1.2
Document
Conventions
1.3
Intended
Audience and
1.4
Project
Scope
1.5
References
2.
Overall
Description
2.1
Product
Perspective
2.2
2.3
User
Classes and Characteristics
2.4
Operating
Environment
2.5
Design
and Implementation Constraints
2.6
Assumptions
and Dependencies
3. System Features
3.1
Student
Features
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.2.1 The
System shall allow the faculty (Student Advisor) to Accept or reject change in
degree requirement courses requested by a student.
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.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.
4. External Interface Requirements
4.1
User
Interfaces
4.2
Software
Interfaces
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
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
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
- 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
|
<Optionally,
include any pertinent analysis models, such as data flow diagrams, class
diagrams, state-transition diagrams, or entity-relationship diagrams.>
< 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.>
This blog is really helpful to deliver updated affairs over internet which is really appraisable. Staff management system
ReplyDelete