System Requirement Specification |
Study Center Allocation System |
NOTE: This is a overview of SRS for SCAS, Please change according your own thought and Analysis capacity |
1 Introduction:
Study center allocations are a vital part of any university’s running because students are what keep a University alive. For all things, it is necessary that one get much educated about online admission process and this is only possible when they will choose best system for admission.
1.1 Purpose
The purpose of the system to provide online admission + Study center allocation facility to campus, off-campus, enter state or a student from anywhere in the world. Study Center Allocation System supports the student admission, selecting various courses, entering academic data and fees payment. Database maintained by this system usually contains the student’s personal, academic and its fee related information. It focuses on storing and processing using web pages.
1.2 Scope
As per our discussion with Ignou Managers, They are talking about their manual process of Study center allocation. Today all the work at the time of SCAS of the students is done manually in branch office and head office, which is slow and consuming much efforts and time, and Student can’t request for Study center online. It is required to Design of Study Center Allocation System, to speed up and make it easy to use system from anywhere.
· University can approach to the geographically scattered students.
· Trace all of the University Courses.
· Common interface on web accessed by everyone.
· Online admission forms along with online submission and fees payment.
· Central database having all information about candidates and courses with Study Centers.
· Preparation of merit list for each course.
· On each event all information is stored in central database controlled by authorized persons & online available for candidates.
1.3 Benefits
Benefit of a software system is the use of a central database and connect applicant online. This is a far more reasonable storage method than a paper-based file system, where the time of traveling to and physically searching the records for the required information could be a burden. Human error could also be a factor in that mistakes could be made in the filing process which would not occur in a well written database system and mistakes or changes on physical records can be messy to correct. Software systems are also much faster at performing certain tasks than humans, meaning that time can be saved performing processes. This also means that these tasks can be done solely by the system, freeing up those involved to perform more important tasks.
That is also beneficial for applicant who wants to apply for a course but not able to come in university. Study Center Allocation System will increase number of admissions in university.
2 Informative Description about the system
2.1 Information flow and features
This system having following product features:
i. Applicant can register and login.
ii. Applicant can search for courses.
iii. Applicant can choose and pay for selected courses.
iv. Applicant can check admission status.
v. Management has a panel login for editing data.
vi. Management can update/view details of courses and fees.
vii. Management can generate merit and update admission status.
2.2 NONFUNCTIONAL REQUIREMENTS
2.2.1 Performance Requirements
· A database which can perform and process minimum 10,000 records at a time.
· Software will support multiple user session at a time.
· Hosting server which can handle multiple process and db operations at a time.
2.2.2 Security Requirements:
· Some of the factors that are identified to protect the software from accidental or malicious access, use, modification, destruction, or disclosure are described below.
· Specific requirements in this area could include the need to: Utilize certain cryptographic techniques, Keep specific log or history data sets, Assign certain functions to different modules, Restrict communications between some areas of the program, Check data integrity for critical variables.
2.2.3 Portability Requirements:
· Some of the attributes of software that relate to the ease of porting the software to other host machines and/or operating systems.
2.2.4 Maintainability
· The user will be able to reset all options and all stored user variables to default settings.
2.2.5 Reliability
· All data storage for user variables will be committed to the database at the time of entry.
· Data corruption is prevented by applying the possible backup procedures and techniques.
2.2.6 Usability requirements
· A logical interface is essential to an easy to use system, speeding up common tasks.
· Error prevention is integral to the system.
· Logging errors for future enhancement and maintenance.
2.2.7 Availability
· All cached data will be rebuilt during every startup. There is no recovery of user data if it is lost. Default values of system data will be assigned when necessary.
2.2.8 Legal
· No legal action needed.
2.3 EXTERNAL INTERFACE REQUIREMENTS
2.3.1 User Interface
· The application that will be developing will have a user friendly and menu based interface.
· Login Panel with username and password inputs.
· There will be a screen which will be displaying the major tasks that the system will be performing i.e. Registration, Fees and Course details
· All the major tasks mentioned above will have their separate forms and will perform the desired actions.
2.3.2 Software Interface
· User Browser to access application : IE 9+, Firefox:22+, Chrome:22+, Safari 4+
· User Interface : Html/CSS
· Client Side Scripting : Java Script & Jquery
· Development OS : Windows 7 with service pack 2 or higher version
· Programming Language : C#
· Web Application : Asp.net framework 4.0
· IDE : Visual Studio 2013
· Database: MS-SQL 2012
· Server Deployment : Windows Server IIS 7.0 or above
2.3.3 Hardware Interface
2.3.3.1 Server
· Intel core i3 CPU
· 2.53 GHZ
· 2 GB Ram
2.3.3.2 Client
· Client system requirement will depend on browser application requirements.
3 Functional Description of the system
3.1 Functional Description
1) Registration of Student
2) Course selection
3) Fees processing
4) Administrator to Add/Edit/Delete basic services in portal.
5) Reports
3.2 Restriction/ Limitations
· Browser support IE 9+, Firefox 22+, Chrome 30+, Safari 4+
· System works in all platforms.
· Advanced techniques wouldn’t be able to check authorization.
3.3 Performance Requirements
· 256 kb/s or higher internet speed for client and server
· Database will able to process multiple process at a time
· Less graphic are used in user interface for better performance.
3.4 Design Constraints
Please insert a system diagram
4 SYSTEM DESIGN
4.1 LOGICAL DESIGN
4.2 PHYSICAL DESIGN
4.3 Modules Design
1) Admin Manager
a. Login in there panel.
b. They can change Courses and fees structure from admin panel.
c. They can view the registered Students and submitted fees.
d. They can update status of admission or confirm admission.
e. They can view different reports of students, courses and fees.
2) Students
a. Student can login to check status or to change details.
b. They can register themselves for courses and submit personal details and respective fees.
c. Students can choose various courses from online portal of university.
3) Security
a. Change the password
b. Forgot the password
c. Login
d. Student registration
e. Accept Student registration
f. Logout
4) Reports
a. View Course Information
b. View Fee details
c. View Student details
4.4 INPUT DESIGN
4.5 OUTPUT DESIGN
4.6 DATABASE DESIGN
4.6.1 TABLES
· PERSONAL DETAILS
Fields | Data type | Description |
Reg_Id | Varchar(50) | Registration ID, Auto Generate |
Name | Varchar(100) | Student Name, Required |
FatherName | Varchar(100) | Father Name, Required |
Age | Int(11) | Age |
Gender | Bit | Male – True, Female – False |
Religion | Varchar(100) | Hindu, Muslim, Sikh, Christian, Other |
DOB | Datetime | Student Date of Birth |
DTS | Datetime | Last Date of modification |
· User Table
Fields | Data type | Description |
Reg_Id | Varchar(50) | Registration Id from Personal Detail, Can be Empty for Admin users |
Username | Varchar(100) | Provided user name for login |
Password | Varchar(100) | Password to login |
Type | Int(11) | 1. Student 2.Admin |
· Course Table
Fields | Data type | Description |
Course_Id | Varchar(50) | Course Id, auto generated |
Course_Name | Varchar(100) | Name of course |
Course_Description | Varchar(200) | Course Description |
Fees | Decimal | Fees of course |
· Admission Table
Fields | Data type | Description |
Id | int | Unique Id, auto increment |
Reg_Id | Varchar(100) | Student Registration Id |
Course_Id | Varchar(200) | Selected Course ID |
Fees | Decimal | Fees for course |
Status | Int | 1.Accepted/2.Pending/3.Returned |
Status_Desc | Varchar(100) | Description of Status |
DTS | Datetime | Date and time of last modification |
5 Test and Validation
· We need to test the process eg: time taking to register a student, accessible from all browser, no messed up with user interface, validation of data should be proper in database and customer input.
· Performance of system can be increases by using various type of server, development language and frameworks, speed up internet connection.
· Online portal speed depends on number of users accessing system if this is not hosted on cloud and also related with internet speed.
· Project is defined as per plan and delivery of project is scheduled.
o Deadline of each modules are defined.
6 FUTURE ENHANCEMENTS
· System can be upgraded with new features.
· New Modules can be added.
· Security can be enhanced.
· New information can be added.
7 Conclusion
· It will be user friendly, and has required options, which can be utilized by the user to perform the desired operations.
8 Bibliography:
· IEEE Recommended Practice for Software Requirements Specification- IEEE STD 830-1993.
· Google, Wikipedia, Stackoverflow, Codeplex & youtube
