1|Page

Software Requirement Specification

Table of Contents
1. Introduction 3
1.1 Purpose 3
1.2 Scope 3
1.3 Definitions, Acronyms, and Abbreviations 4
1.4 References 4
1.5 Overview: 4
2. General Description 4
2.1 Product Perspective 5
Product Functions 6
2.3 User Characteristics 6
2.4 General Constraints 6
2.5 Assumptions and Dependencies 7
3. Specific Requirements 7
3.1 External Interface Requirements 7
3.1.1 User Interfaces 7
3.1.2 Hardware Interfaces 7
3.1.3 Software Interfaces 7
3.1.4 Communications Interfaces 8
3.2 Functional Requirements 8
3.3 Non-Functional Requirements 8
Security: 8
Maintainability: 8
Portability: 8
Usability: 8
Reliability: 9
Availability: 9
Accuracy 9
3.3 USE CASES 9
3.3.1 Use Case #1 9
3.3.1 Use Case #2 10
3.3.1 Use Case #3 11
Analyses Models 12
Data Flow Diagram 12
Entity Relationship Diagram 13
Appendices 13

2|Page
Software Requirement Specification
1. Introduction
The basic purpose of this document is to present the detailed requirements of the Student
Faculty Management system. Student and faculty are the main parts of institutional system. By
building this system we will facilitate the student and the faculty. Through this system the
Student can access his personal data about academic activities. Faculty easily deal with the
student by using this system. Both personalities will use the system through their institute
account. Student can submit his assignment related to study and can share important files with
the faculty. Student can also check his attendance, marks of assignments, given tasks from the
teacher in shape of assignments, can see the material of study related to his semester and
internal Evaluation. Faculty can receive the assignments from the student, can assign tasks to
the student, can submit marks of assignments, and internal evaluation. The faculty can only
mange the student whom they teach. One admin will control the system he will provide the
accounts to the students, solve the problems of the student with respect to the system, can delete
any files and can change the record or the system.
1.1 Purpose
The purpose of this Requirements Elicitation documents is to provide a clear understanding what
is actually Student Faculty management system and to identify the critical requirements essential
for the projects successful completion. These requirements provide an abstract overview of the
student faculty management system and provides a general overview of the entire project. This
SRS describes the software requirements both functional and non-functional for the System
(Student Faculty management system). This document is intended to be used by the members of
the project team that will implement and verify the correct functioning of the system. All
requirements specified here are unless stated otherwise. This document will be used in all
phases of Software Process.

1.2Scope

This document is intended for providing an abstract overview of Student Faculty management
system and general overview of entire project. It will give the access to the student and the
faculty to share their important data and to do all activities between student and faculty related to
study safely. The scope of this document:
• Functional and Non-Functional requirements
• Stake Holders
• Student management
• Faculty

3|Page
Software Requirement Specification
 • Administrator

1.3Definitions, Acronyms, and Abbreviations

Administrator A person who has all the authority of database

1.4 References

IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE

Std. 1471-2000.
IEEE Recommended Practice for Software Requirements Specifications, IEEE Std. 830-1998.
IEEE Guide for Developing System Requirements Specifications, IEEE Std. 1233-1998.

1.5 Overview:
The student faculty management system is a server-based database system that efficiently
displays the data to the student and faculty member. This system supports the student specially to
check their data and alerts. This system has several features such as, checking information, see
their given tasks, progress of their semesters, given tasks from the teacher and teacher receives
the assignments from the students and also submits the tasks to the student.
The SRS document has got four sections:

1. Section 1 (this section) provides an overview of the entire SRS document

2. Section 2 gives a description of the general factors that affect the product that will be produced
based on this SRS. It includes product perspective and General capabilities, General constraints,
User characteristics, Operational environment and assumptions and dependencies of the product.

3. Section 3 gives a specific description about the specific equipment which is divided into Use
Case Diagram and Functional Requirements.

4. Section 4 gives a list of all Non-functional requirements and Constraint Requirements and
they are described along with attributes

2. General Description
Students faculty management system is the advance version to manage the system activities the
student and the faculty that they can manage all the activities related to the study. Faculty
members can easily deal with all the students whom they teach. It will take less time to share the
4|Page
Software Requirement Specification
 tasks and files and student can easily check the all the marks of the semester then faculty can
easily inform the student about the tasks that students have to complete to pass the semester.
This system will provide authorized members to access the system to solve complete the issues.
2.1 Product Perspective
The Following diagram describes the process of management function
The student faculty management system Functions Part 1:
Creation and Maintenance of Student Details:

He fills up a Hits submit

Administrator
form button and
’s logs in and
consisting of new employee
clicks to new
basic details account is
student button
of student created

Start Step 1 Step 2 Step 3 Stop

The student Management Functions Part 2:

Functions Performed by the Student:

He can check his He then submits his

Student logs in personal details. tasks/assignments
with assigned then submits to the
Can view the
username and server. Then server
progress about sends it to specific
password the semester. tacher

Start Step 1 Step 2 Step 3 Stop

