Online Attendance Management System

PROBLEM STATEMENT

(Online Attendance Management)

To design a software for marking the attendance of

students in a class in university while keeping a

track of the course details of various branches in

the university.

The university database will contain primary details

of all the students in accordance with their semester

number.

The system for marking the attendance will be

based on the login id and password of respective

users.

All the faculty members/ employee would be

provided with the above mentioned login details.

Depending on economic issues, the system may be

embedded in the classrooms or the users may

access using their own PC’s.

The system should also keep a track of details of

the courses in the university.

The faculty member should transfer all the details to

the university server from time to time so as to

highlight the details of those with lower attendance.

The system would present the roll numbers of

students in a column beside which the faculty

members may mark the student’s attendance.

INITIAL REQUIREMENTS DOCUMENT Title of the project Online Attendance Management

Stakeholders involved in

capturing requirements

Administrator, Faculty, Project leader, Students.

Techniques used in requirement

capturing

Interviewing

brainstorming

Name of the persons along with

designation

Dr. Ruchika Malhotra (Ph.D)

Ashwini Sir (M. Tech, DTU)

Anshuj Kumar

Nidhi Kapoor

Sahaj Biyani

Tanuj Mittal

Date August 02, 2011

Version 1.0

Consolidate list of initial requirements:

1. A system is to be implemented which can mark attendance of students in a

university.

2. A user friendly interface should be used to facilitate the process of marking the

attendance.

3. There are three types of members in the system: Administrator, Faculty and

Students.

4. The administrator shall be able to maintain details of all the students along with

their semester and branch details.

5. The administrator shall be able to maintain details of all the faculty members

along with their course details.

6. The system shall calculate the total number of presents of a student at the end

of each month.

7. The system shall be able to display a warning message for the students who

have less than 75% attendance.

8. The administrator shall then send mails to the parents/ guardians of the

students with short attendance.

USE CASE DIAGRAM

maintain student details

maintain member details

maintain course details

DEO

Student

admin

login

mark attendance

view attendance

Generate Reports

Faculty

CLASS DIAGRAM

LoginInterface LoginEntity

DeoEntity FacultyEntity

DeoInterface

LoginController

CourseEntity

MemberEntity

DeoController

FacultyInterface

MarkAttendanceControll

er

FacultyController

StudentEntity AttendanceDetailsEntit

y

AdminInterface

MaintainCourseDetailsCo

ntroller

MaintainMemberDetailsC

ontroller

MaintainStudentDetailsC

ontroller

GenerateReportsControlle

r

StudentInterface

ViewAttendanceControlle

r

StudentController

AdminController

SRS

1. Introduction

1.1. Purpose

The purpose of this document is to present a detailed description of the

Online Attendance Management System. It will explain the purpose and

features of the system, the interfaces of the system, what the system will do, the

constraints under which it must operate and how the system will react to the

external stimuli. This document is intended for both the stakeholders and the

developers of the system & will be proposed to the University for approval.

1.2. Scope

The software system is named as Online Attendance Management System

(OAMS) and will be referred as OAMS in the rest of SRS document. The

proposed OAMS will be able to perform following functions:

Issue of login credentials to the system operators.

Maintain attendance details of the students and faculty in the

university.

Maintain details of programs, departments and coOAMSes offered by

the University (for attendance purpose).

Maintain paper schemes and registration details of the university

students.

Online registration of the students at the commencement of a new

session.

Shortlisting students in case of low attendance.

Generate the following reports:

o List of departments in the university.

o List of programs and coOAMSes offered by the university.

o List of students with short attendance classified on basis of

different course and batches.

The proposed system is not supposed to perform following functions:

Maintain students‟ admission details.

Management of students‟ results.

Management of students‟ fee submission and dues.

Management of student‟s library account details.

The OAMS will provide following benefits to the university:

Easy maintenance of the attendance records of students and faculty in

the university.

Generation of reports of students with short attendance.

Use of computer system to mark attendance of a student.

Generation of various reports.

1.3. Glossary

The various definitions, acronyms and abbreviations used in the OAMS

are given as:

SRS: Software Requirements Specifications.

OAMS: Online Attendance Management System.

System Administrator/Administrator: User having all the privileges

to operate the OAMS.

Data Entry Operator (DEO): User having privileges to maintain

department, program, scheme, faculty, paper and student details.

System Operator: System Administrator, Data Entry Operator.

Faculty: (Teacher of University) User having privileges to mark

attendance for a student.

Student: Any candidate admitted in a program offered by the

university.

User: Student, Faculty.

RAM: Random Access Memory.

1.4. References

Following references are used in the OAMS:

IEEE Recommended Practice for Software Requirements

Specifications – IEEE Standard 830-1998.

„Software Engineering‟ by K.K. Aggarwal and Yogesh Singh, New

Age Publishing House, 3rd

Edition, 2008.

1.5. Overview

The next chapter, the Overall Description section, of this document gives

an overview of the functionality of the system. It describes the informal

requirements and is used to establish the context for the technical requirements

specifications in the next chapter.

The third chapter, the Specific Requirements section, of this document is

written primarily for the developers and describes in technical terms the details

of the functionality of the system.

Both sections of the document describe the same software product in its

entirety, but are intended for different audiences and thus use different

languages.

2. The Overall Description

2.1 Product Perspective

System Block Diagram

The OAMS has four actors and one cooperating system. The faculty and

the student access the system through the internet. The administrator and data

entry operator communicate with the system directly. The system is linked to

some external data systems used by the university.

2.1.1.System Interfaces

The OAMS will be developed using client/server architecture. It will be

compatible with any operating system that can run a JavaScript enabled web

browser. The front-end of the system will be developed using HTML, PHP and

JavaScript and the backend of the system will be supported by a XAMMP

server.

2.1.2 User Interfaces

