SOFTWARE REQUIREMENT SPECIFICATION

“Marks Analysis System (MAS)”

Jaipur Enginnering College & Research Center

Submitted by:- Submitted to:-

Nitesh Sharma Mr. Mukesh
Agarwal
Prateek Gandhi
Prateek Kulshreshtha
Contents
1.0 Introduction………………………………………………………......
1.1 Purpose of the Document ………………………………………….
1.2 Scope of the Project.....................................................................….
1.3 Definitions, Acronyms, and Abbreviations…………………...……
1.4 Overview of Document………………………………………….…

2.0 General Description………………………………………………….

2.1 Product Perspective………………………………………………..
2.2 Product Function…………………………………………………..
2.3 User Characteristics……………………………………………….
2.4 General Constraints……………………………………………….
2.5 Assumptions and Dependencies…………………………………..

3.0 Functional Requirements……………………………………………

4.0 Other Non-Functional Requirements……………………………….
4.1 External Interface Requirements…………………………………
4.2 Software Quality Attributes………………………………………
4.3 Security Requirements…………………………………………….
1.0 Introduction
1.1 Purpose of the Document:-
This document contains the specifications for “A web based Academic
Monitoring System” project. The specifications will include the
functional requirements and the data requirements, both of which will
describe how the developers will design the product in order to achieve
all objectives. This document will serves as a guide for the client and the
developers, allowing for a common document to understand the
implementation.
1.2 Scope of the Project:-
We describe what features are in the scope and what are not in the scope
of the system to be developed.
In Scope:-
a. Providing teachers a way so that they can have a look at students’
performance in their respective subject.
b. Providing the HODs the much better way to monitor the
performance of students of their branch using different views like
Graphs, Pie Charts, etc.
c. To generate an analysis report for each student
based on their performance in a semester as a
whole, with a brief comparison with previous
semesters’ performance.

Out Scope:-
a. To provide each student the chance to compare his performance
with his fellow students.
1.3 Definitions, Acronyms, and Abbreviations:-
• M.A.S:- Marks Analysis System

• MTT1:- Mid Term Test 1

• MTT2:- Mid Term Test 2

• PHP:- PHP Hypertext Pre-Processor

• HTML:- Hyper Text Markup Language

• DEO:- Data Entry Operator

• EI:- Exam In charge

1.4 Overview of Document:-

The next section contains general information on how this
program will run. It will explain most of the program's
features and requirements without many implementation
details. The section after that contains the software
requirement details, including functional and non-
functional requirements.
2.0 General Description
2.1 Product Perspective:-
This product works independently and it is totally self-contained. It takes
the marks of students as input and generates analysis report accordingly.
Thus it provides a way for teachers to study the progress of students
using statistical analysis.
2.2 Product Function:-
The different functions performed by the product are:-

 User Identification

 Functions performed by the HOD/Exam In Charge

• Managing and assigning subjects

• Allocating subjects to different teachers

• Setting minimum and maximum marks for MTT1 and MTT2

• Performing subject-wise or branch-wise analysis of students’

performance

• The Exam in charge can also ask teachers for REVIEW of

marks

 Functions performed by Faculty Members

• Uploading marks of students in respective subjects

• Submitting these marks to Exam in charge

• The teachers can perform any changes in the marks before
submitting, but after submission of marks, they have to
 REQUEST FOR CHANGE which is needed to be approved
by the Exam in charge

• The teachers can also perform section-wise analysis of

students’ performance in particular subject

 Functions performed by the students

• They can have a view at their marks in different subjects and

can take a print out of it

• They can also perform a comparison of their own

performance with other students

• They can also perform a comparison of their performance in

current semester with their performance in previous
semesters

2.3 User Characteristics:-

 The user should possess a basic knowledge about computer should

be able to use it easily

 The user should be intelligent enough to understand and follow a

simple user interface

 The user should have a good understanding of parameters used for

