Software Requirement Specification

Software Requirement
Specification
Result Management System
Project Coordinator: Supriya Khaitan
Safeer Afaque
Roll No 0709013083
IT 2nd Year
Software Requirement Specification SRS
Software Requirement Specification

For
University Result Management System
1. Introduction
A university offers many courses and every course has many branches different colleges are
affiliated by the university these colleges provide students these course. Courses offered by
the colleges have examinations which are conducted by the colleges and the marks obtained
in various subjects are provided to the university. University maintains these records along
with college and student information. University publishes these results in newspapers and
other media. University records result in each semester, there are two semester in each
year. So a system is needed in such a way that it helps in maintaining the student
information such as Roll No, Name, Father’s Name, Course, Branch, Year of Admission and
should store result information such as paper code, semester, marks obtained and college
information such as college name and college code. Further there should be way to store
information of every subjects and their code for respective branches. All this data entries,
their modification should be governed by an authentication system which provides login ID
and passwords for different level of staff members. A Web Based Online System should also
be provided so that students and teacher can see the results.
1.1 Purpose
A university offers many courses and every course has many branches different colleges
are affiliated by the university these colleges provide students these course. Courses
offered by the colleges have examinations which are conducted by the colleges and the
marks obtained in various subjects are provided to the university. University maintains
these records along with college and student information.
1.2 Scope
The new system should provide these functionalities
 Issue Login ID and password to respective staff members who are responsible for
uploading and maintaining the student, college and results information.
 Maintain personal details of student.
 Maintain the list of colleges affiliated.
 Maintain the results of students semester by semester.
 Maintain the criteria for Carry over Papers and year backs.
 Maintain the list of subjects.
 Creating an online web portal from where students and teachers can check the
results.
Safeer Afaque Page 2

 Additional features such as result by branch wise or by college wise can be seen.
1.3 Definition, Acronym and Abbreviation
RMS: Result Management System

User: Any authorised user which are going through the login system.
LAN: Local Area Network
RAM: Random Access Memory
Student: Candidates who are pursuing courses from university, who are going to
access their result online.
System Administrator/Administrator: Authorized person who will logon through
login system and will have all privileges of the RMS.
Semester: Duration for which a student has to study (normally 20 weeks) before
appearing in the university examinations. There are two semesters in a year.
DBA: Database Administrator
Course: Degree Branch (UG or PG) as offered by the college.
1.4 References
(a) Software Engineering “A PRACTITIONER’S APPROACH FIFTH EDITION” by Roger
S. Pressman
(b) IEEE Recommended Practice for Software Requirements Specification IEEE 830
1.5 Overview
The rest of the SRS document describes various system requirements, interfaces,
features and functionalities in detail.
2. Overall Description
RMS Registers student for a Branch offered by the university through various colleges and a
list of colleges will also be maintained along with subjects in every branch along with their
codes and maximum marks. These above information can only be generated by
administrator or the person who is authorized by the system. Authorized person would have
to logon from a login form. And after each examination for a semester administrator will
receive list of students along with their marks and subjects, these information will be
uploaded in the system by the administrator over a LAN or locally. Once loaded these
information would be accessible across LAN or Internet through a WEB interface to students
and teachers. Further for other staff members there will be facility to generate reports and
access the records in read only mode.
Administrator will have following rights

 Maintain Personal Details of Student.
 Maintain the List of Colleges.
 Maintain the Results of Students Semester by Semester.
 Maintain the Criteria for Carry Over and Year Backs.
 Maintain the List of Subjects.
Staff Members
 Generate Reports Of Students.

 Generate Reports Of Results.

 Generate Reports Of Colleges.
 Generate Reports Of Subjects For Branches.
Students & Teachers
 Students can access their result from internet.

 Teachers can access results by college or branch wise.
2.1 Product Perspective
Proposed system will be developed on client/server architecture using Oracle 10g XE the
frontend for administrator and staff members will be developed by the help of oracles
inbuilt application builder. Database will be maintained centrally on a server and all the
other system on LAN will only have Oracle 10g Client Installed. Whereas front end for
students and teachers will be deployed on web server using JSP (Java Server Pages) which
would be connected to Oracle 10g XE database server.
Database
Front End Oracle Client ApplicationOracle Database Server