The system will have following user-friendly and menu-driven interfaces:

Login

This interface is to allow only the authorized users to enter into the

system.

Maintain Student Records

DEO/Administrator will register students at the beginning of every

new semester using this interface for different courses.

Maintain Member Details

The system administrator may add/delete/modify member records

using this interface.

Maintain Course Details

The system administrator/DEO may add/delete/modify the details

of programs offered by the university using this interface.

Generate Report

Several reports may be generated using this interface. This

interface will be available to the system administrator only.

Different reports that may be generated are:

o Attendance List of courses on batch basis in the university.

o List of students with short attendance for a course.

Mark Attendance

o This use case is used by the faculty member only so as to mark

attendance of a student.

View Attendance

Administrator/Faculty/Student can use this use case to view the

attendance.

o Student can view only his/her attendance

o Faculty can view attendance of the batches he/she teaches.

o Administrator can view attendance of anyone and any

course/batch.

2.1.3 Hardware Interfaces

Following hardware interfaces must be provided by the university for

proper functioning of the system:

Screen resolution of at least 800 by 600 or above.

Support for a printer – dot matrix, laser jet or inkjet.

Networked computer systems with CPU configuration of at least500

MHz or above.

2.1.4. Software Interfaces

The software interfaces for the OAMS are as follows:

Microsoft Windows Operating System (NT/XP/Vista/7)

JavaScript enabled web browser (Google Chrome/Mozilla Firefox

2+/Opera 7+ /Internet Explorer 6.0+) for front-end.

XAMMP Server for development of back-end.

2.1.5. Communication Interfaces

The Online Attendance Management System shall use Local Area

Network (LAN) for communication among the server and client terminals. The

LAN may or may not be connected to the internet.

2.1.6. Memory Constraints

The server machine will require at least 256 MB of RAM and 768 MB

space of hard disk to run the software. The clients will require at least 128 MB

of RAM to communicate with the system.

2.1.7. Site Adaptation Requirements

The client terminal will have to support the hardware, software interfaces

specified in sections 2.1.3 and 2.1.4 respectively. It must also adhere to the

memory constraints specified in section 2.1.6.

2.2. Product Functions

The major functions that OAMS shall perform can be summarized as

follows:

A login facility to allow only the authorized access to the system.

The system administrator/DEO will be able to add/modify/delete or

view student, faculty and login information.

Faculty will be able to mark attendance of a student for a course and a

branch.

System should be able to generate reports on the basis of various

criterions such as :

o Student

o Branch

o Course

o Faculty

2.3. User Characteristics

Qualification: Should be at least matriculate and comfortable with

English.

Experience: Should be well informed about the course details of the

university.

Technical Experience: Users should have elementary knowledge of

computers and internet browsing. The system administrators/DEO

must have knowledge of the internals of the system and be able to

rectify small problems that may arise due to power failures, disk

crashes and other catastrophes to maintain the system.

2.4. Constraints

The Attendance Management System is connected to the university‟s

main server and is running 24 hours .

The users access the OAMS from any computer that has internet

browsing capabilities and an internet connection.

The users must have their correct usernames and passwords to enter

into the OAMS.

2.5. Assumptions and Dependencies

The academic section will provide the list of admitted students in the

university.

The establishment section will provide the list of faculty members in

the university.

Details of different programs, departments, papers and courses offered

will be provided by the university.

The login credentials for every new member of OAMS must be

created by the System Administrator/DEO and communicated to the

concerned member confidentially to avoid unauthorized access to the

system.

3. Specific Requirements

3.1 External Interfaces

3.1.1. Login

Username Alphanumeric. Minimum length of 6 characters. No special

character except underscore is allowed.

Password Alphanumeric. Minimum length of 8 characters.

3.1.12. Add Student

Name Text with spaces allowed.

Program Text with spaces allowed.

Roll No. Alphanumeric text with forward slashes allowed.

Reg. No. Alphanumeric text with forward slashes allowed.

Year of Admission Numeric with value between 2000 and 2100.

Address Text.

Contact No. Numeric with minimum length 10. One ‘+’ and ‘-‘ allowed.

E-Mail Address E-Mail address standard.

3.1.14. Add Faculty


Department Text with spaces allowed.

Designation Text with spaces allowed.



Address Text.

Qualification Text.

3.1.14. Add Faculty


Department Text with spaces allowed.

Designation Text with spaces allowed.



Address Text.

Qualification Text.

3.2 Functions

3.2.1 Login

1.1 INTRODUCTION

This use case is used describes how a user logs in to the University

Management System.

1.2 ACTORS

Administrator, Student, Faculty, Data Entry Operator (DEO).

1.3 PRE CONDITION

The user must have a valid login id.

1.4 POST CONDITION

If the user name and password are correct, the user is logged on to the system. If

not, the system state is unchanged.

1.5 BASIC FLOW

1. The user is asked to enter login id and password.

2. The user enters login id and password.

3. The system validates the login id and password, recognizes the role of the

user and logs him/her into the system.

1.6 ALTERNATE FLOW

1. If the user name does not exist, display an error message.

2. If the password does not match with the valid user name, display an error

message.

1.7 SPECIAL REQUIREMENTS

None

1.8 RELATED USECASES

None

3.2.2. Manage Student Details

2.1 INTRODUCTION

This use case is used by for adding, editing and viewing a student record.

2.2 ACTORS

Administrator, DEO

2.3 PRE CONDITION

The user must be logged on.

2.4 POST CONDITION

At the end of the use case, the student‟s details are added/updated in the

database respectively and all entries are time-stamped.

2.5 BASIC FLOW

After successful login, user selects from the following options as per the

requirement :

Add Student

Edit Student

View Student details

Delete Student

Basic Flow 1:

Add student:

the user enters the specific details of the student such as:

name

Roll no.

address

branch

Semester

Course

