A

PROJECT REPORT

On

Student Database Management System

Submitted in partial fulfillment of the requirement for the award of the Degree of

Bachelor of Technology

In

Computer Science and Engineering

Submitted By

ASHISH ARORA

Roll No: 0911483108

Batch I-2

1

Acknowledgement

Acknowledgement is not only a ritual, but also an indebtedness to all those who

have helped in the completion process of the project. One of the most pleasant

aspects in collecting the necessary and vital information and compiling it is the

opportunity to thank all those who actively contribute to it.

First of all I am thankful to the IT department, where I got the golden opportunity to

undertake this project. The help, assistance and guidance that I have received here will be

earnestly cherished throughout my life.

I would also like to thank my APTECH teacher Mr. Bhupesh who taught me very well

and helped me in completing the project. I am really fortunate to be placed under her guidance.

Not only to fulfill a formality but also to express the feelings in my heart, I put on record

my deepest gratitude and profound appreciation to all of them who helped me by correct

guidance upgrading my programming skills, and troubleshooting while doing the assignments.

And last but not the least, I would like to pay my sincere regards to the faculty members for the

invaluable support and blessing, which were vital necessity for the completion of my project.

2

Index

S. No. Title Page No.

1. Certificate 1

2. Acknowledgement 2

3. Project Overview 3

4. SRS Documentation 5

5. Use Case Diagram 16

6. Entity Relationship Diagram 17

7. System Data Flow Diagram 19

8. Introduction of the project 21

9 Outputs of the project 28

10. Conclusion 33

12. References and Bibliography 34

3

Project Overview

Student Database Management System has become important factors in modern education

field. This system should help the institutional to streamline the administrative task and provide

real-time access to the data. Building this system in web based interface will further help the ease

of accessibility through any web browser. The study findings enable the definition of the project

problem statement, its objectives, scopes and advantages of the Student Database Management

System. Student Database Management System streamlines data collection, storage & retrieval

and the management of records to improve both operational (admission, registration, scheduling,

examination and grading) and management tasks (planning, evaluation and decision-making). It

focuses on storing & processing curriculum data, student data and produce outputs supporting

the operational activities. These outputs include student cards, subject descriptions, invoices,

schedules and management information.

4

1. SRS Documentation

1. Introduction

A software requirements specification (SRS) is a complete description of the behavior of the

system to be developed. This Software Requirement Specification is written accordance with the

IEEE STD 830-1998 model.

1.1 Purpose

This SRS Document contains the complete software requirements for a Student Database

Management System (SDMS) and describes the design decisions, architectural design and the

detailed design needed to implement the system. It provides the visibility in the design and

provides information needed for software support. The intended audiences for this document are

the development team, testing team and the end users of the product

1.2 Scope

The software product “Student Database Management System” will be an application that will be

used for maintain the records in an organized manner and to replace old paper work system. The

application will manage the information about various students and teachers. It is also designed

to calculate the annual fee of the students. Specific reports will also be generated regarding the

teachers and the students.

5

1.3 Definitions, Acronyms and Abbreviations

Following abbreviations have been used throughout this document:

IEEE : The Institute of Electrical and Electronics Engineers, Inc.

SRS : Software Requirements Specification

SDMS : Student Database Management System

1.4 Overviews

This document has been prepared in accordance with the IEEE STD 830-1998, IEEE

Recommended Practice for Software Requirements Specification. [IEEE 830-1998 (1998)]. It

provides the information of Product perspective, Product functions, User characteristics,

Constraints, Assumptions and dependencies and specific requirement.

2. The Overall Description

6

This section of the SRS describes all general factors of the product and its requirements.

2.1 Product Perspective

The application will be a window-based, self contained and independent software product.

2.1.1 System Interfaces

None

2.1.2 User Interfaces

The application that will be developed will have a user friendly and menu based interface.

Following screens will be provided:

A login screen for entering the username and password, so that the authorized user can have

an access without any problems.

There will be a screen which will be displaying the major tasks that the system will be

performing i.e. add details, delete details, view details of the student and fee management.

All the major tasks mentioned above will have their separate forms and will perform the

desired actions.

7

Front end client application (with data entry/update/delete/ view and reporting

facility)

Backend

Database

Fig 2.1 Product Perspective

Following reports will also be generated:

Student Report

Student Fees Report

2.1.3 Hardware Interfaces

Screen resolution of at least 800 X 600required for proper and complete viewing of screens.

Higher resolution would not be a problem

Support for printer (dot-matrix/desk-jet/inkjet, etc. – any will do) – that is, appropriate

drivers are installed and connected printer will be required for printing of the reports.