Web Server hosting JSP (Apache Tomcat)
2.1.1 System Interfaces

None
2.1.2 User Interfaces

RMS will have following user interfaces
 Login: To allow administrator and staff members enter the system.
 Student Details: To maintain student details
 College Details: To maintain college list
 Course Details: To add courses and their subjects
 Result: To Upload Results
Web portal for students should have following user interface

 Get Results By Roll No
 Get Result College and branch wise
2.1.3 Hardware Interfaces
 Screen Resolution Of 800 X 600 Or Above

 System should be in a networked environment
 Support For Printer

2.1.4 Software Interfaces
 Microsoft Windows 2000, XP or above

 Oracle 10g XE Database Server
 Apache Tomcat Web server
2.1.5 Communication Interfaces
 HTTP protocol
 TCP/IP protocol
2.1.6 Memory Constraints
 512 MB or more RAM (Depending upon the OS)

 More RAM will be required if Web server is hosted on the same machine
 500 MB or more disk space depending upon the size of database
2.1.7 Operations
None
2.1.8 Site Adaptation Requirement
 Client terminals should have Oracle 10g XE Clients Installed

 Requirements in section 2.1.3 should also be satisfied
2.2 Product Functions
RMS should provide the following facilities according to their authorization level
Administrator will have following rights

 Maintain Personal Details of Student.
 Maintain the List of Colleges.
 Maintain the Results of Students Semester by Semester.
 Maintain the Criteria for Carry Over and Year Backs.
 Maintain the List of Subjects.
Staff Members
 Generate Reports Of Students.

 Generate Reports Of Results.
 Generate Reports Of Colleges.
 Generate Reports Of Subjects For Branches.
Students & Teachers
 Students can access their result from internet.

 Teachers can access results by college or branch wise.
RMS will support following USE cases

Use Case Description

Login Login
Change Password
Student Details Add Student
Edit Student
Delete Student
View Student
Course Details Add, Edit, Delete Course
Add, Edit Delete Subjects
Add, Edit Delete Branches
College Details Add Colleges
Edit Colleges
Delete Colleges
View Colleges
Result Upload Results
Modify Results
View Results
Generate Reports Generate Student Report
Generate College Report
Generate Course Report
Maintenance Maintenance And Backup
Get Results Results By Roll No
Results By College
Results By Branch
2.3 User Characteristic

 Qualification: At least matriculation and comfortable with English.
 Experience: Should be well versed/informed about the registration process of the
university.
 Technical Experience: Elementary knowledge of computers
2.4 Constraints
 There will only be one administrator.

 The Modify and Delete operation is available only to the administrator.
 Staff Members can only generate reports the only have read only rights.
2.5 Assumptions & Dependencies
 The login Id and password must be created by system administrator and communicated
to the concerned user confidentially to avoid unauthorized access to the system.
2.6 Apportioning Of Requirement

None
3. Specific Requirement
This section contains the software requirements in detail along with the various screens to
be developed.
3.1 External Interface Requirement

3.1.1 User Interface
Following User Interface Will Be Provided By The System.
a. Login
Helps in logging in the system
Fields Are
User Name

Password
b. Student Details
This form will be accessible only to system administrator. It will allow him/her to
add/edit/delete/view information about new/existing student (s) for a particular year.
3.1.2 Hardware Interfaces
As stated in section 2.1.3
3.1.3 Software Interfaces
3.1.4 Communication Interfaces
c. Subjects
This form will be accessible only to user system administrator. It will allow him/her to
add/edit/delete/view information about new/existing paper(s) for the college.

d. Course
e. College Details

f. Result Upload

g. Web Page For Students And Teachers