If all details are entered and submitted, new entry to the database is made.

Basic Flow 2 : Edit student:

User specifies the roll number for the student whose details are to be modified

and changes the required values .Respective changes are made to the database.

Basic Flow 3 : View student details

User specifies the roll number of the student whose details are to be seen and

views the details.

Basic Flow 4 : Delete Student

User enters Roll no of student to be deleted and the student details are removed

from system after final confirmation from user.

2.6 ALTERNATE FLOW

Alternative flow 1:

User enters wrong details during addition/edition of student. System prompts

user to enter the details entered incorrectly.

Alternative flow 2

User exists during the process. System closes the use case.

Alternative Flow 3 :

User's session expires and system is redirected to login page i.e use case exists.

Alternative flow 4 :

User enters wrong roll number i.e is not present in the system. System is

redirected to start of use case(edit).

2.7 Related use case :

Login

2.8 Special Requirements : None

3.2.3. Maintain Member Details

3.1 INTRODUCTION

This use case allows the administrator to create/delete/edit members of the

system.

3.2 ACTORS

Administrator

3.3 PRE CONDITIONS

The user should be logged on to the system.

3.4 POST CONDITIONS

If the use case is successful, the required task of creating/deleting/editing of

member is done and the database is updated. If not, then the system state

remains unchanged.

3.5 BASIC FLOW

1. The system asks the user to enter the type of member to be

created/edited./deleted.

2. Depending on the choice, one of the following sub-flows is executed:

If the user enters “Faculty Member creation”, then Faculty creation sub-

flow is executed.

If the user enters “DEO creation”, then DEO creation sub-flow is

executed.

If the user enters “Member editing”, then edit sub-flow is executed.

If the user enters “Member deleting”, then delete sub-flow is executed.

3.5.1 Faculty creation (Basic Flow 1)

1. The user is asked to enter the following details of the faculty member :

Name

Department

Subjects

Designation

Time table details

User id

Password

Employee id

2. After all details have been entered, system verifies for an error and is all

correct, the database is updated. List of students is displayed by the

system.

3. After faculty creation, the schedule for the faculty member is entered into

the system and the database is updated with the new schedule.

3.5.2 DEO creation(Basic flow 2)

1. The user is asked to enter the following details for DEO :

Name

Age

User Id

Password

Employee id

2. After all details have been entered and verified by the system, database is

updated.

3.5.3 Member edit

1. The user is asked to enter the employee id.

2. He/she edits the information to be changed.

3.5.4 Member Delete

1. The user is asked to enter the employee id.

2. Account for that member is deleted after final confirmation.

3.6 ALTERNATE FLOW

1. If the administrator exits suddenly, then state of the system remains

unchanged (goes back to initial point).

2. If database full for adding new member, system shows error message and

use case exits.

3. If any details of member are filled incorrectly, then system shows error

message and system state remains unchanged.

4. Employee id of member not found for editing the account or for deleting,

then system shows error message and state remains unchanged.

5. While entering the schedule for a faculty member is entered, there are any

problems with the existing schedule and so the system shows error for the

entered schedule.


None


Login

3.2.4. Manage Course details

4.1 INTRODUCTION

This use case allows the administrator/DEO to create/delete/edit courses of the

university.

4.2 ACTORS

Administrator, DEO.

4.3 PRE CONDITIONS


4.4 POST CONDITIONS

If the use case is successful, the required task of creating/deleting/editing of

course is done and the database is updated. If not, then the system state remains

unchanged.

4.5 BASIC FLOW

1. The system asks the user to choose from following options :

Create a new course.

Edit existing details.

Delete existing course.

2. Depending on the choice, one of the following sub-flows is executed:

If the user enters “Create a new course”, then create course sub flow is

executed.

If the user enters “Edit course”, then edit course sub-flow is executed.

If the user enters “Delete course”, then delete course sub-flow is

executed.

4.5.1. Create Course (Basic Flow 1)

1.The user is asked to enter the following details of the course member :

Course code

Department

Subjects

Name

Credits

Max students in a batch

2. After all details have been entered, system verifies for an error and is all

correct, the database is updated.

4.5.2. Edit Course(Basic flow 2)

1. The user is asked to enter the course code and after its verification, he/she

can make changes for the course as required.

4.5.3 Delete Course

1. The user is asked to enter the course code.

2. After his/her final confirmation for deleting the course, the course is

removed from the database.

4.6 ALTERNATE FLOW

1. If the user exits suddenly, then state of the system remains unchanged

(goes back to initial point).

2. If database full for adding new course, system shows errors message (no

new courses can be added as system is full) and use case exits.

3. If any details of member are filled incorrectly, then system shows error

message and system state remains unchanged.

4. Course code not found for editing or for deleting, then system shows error

message and state remains unchanged.


None


Login

3.2.5. Generate report

6.1. INTRODUCTION

This use case is used for generating a report of attendance.

6.2. ACTORS

Administrator ,DEO , Faculty

6.3. PRE-CONDITION

The user must be logged in.

6.4. POST-CONDITION

If the use case is successful; attendance report is generated and the database

is updated for it.. If not, the system state remains unchanged.

6.5. BASIC FLOW

1. Depending upon user type, following sub-flows are executed :

If user is faculty, faculty report generation sub flow is generated

If user is Admin/DEO admin report generation sub flow is executed.

6.5.1 Basic flow 1(Faculty report generation)

User select from following options of reports to be generated :

o Batch & year Wise (for those with the faculty as a part).

o Short attendance list for a batch of a particular year (only those

who are under the current user).

6.5.2 Basic flow 2 (Admin report generation)

User selects from the following type of reports :

o Year and batch wise (shows attendance of all students).

o Short attendance (specifying the year and batch).

o Report for a student can also be generate by entering his/her roll

number.

6.6. Alternate flows

6.6.1 Alternate flow 1

