2009

Manojtrendsetter1@yaho o.com

[LOVELY PROFESSIONAL UNIVERSITY]

[Type the abstract of the document here. The abstract is typically a short summary of the contents of the document. Type the abstract of the document here. The abstract is typically a short summary of the contents of the document.]

Lovely Professional University

Department of CA

DESIGN PROBLEMI
Course No: CSE364 concepts & tools Design Problem: 01 Course Title: Software Engineering Sec: RA3803A09 Marks: 12

Software Requirements Specification

Project University management system (UMS)

Submitted to : Mr. Sartaj singh

Submitted by : Manoj verma 10810075 Roll no. A09 MCA(H)

Table of Contents

1. Introduction..................................................................................................................3 1.1 Purpose.....................................................................................................................3 1.2 Intended Audience and Reading Suggestions..........................................................3 1.3 Project Scope........................................................................................................... 3 2. Overall Description......................................................................................................4 2.1 Product Perspective..................................................................................................4 2.2 Product Features.......................................................................................................4 2.3 User Classes and Characteristics............................................................................. 4 3. System Features........................................................................................................... 4 3.1 System Feature ........................................................................................................5 3.1.1 For student...................................................................................................... 5 3.1.2 For teacher...5 3.1.3 For audit traling...5 3.2 Functional requirement.5 3.2.1 User class student..5 3.2.2 User class academic staff..5 3.2.3 User class U.A.A...5 3.2.4 User class System administrator...6 3.2.5 User class Administrator staff...6 4. External Interface Requirements............................................................................... 6 4.1 4.2 4.3 4.4 User Interfaces......................................................................................................... 6 Hardware Interfaces................................................................................................. 6 Software Interfaces.................................................................................................. 7 Communications Interfaces..................................................................................... 7

5. Other Nonfunctional Requirements...........................................................................7 5.1 5.2 5.3 5.4 Performance Requirements......................................................................................7 Safety Requirements................................................................................................ 7 Security Requirements............................................................................................. 7 Software Quality Attributes..................................................................................... 8

6. Other Requirements.................................................................................................... 8 7 E-R Diagram.............................8

1. Introduction
1.1 Purpose

This software has made for a university called university management system. University management system (ums) : University management system is software that will help the students and teachers to view their information related to the university. Software should will help the students to view their marks, attendance, online fee payment facility and also will able to help the teachers to view their attendance, to upload marks, daily activities etc. The software will have two type of end user Student Teacher

By all means the software will manage the information and available for the end user at all time. 1.2 Intended Audience and Reading Suggestions

This document is intended for the many types of readers like developers, project managers, marketing staff, users, testers, and documentation writers. This document is organized for all this type of users that what the project is, what the requirements is, and how the system works on these requirements. Project Scope University Management System is developing for School of Computing, University of Portsmouth and used to replace old paper work system and in order to implement the project marking process and allocating supervisor/ideas to students. This increase in efficiency of project marking, audit trails of marking and attendance process, give feedback to student, finally, publication and email student result. It provides a mechanism to edit the online marking form which makes the system is flexible.

2. Overall Description
2.1 Product Perspective

The program will be a web-based application, meaning it runs from a browser. The product should be able to be run from a remote client with an Internet connection. This decision is made depending on where the data file is stored. If it is stored locally, then the program will run on the local machine. The external interface with be through the browser, through HTML, PHP 4.4.2 etc. Product Features Software will be able to help the students to view their marks, attendance, online fee payment facility etc. Software swill be able to help the teachers to view their attendance, to upload marks, daily activities etc. User Classes and Characteristics

2.3

The users of "Ums Management System" will be Students of schools from children to graduate level. The program will feature a simple point-and-click graphical interface similar to that which most students use. The users are expected to have basic knowledge of Web accessing. I think the student of schools can get the schedule of their current courses they are enrolled in. secondly they can track their current progress in the course. Thirdly they can better analyze the future scope of the technology they are working on.

3. System Features
This section contains the feature of the UMS or services provided by by the UMS. The all requirement of the user satisfied by the product , the attendance, marks, on-line fee facility and daily activities etc. All features provided by UMS in operation by forming different class. Classes name attendance, marks, online fee and daily activity are compound

