Software Requirement SpecificationResult Management SystemProject Coordinator: Supriya Khaitan Safeer Afaque Roll No 0709013083 IT 2nd Year

Software Requirement Specification SRS

Software Requirement Specification For University Result Management System1. 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 functionalitiesy y y y y y y

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

Software Requirement Specification SRSy

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 y Maintain Personal Details of Student. y Maintain the List of Colleges. y Maintain the Results of Students Semester by Semester. y Maintain the Criteria for Carry Over and Year Backs. y Maintain the List of Subjects. Staff Membersy y

Generate Reports Of Students. Generate Reports Of Results.

Safeer Afaque

Page 3

Software Requirement Specification SRSy y

Generate Reports Of Colleges. Generate Reports Of Subjects For Branches.

Students & Teachersy y

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 Application

Oracle 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 y Login: To allow administrator and staff members enter the system. y Student Details: To maintain student details y College Details: To maintain college list y Course Details: To add courses and their subjects y Result: To Upload Results Web portal for students should have following user interface y Get Results By Roll No y Get Result College and branch wise 2.1.3 Hardware Interfacesy y

Screen Resolution Of 800 X 600 Or Above System should be in a networked environment

Safeer Afaque

Page 4

Software Requirement Specification SRSy

Support For Printer

2.1.4 Software Interfacesy y y

Microsoft Windows 2000, XP or above Oracle 10g XE Database Server Apache Tomcat Web server

2.1.5 Communication Interfacesy y

HTTP protocol TCP/IP protocol

2.1.6 Memory Constraintsy y y

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 Requirementy y

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 y Maintain Personal Details of Student. y Maintain the List of Colleges. y Maintain the Results of Students Semester by Semester. y Maintain the Criteria for Carry Over and Year Backs. y Maintain the List of Subjects. Staff Membersy y y y

Generate Reports Of Students. Generate Reports Of Results. Generate Reports Of Colleges. Generate Reports Of Subjects For Branches.

Students & Teachersy y

Students can access their result from internet. Teachers can access results by college or branch wise.

RMS will support following USE cases

Safeer Afaque

Page 5

Softw r R

uir

t Specification S S

Us C s Login S dent Details

Course Details

College Details

Result

Generate Reports

Safeer Afaque

Maintenance Get Results

D s iption Login Change Pass ord Add Student Edit Student Delete Student Vie Student Add, Edit, Delete Course Add, Edit Delete Subjects Add, Edit Delete Branches Add Colleges Edit Colleges Delete Colleges Vie Colleges Upload Results Modify Results Vie Results Generate Student Report Generate College Report Generate Course Report Maintenance And Bac up Results By Roll No Results By College Results By Branch

Page 6

Software Requirement Specification SRS2.3 User Characteristic Qualification: At least matriculation and comfortable with English. Experience: Should be well versed/informed about the registration process of the university. y Technical Experience: Elementary knowledge of computers 2.4 Constraintsy y y There will only be one administrator. y The Modify and Delete operation is available only to the administrator. y Staff Members can only generate reports the only have read only rights. 2.5 Assumptions & Dependencies y

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

Safeer Afaque

Page 7

Software Requirement Specification SRSFields 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

As stated in section 2.1.4 3.1.4 Communication Interfaces As stated in section 2.1.5 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.

Safeer Afaque

Page 8

Software Requirement Specification SRS

d. Course

Safeer Afaque

Page 9

Software Requirement Specification SRSe. College Details

f. Result Upload

Safeer Afaque

Page 10

Software Requirement Specification SRSg. Web Page For Students And Teachers

Safeer Afaque

Page 11

Software Requirement Specification SRS

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.y

If the actor selects Login , the Login sub flow is executed.

Safeer Afaque

Page 12

Software Requirement Specification SRSy

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.

Safeer Afaque

Page 13