User exits in midst of an operation.

System state remains unchanged and it exits


Wrong details entered for report generation.

Use case returns to beginning.


Wrong Roll no. entered by the user.

System state remains unchanged and an error message for wrong roll

number is shown.

6.7. SPECIAL REQUIREMENTS

None

6.8. RELATED USECASES

Login, Maintain Student Details, Print

3.2.7. View attendance

7. REGISTER

7.1. INTRODUCTION

This use case is used by a student for viewing his/her attendance.

7.2. ACTORS

Student

7.3. PRE-CONDITION


7.4. POST-CONDITION

If the use case is successful, then also the system state remains unchanged.

7.5. BASIC FLOW

1. The user is again asked to enter his/her roll for viewing attendance.

2. The system validates the roll number of the student and his attendance is

how to him.

7.6. ALTERNATE FLOW

7.6.1. Invalid Roll no.

If the roll no. entered is incorrect or invalid, display an error message and

return to basic flow.

7.6.2. User Exits

If the user exits suddenly, then the system remains unchanged.

7.7. SPECIAL REQUIREMENTS

None

7.8. RELATED USECASES

Login.

3.3. Performance Requirements

The performance requirements for the OAMS are as follows:

Should support at least 20 users simultaneously.

Should run on 1GHz, 256 MB RAM machine.

Responses should be within 0.5 seconds.

3.4. Logical Database Requirements

3.4.1. Student Data Entity

Data Item Type Description Comment

Name Text Name of the student

Course Code Char(10) Course code

Roll No. Numeric Roll no of the student in

university‟s records

Unique

Year Numeric Year of enrollment in

university

Address Alphanumer

ic

Residential address

Phone Number Numeric Contact no. May be

several

E-Mail Address Alphanumer

ic

E-mail address

Semester Integer Current semester of student

3.4.2. Member Data Entity


Name Text Name of the faculty

Designation Text Designation

Phone Number Integer Contact number May be

several

Address Alphanumeric Residential address

Department Integer Department of teacher

Identification

No.

Integer Unique identification

number of faculty in

university‟s records

Unique

3.4.3. Course Data Entity


Course ID String Unique identification number

of course in university‟s

records

Unique

Course Name Text Department‟s name

Credits Integer Credits for the course

3.4.4. Batch data entity(created new every year)


Student roll String Roll number of students in

the batch

Unique and

last row

contains

number of

classes held

for a course

Course code 1 Integer Course code for course






3.4.5. Short attendance list


Roll number String Student roll number Unique

Branch Integer Branch for which scheme is

designed

Semester Integer Semester for which scheme is

designed

Course code String Course in which attendance is

short

3.4.6. Paper Data Entity


Paper Code Alphanumeric Unique identification code

for paper in university‟s

records

Unique

Subject Name Text Subject‟s name

Syllabus Text Syllabus for the paper

Credits Integer Credits for the paper

Scheme Integer Scheme for which paper is

designed

May be

several

3.4.7. login Data Entity


Account Type Integer Type of account: Student,

Faculty, Administrator, DEO

Actor name string Actor who owns the account Unique

Username Alphanumeric Username of account holder Unique

Password Alphanumeric Password for the account

3.5. Design Constraints

3.5.1. Software Language Used

The languages that shall be used for coding the Online Attendance Management

System are HTML, CSS, JavaScript and PHP. For working on the coding phase

of the University Registration System, the XAMMP server needs to be installed.

3.5.2. Development Tools

System will make use of available web development toolkits like Notepad++

and Adobe Dreamweaver along with use of online references available for

developing systems using HTML, CSS, JavaScript and PHP.

3.6. Software System Attributes

3.6.1. 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.

The system is user friendly and self-explanatory.

3.6.2. Reliability

The system has to be very reliable due to the importance of data and the

damages incorrect or incomplete data can do.

3.6.3. 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.

3.6.4. Mean Time Between Failures (MTBF)

The system will be developed in such a way that it may require

maintenance every 6 months.

3.6.5. Mean Time to Repair (MTTR)

Even if the system fails, the system will be recovered back up within an

hour or less.

3.6.6. Accuracy

The accuracy of the system is limited by the accuracy of the speed at

which the employees of the university and users of the university use the

system.

3.6.7. Access Reliability

The system shall provide 100% access reliability.

3.6.8. Response Time

The Splash Page or Information page should be able to be downloaded in

less than a minute using a 56K modem. The system shall respond to the

member in not more than half a second from the time of the request

submittal. The system shall be allowed to take more time when doing

large processing jobs.

3.6.9. System Administrator/DEO Response

The system shall take as less time as possible to provide service to the

system administrator or the DEO.

3.6.10. Throughput

The number of transactions is directly dependent on the number of users;

the users may be the system administrator, DEO, faculty or the students

of the university.

3.6.11. Capacity

The system is capable of handling 100 users at a time.

Admin/DEO

Admin

Admin/DEO

Login Interface Login Details

Faculty

Course Details InterfaceCourse Entity

Maintain Course Details Controller

Student Details Interface

Maintain Student details Controller

Member Details Interface

Member Entity

Maintain Member Details Controller

Mark Attendance Interface

Mark Attendance

Generate report interface

Batch Entity

Generate Report Controller

short attendance entity

Part of

schedule

For faculty

member only

Admin/DEO/Faculty

Login Controller

11

11

11

student only

view attendancecontrol

Student Entity


Maintain Student Details

Maintain course details

View Attendance

StudentLogin

Mark Attendance

Administrator

DEO

Generate Reports

Faculty

LOGIN ACTIVITY DIAGRAM

enter login id,

password, role

user logged in

successfully

login

unsuccessful

[details=invalid]

[details=valid]

MAINTAIN MEMBER DETAIL ACTIVITY DIAGRAM

MAINTAIN COURSE DETAIL ACTIVITY DIAGRAM