Standalone system or network based – not a concern, as it will be possible to run the

application on any of these.

2.1.4 Software Interfaces

Any window based operating system can be used (windows 95/98/2000/XP/NT/Vista/7)

Oracle as DBMS for database. Future release of the application will aim at upgrading oracle

8i as the DBMS.

Visual Studio 9 for coding, developing the software.

2.1.5 Communications Interfaces

None

8

2.1.6 Memory Constraints

At least 64MB RAM and 2GB space on hard disk will be required for running the application.

2.1.7 Operations

The product release will not cover any automated housekeeping aspects of the database. The

DBA (Database Administrator) at the client site (i.e. the school) will be responsible for manually

deleting old/non required data. Database backup and recovery will also have to be handled by the

DBA. However, the system will provide a “RESET SYSTEM” function that will delete (upon

confirmation from the administrator) all the existing information from the database.

2.1.8 Site Adaptation Requirements

The terminals at the client site will have to support the hardware and software interfaces

specified in the above sections.

2.2 Product Functions

The system will allow access only to authorized users entering the appropriate password. A

summary of the major function that the software will perform are as follows:

A login facility to allow only the authorized users to have an access to the software system.

This prevents the unauthorized users to misuse the software.

User (as Data Entry Operator) will be able to add/delete/modify information about different

students and moderator present in the school.

9

The reports can also be generated in case a user wants them. The reports will contain all the

details about the student whose report is generated. For e.g. their name, id, age, gender,

phones no etc.

2.3 User Characteristics

Educational level: At least graduate should be comfortable with English language.

Experience: The operator should be well versed about the nature and the processes of the

school.

Technical expertise: should be comfortable using general purpose applications on a

computer.

2.4 Constraints

GUI is only in English.

Login and password is used for identification of user and there is no facility for Guest.

2.5 Assumption and Dependencies

The fee structure differs for the students in different standards.

The amount for personal deposit will remain the same for all the students.

2.6 Apportioning of Requirements

Not required.

10

3. Specific Requirements

This section contains the software requirements to a level of detail sufficient to enable designers

to design the system and the tester to test that system.

3.1 External interfaces

This interface will be the actual interface through which the user will communicate with the

application and perform the desired tasks. The following screens will be provided:

Login Screen:

The login screen will be the first screen that a user will face. This screen is responsible to allow

the authorized users to access the application. It will accept the username and password from the

user and verify it. If the username and password match, then the user will be allowed an access to

the application else and error will be raised i.e. ACCESS DENIED. The fields available on this

screen will be:

Username : Varchar2 of length up to 10 characters.

Password : Number of length up to 15 characters.

Menu Screen:

11

This screen will display 4 small screens inside of it which will perform the major tasks. In the

menu screen we can select any of these four screens and perform the desired actions. The four

screens will be Student Information and Fee Management.

Student Information Screen:

The user can add, delete and modify the student record as per his needs. This screen will show

the user, information about each and every student present in the school. He can also add a new

record in the database if a new student takes admission in the school. The fields available on this

screen will be:

ID : Number of length up to 10 digits

Name : Varchar2 of length up to 20 digits

Admission No : Number of length up to 10 digits

Roll No : Number of length up to 10 digits

Age : Number of length up to 2 digits

Fee Management Form:

12

This form will display the fee information i.e. the fee that has to be paid by the parents. It

includes the details like hostel charges, admission fees, personal deposit etc. The fields available

on this screen will be:

Annual Fees : Number of length up to 5 digits

Tuition Fees : Number of length up to 5 digits

Activity Fees : Number of length up to 5 digits

Security Fees : Number of length up to 5 digits

Transport Fees : Number of length up to 5 digits

3.2 System features

Student Information Management

Description

The system will maintain all the information regarding the students such as Name, Gender, Date

of Birth, ID (Unique), Address, Phone no., Age, etc. This system will also allow the user to

add/delete/update the information as per his requirements.

Validity checks:

If you are adding any record then you must give a unique ID number.

If you are adding any record then you must give a unique roll no. number.

The phone number must exceed 10 digits.

The ID field cannot be left blank.

Sequencing information

13

After a successful login the user will be allow to choose from the options such as Student

Information and Fee Management. He can choose any one of these. As far as Student

Information Management is concerned the user will have to enter the ID of the student in order

to generate the desired details. After the ID has been given the user will click on the “Show

Record” button and he will be displayed the necessary information about that student.

Report Generation

Student Report:

A report will be generated containing the details of all the students. There will be an individual

report for each student which will tell the user about his/her ID, Name, Age, Class etc.

