22-03-2011, 11:54 AM
[attachment=10725]
1. Introduction
1.1 Purpose
The purpose this documents is to present a detailed description of the Student Result
Management System. It will explain the purpose and features of the software, the
interfaces of the software, what the software will do, the constraints under which it must
operates and how the software will react to external stimuli. This document is intended
for both the end users and the developers of the software.
1.2 Document Conventions
To develop the SRS on Student Result Management System we have used IEEE format
SRS, Font size is 12, Font type is Times New Roman.
1.3 Intended audience and Reading Suggestions
The intended audiences for this document are:
• The developers of the project
• The Lecturers who is the client
• The Programmer who are going to implement the software
This document will be reviewed frequently by the above audience to check if the different phases of he project are being completed by meeting the given requirement.
1.4 Project Scope
This document covers the requirements for the Student Result Management System. This
software will provide a graphical environment in which the users of the system will be
able to perform various operations that are associated with storing, marinating, updating
and retrieving Student information. The purpose of this is to guide developers in selecting
a design that will be able to accommodate the full-scale application.
1.5 References
An Integrated Approach to Software Engineering Approach - Pankaj Jalote
Software Engineering A Practitioner’s Approach - Roger S Pressman
2. Overall Description
2.1 Product Perspective
The product Student Result Management system, is an independent product
and does not depend on any other product or system. The product will automate various tasks associated with handling student details and better organizing the stored information and optimum performance, thus helping the Colleges to ensure smooth working of these processes.
2.2 Product Features
The product, SDMS will automate various tasks associated with handling student details. The software will be used by office personnel to store the details of the admission forms of the enrolled students. Periodically it will be used by the office personnel to input the marks and attendance information after internal or end semester exams. He software inherently makes automatic calculations on marks and attendance. And all this information is accessible to administrators and teaching staff to keep track of their student’s progresss. Also the software has a provision that will allow end users to print the required reports of various student statistics.
2.3 User Classes and Characteristics
This software gives access to 2 kinds of users.
1. Administrator: The personnel and College administrator will have administrator access to add, delete and modify information stored in the database.
2. Authorized User: Teaching staff will have access to only view the data stored in the database in the form of formatted reports.
2.4 Operating Environment
2.4.1Software Components
• Product will only run on a computer with Windows Operating System
• Product will have to be configured to connect to the centralized database
• The required software’s has to be installed to run the software
• All data is stored in and retrieved from a centralized database
2.4.2 Hardware Components
• Product will run on a Pentium or AMD based desktop
• Product will run on a computer with at least 128MB RAM and 40GB hard disk
• Printer has to be installed on the machine to print reports
• The machine will have to be a part of the College LAN to access the centralized database.
2.5 Design and Implementation Constraints
This software provides security. The login form prevents the system from being misused by unauthorized users. Only an authorized operator will be granted rights to modify as per requirements. This software is also reliable and fault tolerant. The system developed is designed to handle invalid inputs. Since reliability is major area of concern the system has a backup to avoid data loss. The user should know the programming language very well that is used to develop a software.
2.6 User Documentation
In order to help the client extra documentation components like user manual, on-line help and tutorials will be delivered along with the software.
2.7 Assumptions and Dependencies
• We assume that the Office personnel do all the data entry based n the correct values obtained from forms and registers.
• We assume that the computers that will use the software will be part of the college LAN.
• Users with administrator access should be careful in deleting or modifying any information knowingly or unknowingly which will lead to inconsistency of the database.
• The end users of this software are assumed to have basic level of computer knowledge i.e point and click .
3.System Features
Login
3.1.1 Description and Priority
The login form is used all the users. This module has the highest priority when compared to all the other modules.This model allows the the user to enter his username and password in order to make use of the software.
3.1.2 Stimulus/Response Sequences
This module has text boxes where the user can enter the his username name and password.If the necessary information is not provided or if invalid inputs are given by the user then the system will pop a message box.
3.1.3 Functional Requirements
Only authorized users are allowed to login. The authorized users are the bank
administrator, deposit officer, loan officer and the other banking staff. If invalid user
name or password is given by the bank the system should inform the user. If
unauthorized users try to access then it should nit allow the user to work on the
system.
3.2 Data Entry module
3.2.1Description and Priority
This module is used by data entry operator who is responsible for entrying the details of a student.The module requests that the Data entry Operator specify the function he/she would like to perform(either Add a student,update a student, or delete a student details).
3.2.2 Stimulus/Response Sequences
Once the Data entry Operator provides the requested information , one of the sub-flows is executed.
• “Add a student” sub flow
• “Update a student” sub flow
• “Delete a student” sub flow
3.2.3 Functional Requirements
In “Add a student” Once the Data entry operator provides the requested information , the student is added to the system and an appropriate message is displayed
In “Update a student” Once the Data entry Operator updates the necessary information ,the system updates the student record with the updated information
In“Delete a student” Once the Data entry operator deletes the record, the system prompt s the user to confirm the deletion of the student.
3.3 Marks Entry Module
3.3.1Description and Priority
This module allows the Marks entry operator to add, delete or modify the student information from the system
3.3.2 Stimulus/Response Sequences
The system requests the Marks entry clerk to specify the function she/he wuld like to perform(either Add Marks,Update marks,Delete Marks and Generate Report).
3.3.3 Functional Requirements
In “Add Marks” Once the Marks entry clerk provide the requested information , the system saves the marks and an appropriate message is displayed
In “Update Marks” the Marks entry operator makes the desired changes to the marks details and at the same time the database will save the changes that are made by the Marks entry operator.
In “Delete Marks” if the clerk wishes to proceed with the deletion of the record on click of this the record is deleted from the system
In “Report generation” the computed result of a particular student is displayed
1. Introduction
1.1 Purpose
The purpose this documents is to present a detailed description of the Student Result
Management System. It will explain the purpose and features of the software, the
interfaces of the software, what the software will do, the constraints under which it must
operates and how the software will react to external stimuli. This document is intended
for both the end users and the developers of the software.
1.2 Document Conventions
To develop the SRS on Student Result Management System we have used IEEE format
SRS, Font size is 12, Font type is Times New Roman.
1.3 Intended audience and Reading Suggestions
The intended audiences for this document are:
• The developers of the project
• The Lecturers who is the client
• The Programmer who are going to implement the software
This document will be reviewed frequently by the above audience to check if the different phases of he project are being completed by meeting the given requirement.
1.4 Project Scope
This document covers the requirements for the Student Result Management System. This
software will provide a graphical environment in which the users of the system will be
able to perform various operations that are associated with storing, marinating, updating
and retrieving Student information. The purpose of this is to guide developers in selecting
a design that will be able to accommodate the full-scale application.
1.5 References
An Integrated Approach to Software Engineering Approach - Pankaj Jalote
Software Engineering A Practitioner’s Approach - Roger S Pressman
2. Overall Description
2.1 Product Perspective
The product Student Result Management system, is an independent product
and does not depend on any other product or system. The product will automate various tasks associated with handling student details and better organizing the stored information and optimum performance, thus helping the Colleges to ensure smooth working of these processes.
2.2 Product Features
The product, SDMS will automate various tasks associated with handling student details. The software will be used by office personnel to store the details of the admission forms of the enrolled students. Periodically it will be used by the office personnel to input the marks and attendance information after internal or end semester exams. He software inherently makes automatic calculations on marks and attendance. And all this information is accessible to administrators and teaching staff to keep track of their student’s progresss. Also the software has a provision that will allow end users to print the required reports of various student statistics.
2.3 User Classes and Characteristics
This software gives access to 2 kinds of users.
1. Administrator: The personnel and College administrator will have administrator access to add, delete and modify information stored in the database.
2. Authorized User: Teaching staff will have access to only view the data stored in the database in the form of formatted reports.
2.4 Operating Environment
2.4.1Software Components
• Product will only run on a computer with Windows Operating System
• Product will have to be configured to connect to the centralized database
• The required software’s has to be installed to run the software
• All data is stored in and retrieved from a centralized database
2.4.2 Hardware Components
• Product will run on a Pentium or AMD based desktop
• Product will run on a computer with at least 128MB RAM and 40GB hard disk
• Printer has to be installed on the machine to print reports
• The machine will have to be a part of the College LAN to access the centralized database.
2.5 Design and Implementation Constraints
This software provides security. The login form prevents the system from being misused by unauthorized users. Only an authorized operator will be granted rights to modify as per requirements. This software is also reliable and fault tolerant. The system developed is designed to handle invalid inputs. Since reliability is major area of concern the system has a backup to avoid data loss. The user should know the programming language very well that is used to develop a software.
2.6 User Documentation
In order to help the client extra documentation components like user manual, on-line help and tutorials will be delivered along with the software.
2.7 Assumptions and Dependencies
• We assume that the Office personnel do all the data entry based n the correct values obtained from forms and registers.
• We assume that the computers that will use the software will be part of the college LAN.
• Users with administrator access should be careful in deleting or modifying any information knowingly or unknowingly which will lead to inconsistency of the database.
• The end users of this software are assumed to have basic level of computer knowledge i.e point and click .
3.System Features
Login
3.1.1 Description and Priority
The login form is used all the users. This module has the highest priority when compared to all the other modules.This model allows the the user to enter his username and password in order to make use of the software.
3.1.2 Stimulus/Response Sequences
This module has text boxes where the user can enter the his username name and password.If the necessary information is not provided or if invalid inputs are given by the user then the system will pop a message box.
3.1.3 Functional Requirements
Only authorized users are allowed to login. The authorized users are the bank
administrator, deposit officer, loan officer and the other banking staff. If invalid user
name or password is given by the bank the system should inform the user. If
unauthorized users try to access then it should nit allow the user to work on the
system.
3.2 Data Entry module
3.2.1Description and Priority
This module is used by data entry operator who is responsible for entrying the details of a student.The module requests that the Data entry Operator specify the function he/she would like to perform(either Add a student,update a student, or delete a student details).
3.2.2 Stimulus/Response Sequences
Once the Data entry Operator provides the requested information , one of the sub-flows is executed.
• “Add a student” sub flow
• “Update a student” sub flow
• “Delete a student” sub flow
3.2.3 Functional Requirements
In “Add a student” Once the Data entry operator provides the requested information , the student is added to the system and an appropriate message is displayed
In “Update a student” Once the Data entry Operator updates the necessary information ,the system updates the student record with the updated information
In“Delete a student” Once the Data entry operator deletes the record, the system prompt s the user to confirm the deletion of the student.
3.3 Marks Entry Module
3.3.1Description and Priority
This module allows the Marks entry operator to add, delete or modify the student information from the system
3.3.2 Stimulus/Response Sequences
The system requests the Marks entry clerk to specify the function she/he wuld like to perform(either Add Marks,Update marks,Delete Marks and Generate Report).
3.3.3 Functional Requirements
In “Add Marks” Once the Marks entry clerk provide the requested information , the system saves the marks and an appropriate message is displayed
In “Update Marks” the Marks entry operator makes the desired changes to the marks details and at the same time the database will save the changes that are made by the Marks entry operator.
In “Delete Marks” if the clerk wishes to proceed with the deletion of the record on click of this the record is deleted from the system
In “Report generation” the computed result of a particular student is displayed