maintain

member details

maintain

faculty detailsmaintain DEO

details

add faculty

detailsupdate faculty

detailsadd DEO

details

delete DEO

details

update DEO

detailsdelete faculty

details

[member=DEO][member=faculty]

[choice=add]

[choice=update]

[choice=delete]

[choice=delete]

[choice=update] [choice=add]

maintain course

details

add course

details

update course

details

delete course

details

[choice=delete]

[choice=update]

[choice=add]

MAINTAIN STUDENT DETAIL ACTIVITY DIAGRAM

maintain

student details

add student

details

delete student

details

update student

details

[choice=update]

[choice=delete]

[choice=add]

COLLABORATION DIAGRAM – LOGIN BASIC FLOW

user : admin : LoginInterface

: LoginController

: LoginEntity

1: enter login id2: enter password

3: enter role4: enter(login id, password, role)

5: enter(login id, password, role)

6: validate(login id, password, role)

7: validated

COLLABORATION DIAGRAM – LOGIN BASIC FLOW

user : admin : LoginInterface

: LoginController

: LoginEntity

1: enter login id2: enter password

3: enter role4: enter(login id, password, role)

5: enter(login id, password, role)

6: validate(login id, password, role)

7: invalid (login id, password, role)



COLLABORATION DIAGRAM – MAINTAIN STUDENT DETAIL

(ADD) BASIC FLOW

: DEO : DeoController

:

MaintainStudentDetailsController

: DeoInterface

: StudentEntity

3: Maintain Student Details

4: Add/Delete/Update

9: add

10: create student object

11: successful creation

12: enter details

17: enter(name, roll no, sem, branch)

18: add new record

19: record added successfully


2: Maintain Student Details8: add

16: enter(name, roll no, sem, branch)

5: Add/Delete/Update13: enter details


1: Maintain Student Details7: add

15: enter(name, roll no. sem, branch)

6: add/ delete/ update14: enter details


(DELETE) BASIC FLOW

: DEO : DeoInterface

: DeoController

:


: StudentEntity






6: add/ delete/ update

7: delete

8: delete

9: delete

10: enter roll number



13: roll number

14: roll number

15: roll number

16: delete(roll no)17: deleted

18: deleted

19: deleted


(MODIFY) BASIC FLOW


: DeoController

:


: StudentEntity







7: edit student details






13: roll number

14: roll number

15: roll number

16: validate(roll no)

17: validated

18: fetch details

19: details

20: details

21: details

22: details

23: update(roll no, name, sem, branch)



26: update record


(ADD) ALTERNATE FLOW 1

: DEO

: DeoInterface

: DeoController

: MaintainStudentDetailsController

: StudentEntity







7: add

8: add

9: add


11: unsuccessful creation






: DeoController


: StudentEntity







7: add

8: add

9: add


11: cretion successful. enter details

12: creation successful. enter details

13: creation successful. enter details

14: enter details.

15: enter(roll no, name, sem, branch)




19: redundancy

20: redundancy

21: redundancy


(DELETE) ALTERNATE FLOW


: DeoController


: StudentEntity







7: delete

8: delete

9: delete




13: roll number

14: roll number

15: roll number

16: delete(roll no)

17: roll no not found

18: roll number not found

19: roll number not found


(MODIFY) ALTERNATE FLOW


: DeoController


: StudentEntity













13: roll number

14: roll number

15: roll number

16: validate(roll no)

17: roll no. not found



COLLABORATION DIAGRAM – MAINTAIN COURSE DETAIL

(ADD) BASIC FLOW


: DeoController : MaintainCourseDetailsController

: CourseEntity

1: Maintain Course Details






7: add

8: add

9: add

10: Create Course Object11: Created Successfully

12: enter details

13: enter details

14: enter details

15: enter(course name, course code,sem,branch,faculty)



18: add new record19: record added successfully

20: record added successfull

21: record added successfull


(DELETE) BASIC FLOW

: DEO

: DeoInterface

: DeoController

: MaintainCourseDetailsController

: CourseEntity







7: delete

8: delete

9: delete

10: enter course code



13: course code

14: course code

15: course code

16: delete(course code)

17: deleted

18: deleted

19: deleted


(MODIFY) BASIC FLOW

: DEO

: DeoInterface


: CourseEntity

1: Maintain course Details






7: edit course details






13: course code

14: course code

15: course code

16: validate(course code)

17: validated

18: fetch details

19: details

20: details

21: details

22: details

23: update(course code, name, sem, branch, faculty)



26: update record



: DEO

: DeoInterface

: DeoController


: CourseEntity







7: add

8: add

9: add

10: Create Course Object11: Created Successfully

12: enter details

13: enter details

14: enter details




18: add new record19: course code already exists

20: course code already exists

21: course code already exists



: DEO

: DeoInterface


: CourseEntity

1: Maintain member Details






7: add

8: add

9: add

10: create member object





(DELETE) ALTERNATE FLOW 1

: DEO

: DeoInterface

: DeoController


: CourseEntity







7: delete

8: delete

9: delete




13: course code

14: course code

15: course code

16: delete(course code)17: course code invalid

18: course code invalid






: StudentEntity







7: delete

8: delete

9: delete




13: course code

14: course code

15: course code

16: delete(course code)

17: course code not found




(MODIFY) ALTERNATE FLOW 1


: DeoController


: CourseEntity













13: course code

14: course code

15: course code

16: validate (course code)17: course code invalid



COLLABORATION DIAGRAM – MAINTAIN MEMBER DETAIL

(ADD FACULTY) BASIC FLOW


: DeoController

: MaintainMemberDetailsController

: FacultyEntity

1: Maintain Member Details






7: add

8: add

9: add

10: Faculty/DEO

11: Faculty/DEO

12: Faculty/DEO

13: Faculty

14: Faculty