3.2 Functional Requirement
3.2.1 Login
A. Use Case Description
1 Introduction
This use case documents the steps that must be followed in order to
log into the Result Management System
2 Actors
Administrator
Staff Members
3 Pre-Condition
The user must have valid login Id and password.
4 Post Condition
If the use case is successful, the actor is logged into the system. If not,
the system state remains unchanged.
5 Basic Flow
Starts when actor wishes to login onto the URS
i. The system requests that the actor specify the function he/she
would like to perform (either Login, Change Password)
ii. Once the actor provides the requested information, one of the
sub flows is executed.
 If the actor selects “Login”, the Login sub flow is executed.

 If the actor selects “Change Password”, the Change Password

sub flow is executed.
5.1 Login
(i) The system requests that the actor enters his/her login Id and
password information.
(ii) The actor enters his/her login Id and password.
(iii) The system validates the entered login Id and password and
allows the actor to enter into the system.
5.2 Change Password
(i) The system requests that the actor enters old password,
new password and confirm the new password information.
(ii) The actor enters old password, new password and confirm
the new password. information
(iii) The system validates the entered new password and
password change is confirmed.
6 Alternative flows
6.1 Invalid login Id/password
If in the Login sub flow, the actor enters an invalid

login Id and /or password or leaves the login name
and /or password empty, the system displays an
error message. The actor may choose to either
return to the beginning of basic flow or cancel the
use case. If the actor chooses to cancel the login use
case, the use case ends.
6.2 Invalid password
If in the Change Password sub flow, the actor enters

an invalid password or leaves the password (new
and confirm new) empty or the new and confirmed
new password does not match, the system displays
an error message. The actor may choose to either
return to the beginning of basic flow or cancel the
change password operation. If the actor chooses to
cancel the login use case, the use case ends.
7 Special Requirement
None
8 Associated use cases

None
B. Validity Checks
(i) Every user will have a unique login Id.

(ii) Login Id cannot be blank.
(iii) Login Id can only have 11 digits.
(iv) Login Id will not accept alphabetic, special and blank spaces.
(v) Password cannot be blank.

(vi) Length of password can only be 4 to 15 digits.
(vii)Alphabets, digits and hyphen & underscore characters are allowed
in password field.
(viii) Password will not accept blank spaces.
3.2.2 MAINTAIN COLLEGE DETAILS
1 Introduction
Allow administrator to maintain details of a College in the university. This includes
adding, updating, deleting and viewing College information.
2 Actors
Administrator
3 Pre-Conditions
The administrator must be logged onto the system before this use case begins.
4 Post-Conditions
If the use case is successful, the College information is
added/updated/deleted/viewed from the system. Otherwise, the system state is
unchanged.
5 Basic Flow
This use case starts when administrator wishes to add/edit/delete/view College
information
i. The system requests that the administrator specify the function he/she
would like to perform (either Add a College, Edit a College, Delete a
College or View a College)
ii. Once the administrator provides the requested information, one of the
sub flows is executed.
 If the administrator selects “Add a College”, the Add a College sub flow is
executed.
 If the administrator selects “Edit a College”, the Edit a College sub flow is
executed.
 If the administrator selects “Delete a College”, the Delete a College sub
flow is executed.
 If the administrator selects “View a College”, the View a College sub flow
is executed.
5.1 Add a College

The system requests that the administrator enter the College information.
This includes
(i) The system requests the administrator to enter:
1. College name
(ii) Once the administrator provides the requested information, the system
generates unique College code. The College is added to the system.

5.2 Edit a College

(i) The system requests that the administrator to enter the College
code.
(ii) The administrator enters the code of the College. The system
retrieves and displays the College name information.
(iii) The administrator makes the desired changes to the College
information. This includes any of the information specified in the
Add a College sub-flow.
(iv) The system prompts the administrator to confirm the updating of
the College.
(v) After confirming the changes, the system updates the College record
with the updated information.
5.3 Delete a College

(i) The system requests that the administrator specify the code of the
College.
(ii) The administrator enters the code of the College. The system retrieves
and displays the College information.
(iii) The system prompts the administrator to confirm the deletion of the
College.
(iv) The administrator confirms the deletion.
(v) The system deletes the College record.
5.4 View a College