dependent on classes named student and teacher. All the classes have their different operations and functionally dependent on each other.

The features of UMS are subdivided further -3.1.1 For students : The Student can register a UMS accounts and start the progress of project. On the register form, student should enter all their detail such as HEMIS numbers, Email and contact number. The system will generate activation code and send email to student and confirm the registration. After, the system allow student to change information and provide the function forget password for student to retrieve back the password. 3.1.2 For teacher : The teacher must be able to: 1. Upload the marks of student. 1. View their daily activity 2. View their attendence

3.1.3 Audit Trailing : Each user will have an associated record of history.
This will provide information on various events such as . Previous Development a number of components have been developed by the client, Jim Briggs, and previous developer, Steven J Powell. New components need to compatible to the exist system.

3.2

Functional requirements

3.2.1 User class Student

1. Student registration form. 2. Change Detail. Student can change detail if information is incorrect such as telephone number. 3. Change Password. Student can change his login password at any time for security reason. 4. Forget password. Student can request his password if he/she forgotten the password.

3.2.2 User class Academic Staff

All staff can view the details of any student.

3.1.3 User class Unit Cohort 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.

Change Student Detail Unit Cohort co-ordinator can change student detail for incorrect information. View Student Detail Unit Cohort co-ordinator can view student information and monitor their progress. List Student Unit Cohort co-ordinator can list all students in different period of different group. Change Password Unit Cohort co-ordinator can reset the students password if required. 3.1.4 User class System Administrator List Student System Administrator can list all students in different period of different group to check any mistake in uploading information. Change Password System Administrator can reset the students password if required. 3.1.5 User class Administration Staff List Student Administration Staff can list the students in different period.

4. External Interface Requirements 4.1 User Interfaces

The logical characteristics of each interface between the UMS and the users included this This software including images of the university, current news regarding education and university a style guides some standard i.e. help that will appear on every screen.

4.2 Hardware Interfaces

Server side : The web application will be hosted on one of the departments Linux servers and connecting to one of the school Oracle Database server. The web server is listening on the web standard port, port 80. Client side : The system is a web based application; clients are requiring using a modern web browser such as Mozilla Firebox 1.5, Internet Explorer 6 and Enable Cookies. The computer must have an Internet connection in order to be able to access the system.

4.3 Software Interfaces

Server side : The UMS already has the required software to host a Java web application. A development database will be hosted locally the production database is hosted centrally (using Oracle).

Client side : An OS is capable of running a modern web browser which supports HTML version 3.2 or higher. 4.4 Communications Interfaces The HTTP protocol will be used to facilitate communications between the client and server.

5. Other Nonfunctional Requirements

5.1

Performance Requirements

There is no such specific performance requirement for this project. The software will be work same in all circumstances. The mainly using purpose of marks will be covered in the specialization manner.

5.2 Safety Requirements

The safety requirement contains back up of data stored in the UMS. A software is also added as safeguard for its unforeseen losses.

5.3 Security Requirements

Requirements regarding security or privacy issues surrounding use of the

product or protection of the data used or created by the UMS is covered by the developer. A user id and password will be assign to both of the end user teacher and student in the form of biometric id and registration no.

5.4 Software Quality Attributes

Some additional characteristics for the UMS that will also be important to either the customers or the developers :-Correctness : The correctness of this software is obviously high than manual. Moreover its correctness is based on its updation. Flexibility : This software has moreover quality is its flexibility. It can be used by employees, visitors like new student and banks that are providing online fee facility according to authority given by university. Maintainability : Maintanability of the software is high according to its use. Reliability : The software is reliable with its working. Updation : Updation in this software can be easily done according to change in requirement.

6.

Other Requirements

Besides these requirements the end users will be also able to use for assignments, notes related to course and important messages can also be a requirement. For further extending, is able to send notification by SMS.

E R Diagram
UMS Home Page

Login ID

tru e
Acces s
Semester Section

Password

Stud_I D

S_Name

Teach_I D

T_Nam e Course

Student

Studies

Programs

Teach es

Teache r

Deptt

Year Fine
View s

Fees

Account

Course No.

Attendance

Other dues

Loan/Instalmen t Mark s E_ID

Course Exams
Time

Title
Syllabu s

E_Nam
e

Grad e