You are on page 1of 59

STUDENT ATTENDANCE

MANAGEMENT SYSTEM
PROBLEM STATEMENT

The problem statement of student attendance management system of B. Tech.


(CSE, IT, EEE, ECE) program for a college is given below:

The purpose of this system is to automate and computerize the attendance of


students in the college.

The B.Tech Program is a 4 year course and consists of 8 semesters.

The intake of students for every branch is given as:

◊ CSE -- 132
◊ ECE -- 132
◊ IT -- 66
◊ EEE – 66

Each semester consists of practical as well as theory subjects.

The number of subjects offered in different semesters is:

SEMESTE NO. OF THEORY NO. OF PRACTICAL


R SUBJECTS SUBJECTS

1st 7 5

2nd 7 5

3rd 6 4

4th 6 4

5th 6 4

6th 6 5

7th 4 4

8th 3 4

Number of lectures per week:

 5 lectures for each theory subject


 1 lab session for each practical subject
Each subject is be assigned some specific code for convenience in maintaining the
database.

75% is the Compulsory attendance for a student else a short attendance report is
generated.

So a list of students along with their daily attendance for class, subjects offered and
faculty members is to be maintained.

The faculty members of respective subjects provide attendance details to the data
entry operator who all details into the system database. This process is carried out
daily by the faculty members and the data entry operator. Attendance is updated on
all weekdays except Saturdays and Sundays. Once the data entry operator has
updated the attendance, he/she would not be allowed to change the attendance
again.

The students and faculty members can also login the system to view and generate
reports for student information, subjects opted by them and their attendance in any
subject.

The system will generate monthly attendance reports and the reports should be
printable.
SOFTWARE
REQUIREMENT
SPECIFICATIONS
(SRS)
TABLE OF CONTENTS
1. INTRODUCTION
1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms and Abbreviations

1.4 References

1.5 Overview

2. OVERALL DESCRIPTION
2.1 Product Perspective

2.1.1 System Interfaces

2.1.2 User Interfaces

2.1.3 Hardware Interfaces

2.1.4 Software Interfaces

2.1.5 Communication Interfaces

2.1.6 Memory Constraints

2.1.7 Operations

2.1.8 Site Adaptation Requirements

2.2 Product Functions

2.3 User Characteristics

2.4 Constraints

2.5 Assumptions and Dependencies

2.6 Apportioning of Requirements

3. SPECIFIC REQUIREMENTS
3.1 External Interface Requirements

3.1.1 User Interfaces

Login Screen:

Student Info Parameters Screen:

Student Info Screen:

Subject Info Parameters Screen:

Subject Info Screen:

Faculty Members Info Parameters Screen:

Faculty Info Screen:

Attendance Entry Info Parameters Screen:

Attendance Entry Info Screen:

Report Generation Parameter Screen:

3.1.2 Hardware Interfaces

3.1.3 Software Interfaces

3.1.4 Communication Interfaces

3.2 Software Product Features

3.2.1 User Account Maintenance

Validity Checks

Sequencing Information

Error Handling/Response to Abnormal Situations

3.2.2 Student Information Maintenance

Validity Checks

Sequencing Information

Error Handling/Response to Abnormal Situations

3.2.3 Subject Information Maintenance

Validity Checks
Sequencing Information

Error Handling/Response to Abnormal Situations

3.2.4 Faculty Member Information Maintenance

Validity Checks

Sequencing Information

Error Handling/Response to Abnormal Situations

3.2.5 Student Attendance Information Maintenance

Validity Checks

Sequencing Information

Error Handling/Response to Abnormal Situations

3.2.6 Attendance Report Generation

Validity Checks

Sequencing Information

Error Handling/Response to Abnormal Situations

3.3 Performance Requirements

3.4 Design Constraints

3.5 Software System Attributes

3.5.1 Security

3.5.2 Maintainability

3.5.3 Portability

3.6 Logical Database Requirements

3.7 Other Requirements

1. INTRODUCTION
The student attendance management system is a software developed for daily
attendance of students in colleges. It facilitates the access of attendance information
of a particular student belonging to a particular class. The attendance information is
provided to the DEO by the faculty teacher for a particular class and subject. The
software system also helps in evaluating the examination eligibility criteria for a
student in the sense that only those students with attendance above 75% are
allowed to be eligible for the semester exams.

