Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Students Marks Analyzing System: Software Requirement Specifications

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 10

Software Requirement Specifications

STUDENTS MARKS
ANALYZING
SYSTEM

By :

Baraiya Manit Rameshkumar

20BCE1168

Aryan Shah

20BCE1490
Table of Contents

1.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
....
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
1.2. Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
1.3.
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
..
2. Overall Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
2.1 Product Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
2.2 Product
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 User Classes and Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
2.4 Operating
Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 User
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6 Assumptions and
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3. System
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1. Database – Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
3.2 . Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
3.2.1 Interface Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
3.2.1.1 User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
4. Non Functional
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1. User
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Hardware
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3. Software Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
4.4. Communications Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
5. Other Nonfunctional
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1. Performance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
5.2. Safety Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....
5.3. Security
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4. Software Quality Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.....

1. Introduction
1.1. Purpose
 This Application provides facility to analyse the marks of students
of an institute or organisation.
 It saves time as it allows the organization to store the marks of the students of all the semesters
and analyse the performance.It also saves a lot of time of the college or institute as they don’t
have to do the calculations for every student. It is automatically generated by the server.
 Administrator has a privilege to create, modify and delete the marks,percentage and other details
of a student.
 User can register, login and look his/her performance in almost every field with his specific id.

1.2. Document Conventions


The following are the list of conventions and acronyms used in this
document and the project as well:
Administrator: A login id representing a user with user administration
privileges to the software
 User: A general login id assigned to users
 Client: Intended users for the software

1.3. Scope
Scope of this project is very broad in terms of any institute keeping records of
their students.
Few of them are:-
-This can be used in educational institutions as well as in corporate
world.
- Can be used anywhere any time as it is a web based application.

2. Overall Description

2.1. Product Perspective

The proposed Students Marks Analysing System is an on-line Marks


Analysing System.
The online Students Marks Analysing System created for analyzing performances
of sudents has following stages
 Login
 Watch your performance
 Get marksheet

Login:-
There is a quality login window because this is more secure than other
login forms as in a normal login window there are multiple logins available
so that more than one person can access to test with their individual login.
But in this project there is only one login id i.e. administrator id and
password by which a person enter the site. Hence it is more secure and
reliable than previously used on-line test simulators.

Performance:
Performance page is the most creative and important page in this project.
2.2. Product Features
There are two
. different users who will be using this product:
 University chancellor who will be acting as the administrator.
 Students who will be accessing the SMAS online.
The features that are available to the Administrator are:
 The administrator has the full fledged rights over the SMAS.
 Can create/delete an account.
 Can view the accounts.
 Can change the password.
 Can hide any kind of features from the both of users.
 Insert/delete/edit the information of available on SMAS.
 Can access all the accounts of the faculty members/students.
The features available to the Students are:
 Can view The different categories of marks available in their account.
 Can view their rank.
 Can view the various reading material.
 Can view and modify its profile and also modify it to an extent.

User Case Diagram

2.3. User Classes and Characteristics


There are various kinds of users for the product. Usually web products are visited
by various users for different reasons.
The users include :
 Chancellor who will be acting as the controller and he will have all the
privileges of administrator.
 Students who will be using the above features by accessing the SMAS
online.

2.4. Operating Environment


The product will be operating in windows environment. Also it will be compatible
with the IE 6.0. Most of the features will be compatible with the Mozilla Firefox &
Opera 7.0 or higher version. The only requirement to use this online product
would be the internet connection.

2.5. User Documentation


The product will include user manual. The user manual will include
product overview, complete configuration of the used software, technical details,
backup procedure and contact information which will include email address. The
product will be compatible with the Internet Explorer 6.0 or higher.

2.6. Assumptions and Dependencies


Full working of SMAC is dependent on the availability of Internet connection.

 Assumptions:
In general it has been assumed that the user has complete knowledge of the
system that means user is not a naïve user. Any data entered by him/her will
be valid. To make the software as user friendly as possible but at the same
time keeping in minds user requirements.
->Server OS should be Windows NT/2000/XP/Vista.
->Client PC should be Windows 9X/NT/WorkStation or Windows 2000/Vista
with latest service pack.
 Dependencies:
It depends that the one should follow the international standards for the
generating the User ID & should fill the related information in the proper
format.
3. System Features

3.1. Database – Storage

3.1.1. Description and Priority


Proposed Database is intended to store, retrieve, update, and manipulate
information related to students which include
 Profile of both users
 Student details
 My account
 Test results
 Grade calculation
 Mark sheet

3.1.2. Stimulus / Response Sequences


Responses for Administrator: The administrator can Login and
Logout. When the Administrator Logs into the Student Marks Analysis System
system. The system will check for validity of login .If the Login and
password are valid, the response to this action is the administrator will
be able to modify, view, add, deleting and all other functions that can
be performed on the database.
Marks Analysis:
First of all the user/student gets a valid identification number (same as
the roll no for a college).The user can log on with this
identification no. and can view his marks and analysis depending upon his marks. After logging in the
user can see various options and can choose the option from the menu. Faculty and teachers can enter
marks of students as per his examination result.

3.2. Functional Requirements


This section gives the list of Functional and non functional
requirements which are applicable to the Student Marks Analysis
System. Functional requirements are nothing but the services provided by the system to its end users.
There are three sub modules in this phase.
 Student module.
 Analyzing module.
 Administrator module.
The functionality of each module is as follows.
Student module: The student will logon to the software and view his marks with the grade awarded.
He can also check his previous semester marks and his details.
Analysing module: The database is prepared & loaded into the software. Selection for semester can
be done language wise by the examiner. The marksheet and analysis will be displayed .
Administrator module: The administrator collects all the marks and results after successful
analysis and sends to the head quarters as and when required.

3.2.1 Interface Requirements


This section describes how the software interfaces with other software
products or users for input or output.

3.2.1.1 User Interface


Application will be accessed through a Browser Interface. The interface
would be viewed best using 1024 x 768 and 800 x 600 pixels resolution
setting. The software would be fully compatible with Microsoft Internet
Explorer for version 6 and above. No user would be able to access any part of
the application without logging on to the system.

4. Non Functional Requirements


4.1. User Interfaces
Application will be accessed through a Browser Interface. The interface
would be viewed best using 1024 x 768 and 800 x 600 pixels resolution
setting. The software would be fully compatible with Microsoft Internet
Explorer for version 6 and above. No user would be able to access any part of
the application without logging on to the system.

4.2. Hardware Interfaces


Server Side:
 Operating System: Windows 9x/xp ,Windows ME/Vista
 Processor: Pentium 3.0 GHz or higher
 RAM: 256 Mb or more
 Hard Drive: 10 GB or more
Client side:
 Operating System: Windows 9x or above, MAC or UNIX.
 Processor: Pentium III or 2.0 GHz or higher.
 RAM: 256 Mb or more

4.3. Software Interfaces


Client Side : .HTML, Web Browser, Windows XP/2000/Vista
Web Server: .HTML, Windows XP/2000/Vista

4.4. Communications Interfaces


The Customer must connect to the Internet to access the
Website:
 Dialup Modem of 52 kbps
 Broadband Internet
 Dialup or Broadband Connection with a Internet Provider.

5. Other Nonfunctional Requirements

5.1. Performance Requirements


Some Performance requirements identified is listed below:
The database shall be able to accommodate a minimum of 10,000 records of
students.
The software shall support use of multiple users at a time.
There are no other specific performance requirements that will affect
development

5.2. Safety Requirements


The database may get crashed at any certain time due to virus or
operating system failure. Therefore, it is required to take the
database backup.

5.3. Security Requirements


Some of the factors that are identified to protect the software from accidental or
malicious access, use, modification, destruction, or disclosure are described
below.
Keep specific log or history data sets
Assign certain functions to different modules
Restrict communications between some areas of the program
Check data integrity for critical variables
Communication needs to be restricted when the application is
validating the user or license. (i.e., using https).

5.4. Software Quality Attributes


The Quality of the System is maintained in such a way so that it
can be very user friendly to all the users.
The software quality attributes are assumed as under:
1)Accurate and hence reliable.
2) Secured.
3) Fast speed.
4) Compatibility.

You might also like