analysis of students’ performance

2.4 General Constraints:-

The different constraints of this product are:-
 • Data encoding scheme: ASCII character Confirmation
messages on taken actions, input acceptance and
error conditions will be displayed after each input.

• Total memory to be used by this product including memory

occupied by different tables, etc will vary directly with number of
students.

• Confirmation messages on taken actions, input

acceptance and output generation will be displayed
after each input.
• Similarly, error messages will be displayed for errors
in input or on trying to perform illegal action.

• The product will provide full security to actions performed by

different users, as long as admin doesn’t provide them out of
context rights.

2.5 Assumptions and Dependencies:-

• The users must have a unique username to go with a unique

password.

• The profile information provided by user should be true so to

categorize them in different categories.

• User must be connected to network for accessing the

services of the application.

• The Database will be modified according to the user

accounts.
 3.0 Functional Requirements
Use cases:
1. Login page
a.) Use case id 100
b.) Pre condition:
Internet explorer is running.
c.) Main success scenario:
User enters user name and password
then clicks on Sign in button.
d.) Post condition:
User is forwarded to the home
page depending
on the level of authentication.
Level1:HOD/E.I (refer to id 101)
Level2:faculty (refer to id 201)
Level3:Students (refer to id 301)

e.) Alternate flow:

User selects help option given on the
login page
f.) Exception:
User enter wrong password or
Username or both hence login is not granted

2. HOD/E.I page
a.) Use case id 101
b.) Pre condition:
HOD/E.I enter the correct username and
password and click on Sign in button.
 c.) Main success scenario:
i) HOD/E.I Page is Displayed.
ii) User selects administrator option.

d.) Post condition:

User is moves on to admin page id no 102.
e.) Alternate flow:
i) User Selects logout option.
ii) User Selects the view marks option

3. Administrator Page
a.) Use case id 102
b.) Pre condition:
User must have selected the administrator
option on the HOD/E.I home page id no 101.
c.) Main success scenario:
i) Administrator page opens up.
ii) User selects the faculty option.
d.) Post condition:
User is on page having id 103(Select faculty
Page).

e.) Alternate Flow:

i) User selects the student option.
ii) User selects the classes option.
iii) User selects the change password option.
iv) User selects the logout option.
 4. Select Faculty Page
a.) Use case id 103
b.) Pre condition:
Administrator Page is open and user
selects faculty option.
c.) Main success scenario:
i) Select faculty page opens up.
ii) User fill the name in the search box and
selects the search option.
d.) Post condition:
User is on the search result page having id
104.
e.) Alternate flow:
i) User selects the name of faculty from the list.
ii) User selects the logout option.
f.) Exception:
i) User lefts the search option box empty.

5. Search results Page

a.) Use case id 104
b.) Pre condition:
User must be on select faculty page and
he must have filled the search box with
required information and select the search
option.
c.) Main success scenario:
i) System Displays the Search results for the
user entered information.
ii) User selects the faculty from the search
results and moves to use case id 105.
d.) Post condition:
User moves on use case id 105.
 6. Faculty info Page
a.) Use case id 105
b.) Pre condition:
User is on Select faculty page or on the
search result page where user selects the
faculty.
c) Main Success Scenario:
i) System displays the profile of the selected
faculty.
ii) User selects the edit profile option.
d.) Post condition:
User is on edit faculty info page having use
case id 106.
e.) Alternate flow:
i) User selects the Subjects option and moves to
use case id
107.

7.Edit Faculty info Page

a.) Use case id 106
b.) Pre condition:
User selects edit profile option in use case
id 105.
c.) Main Success Scenario:
i) System Displays form to be filled for updating
information.
ii) User fill all the information to update Faculty
information.
iii) User selects update button to update the
information or discard the changes.
d.) Post condition:
User moves to use case id 105.
 8.Faculty Subject Page