1.1 PURPOSE

This specification document describes the capabilities that will be provided by the
software application “Student Attendance Management System”. The purpose of
developing this attendance management system is to computerize the traditional
way of taking attendance in classes and also manage student and teachers’
information along with their classes and subjects.

Another purpose for developing the software is to generate the reports automatically
whenever required-in between the semesters or after the semester.

1.2 SCOPE

The scope of the project is the system, on which the software is installed, i.e., the
project is developed as a desktop application, and it will work for a particular college.
But later on, the project can be modified to operate it online.

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

INFO: Information

B.TECH: Bachelor of Technology

DEO: Data Entry Operator

1.4 REFERENCES

IEEE Recommended Practice for Software Requirements Specification-IEEE Std


830-1993.

1.5 OVERVIEW

The rest of the SRS document describes the various system requirements,
interfaces, features and functionalities in detail.
2. OVERALL DESCRIPTION

The student attendance management system is a cost and time effective


computerized system that maintains daily attendance of students on the basis of
their attendance in theory and laboratory courses opted by them. The students are
offered various theory and practical subjects depending upon the ongoing semester.
The system maintains student details, the subjects opted by them, their attendance
in a particular subject and details of the faculty member teaching them. The system
also generates summary reports of all these details.

2.1 PRODUCT PERSPECTIVE

The application will be a windows-based, self-contained and independent software


product.

2.1.1 SYSTEM INTERFACES

None.

2.1.2 USER INTERFACES

The application will have a user-friendly and menu-based interface. Following


screens will be provided:

• LOGIN SCREEN: for entering the username, password and role


(Administrator, DEO, Student or Faculty Member). Further access to different
screens will be provided based upon the role of the user.

• SUBJECT INFO SCREEN: for capturing and displaying information regarding


what all subjects are offered during which semester and branch, how many
credit points are assigned to that subject and whether the subject is of theory
or practical?

• STUDENT INFO SCREEN: for capturing and displaying the details of all
students enrolled for the course in different years, their name, enrollment
number, branch, semester and courses opted by them.

• FACULTY INFO SCREEN: for capturing and displaying the details of all
faculty members-their name, department, qualification, experience, salary,
teaching subject/s and class/es.

• ATTENCANCE INFO SCREEN: for capturing and displaying the attendance


details of all students belonging to a particular Batch Year.
The following reports can be generated:

• STUDENT ATTENDANCE DETAILS: Printable reports can be generated for


an individual as well as a list of students belonging to particular Batch
showing the status of their attendance in all subjects opted by them.

2.1.3 HARDWARE INTERFACES

Screen resolution of at least 800*600 required for proper and complete viewing of
screen and support for printer is also required for printing of reports.

2.1.4 SOFTWARE INTERFACES

Any windows-based Operating system.

MS Access 2000 as the DBMS-for database.

2.1.5 COMMUNICATION INTERFACES

None.

2.1.6 MEMORY CONSTRAINTS

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

2.1.7 OPERATIONS

The Administrator at client site will be responsible for manually deleting old/non
required data. Database backup and recovery will also be handled by administrator.

2.1.8 SITE ADAPTATION REQUIREMENTS

The terminals at client site will have to support hardware and software interfaces
specified in the above sections.

2.2 PRODUCT FUNCTIONS

The system will allow access to only authorized users with specific roles
(administrator, DEO, student, faculty member). Depending upon the role, he/she will
be able to access only specific modules of the system.

A summary of the major functions that the software will perform:

• Login facility for enabling only authorized access to the system.


• DEO will be able to add/modify/delete info about different students enrolled for
the course in different subjects.

• DEO will be able to add/modify/delete info about different subjects that are
offered and opted by students in a particular semester and branch.

• DEO will be able to add/modify/delete info about various faculty members


belonging to a particular department and teaching a particular subject/s.

• DEO will be able to add/modify/delete attendance info in all subjects opted by


all students enrolled in the course.

• Administrator will be able to create/modify/delete new/existing user accounts.

• User( Administrator/ student/ faculty member) will be able to generate and


print reports of student attendance info including the student info as well as
subject info.

2.3 USER CHARACTERISTICS

• Educational Level: At least graduate, should be comfortable with English


language.

• Experience: Should be well-versed/informed about the course structure of


B.Tech. DEO and Administrator must have an experience of at least 3
years.