5|Page
Software Requirement Specification
 The Student Faculty Management Functions Part 3:
Function performed by the faculty member:

Submits the
Faculty Modifies the tasks to the
member logs detail of the students and
in check the student may alters them
detail of all submit the about the
students tasks tasks

Start
Start S1 S2 S3

Product Functions
This software package is expected to offer the following services:
1. Administrator
a) To facilitate the maintenance of important records of student and faculty member.
b) To maintain record of any student and to provide solutions if user have an type of problem
2. For Faculty Member
a) Facility to view their personal details and view some of them and check the record of
student is well.
3. For Student
a) Facility to check his all progress of the semester, receive all the tasks by sitting at one place and
submit them there.

2.3 User Characteristics

a) Administrator:
In the aspect of the Student, this user will create profile for a new student; assign him/her the
special identity number. Admin can modify the details related to the registered student.

b) Student
This user can see his profile and can contact to the faculty if there are any issues related to it.
2.4 General Constraints
The software package should be designed so as to handle the access by less than 5
administrators, 100 students and 10 faculty members concurrently.
6|Page
Software Requirement Specification
2.5 Assumptions and Dependencies
We assume that everyone that uses the system has access to the internet at speeds of 56k or
above. The system is depended upon by many users therefore it should be able to deal with
hundreds of users logging onto the system at any one time.

3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
The software provides good graphical interface for the front end of the management system so that
new users can make use of the system with ease.

3.1.2 Hardware Interfaces

1) 40 GB hard disk
2) 1GB RAM
3) Peripheral devices

3.1.3 Software Interfaces

1) V C# .NET 2010

7|Page
Software Requirement Specification
2) SQL Server 2017
3.1.4 Communications Interfaces
1) LAN

3.2 Functional Requirements

Registration:
If the user is not register than first user must be registered.
Login:
If the user is registered then he will be logged in by entering user name and password.
Attendance Records:
The user must view, edit attendance records.
Notice uploaded by department:
The user must download or upload notices and alerts from online portal.
Document details:
This module must store documents in word and pdf format and also should allow students to
view particular data.
Student Download:
The system should allow students to download only allowed semester data through their device
using an active internet connection.
Notifications:
The system should send notification to student account about new upload from teacher’s data
related to his semester.
Alerts of tasks:
The student must receive a notification when faculty member will define a task or assignment.
Time Table:
The admin must upload time table which student can view.
Logout:
The user must log out from the system when he wants to.
Settings:
The user must edit his data from settings.
3.3 Non-Functional Requirements
Security:
The system needs to log client’s information of registration such as IP address and time for security
purpose.
Password should encrypted and store in the database.
Maintainability:
The system developing using Struts, all action is detailed in struts-config.xml and web.xml that
easy to modify and make update.
Portability:
The web application is coding in J2EE and Struts, therefore, it should be transferable between
different OS and Java container
Usability:
The system shall allow the users to access the system from the Internet using HTML or its
derivative technologies. The system uses a web browser as an interface. Since all users are
familiar with the general usage of browsers, no specific training is required.
8|Page
Software Requirement Specification
The system is user friendly and self-explanatory.
Reliability:
The system has to be very reliable due to the importance of data and the damages incorrect or
incomplete data can do.
Availability:
The system is available 100% for the user and is used 24 hours a day and 365 days a year. The
system shall be operational 24 hours a day and 7 days a week.
Mean Time between Failures (MTBF)
The system will be developed in such a way that it may fail once in a year.
Mean Time to Repair (MTTR)
Even if the system fails, the system will be recovered back up within an hour or less.
Accuracy
The accuracy of the system is limited by the accuracy of the speed at which the employees of the
library and users of the library use the system
Access Reliability
The system shall provide 100% access reliability
Validation Criteria:
A Software Testing Plan (STP) will be created to define a set of qualification methods and to
specify for each requirement in this document a method of ensuring that the requirement is
satisfied.
➢ How do we recognize a successful implementation?
➢ What classes of tests must be conducted to validate function, performance and
constraints?

3.3 USE CASES

3.3.1 Use Case #1
Actor: Student
Use Cases:
• Login
• Authentication
• Logout
• View Attendance, marks and semester progress.
• Account management
• View My Profile

9|Page
Software Requirement Specification
3.3.1 Use Case #2
Actor: Administrator
Use Cases:
• Search Student Info.
• Student Management
• Add Student Detail
• Delete Student Detail
• Attendance Management Faculty and Student
• Update Management

10 | P a g e
Software Requirement Specification
3.3.1 Use Case #3
Actor: Faculty Member
Use Cases:
• Login
• Authentication
• Logout
• View Salary
• Salary Management
• View My Profile
• Search Student Info.
• Student Management
• Edit Student Detail
• Delete Student Detail
• File Management

11 | P a g e
Software Requirement Specification
Analyses Models
Data Flow Diagram

12 | P a g e
Software Requirement Specification
Entity Relationship Diagram

Appendices
Appendix 1 (N/A)
Appendix 2 (N/A)

13 | P a g e
Software Requirement Specification