15: Faculty

16: create faculty object


18: enter details

19: enter details

20: enter details

21: enter(username,password,name)



24: add new record





(DELETE) BASIC FLOW

: DeoController

: DEO

: DeoInterface


: DeoEntity







7: delete

8: delete

9: delete

10: username

11: username

12: username

13: username

14: username

15: username

16: delete faculty object

17: successful deletion




(MODIFY) BASIC FLOW

: DEO

: DeoInterface

: DeoController


: MemberEntity







7: update

8: update

9: update

10: enter username

11: enter username

12: enter username

13: username

14: username

15: username

16: validate(username)17: validated18: fetch details19: details

20: details

21: details

22: details

23: update(details)

24: update(details)

25: update(details)

26: update record


(ADD DEO) BASIC FLOW

: DeoController


: MaintainMemberDetailsController : DeoEntity



3: Maintain Member Details4: Add/Delete/Update



7: add

8: add

9: add10: Faculty/DEO

11: Faculty/DEO

12: Faculty/DEO

13: DEO

14: DEO

15: DEO

16: create faculty object


18: enter details

19: enter details

20: enter details




24: add new record





(ADD DEO) ALTERNATE FLOW 1


: DeoController : MaintainMemberDetailsController

: DeoEntity







7: add

8: add

9: add

10: create membert object11: unsuccessful creation




(ADD DEO) ALTERNATE FLOW 2


: DeoController


: DeoEntity







7: add

8: add

9: add

10: Create member Object

11: Created Successfully

12: enter details

13: enter details

14: enter details

15: enter(username, password, name)



18: add new record

19: username already exists




(ADD FACULTY) ALTERNATE FLOW 1

: DEO

: DeoInterface

: DeoController


: FacultyEntity







7: add

8: add

9: add

10: create membert object11: unsuccessful creation




(ADD FACULTY) ALTERNATE FLOW 2


: DeoController : MaintainMemberDetailsController

: FacultyEntity







7: add

8: add

9: add

10: Create member Object11: Created Successfully

12: enter details

13: enter details

14: enter details




18: add new record19: username already exists





: DeoController

: DEO

: DeoInterface


: MemberEntity







7: delete

8: delete

9: delete

10: username

11: username

12: username

13: username

14: username

15: username

16: delete member object

17: username invalid





: DEO

: DeoInterface

: DeoController


: MemberEntity







7: update

8: update

9: update

10: enter username

11: enter username

12: enter username

13: username

14: username

15: username

16: validate(username)17: username invalid



COLLABORATION DIAGRAM – MARK ATTENDANCE BASIC

FLOW

: Faculty

: FacultyInterface

: FacultyController : MarkAttendanceController

: AttendanceDetailsEntity

1: Mark Attendance

2: Mark Attendance

3: Mark Attendance

4: Select Subject Code



7: Subject Code

8: Subject Code

9: Subject Code

10: Subject Code

11: List of Students




15: Mark and Submit

16: Mark and Submit

17: Submit

18: Submit

19: Submitted successfully

20: submitted successfully



TEST CASE MATRIX FOR LOGIN USE CASE

TEST CASE

SCENARIO AND DESCRIPTION

NAME

INPUT EXPECTED OUTPUT

REMARKS (If Any) Role Username Password

TC1 Scenario 1- Login Basic Flow

Student valid valid Student is logged in

TC2 Scenario 1 – Login Basic Flow

Faculty valid valid Faculty is logged In

TC3 Scenario 1 – Login Basic Flow

DEO valid valid DEO is logged In

TC4 Scenario 1 – Admin valid valid Admin is

Login Basic Flow

Logged In

TC5 Scenario 2 – Login Alternate Flow

Student Invalid Valid/invalid Invalid Username

Username doesn’t exist in database


Faculty valid invalid Invalid Password

Password doesn’t exist in database


DEO Invalid Valid/invalid Invalid Username

Username and Password doesn’t exist in database


Administrator Valid invalid Invalid Password

Password doesn’t exist in database

TEST

CASE

SCENARIO AND

DESCRIPTION NAME

INPUT EXPECTED

OUTPUT

REMARKS (If Any) Operati

on Course name

Course code

Semester

Branch

Faculty

TC1 Scenario 1- Maintain Course Detail Basic Flow

Add valid valid valid valid valid Course detail added successfully


Delete valid valid valid valid valid Course detail deleted successfully


Modify valid valid valid valid valid Course detail modified successfully

TC4 Scenario 2- Maintain Course Detail Alternate Flow

Add valid invalid

valid valid valid Could not add course detail

Already exists


Add valid valid valid valid valid Could not add course detail

Unsuccessful Creation


Delete valid invalid

valid valid valid Could not delete course detail

Course Code not found


Delete valid valid valid valid valid Could not delete course detail

Unsuccessful Deletion


Modify valid invalid

valid valid valid Could not modify course detail

Not found

TEST CASE MATRIX FOR MAINTAIN COURSE DETAIL USE CASE

TEST CASE MATRIX FOR MAINTAIN MEMBER DETAIL USE

CASE

TEST CAS

E

SCENARIO AND

DESCRIPTION NAME


REMARKS (If Any)

Role Operation

Name

Username

Password

TC1 Scenario 1- Maintain Faculty

Detail Basic Flow

Faculty

Add valid valid valid Faculty detail added successfully


Detail Basic Flow

Faculty

Delete valid valid valid Faculty detail deleted successfully


Detail Basic Flow

Faculty

Modify valid valid valid Faculty detail modified successfully

TC4 Scenario 2- Maintain

DEO Detail Basic Flow

DEO Add valid valid valid DEO detail added successfully

TC5 Scenario 2- Maintain

DEO Detail Basic Flow

DEO Delete valid valid valid DEO detail deleted successfully

TC6 Scenario 2- DEO Modify valid valid valid DEO detail