Student Fee Report

A report will be generated containing the details of fees deposited by the student. There will be

an individual report for each student which will tell the user about his/her ID, Name, Age etc.

3.3 Performance Requirements

None

3.4 Design Constraints

None

14

3.5 Software System Attribute

3.5.1 Security

The application will be password protected. The users will have to enter the correct user name

and password in order to access the software.

3.5.2 Maintainability

The system will be designed in a maintainable order. The system can be easily modified and

renewed according to the need of the user.

3.5.5 Portability

The system will be easily portable on any windows based application that has oracle installed.

3.6 Logical Database Requirements

The following information will be stored in the database:

Student Info: ID, Name, Admission No, Roll No, Father’s Name, Mother’s Name, Address,

Gender, Age, Phone No, Date of Birth.

Fee Info: Admission Fees, Tuition Fees, Hostel Charges, Administrative Charges, Personal

Deposit.

3.7 Other Requirements

None

15

2. Use Case Diagrams

A use case diagram is defined by and created from a Use-case analysis. Its purpose is to present a

graphical overview of the functionality provided by a system in terms of actors, their goals

(represented as use cases), and any dependencies between those use cases.

The main purpose of a use case diagram is to show what system functions are performed for

which actor. Roles of the actors in the system can be depicted. The actions which they perform

are also displayed.

In the following use case diagram, three actors are defined: Administrator, Moderator and

Student. All these can access, update, and delete information on the basis of their roles, rights

provided to them.

16

3. ER Diagram

Entity-relationship model (ERM) is an abstract and conceptual representation of data. Entity-

relationship modeling is a database modeling method, used to produce a type of conceptual

schema or semantic data model of a system, often a relational database, and its requirements in a

top-down fashion. The first stage of information system design uses these models during

the requirements analysis to describe information needs or the type of information that is to be

stored in a database. An entity may be defined as a thing which is recognized as being capable of

an independent existence and which can be uniquely identified. An entity is an abstraction from

the complexities of some domain. A relationship captures how two or more entities are related to

one another. Relationships can be thought of as verbs, linking two or more nouns. Diagrams

created by this process are called entity-relationship diagrams, ER diagrams, or ERDs. We have

presented below the ER Diagram for our software system.

17

18

4. System DFD

A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an

information system. DFDs can also be used for the visualization of data processing (structured

design). On a DFD, data items flow from an external data source or an internal data store to an

internal data store or an external data sink, via an internal process.

A DFD provides no information about the timing of processes, or about whether processes will

operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows

the flow of control through an algorithm, allowing a reader to determine what operations will be

performed, in what order, and under what circumstances, but not what kinds of data will be input

to and output from the system, nor where the data will come from and go to, nor where the data

will be stored (all of which are shown on a DFD).

Following are the DFD’s of level 0 and level 1 for this software system.

19

20

5. Introduction of the Project

5.1 Purpose

Student Database Management System has become important factors in modern education

field. This system should help the institutional to streamline the administrative task and provide

real-time access to the data. Building this system in web based interface will further help the ease

of accessibility through any web browser. The study findings enable the definition of the project

problem statement, its objectives, scopes and advantages of the Student Database Management

System. Student Database Management System streamlines data collection, storage & retrieval

and the management of records to improve both operational (admission, registration, scheduling,

examination and grading) and management tasks (planning, evaluation and decision-making). It

focuses on storing & processing curriculum data, student data and produce outputs supporting

the operational activities. These outputs include student cards, subject descriptions, invoices,

schedules and management information.

5.2 Description Of the organization

A school is an institution designed for the teaching of students (or "pupils") under the

supervision of teachers. Most countries have systems of formal education, which is commonly

compulsory. In these systems, students progress through a series of schools. The names for these

schools vary by country, but generally include primary school for young children and secondary

school for teenagers who have completed primary education.

In addition to these core schools, students in a given country may also have access to and attend

schools both before and after primary and secondary education. Kindergarten or pre-school

provide some schooling to very young children (typically ages 3–5). University, vocational

21

school, college or seminary may be available after secondary school. A school may also be

dedicated to one particular field, such as a school of economics or a school of dance. Alternative

schools may provide nontraditional curriculum and methods.

There are also non-government schools, called private schools. Private schools may be for

children with special needs when the government does not supply for them; religious, such as

Christian schools, hawzas, yeshivas and others; or schools that have a higher standard of

education or seek to foster other personal achievements. Schools for adults include institutions of

corporate training and Military education and training.

A Student Database Management System is a software application for educational

establishments to manage the data of the students. This system provides capabilities for

management of students, their complete information. It also provides the capabilities to manage