(i) The system requests that the administrator specify the College code.
(ii) The system retrieves and displays the College information.
6 Alternative Flows
6.1 College Code Already Exist
If in the Add a College sub-flows, a specified College code already exists, the
system displays an error message. The administrator can then enter a different
College code or cancel the operation, at which point the use case ends.
6.2 College Not Found

If in the Edit a College or Delete a College or View a College sub-flows, a
College with the specified College code does not exist, the system displays an
error message. The administrator can then enter a different College code or
cancel the operation, at which point the use case ends.
6.3 Edit Cancelled
If in the Edit a College sub-flow, the administrator decides not to edit the
College, the edit is cancelled and the Basic Flow is re-started at the beginning.
6.4 Delete Cancelled
If in the Delete a College sub-flow, the administrator decides not to delete the
College, the delete is cancelled and the Basic Flow is re-started at the
beginning.

7 Special Requirements
None.
8 Associated Use cases

None.
B. Validity Checks
(i) Only Administrator will be authorized to access the Maintain College Details
module.
(ii) Every College will have a unique College name.
(iii) College code cannot be blank (auto generated).
(iv) College code will have only 2 digits.
(v) College name cannot be blank.
(vi) College name will only accept alphabetic characters and blank spaces.
(vii) College name cannot accept special characters and numeric digits.
C. Sequencing information
None
D. Error Handling/Response to Abnormal Situations
If any of the validations flow does not hold true, appropriate error message will be
prompted to the user for doing the needful.
3.2.3 MAINTAIN COURSE DETAILS
1 Introduction
Allow administrator to maintain details of papers of a particular Branch for a Branch.
This includes adding, updating, deleting and viewing paper information.
2 Actors
Administrator
3 Pre-Conditions
The administrator must be logged onto the system. The College, Branch and Branch
details to which the papers are to be added/updated/deleted/viewed must be available
before this use case begins.
4 Post-Conditions
If the use case is successful, the paper information is
unchanged.

5 Basic Flow
This use case starts when administrator wishes to add/edit/delete/view paper

information
i. The system requests that the administrator specify the function he/she
would like to perform (either Add a paper, Edit a paper, Delete a paper or
View a paper)
ii. Once the administrator provides the requested information, one of the sub
flows is executed.
 If the administrator selects “Add a Paper”, the Add a Paper sub flow is
executed.
 If the administrator selects “Edit a Paper”, the Edit a Paper sub flow is
executed.
 If the administrator selects “Delete a Paper”, the Delete a Paper sub flow is
executed.
 If the administrator selects “View a Paper”, the View a Paper sub flow is
executed.
5.1 Add a Paper

The system requests that the administrator enter the paper information. This
includes:
(i) The system requests the administrator to enter:
1. College name
2. Branch name
3. Semester
4. Paper code
5. Paper name
6. Paper type
7. Credits
(ii) Once the administrator provides the requested information, the paper is added to
the system.
5.2 Edit a Paper

(i) The system requests that the administrator to enter the paper code.
(ii) The administrator enters the name of the paper code. The system retrieves and
displays the paper information.
(iii) The administrator makes the desired changes to the paper information. This
includes any of the information specified in the Add a Paper sub-flow.
(iv) The system prompts the administrator to confirm the updating of the paper.
(v) After confirming the changes, the system updates the paper record with the
updated information.
5.3 Delete a Paper

(i) The system requests that the administrator specify the paper code.
(ii) The administrator enters the paper code. The system retrieves and displays the
paper information.
(iii) The system prompts the administrator to confirm the deletion of the paper.
(v) The system deletes the specified paper record.

5.4 View a Paper

(i) The system requests that the administrator specify the paper code.
(ii) The system retrieves and displays the paper information.
6 Alternative Flows
6.1 Paper already exist

If in the Add a Paper sub-flow, a paper code in a specified semester already exists,
the system displays an error message. The administrator can then enter a different
semester or cancel the operation, at which point the use case ends.
6.2 Paper code already exist

If in the Add a Paper sub-flows, a paper with a specified paper code already exists,
paper code or cancel the operation, at which point the use case ends.
6.3 Paper not found