• Technical Expertise: Should be comfortable in using general-purpose


applications on a computer.

2.4 CONSTRAINTS

Since DBMS is MS Access 2000, which is not very powerful, it will not be able to
store a very huge number of records.

Due to limited features of DBMS being used, database auditing and performance
tuning features will not be provided.

2.5 ASSUMPTIONS AND DEPENDENCIES

• The number of subjects to be taken by a student in each semester does not


change.

• The number of semesters in B.Tech program does not change.


• The attendance once updated is not modified.

2.6 APPORTIONING OF REQUIREMENTS

Not required.

3. SPECIFIC REQUIREMENTS

This section consists of software requirements to a level of detail sufficient to enable


designers to design the system and testers to test the system.

3.1 EXTERNAL INTERFACE REQUIREMENTS

3.1.1 USER INTERFACEES

The following screens will be provided:

LOGIN SCREEN:

This is the first screen displayed. It will allow users to access different screens based
on their role. Various fields will be: Username, Password, Role (Administrator,
Student, Faculty member, DEO).

STUDENT INFO PARAMETERS SCREEN:

This screen will be accessible to user with any role. It will allow the user to enter the
Batch Year for which the user wants to access student info.

STUDENT INFO SCREEN:

This screen will be accessible to user with role DEO. It will allow the user to
add/modify/delete any info about new/existing student/s. Various fields on the screen
will be: Student name, enrollment no., branch, address, phone no., etc...

SUBJECT INFO PARAMETERS SCREEN:

This screen will be accessible to user with any role. It will allow the user to enter the
semester number for which user wants to access the subject info.

SUBJECT INFO SCREEN:


This screen will be accessible to user with role DEO. It will allow the user to
add/modify/delete any info about new/existing subject/s for a particular semester.
Various fields on the screen will be: Subject name, code, credits, type, branch, etc...

FACULTY MEMBER INFO PARAMETER SCREEN:

This screen will be accessible to user with any role. It will allow the user to enter the
department name for which user wants to access the faculty member info.

FACULTY MEMBER INFO SCREEN:

This screen will be accessible to user with role DEO. It will allow the user to
add/modify/delete any info about new/existing faculty member/s. Various fields on
the screen will be: Faculty member name, department, designation, qualification,
experience, salary, teaching subject, etc...

ATTENDANCE INFO PARAMETER SCREEN:

This screen will be accessible to user with any role. It will allow the user to enter the
Batch Year for which the user wants to access the individual or list of students’
attendance info.

ATTENDANCE INFO SCREEN:

This screen will be accessible to user with role DEO. It will allow the user to
add/modify/delete any info about new/existing student attendance. Various fields on
the screen will be: Student info, Subject info, Daily attendance, etc...

REPORT GENERATION PARAMETER SCREEN:

This screen will be accessible to user with any role. It will allow the user to enter the
Batch Year for which the user wants to view and print student attendance info.

3.1.2 HARDWARE INRERFACES

As stated in section 2.1.3.

3.1.3 SOFTWARE INTERFACES

As stated in section 2.1.4.

3.1.4 COMMUNICATION INTERFACES

None

3.2 SYSTEM FEATURES

3.2.1 USER ACCOUNT MAINTENANCE


The system will maintain information about the various user accounts with their
different roles to access the system. The following kinds of user accounts can be
there:

DEO, Administrator, Student, Faculty member.

The following info will be maintained for a particular user account:

Username, Password, Role.

The system will also allow creation/modification/deletion of new/existing accounts by


the administrator.

VALIDITY CHECKS

• Only user with role Administrator will be authorized to access the User
Accounts Maintenance module.

• Username cannot be blank and should be unique for every user.

• Password cannot be blank and should be unique for every user.

• Role cannot be blank.

SEQUENCING INFORMATION

User account for a particular user has to be created in order for the system to be
accessible to that user. At system startup, only a default user account for
‘Administrator’ would be present in the system.

ERROR HANDLING/RESPONSE TO ABNORMAL SITUATIONS

If any of the above validations/sequencing flow does not hold true, appropriate error
messages will be prompted to the user for doing the needful.

3.2.2 STUDENT INFO MAINTENANCE

The system will maintain info. about various students enrolled in the course in
different years. The following info. will be maintained for each student:

Student name, enrollment no., enrollment year, branch, address, phone no.