a.) Use case id 107
b.) Pre condition:
User selects the Subjects option.
c.) Main Success Scenario:
i) System displays the Subject information of the
selected Faculty.
ii) User selects the edit subject option on the use
case id 107
d.) Post condition:
User is on use case id 108.
e.) Alternate flow:
i) User selects the logout option.

9.Edit Faculty Subject page

a.) Use case id 108
b.) Pre condition:
User selects the edit subject option on use
case id 107.
c.) Main Success Scenario:
i) System displays the three fields which is to be
filled by selecting option.
ii) After filling the three fields (semester, subject,
batch), user selects the update option
d.) Post condition:
User is on use case id 107.

10. View Classes Page

a.) Use case id 109
b.) Pre condition:
User selects the view classes option on
use case id 102.
c.) Main Success Scenario:
 i) User selects one of the semester and the
section in it and clicks on O.K to move on to
the use case id 110.
d.) Post condition:
User is on use case id 110
e.) Alternate flow:
i) User Selects logout option and moves to use
case id 100.

11. Class information Page

a.) Use case id 110
b.) Pre condition:
HOD selects section and semester and
clicks on O.K in use case id 109.
c.) Main Success Scenario:
i) System displays the information of the classes
for the selected semester and the selected
batch.
d.) Post condition:
User is on use case id 109.
e.) Alternate flow:
i) User Selects logout option and moves to use
case id 100.

12. Select Student page

a.) Use case id 111
b.) Pre condition:
User selects the student option on the use
case id 102
c.) Main Success Scenario:
 i) System Displays select Student option page.
ii) User selects the semester to view students.
iii) User selects the view option to view students
of selected semester.
d.) Post condition:
User is on use case id 112.

13. Update Faculty Page

a.) Use case id 112
b.) Pre condition:
User must have selected the semester on
use case id 111.
c.) Main Success Scenario:
i) System displays list of students in alphabetical
order.
ii) User selects the student to view his profile and
marks.

d.) Post condition:

User is on use case id 113.
e.) Alternate flow:
User selects the logout option and
moves to use case id
100

14. Student Information Page

a.) Use case id 113
b.) Pre condition:
User selects one of the students from the
list and clicks O.K to move to use case id
113.
c.) Main Success Scenario:
i) System displays information and marks of the
student.
 ii) User selects the back option to move to use
case id 112.
d.) Post condition:
User is on use case id 112.

15. Change password Page

a.) Use case id 114
b.) Pre condition:
User selects the change password option
from the use case id 102.
c) Main Success Scenario:
i) System displays the form to be filled.
ii) User enters the new password in the given
field.
iii) User selects the update option
d) Post condition:
User is on use case id 102.

16. Marks page

a.) Use case id 115
b.) Pre condition:
User selects the marks option the use case
id 101.
c.) Main Success Scenario:
i) System displays the two options to view marks
and to analyze marks.
ii) User selects the view marks option.
d.) Post condition:
User is on use case id 116.
e) Alternate Flow:
i) User selects the analyze marks option and
moves to use case id 118
17. Admin View marks page
a.) Use case id 116
b.) Pre condition:
User selects the view marks option on the
use case
id 115.
c) Main Success Scenario:
i) System displays option to select the semester,
subject and batch.
ii) User then selects the ok option.
d.) Post condition:
User is on use case id 117.

18. Admin marks display page

a.) Use case id 117
b.) Pre condition:
User selects the ok option in the use case
id 116.
c) Main Success Scenario:
i) System displays information about the marks
of the student.
ii) User selects the enter marks option.
d.) Post condition:
User is on use case id 117.

19. Admin Marks analysis page

a.) Use case id 118
b.) Pre condition:
User selects the marks analysis option on
the use case id 115.
 c.) Main Success Scenario:
i) System displays the two options to analyze the
marks.
ii) User selects the Inter-class analysis option.
d.) Post condition:
User is on use case id 119.
e.) Alternate flow:
i) User Selects Intra-class analysis option and
moves to use case id 100.