Software Requirement Specification SRS(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 A. Use Case Description 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.y y y y

If the administrator selects executed. If the administrator selects executed. If the administrator selects flow is executed. If the administrator selects is executed.

Add a College , the Add a College sub flow is Edit a College , the Edit a College sub flow is Delete a College , the Delete a College sub View a College , the View a College sub flow

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.

Safeer Afaque

Page 14

Software Requirement Specification SRS5.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.

Safeer Afaque

Page 15

Software Requirement Specification SRS7 Special Requirements None. 8 Associated Use cases None. B. Validity Checks (i) (ii) (iii) (iv) (v) (vi) (vii) Only Administrator will be authorized to access the Maintain College Details module. Every College will have a unique College name. College code cannot be blank (auto generated). College code will have only 2 digits. College name cannot be blank. College name will only accept alphabetic characters and blank spaces. 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 A. Use Case Description 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 added/updated/deleted/viewed from the system. Otherwise, the system state is unchanged.

Safeer Afaque

Page 16

Software Requirement Specification SRS5 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.y y y y

If the administrator selects Add a Paper executed. If the administrator selects Edit a Paper executed. If the administrator selects Delete a Paper executed. If the administrator selects View a Paper executed.

, the Add a Paper sub flow is , the Edit a Paper sub flow is , the Delete a Paper sub flow is , the View a Paper sub flow is

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. (iv) The administrator confirms the deletion. (v) The system deletes the specified paper record.

Safeer Afaque

Page 17

Software Requirement Specification SRS5.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, the system displays an error message. The administrator can then enter a different 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.

7 Special Requirements None. 8 Associated use cases Maintain College Details, Maintain Branch Details, Maintain Branch Details, Maintain Student Details, Maintain Student Registration Details. B. Validity Checks (i) (ii) Only Administrator will be authorized to access the Maintain Paper Details module. A Branch will have more than one paper.

Safeer Afaque

Page 18

Software Requirement Specification SRS(iii) (iv) (v) (vi) (vii) (viii) (ix) (x) (xi) (xii) (xiii) (xiv) (xv) (xvi) (xvii) No two semesters will have same paper i.e. a paper will be offered only in a particular semester for a given Branch. College name cannot be blank. Branch name cannot be blank. Semester cannot be blank. Semester can have value only between 1 and 14. Paper code cannot be blank. Paper code cannot accept special characters. Paper code can have both alphabetic and numeric characters. Paper code can include blank spaces Paper code can have length of 5 to 7. Paper name cannot be blank. Paper name can only have alphanumeric (alphabets and digits) or blank space characters. Paper name cannot have special characters. Paper type may be compulsory, elective or practical. Credit cannot be blank.

C. Sequencing information College, Branch and Branch details will have to be entered in the system before any paper details can be entered into the system. D. Error Handling/Response to Abnormal Situations If any of the validations/sequencing flow does not hold true, appropriate error mess will age be prompted to the user for doing the needful. 3.2.4 MAINTAIN STUDENT DETAILS A. Use Case Description 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 added/updated/deleted/viewed from the system. Otherwise, the system state is unchanged.

Safeer Afaque

Page 19

Software Requirement Specification SRS5 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.y y y y

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 an d 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. (iv) The administrator confirms the deletion. (v) The system deletes the student record.

Safeer Afaque

Page 20

Software Requirement Specification SRS5.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, 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.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. 7 Special Requirements None. 8 Associated use cases Maintain Student Registration Details, Maintain College Details, Maintain Branch Details. B. Validity Checks (i) (ii) (iii) (iv) (v) (vi) Only administrator will be authorized to access the Maintain Student Details module. Every student will have a unique roll number. Roll no. cannot be blank. Length of Roll no. for any user can only be equal to 11 digits. Roll no. cannot contain Alphabets, special characters and blank spaces. Student name cannot be blank.

Safeer Afaque

Page 21

Software Requirement Specification SRS(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) C. Sequencing information College and Branch details will have to be entered in the system before any student details can be entered into the system. D. Error Handling/Response to Abnormal Situations 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.5 GENERATE REPORT A. Use Case Description 1 Introduction This use case allows generating following reportsy y y

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 Flowy y

The administrator/Staff Members issue the command to generate the report. The system displays the report.

6

Alternate Flow Records not found

Safeer Afaque

Page 22

Software Requirement Specification SRSIf 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. 7 Special Requirements None

8 Associated use cases Maintain College Details, Maintain Course Details, Maintain Paper Details, Maintain Student Details B. Validity Checks Only administrator/Staff Members will be authorized to access the Generate Reports module. C. Sequencing information Reports can be generated only after College, Course, Branch, paper and student registration details have been entered. D. Error Handling/Response to Abnormal Situations 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.6 RESULT A. Use Case Description 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 2 The administrator issues the command to upload the result. The system asks for the following data. y Roll No. y Subject Code y Semester y Marks Obtained (i)

Safeer Afaque

Page 23

Software Requirement Specification SRS6 Alternate Flow Roll No. does not exist, subject code does not exist or not a valid semester 7 Special Requirements None 8 Associated use cases Maintain College Details, Maintain Course Details, Maintain Paper Details, Maintain Student Details B. Validity Checks 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 C. Sequencing information Results can be uploaded only after College, Course, Branch, paper and student registration details have been entered. D. Error Handling/Response to Abnormal Situations 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.7 GET RESULT A. Use Case Description 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. (i)

Safeer Afaque

Page 24

Software Requirement Specification SRSy y y y

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 7 Special Requirements Web Browse D. Error Handling/Response to Abnormal Situations 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 y Should run on a PIII 500 MHz or equivalent system with a RAM of 256MB or more y 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

Safeer Afaque

Page 25

Software Requirement Specification S S B i f D s iption of

Course

Stores the details of the Course and their respective branches Stores details of Subjects offered in a branches

Subjects Student College Result

Records se ester wise marks of student along with their Roll No. In respective subjects

Safeer Afaque

Records college details

Records the student details

bl N

bl s D s iption

Page 26

Software Requirement Specification SRSER Diagram Type Max Marks Marks Roll No Subject Code Pass Marks

Semester

Results

Of

Subjects

Subject Name

Subject Code

Branch Code

Name

Have

Roll No

Fathers Name College Code Have Branch CodeAdmitted

Course

Students

Year

Branch Code

College Code Name Colleges Branch Name College Name

Branches

Safeer Afaque

Page 27

Software Requirement Specification SRSStudent Table

Result Table

Subject Table

Course Table

College Table

Safeer Afaque

Page 28

Software Requirement Specification SRSData Flow Diagrams Level 0

Level 1

Safeer Afaque

Page 29

Software Requirement Specification SRSLevel 2

Safeer Afaque

Page 30