The system will also allow creation/modification/deletion of new/existing students’


info by the DEO and also the ability to list all the students enrolled in a particular
year.

VALIDITY CHECKS
• Only user with role DEO will be authorized to access the Student Info
Maintenance module.

• Enrollment no. should be unique for every student.

• Student name, Enrollment no., Enrollment year, Branch, Address or Phone


no. cannot be blank.

SEQUENCING INFORMATION

Student info for a particular student will have to be entered in the system before any
attendance info can be entered for that student.

ERROR HANDLING/RESPONSE TO ABNORMAL SITUATIONS

If any of the above validations/sequencing flow does not hold true, appropriate error
messages will be prompted to the user for doing the needful.

3.2.3 SUBJECT INFO MAINTENANCE

The system will maintain info. about various subjects offered to the students of
particular semester and branch of the course. The following info. will be maintained
for each subject:

Subject name, code, credits, type (theory or practical), branch, and semester.

The system will also allow creation/modification/deletion of new/existing students’


info by the DEO and also the ability to list all the available subjects for a particular
semester and branch.

VALIDITY CHECKS

• Only user with role DEO will be authorized to access the Subject Info
Maintenance module.

• Subject code will be unique for every subject.

• No two semesters can have the same subject.

• Subject name, code, credits, type, branch or semester cannot be blank.

• Credits can have value between 0 to 10.

SEQUENCING INFORMATION

Subject info for a particular branch will have to be entered in the system before any
student attendance for that semester can be entered.
ERROR HANDLING/RESPONSE TO ABNORMAL SITUATIONS

If any of the above validations/sequencing flow does not hold true, appropriate error
messages will be prompted to the user for doing the needful.

3.2.4 FACULTY MEMBER INFO MAINTENANCE

The system will maintain info about various faculty members belonging to different
departments teaching the course. The following info will be maintained for each
faculty member:

Faculty member name, department, designation, qualification, experience, salary,


teaching subject/s.

The system will also allow creation/modification/deletion of new/existing faculty


members’ info by the DEO and also the ability to list all the faculty members
belonging to a particular department.

VALIDITY CHECKS

• Only user with role DEO will be authorized to access the Faculty Member Info
Maintenance module.

• Designation should be unique for every faculty member.

• A faculty member cannot belong to more than one department.

• Faculty member name, department, designation, qualification, experience,


salary, teaching subject cannot be blank.

SEQUENCING INFORMATION

Faculty member info for a particular branch can be entered in the system only after
the subject info and student info have been entered.

ERROR HANDLING/RESPONSE TO ABNORMAL SITUATIONS

If any of the above validations/sequencing flow does not hold true, appropriate error
messages will be prompted to the user for doing the needful.

3.2.5 STUDENT ATTENDANCE INFO MAINTENANCE

The system will maintain info. about various students enrolled in the course along
with their subject choice and their daily attendance in that particular subject. The
following info will be maintained for each student:

Student info, Subject info, Daily attendance.


The system will also allow creation/modification/deletion of new/existing students’
attendance info by the DEO and also the ability to list all attendance info for a
student belonging to a particular batch year.

VALIDITY CHECKS

• Only user with role DEO will be authorized to access the Student Attendance
Info Maintenance module.

• Student info, Subject info, Daily attendance cannot be blank.

• Attendance once written cannot be updated and if less than 75%, then
student will not be eligible for semester-end exams.

• Attendance cannot be less than 0 and not greater than 100%

SEQUENCING INFORMATION

Student attendance info for a particular branch can be entered in the system only
after the subject info and student info have been entered.

ERROR HANDLING/RESPONSE TO ABNORMAL SITUATIONS

If any of the above validations/sequencing flow does not hold true, appropriate error
messages will be prompted to the user for doing the needful.

3.2.6 ATTENDANCE REPORT GENERATION

The attendance info reports will be generated for every student enrolled in the
program either for an individual or the whole list of students of a particular batch
year. This report will be generated in the following format:

Attendance Table:

S.NO. FIELD NAME DATA TYPE DESCRIPTION