20.Admin Inter-class page

a.) Use case id 119
b.) Pre condition:
User selects the Inter-class option on the
use case
Id 118.
c.) Main Success Scenario:
i) System displays option to select the semester,
subject to analyze marks .
ii) User selects the ok option.
d.) Post condition:
user is on use case id 121.

21. Admin Intra-class page

a.) Use case id 120
b.) Pre condition:
User selects the Intra-class analysis option
on the use case id 118.
c.) Main Success Scenario:
i) System displays the option to select the
semester, subject and class to compare the
results.
ii) User selects the ok option.
d.) Post condition:
 User is on use case id 121.

22. Admin Graphical option page

a.) Use case id 121
b.) Pre condition:
User selects the ok option on the use case
id 119
Or User selected the ok option on use
case id 120.
c) Main Success Scenario:
i) System displays option for type of the graph he
want to see.
ii) User selects the one of the option from the list
of option.
d.) Post condition:
user is on use case id 122.

23. Admin Graph Display page

a.) Use case id 122
b.) Pre condition:
User selects from the option for the type
of graph he want to see on use case id 121.
c.) Main Success Scenario:
i) System displays the required graph by the
user.
d.) Post condition:
User is on use case id 122.
24. Faculty Home page
a.) Use case id 201
b.) Pre condition:
Faculty enters the username and
password.
c.) Main Success Scenario:
i) System displays information about the faculty.
 ii) User selects the enter marks option.
d.) Post condition:
User is on use case id 202.
e.) Alternate flow:
i) User Selects marks analysis option and moves
to use case id 210.

25. Select Semester page

a.) Use case id 202
b.) Pre condition:
User selects the enter marks option on
use case id 201
c.) Main Success Scenario:
i) System displays information about the
semester subject and section.
ii) User selects the semester, subject and section
to edit marks and also MTT1/MTT2 option for
midterm marks.
iii) User selects enter marks option.
d.) Post condition:
User is on use case id 203.

26. Enter Marks page

a.) Use case id 203
b.) Pre condition:
User selects the enter marks option on
use case
id 202.
c) Main Success Scenario:
i) System displays the two option one is enter
marks individually.
ii) Second option is import marks file.
 iii) User selects the import file option.
d.) Post condition:
User is on use case id 204.
e.) Alternate flow:
i) User selects enter marks individually option and
moves to use case id 206.

27. Import file page

a.) Use case id 204
b.) Pre condition:
User selects the import file option on the
use case id 203.
c.) Main Success Scenario:
i) System displays the option to select the file
from the system for uploading marks.
ii) User selects the upload option.
d.) Post condition:
User is on use case id 205.

28. Display Marks page

a.) Use case id 205
b.) Pre condition:
User selects the upload option on use
case id 204 or User selects the save option
on use case id 206.
c.) Main Success Scenario:
i) System displays the marks of the student with
there roll numbers and names.
ii) User selects the edit marks option.
 d.) Post condition:
User is on use case id 206.
e.) Alternate flow:
i) User selects submit marks option and moves to
use case id 207.
ii) User selects Request for change option and
moves to use case id 207.

29. Edit Marks page

a.) Use case id 206
b.) Pre condition:
User selects the edit marks option on use
case id 205 or User selects the enter marks
individually option on Use case id 203.
c.) Main Success Scenario:
i) System displays the marks of the students
with the
editable fields.
ii) User changes the required field and selects
the save option.
d.) Post condition:
User is on use case id 205.

30. Submit Marks option

a.) Use case id 207
b.) Pre condition:
User selects the submit option on the use
case id 205.
c) Main Success Scenario:
i) System displays the option to select the
subject, semester, class and MTT1/2 .
 ii) User after selecting the required option selects
on the ok option and the marks get
submitted to Exam in charge.