If in the Edit a Paper or Delete a Paper or View a Paper sub-flows, a paper with the
specified Branch does not exist, the system displays an error message. The
administrator can then enter a different College name or cancel the operation, at
which point the use case ends.
6.4 Edit cancelled
If in the Edit a Paper sub-flow, the administrator decides not to edit the paper, the
edit is cancelled and the Basic Flow is re-started at the beginning.
6.5 Delete cancelled
If in the Delete a Paper sub-flow, the administrator decides not to delete the paper,
the delete is cancelled and the Basic Flow is re-started at the beginning.
6.6 Deletion not allowed

If in the Delete a Paper sub-flow, student registration details of the paper code in a
specified semester already exists then the system displays an error message. The
administrator can then enter a different College name or cancel the operation, at
which point the use case ends.
None.
Maintain College Details, Maintain Branch Details, Maintain Branch Details, Maintain
Student Details, Maintain Student Registration Details.
B. Validity Checks
(i) Only Administrator will be authorized to access the Maintain Paper Details
module.
(ii) A Branch will have more than one paper.

(iii) No two semesters will have same paper i.e. a paper will be offered only in a
particular semester for a given Branch.
(iv) College name cannot be blank.
(v) Branch name cannot be blank.
(vi) Semester cannot be blank.
(vii) Semester can have value only between 1 and 14.
(viii) Paper code cannot be blank.
(ix) Paper code cannot accept special characters.
(x) Paper code can have both alphabetic and numeric characters.
(xi) Paper code can include blank spaces
(xii) Paper code can have length of 5 to 7.
(xiii) Paper name cannot be blank.
(xiv) Paper name can only have alphanumeric (alphabets and digits) or blank space
characters.
(xv) Paper name cannot have special characters.
(xvi) Paper type may be compulsory, elective or practical.
(xvii) Credit cannot be blank.
College, Branch and Branch details will have to be entered in the system before any paper
details can be entered into the system.
If any of the validations/sequencing flow does not hold true, appropriate error message will
be prompted to the user for doing the needful.
3.2.4 MAINTAIN STUDENT DETAILS
1 Introduction
Allow administrator to maintain student details. This includes adding, updating,
deleting and viewing student information.
2 Actors
Administrator
3 Pre-Conditions
The administrator must be logged onto the system. The College and Branch details to
which the student is admitted must be added before this use case begins.
4 Post-Conditions
If the use case is successful, the student information is
unchanged.

5 Basic Flow
This use case starts when administrator wishes to add/edit/delete/view student

information
i. The system requests that the administrator specify the function
he/she would like to perform (either Add a student, Edit a student,
Delete a student or View a student)
ii. Once the administrator provides the requested information, one
of the sub flows is executed.
 If the administrator selects “Add a Student”, the Add a Student sub flow is
executed.
 If the administrator selects “Edit a Student”, the Edit a Student sub flow is
executed.
 If the administrator selects “Delete a Student”, the Delete a Student sub
flow is executed.
 If the administrator selects “View a Student”, the View a Student sub flow is
executed.
5.1 Add a Student

The system requests that the administrator enter the student information. This
includes:
(i) The system requests the
administrator to enter:
1. College
2. Branch
3. Roll No.
4. Name
5. Year of admission
(ii) Once the administrator provides the requested information, the system checks that
roll no. is unique and generates password. The student is added to the system.
5.2 Edit a Student

(i) The system requests the administrator to enter the roll number.
(ii) The administrator enters the roll no. of the student. The system retrieves and
displays the student information.
(iii) The administrator makes the desired changes to the student information. This
includes any of the information specified in the Add a Student sub-flow.
(iv) The system prompts the administrator to confirm the updating of the student.
(v) After confirming the changes, the system updates the student record with the
updated information.
5.3 Delete a Student

(i) The system requests that the administrator specify the roll no. of the student
(ii) The administrator enters the roll no. of the student. The system retrieves and
displays the student information.
(iii) The system prompts the administrator to confirm the deletion of the student.
(v) The system deletes the student record.