Maintain DEO Detail Basic Flow

modified successfully

TC7 Scenario 3-Maintain Faculty Detail

Alternate Flow

Faculty

Add valid valid valid Already Exists


Alternate Flow

Faculty

Add valid valid valid Unsuccessful due to technical reasons


Alternate Flow

Faculty

Delete -- Invalid -- Does not exist

TC10

Scenario 3-Maintain Faculty Detail

Alternate Flow

Faculty

Modify -- Invalid Does not exist

TC11


Alternate Flow

Faculty

Modify valid valid valid Unsuccessful due to technical reasons

TC12


Alternate Flow

DEO Add valid valid valid Already Exists

TC13


Alternate Flow

DEO Add valid valid valid Unsuccessful due to technical reasons

TC14


Alternate Flow

DEO Delete -- Invalid -- Does not exist

TC15


Alternate Flow

Faculty

Modify valid valid valid Unsuccessful due to technical reasons

TEST CASE MATRIX FOR MAINTAIN STUDENT DETAIL USE

CASE

TEST CASE


NAME


REMARKS (If Any)

Operation Name Roll no. Semester Branch

TC1 Scenario 1- Maintain Student Detail Basic Flow

Add valid valid valid valid Student detail added successfully


Delete valid valid valid valid Student detail deleted successfully


Modify valid valid valid valid Student detail modified successfully


Add valid invalid valid valid Could not add Student detail

Already exists


Add valid valid valid valid Could not add Student detail

Unsuccessful Creation


Delete valid invalid valid valid Could not delete Student detail

Student Roll Number not found


Delete valid valid valid valid Could not delete Student detail

Unsuccessful Deletion


Modify valid invalid valid Valid Could not modify Student detail

Student Roll Number not found

TEST CASE MATRIX FOR MARK ATTENDANCE USE CASE

TEST CASE


NAME

INPUT EXPECTED OUTPUT REMARKS (If Any)

Check Attendance Box

TC1 Scenario 1- Mark Attendance Basic Flow

valid Attendance Marked Successfully

TC1 Scenario 1- Mark Attendance Basic Flow

valid Could Not Mark Attendance Unsuccessful due to technical reasons

SEQUENCE DIAGRAM – LOGIN BASIC FLOW

user : admin : LoginInterface : LoginController : LoginEntity

enter login id

enter password

enter role

enter(login id, password, role)


validate(login id, password, role)

validated

SEQUENCE DIAGRAM – LOGIN ALTERNATE FLOW

user : admin : LoginInterface : LoginController : LoginEntityenter login id

enter password

enter role



validate(login id, password, role)

invalid (login id, password, role)



SEQUENCE DIAGRAM – MAINTAIN STUDENT DETAIL (ADD)

BASIC FLOW

: DEO : DeoInterface : DeoController :

MaintainStudentDetai...

: StudentEntity

Maintain Student DetailsMaintain Student Details


Add/Delete/Update

Add/Delete/Update

addadd

add

enter details

enter details

enter(name, roll no. sem, branch)enter(name, roll no, sem, branch)

enter(name, roll no, sem, branch)add new record

create student object

successful creation

record added successfully



SEQUENCE DIAGRAM – MAINTAIN STUDENT DETAIL (DELETE)

BASIC FLOW



: StudentEntity


delete

enter(roll number)


Add/Delete/Update

delete

enter roll number

enter(roll number)


Add/Delete/Update

delete

enter roll number

enter(roll number) delete(roll no)

delteddelted

deleted

SEQUENCE DIAGRAM – MAINTAIN STUDENT DETAIL

(MODIFY) BASIC FLOW



: StudentEntity


edit student details

enter(roll number)


Add/Delete/Update


enter roll number

enter(roll number)


Add/Delete/Update


enter roll number

enter(roll number)

detailsdetails

update(roll no, name, sem, branch)

update(roll no, name, sem, branch)update(roll no, name, sem, branch)

update record

fetch details

details

validate(roll no)

validated

update successful

update successful

update successful


ALTERNATE FLOW 1



: StudentEntity


add


Add/Delete/Update

add


Add/Delete/Update

add create student object

unsuccessful creation




ALTERNATE FLOW 2



: StudentEntity


add


Add/Delete/Update

add

creation successful. enter details


Add/Delete/Update

add

creation successful. enter details

create student object

cretion successful. enter details

enter(roll no, name, sem, branch)

enter(roll no, name, sem, branch)enter(roll no, name, sem, branch)enter(roll no, name, sem, branch)

redundancy

redundancyredundancy

SEQUENCE DIAGRAM – MAINTAIN STUDENT DETAIL (DELETE)

ALTERNATE FLOW



: StudentEntity


delete

enter(roll number)


Add/Delete/Update

delete

enter roll number

enter(roll number)

roll number not found


Add/Delete/Update

delete

enter roll number

enter(roll number) delete(roll no)

roll no not foundroll number not found

SEQUENCE DIAGRAM – MAINTAIN STUDENT DETAIL

(MODIFY) ALTERNATE FLOW



: StudentEntity



enter(roll number)


Add/Delete/Update


enter roll number

enter(roll number)


Add/Delete/Update


enter roll number

enter(roll number) validate(roll no)

roll no. not found

roll no. not found

roll no. not found

SEQUENCE DIAGRAM – MAINTAIN COURSE DETAIL (ADD)

BASIC FLOW


MaintainCourseDetai...

: CourseEntity


add

enter(course name, course code,sem,branch,faculty)

Maintain Courset Details

Add/Delete/Update

add

enter details



Add/Delete/Update

add

enter details

enter(course name, course code,sem,branch,faculty)add new record

Create Course Object

Created Successfully


record added successfull

record added successfull

SEQUENCE DIAGRAM – MAINTAIN COURSE DETAIL (DELETE)

BASIC FLOW