d.) Post condition:

user is on use case id 208.

e.) Alternate flow:

i) User selects subject, semester, class and
MTT1/MTT2 and selects request for change
option and moves to use case id 209.

31. Success page

a.) Use case id 208
b.) Pre condition:
User selects on the ok option on the use
case id 207.
c.) Main Success Scenario
i) System displays message showing the success
full submission of the marks.

ii) User selects the home page option

d.) Post condition:
User is on use case id 201.

32. Successfully requested page

a.) Use case id 209
b.) Pre condition:
User selects the request for change option
on the use case id 207.
c) Main Success Scenario:
 i) System displays message showing the
successful submission of request for change
of marks of selected exam to the Exam in
charge.
ii) User selects the home page option
d.) Post condition:
User is on use case id 201.

33. Marks analysis page

a.) Use case id 210
b.) Pre condition:
User selects the marks analysis option
on the use case id 201.
c.) Main Success Scenario:
i) System displays the two options to analyze the
marks.
ii) User selects the Inter-class analysis option.
d.) Post condition:
User is on use case id 210.
e.) Alternate flow:
i) User Selects Intra-class analysis option and
moves to use case id 212.

34. Inter class page

a.) Use case id 211
b.) Pre condition:
User selects the Inter-class option on the
use case id 210.
c.) Main Success Scenario:
i) System displays option to select the semester,
subject to analyze marks.
ii) User selects the ok option.
 d.) Post condition:
User is on use case id 213.

35. Intra-class page

a.) Use case id 212
b.) Pre condition:
User selects the Intra-class option on the
use case id 210.
c.) Main Success Scenario:
i) System displays the option to select the
semester, subject and class to compare the
results.
ii) User selects the ok option.
d.) Post condition:
user is on use case id 213.

36. Graphical option page

a.) Use case id 213
b.) Pre condition:
User selects the ok option on the use
case id 211
Or User selected the ok option on use
case id 212.
c) Main Success Scenario:
i) System displays option for type of the graph he
want to see.
ii) User selects the one of the option from the list
of option.
d.) Post condition:
User is on use case id 214.
 37. Graph Display page
a.) Use case id 214
b.) Pre condition:
User selects from the option for the
type of graph
he want to see on use case id 213 .
c) Main Success Scenario:
i) System displays the required graph by the
user.
ii) User selects the home page option.
d.) Post condition:
User is on use case id 201.

38. Student homepage

Use Case id: 302
Pre Condition:
Student should be logged in. (Refer to case id:
1002)
Main Scenario:
1. Student has his personal information regarding branch,
semester, section, and roll no.etc
2. Student selects to view his marks.
Post Condition:
1. View marks screen is displayed.
2. Refer to case id 1003(a).
Alternate Scenario:
 1. Student selects option to analyze marks (refer to
case id 1003(b)).
2. Student selects to log out.

39. View marks

Use Case id: 303(a)
Pre Condition:
Student should be logged in. (Refer to case id:
1002)
Main Scenario:
1. Student initiates the view marks screen.
2. Student is prompted for whether to view marks for
Midterm 1, Midterm 2 or previous semesters.
3. Students select to view marks for midterm1.
Post Condition:
1. Student made his choice.
2. Student is directed to midterm1 marks page.
3. Refer to case id 1004(a)
Alternate Scenario:
1. Student opts to return to the homepage without
viewing the marks.

40. Midterm1 marks page

Use Case id: 304(a)
Pre Condition:
Student should be logged in. (Refer to case id:
1003)
Main Scenario:
1. Student selects to view midterm marks.
2. Student is provided with a table containing all the
subjects, min marks, max marks and marks obtained.
3. Student selects to go back to the view marks page.
Post Condition:
1. View marks page is displayed.
Alternate Scenario:
1. Student selects to log out his account.

41. Previous semester marks page