5.4 View a Student
(i) The system requests that the administrator specify the roll no. of the student
(ii) The system retrieves and displays the student information.
6 Alternative Flows
6.1 Roll no. already exist
If in the Add a Student sub-flows, a student with a specified roll no. already exists,
roll no. or cancel the operation, at which point the use case ends.
6.2 Student not found

If in the Edit a Student or Delete a Student or View a Student sub-flows, a student
with the specified roll no. does not exist, the system displays an error message. The
administrator can then enter a different roll no. or cancel the operation, at which
point the use case ends.
6.3 Edit cancelled
If in the Edit a Student sub-flow, the administrator decides not to edit the student,
the edit is cancelled and the Basic Flow is re-started at the beginning.
6.4 Delete cancelled
If in the Delete a Student sub-flow, the administrator decides not to delete the
student, the delete is cancelled and the Basic Flow is re-started at the beginning.
6.5 Deletion not allowed

If in the Delete a Student sub-flow, student registration details of the specified Roll
No. already exists then the system displays an error message. The administrator can
then enter a different College name or cancel the operation, at which point the use
case ends.
None.

Maintain Student Registration Details, Maintain College Details, Maintain Branch
Details.
B. Validity Checks
(i) Only administrator will be authorized to access the Maintain Student

Details module.
(ii) Every student will have a unique roll number.
(iii) Roll no. cannot be blank.
(iv) Length of Roll no. for any user can only be equal to 11 digits.
(v) Roll no. cannot contain Alphabets, special characters and blank spaces.
(vi) Student name cannot be blank.
(vii) Length of student name can be of 3 to 50 characters.

(viii) Student name will only accept alphabetic characters and spaces.
(ix) Student name will only accept alphabetic characters and spaces
(x) Year of admission cannot be blank.
(xi) Year of admission can have only 4 digits.
(xii)
College and Branch details will have to be entered in the system before any student details
can be entered into the system.
3.2.5 GENERATE REPORT
1 Introduction
This use case allows generating following reports
 Generate Student Report

 Generate College Report
 Generate Course Report
2 Actors
Administrator, Staff Members
3 Pre-Condition
The Administrator/Staff Members must be logged onto the system before the use case
begins.
4 Post-Condition
If this use case is successful, the desired report is generated. Otherwise, system state
remains unchanged.
5 Basic Flow
 The administrator/Staff Members issue the command to generate the

report.
 The system displays the report.
6 Alternate Flow
Records not found

If records are not found error message is displayed. The administrator/Staff
Members can select another option or cancel the operation. At this point, the use
case ends.
None

Maintain College Details, Maintain Course Details, Maintain Paper Details, Maintain
Student Details
B. Validity Checks
(i) Only administrator/Staff Members will be authorized to access the Generate

Reports module.
Reports can be generated only after College, Course, Branch, paper and student registration
details have been entered.
3.2.6 RESULT
1 Introduction
This use case allows uploading and modifying results
2 Actors
Administrator
3 Pre-Condition
The Administrator must be logged onto the system before the use case begins.
4 Post-Condition
If this use case is successful, the results would be uploaded. Otherwise, system state
remains unchanged.
5 Basic Flow
1 The administrator issues the command to upload the result.

2 The system asks for the following data.
 Roll No.
 Subject Code
 Semester
 Marks Obtained

6 Alternate Flow
Roll No. does not exist, subject code does not exist or not a valid semester
None

Maintain College Details, Maintain Course Details, Maintain Paper Details, Maintain
Student Details
B. Validity Checks
(i) Only administrator/Staff Members will be authorized to access the Generate

Reports module.
(ii) Marks obtained must not be greater than Maximum marks for the subject
(iii) Semester must be between 1 -14
Results can be uploaded only after College, Course, Branch, paper and student registration
details have been entered.
3.2.7 GET RESULT
1 Introduction
This use case allows uploading and modifying results
2 Actors
Student and Teachers
3 Pre-Condition
Must have Internet Connection and Get Result Pages Is Displayed
4 Post-Condition
If this use case is successful, the results would be displayed. Otherwise, system state
remains unchanged.
5 Basic Flow
1 The user issues the command to display the result.