: CourseEntity


add/ delete/ update

delete

enter course code

course code


Add/Delete/Update

delete

enter course code

course code

deleted


Add/Delete/Update

delete

enter course code

course code delete(course code)

deleteddeleted

SEQUENCE DIAGRAM – MAINTAIN COURSE DETAIL (MODIFY)

BASIC FLOW



: CourseEntity

Maintain course Details

add/ delete/ update

edit course details

enter course code

course code

details

update(course code, name, sem, branch, faculty)


Add/Delete/Update

edit course details

enter course code

course code



Add/Delete/Update

edit course details

enter course code

course code

detailsdetails


update record

fetch details

details

validate(course code)

validated


ALTERNATE FLOW 1



: CourseEntity


add/ delete/ update

add

enter details



Add/Delete/Update

add

enter details



Add/Delete/Update

add

enter details

enter(course name, course code,sem,branch,faculty)add new record

Create Course Object


course code already exists




ALTERNATE FLOW 2



: CourseEntity

Maintain member Details

add/ delete/ update

add


Add/Delete/Update

add



Add/Delete/Update

add


create member object



ALTERNATE FLOW 1



: CourseEntity


add/ delete/ update

delete

enter course code

course code


Add/Delete/Update

delete

enter course code

course code

course code invalid


Add/Delete/Update

delete

enter course code


course code invalidcourse code invalid


ALTERNATE FLOW 2



: StudentEntity


add/ delete/ update

delete

enter course code

course code


Add/Delete/Update

delete

enter course code

course code

course code not found


Add/Delete/Update

delete

enter course code


course code not foundcourse code not found

SEQUENCE DIAGRAM – MAINTAIN COURSE DETAIL (MODIFY)

ALTERNATE FLOW 1



: CourseEntity


add/ delete/ update

edit course details

enter course code

course code


Add/Delete/Update

edit course details

enter course code

course code


Add/Delete/Update

edit course details

enter course code

course code validate (course code)

course code invalid

course code invalid

course code invalid

SEQUENCE DIAGRAM – MAINTAIN MEMBER DETAIL (ADD

FACULTY) BASIC FLOW


MaintainMemberDeta...

: FacultyEntity


add/ delete/ update

add

enter details

enter(username,password,name)


Add/Delete/Update

add

enter details



Add/Delete/Update

add

enter details

enter(username,password,name)add new record

create faculty object

successful creation

Faculty/DEOFaculty/DEO

Faculty/DEO

FacultyFaculty

Faculty




SEQUENCE DIAGRAM – MAINTAIN MEMBER DETAIL (DELETE)

BASIC FLOW

: DeoController : DEO : DeoInterface :


: DeoEntity



Add/Delete/Update

add/ delete/ update

deletedelete

username

username

username


Add/Delete/Update

delete

usernameusername

username

delete faculty object

successful deletionsuccessful deletion

successful deletion

SEQUENCE DIAGRAM – MAINTAIN MEMBER DETAIL

(MODIFY) BASIC FLOW



: MemberEntity


add/ delete/ update

update

enter username

username

details

update(details)


Add/Delete/Update

update

enter username

username

update(details)


Add/Delete/Update

update

enter username

username

detailsdetails

update(details)

update record

fetch details

details

validate(username)

validated

SEQUENCE DIAGRAM – MAINTAIN MEMBER DETAIL (ADD DEO) BASIC FLOW

: DeoController : DEO

: DeoInterface :


: DeoEntity



Add/Delete/Update

add/ delete/ update

addadd

enter details

enter details

enter(username,password,name)enter(username,password,name)

Faculty/DEO

DEODEO


Add/Delete/Update

add

enter details


Faculty/DEOFaculty/DEO

DEO

add new record

create faculty object

successful creation


record added successfullyrecord added successfully


DEO) ALTERNATE FLOW 1



: DeoEntity


add/ delete/ update

add


Add/Delete/Update

add



Add/Delete/Update

add


create membert object



DEO) ALTERNATE FLOW 2



: DeoEntity


add/ delete/ update

add

enter details

enter(username, password, name)


Add/Delete/Update

add

enter details


username already exists


Add/Delete/Update

add

enter details



add new record

Create member Object




FACULTY) ALTERNATE FLOW 1



: FacultyEntity


add/ delete/ update

add


Add/Delete/Update

add



Add/Delete/Update

add


create membert object



FACULTY) ALTERNATE FLOW 2



: FacultyEntity


add/ delete/ update

add

enter details



Add/Delete/Update

add

enter details




Add/Delete/Update

add

enter details



add new record

Create member Object



SEQUENCE DIAGRAM – MAINTAIN MEMBER DETAIL (DELETE)

ALTERNATE FLOW 1

: DeoController : DEO : DeoInterface :


: MemberEntity



Add/Delete/Update

add/ delete/ update

deletedelete

username

username

username


Add/Delete/Update

delete

usernameusername

username

delete member object

username invalidusername invalid

username invalid

SEQUENCE DIAGRAM – MAINTAIN MEMBER DETAIL




: MemberEntity


add/ delete/ update

update

enter username

username


Add/Delete/Update

update

enter username

username


Add/Delete/Update

update

enter username

username validate(username)

username invalid

username invalid

username invalid

SEQUENCE DIAGRAM – MARK ATTENDANCE BASIC FLOW

: Faculty : FacultyInterface : FacultyController :

MarkAttendanceController

:

AttendanceDetailsEntity

Mark Attendance

Mark Attendance

Mark Attendance

Select Subject Code

Select Subject Code

Select Subject Code

Subject CodeSubject Code

Subject Code

Subject Code

List of Students

List of Students

List of Students

List of Students

Mark and SubmitMark and Submit

SubmitSubmit

Submitted successfully

submitted successfullysubmitted successfully

submitted successfully

Documents

Online Attendance Management System