1. ENROLLMENT INT ENROLLMENT
NO. NO. OF
STUDENT
2. STUDENT STRING NAME OF
NAME STUDENT
3. SEMESTER INT SEMESTER IN
WHICH
STUDENT IS
STUDYING
4. SUBJECT STRING SUBJECT WISE
DETAILS ATTENDANCE
IS
MAINTAINED
5. BRANCH STRING WHICH
BRANCH DOES
THE STUDENT
BELONG TO
6. ATTENDANCE INT TOTAL NO. OF
CLASSES
STATUS
ATTENDED BY
THE STUDENT

VALIDITY CHECKS

User with any role DEO is authorized to access the Student Attendance Report
Generation module.

SEQUENCING INFORMATION

Student attendance info reports for a particular student can be generated by the
system only after the whole student and their subjects info have been entered.

ERROR HANDLING/RESPONSE TO ABNORMAL SITUATIONS

If any of the above validations/sequencing flow does not hold true, appropriate error
messages will be prompted to the user for doing the needful.

3.3 PERFORMANCE REQUIREMENTS

None.

3.4 DESIGN CONSTRAINTS

None.

3.5 SOFTWARE SYSTEM ATTRIBUTES

3.5.1 SECURITY
The application will be password protected. Users will have access to enter correct
username, password and their role in order to access the application.

3.5.2 MAINTAINABILITY

The application will be designed in a maintainable manner. It will be easy to


incorporate new requirements in the individual modules (i.e. student info, subject
info, faculty member info, student attendance info, user accounts info and reports
generation).

3.5.3 PORTABILITY

The application will be easily portable on any windows-based system that has MS
Access 2000 installed.

3.6 LOGICAL DATABASE REQUIREMENTS

The following info will be placed on the database:

• STUDENT INFO: Student name, enrollment no., enrollment year, branch,


address, phone no

• SUBJECT INFO: Subject name, code, credits, type (theory or practical),


branch, and semester.

• FACULTY MEMBER INFO: Faculty member name, department, designation,


qualification, experience, salary, teaching subject/s.

• STUDENT ATTENDACE INFO: Student info, Subject info, Daily attendance.

• USER ACCOUNTS INFO: Username, Password, Role.

3.8 OTHER REQUIREMENTS

None.
USE-CASE DIAGRAM
Student
DEO Maintain Student Information
Log in

Maintain Subject Information


View details

Administrator

Faculty Member
Generate reports Maintain Faculty Information

Maintain User Account Maintain Attendance details


ACTIVITY DIAGRAMS

° Login
USER DATABASE

Enter user id
and password invalid

valid

Prompt for change of


user ID/password

Confirmation for user


ID/password change

Enter new user


ID/password

Update details

Get new user


ID/password
° User Account Maintenance

ADM INIS TRATO R DATABAS E

Search for account in


database

Prompt to edit
account

Ask for new account


Delete/M odify/Add
details
new account details

Get success/error message of Update account in


account updation database
° Accepting Details

DE O D A TA B A S E

Login and prom pt to


edit(add/m odify /delete) inform ation

S earc h for ex is ting s tudent/s ubjec t/fac ulty


m em ber/attendanc e details

E nter new s tudent/s ubjec t /fac ulty


m em ber/attendanc e details

S tore and update s tudent/s ubjec t/fac ulty


m em ber/attendanc e info.

G et s uc c es s /error m es s age
for info. updation
° View and Generate Reports

USER DATABASE

Enter student and subject information


to view attendance information
Search and display student
attendance details in database

View student attendance information

Print student attendance details


Prompt to print reports
reports

Get printed reports of student


attendance details
SEQUENCE DIAGRAMS
° Login
Login Login Checker Login Details/Change
: User
password

1: Enter user id and password


2: Submit details 3: Get login details

User can be
a Student or Teacher
4: Check login

5: Error or sucess message

6: Prompt for password change

7: Confirmation for password change

8: Get new password

9: Enter new password

10: Update details

11: Success or Error message


° User Account Maintenance

Edit
: Administrator : Database

1: Prompt for edit (Add, delete, change)


2: Getting details
3: Searching for details

4: Asking for new details

5: Giving details
6: Entering details
7: Updating details

8: Success or Error message

9: Success or Error message


° Accepting Details

Accepting
: Data Entry : Database
Details
Operator

1: Getting Details

2: Accepting Details

3: Success or Error Message

4: Storing Data
5: Update Details

6: Success or Error message


7: Success or Error message
° View Subject Details
Semester Details Branch Details Subject details
: User : Database
Display Screen Display Screen Display Screen