the fee structure, the attendance of the students and teachers.

5.2.1 Organizational Objectives:

To allow principal, teachers, and school officials to view required reports.

Handling the admissions process.

To facilitate administrator and moderator record keeping,

To manage the data of a particular student.

To control the fee management structure.

To retrieve the data of a particular student.

22

5.2.2 Services Provided:

This Student Database Management System software provides various services to the user, mentioned below:

A user account. Maintains the profiles of the administrator, moderator, and students. It also maintains the fees structure for the students.

5.2.3 Functions/Activities with respect to the proposed system:

Records and Profiles Management: This software has a module dedicated to management of

students, teachers and staff records, which makes it useful profile management software. This

profile management system captures master data such as name and contact information of the

students, parents, teachers and other supporting staff.

Fee Management: Fee collection and management is one of the critical processes of a school.

This software stores all fee-related information along with the frequency at which it is collected.

It also performs the task of adding all the fees submitted during different quarters.

5.3. System Analysis

Systems analysis is the study of systems sets of interacting entities, including computer systems.

This field is closely related to operations research. It is also "an explicit formal inquiry carried

out to help someone, referred to as the decision maker, identify a better course of action and

make a better decision than he might have otherwise made.

23

5.3.1 Block Diagram

24

Fig.5.3 Block Diagram of the proposed system

Enter

Details

Enter

Details

Student Fee Details

Student

Details

User Account

Administratr

Profile

Profile

Student Profile

Fee Management Structure

Final

Reports

Receipts

Output

Student Profile

Output

5.3.2 Description of the system

This software is basically developed for the user so that the user can maintain the records in an

organized manner. For this purpose we have created different modules that are dedicated to the

management of students, teachers and staff records, also the user can maintain the attendance

records which makes it useful management software. Fee collection and management is one of

the critical processes of a school. This software also stores all fee-related information along with

the frequency at which it is collected.

5.3.3 Processes and input output identification

This section contains the details about all the processes that are performed in the software system

and also tells us about the input and output identification i.e. what is the input being given and

what is the desired output.

Student and Administrator profile management process: These two processes are

responsible to maintain the profiles of the students, moderators and the administrator present in

the school. All the details regarding each and every student and moderator are kept in their

respective modules.

Input: The user will enter the details of a new student if the user wants to add a new record, he

can also update and delete a particular record.

Process: All the processing regarding the addition, updating and deletion of a record is done

here.

Output: The user can see the records of a particular student and moderator if he/she have

particular rights.

25

Fee Management Process: This process is responsible to manage the fee record structure of

the each and every student present in the school. The user can see these records whenever he

wants to.

Input: The user will enter the details of a particular student.

Process: Record processing will be done in this section in order to generate a particular fee

record.

Output: All the fee details of the student will be displayed.

26

5.3.5 Processing Logic Flowchart

27

Outputs of the Project

Student Database Management System Login Form

The above shows the snapshot of the Student Database Management System login form i.e. the page the users are first greeted with when they first visit the software.

28

Add Student Details Page

After the user log in he can select from the menu any option. This is the snapshot of add student details . The user can enter his details n save it in database for further use.

29

Delete Student Details

The above snapshot shows the delete user web page. The user can delete his details from the database after logging in. He requires filling in the details for deleting an account from the database.

30

View Reports

The above snapshot shows the view reports web page. The user can view his details from the database after logging in. He requires filling in the student name and the admission number to view the report from the database.

31

Fee Management

The above snapshot shows the fee management web page. The user can enter his fees details in the database after logging in. He requires filling in the student name, admission number and the corresponding fees after which total fees will be calculated and will be stored in the database.

32

Conclusion

Student Management System can completely implement all the basic things required to

manage the student record in the school.

It allows addition of student records, manage their profile, view their records, update / delete the

details entered and also manage the fees deposited by the student. The user can also view the

report of students and also their fees report. The user can access the record only after entering a

valid username and a valid password associated with the username.

33

References and Bibliography

http://eljabiri1.tripod.com/sitebuildercontent/sitebuilderfiles/Req-Gathering-1-.pdf

http://www.westfallteam.com/Papers/

The_Why_What_Who_When_and_How_Of_Software_Requirements.pdf

http://en.wikipedia.org/wiki/Microsoft_.NET#Microsoft_.NET

http://en.wikipedia.org/wiki/Requirements_analysis

http://portal.acm.org/citation.cfm?id=1010800.1010802

http://en.wikipedia.org/wiki/Secondary_data

http://brent.tvu.ac.uk/dissguide/hm1u3/hm1u3text3.htm

34