2 The system asks for the following data.

 Roll No.
 Semester
 Branch
 College
6 Alternate Flow
Roll No. does not exist, not a valid semester, Branch does not exist, College does
not exist
Web Browse
If any of the validations/sequencing flow does not hold true, appropriate error message
will be prompted to the user for doing the needful.
3.3 Performance Requirement

 Should run on a PIII 500 MHz or equivalent system with a RAM of 256MB or more
 Responses should be in less than 5 seconds
3.4 Design Constraints

None
3.5 Software System Attributes

Security
Database will be encrypted and application will be password protected using the
inbuilt authorization system of Oracle 10g XE
Maintainability
Since the application and the data base will reside on single system containing the
Oracle 10g XE server the whole system will be easily maintainable and will accommodate for
new changes
Portability
Since the application and the data base will reside on single system containing the
Oracle 10g XE server the whole system will be easily portable only Oracle 10g XE client will
have to be installed on the new system.
3.6 Logical Database Requirement
The Following Information Will Be Placed In Database

Brief Description of Tables
Table Name Description
Course Stores the details of the Course and their respective

branches
Subjects Stores details of Subjects offered in a branches
Student Records the student details.
College Records college details.
Result Records semester wise marks of student along with their

Roll No. In respective subjects
ER Diagram

Type
Max Marks Pass Marks
Marks
Roll No Subject Code
Semester Results Of Subjects Subject Name
Subject Code Branch Code Name
Name Have
Roll No Fathers Name
College Code Name

Course Students
Have
Branch Code
Year
Admitted Branch Code Name
College Code Name

Branches
Colleges
Branch Name
College Name
Student Table

Result Table
Subject Table
Course Table
College Table
Data Flow Diagrams

Level 0
Level 1
Level 2


Software Requirement Specification

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Requirement Specification

Transféré par

Droits d'auteur :

Formats disponibles

Software Requirement

Project Coordinator: Supriya Khaitan

Software Requirement Specification

The new system should provide these functionalities

Safeer Afaque Page 2

1.3 Definition, Acronym and Abbreviation

RMS: Result Management System

Administrator will have following rights

 Generate Reports Of Students.

Safeer Afaque Page 3

Students & Teachers

 Students can access their result from internet.

2.1 Product Perspective

Front End Oracle Client ApplicationOracle Database Server

2.1.1 System Interfaces

2.1.2 User Interfaces

Web portal for students should have following user interface

2.1.3 Hardware Interfaces

 Screen Resolution Of 800 X 600 Or Above

Safeer Afaque Page 4

 Microsoft Windows 2000, XP or above

2.1.5 Communication Interfaces

2.1.6 Memory Constraints

 512 MB or more RAM (Depending upon the OS)

2.1.8 Site Adaptation Requirement

 Client terminals should have Oracle 10g XE Clients Installed

2.2 Product Functions

Administrator will have following rights

 Generate Reports Of Students.

Students & Teachers

 Students can access their result from internet.

RMS will support following USE cases

Safeer Afaque Page 5

Use Case Description

Safeer Afaque Page 6

 There will only be one administrator.

2.6 Apportioning Of Requirement

3.1 External Interface Requirement

Safeer Afaque Page 7

3.1.2 Hardware Interfaces

As stated in section 2.1.3

3.1.3 Software Interfaces

As stated in section 2.1.4

3.1.4 Communication Interfaces

As stated in section 2.1.5

Safeer Afaque Page 8

Safeer Afaque Page 9

Safeer Afaque Page 10

Safeer Afaque Page 11

3.2 Functional Requirement

A. Use Case Description

 If the actor selects “Login”, the Login sub flow is executed.

Safeer Afaque Page 12

 If the actor selects “Change Password”, the Change Password

6.1 Invalid login Id/password

If in the Login sub flow, the actor enters an invalid

6.2 Invalid password

If in the Change Password sub flow, the actor enters

8 Associated use cases

(i) Every user will have a unique login Id.

Safeer Afaque Page 13

3.2.2 MAINTAIN COLLEGE DETAILS

A. Use Case Description