User can be
a Student or Teacher

1: Prompt For Semester Details 2: Getting Semester Information


3: Searching For Semester Details

4: Success Or Error Message

5: Success Or Error Message

6: Prompt For Branch Details

7: Getting Branch Details


8: Searching For Branch Details

9: Success Or Error Message

10: Success Or Error Message

11: Prompt For Subject Details


12: Getting Subject Details

13: Searching for Subject Details

14: Success Or Error Message

15: Success Or Error Message


° View Student Details

Student Details
: User Display Screen
: Database

User can be
a Student or Teacher

1: Prompt For Enrollment Number2: Getting Student Details

3: Searching For Details

4: Success Or Error Message

5: Success Or Error Message


° View Faculty Details

Employment details
: User : Database
display screen

1: Prompt for details

2: Getting Faculty details

3: Searching for details

4: Success or Error message


5: Success or Error message
° Generating Reports
Report Printing reports
: Administrator Display : Database
Generation Report
Attendance

1: Generate report
2: Getting attendance details
3: Searching for details

4: Generating reports

5: Display report

6: Printing report
COLLABORATION
DIAGRAMS
° Login
Login

1: Enter user id and password


: User

5: Error or success message


7: Confirmation for password change
9: Enter new password

2: Submit details 6: Prompt for password change


8: Get new password
11: Success or Error message

4: Check login
10: Update details
3: Get login details
Login Login Details/Change
Checker password
° User Account Maintenance

1: Prompt for edit (Add, delete, change)


: Administrator 5: Giving details

4: Asking for new details


9: Success or Error message
Edit

3: Searching for details


7: Updating details 8: Success or Error message

2: Getting details
6: Entering details

: Database
° Accepting Details

5: Update Details

: Data Entry : Database


Operator

1: Getting Details 4: Storing Data

6: Success or Error message


3: Success or Error Message
2: Accepting Details
7: Success or Error message

Accepting
Details
° View Subject Details
3: Searching For Semester Details
8: Searching For Branch Detail
13: Searching for Subject Details

1: Prompt For Semester Details

4: Success Or Error Message


Semester Details
: User : Database 2: Getting Semester Information Display Screen
5: Success Or Error Message

11: Prompt For Subject Details


7: Getting Branch Details
14: Success Or Error Message
6: Prompt For Branch Details 12: Getting Subject Details
10: Success Or Error Message
15: Success Or Error Message
9: Success Or Error Message

Branch Details Subject details


Display Screen Display Screen

° View Student Details


1: Prompt For Enrollment Number
: User

5: Success Or Error Message

Student Details
Display Screen

4: Success Or Error Message


3: Searching For Details

2: Getting Student Details

: Database
° View Faculty Details

1: Prompt for details


: User

5: Success or Error message


Employment details
Display screen

4: Success or Error message

3: Searching for details

2: Getting Faculty details

: Database
° Generating Reports
4: Generating reports 3: Searching for details

2: Getting attendance details


Report
Generation

: Database
6: Printing report

5: Display report
Printing
1: Generate report reports

Display Attendance
Report

: Administrator
CLASS DIAGRAM
STUDENT INFO
LOGIN SUBJECT INFO
NAME
USER ID SUBJECT NAME
ENROLLMENT NO.
PASSWORD CREDITS
ENROLLMENT YEAR
CODE
SEMESTER
LOGINCHECKER() SEMESTER
BRANCH
CHANGEPASSWORD() BRANCH
ADDRESS
ADDUSER() PHONE NO.
DELETEUSER() ADD()
MODIFY()
ADD()
DELETE()
MODIFY()
DELETE()

FACULTY MEMBER
INFO
NAME
DEPARTMENT
DESIGNATION REPORT GENERATION
QUALIFICATION
EXPERIENCE GENERATEREPORT()
SALARY
ATTENDANCE INFO
ADD() DAILY ATTENDANCE
MODIFY()
DELETE() ADD()
MODIFY()
STATE TRANSITION
DIAGRAM
Verification

System Login
Login Use
checker Screen
Enter login id and password Access granted

Detail Type Selection

Generating Reports View


Details

Logging out
Report
Generation

Logging out

System Exit
DATA FLOW DIAGRAMS

° LEVEL-0
° LEVEL-1
E-R DIAGRAM

You might also like