Use Case id: 304(b)
Pre Condition:
Student should be logged in. (Refer to case id:
1003)
Main Scenario:
1. Student chose to view previous semester marks.
2. System asks the student for selecting the semester
from a drop down menu.
3. Student selects the semester accordingly.
4. Student’s mark sheet corresponding to selected
semester is displayed in lower half of the page.
5. Student selects to go back to the view marks page.
Post Condition:
1. View marks page is displayed.
Alternate Scenario:
1. Student selects to log out his account.

42. Analyze marks

Use Case id: 303(b)
Pre Condition:
Student should be logged in his account.
Main Scenario:
1. Student is directed to his homepage.
2. Student selects the analyze marks tab.
3. Student is directed to analyze marks page
Post Condition:
1. Analyze marks page is displayed.
Alternate Scenario:
1. Student selects to view marks.

43. Subject wise class analysis

Use Case id: 305(a)
Pre Condition:
Student should be logged in.
Main Scenario:
1. After clicking on analyze marks tab student is provided
with th option to choose whether from ‘Subject wise class
analysis’ or ‘Performance Graph’.
2. Student selects Subject wise class analysis.
3. Student is provided with the name of all the subjects of
current sem. The student chooses one and Percentage v/s
no. of student graph is displayed in every choice of the
user.
4. Student selects to move back.
Post Condition:
1. Student is directed to analyze marks page.
Alternate Scenario:
1. Student selects to navigate to ‘Performance graph
page’.
2. Student selects to logout.

45. Performance Graph page

Use Case id: 305(b)
Pre Condition:
 Student should be directed from Analyze marks
Page
Main Scenario:
1. A graph plotted between percentage obtained and all
the previous semesters is displayed.
2. Student selects to return back.
Post Condition:
1. Student is redirected to analyze marks page.
Alternate Scenario:
1. Student selects to view Subject wise class analysis .
2. Student selects to log out.
 4.0 Other Non-Functional Requirements
4.1 External Interface Requirements:-
4.1.1 User Interface Requirements:-
The different types of users are:-
I. HOD/ Exam In charge
II. Faculty Members
III. Students

HOD/Exam In Charge:-
These users will be able to use the system once they
get logged in by using their unique username and
password. They are the most powerful users of this
system as they have all rights from changing subjects to
changing teachers.
Faculty Members:-
Faculty members will be responsible for uploading
students’ marks in different subjects. After uploading,
they can do changes and then they have to submit them
to Exam in charge. After submission, if they felt the need
for further changes in marks, they have to REQUEST to
Exam in charge.
Students:-
After marks have been submitted by teachers, the
students will be able to view their marks in different
 subjects. They students can also view the marks of other
students.
4.1.2 Hardware Interfaces:-
The Marks Analysis System Application is having the
following hardware.
 A computer acts as Server
 Other pc’s acting as clients/users.

4.1.3 Software Interfaces:-

System will interact with the system database to record
all information generated by the feedback system.

4.2 Software Quality Attributes:-

 Reliability

The system is thoroughly tested at the time of

delivery so that computational errors are
minimized.
 Maintainability
Each module is designed independently so that
any change corresponding to a request can be
modified easily.

4.3 Security Requirements:-

In this system, only the Exam in charge and teachers
will have the power to perform any changes. Students will
only be able to view their marks in different subjects. The
Exam in charge will have the power to change subjects or
to allocate various subjects among pool of teachers,
whereas the teacher will be responsible for uploading
marks and to perform any changes into them.
 Deptna
Dept ID HOD _ID
me

Departmen
t

has has
Faculty_I Name Dept ID Name
D

faculty Examinatio
sets Incharge
n incharge
_ID
Subject_I
D Dept_ID
Add/
delet UPDA
e TES
Upda Semeste
tes r
mark Classes
s of Branch
Student_ Name
ID
Faculty_I
Student Subject D
Subject_I
D

Name
Semeste
Branch Semeste
r
r