Software RequirementSpecification For University Management System

Submitted by: To: Mr.Sartaj Sir Khosla

Submitted Gunjan 10809469 A3 MCA(Hons

803B32 )

Ques. Design a SRS (Software Required Specification) document for implementing UMS (University Management System) in LPU for Teachers as well as for students. Input specification: Software should able to help the students to view their marks, attendance, online fee payment facility etc. Software should able to help the teachers to view their attendance, to upload marks, daily activities etc. Output specification: Draw ER Diagrams Design a SRS

PROBLEM::::
1.. Preface:::: This document should define the expected readership of the document and describe its version history.

2..INTRODUCTION::::

2.1Purpose :::: This SRS document contain a description for university management system enhancement. This document will contain the functional requirements of the project . It also describes the design decisions, architectural design and the detailed design needed to implement the system 2.2 Scope::: Univer sity Mana gement System for LPU is used is to build upon the existing small level pr oject mar king system in or der to implement the pr oject mar king pr ocess and help to students. As well as teacher s to see daily updationd r elated to them.

2.3 Definition, Acronyms :::: The Software requirement document (sometimes called SRS) is the official statement of what the software developers should implement.

SRS LPU UMS J2EE OS

Software Requirement Specification Lovely Professional University University Management System Java 2 Platform Enterprise Edition Operating System

2.4.References:::: IEEE 1998 IEEE Std 830 1998, IEEE Recommended Practice for Software Requirements Specifications. ISBN 07381-0332-2.

2.5.Overview:::: This document has been prepared in accordance with the IEEE Standards 830-1998, IEEE Recommended Practice for Software Requirements Specification. It provides the information of Product perspective, Product functions, User characteristics, constraints,

Assumptions and dependencies and specific requirements

2.6 Developers Responsibilities:::: The developer is responsible for (a) developing the system, (b) installing the software of the clients hardware, (c) maintaining the system for a period of one year after installation.

3 General Description: 3.1 Product Perspective:::: 3.1.1. System interfaces 3.1.2. User Interfaces 3.1.3 Hardware Interfaces 3.1.4. Software Interfaces 3.2 Product Functions:::: For students : 3.2.1. View marks/grades 3.2.2. view /add attendance 3.3.3. view results

3.3.4. daily update information. For Teachers::::: 3.3.5Add assignment. 3.3.6Add Notes. 3.3.7.Add Attendance 3.3 General Constraints::: The system should run on Sun 3/50 workstations running UNIX 4.2 BSD.. 3.4 Assumptions and Dependencies:::: UMS from unauthorized access; functionality such as announcements that is made for students and attendance are assumed to be sufficiently protected under the existing security policies applied by the University network team. Redundant Database is setup as the role of backup Database Server when primary database is failed.

4..Specific Requirements:::: 4.1.Functional requirements 4.1.1. User class Student

This section is for LPUs students 1. Student login form. Student can log in to the system through entering the registration number and can add documents such as assignments, term papers, etc. 2. Change detail. Student can also change detail if information is incorrect such as parents name or telephone number. 3. Change Password. Student can change his login password at any time for security reason. 4. Forgot Password. Student can request his password if he/she forgot the password. 4.1.2. User class Academic Staff All staff can view the details of any student. 4.1.3. User class Unit co-ordinator Certain staff may be designated as Unit or Cohort Co-ordinators and can change the details of any student doing their unit or project cohort. They can change student detail for incorrect information.

 Can view student information and monitor their progress. Can list all the students in different period of different group. Can reset the students password if required.

4.1.4 User class-System Administrator System administrator can list all students in different period of different group to check errors if any. System administrator can also reset the students password if required. 4.1.5 User class Academic Staf f All staf f can view the details of any student and some infor mation could also change or modify.. Change Student Detail Academic Staff can change some student detail for incorrect information. View Student Detail Academic Staff can view all the student information and monitor their progress. List Student

Academic Staff can list all students in different period of different group.

4.2 Attributes of software ::

4.2.1. Security The system needs to log clients information of registration such as IP address and time for security purpose. Password should encrypt and store in the database. 4.2.2 Maintainability The system developing using struts, all action is detailed in struts-config.xml and web.xml that easy to modify and make update. 4.2.3. Portability The web application is coding in J2EE and Struts, therefore, it should be transferable between different OS and Java container.

Appendices

Teacher

Send s

Attendance

Student

identif ication

Course

Reg no

name

course id Course name