Online Attendance Management System
Online Attendance Management System
(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 PCs. 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 students attendance.
Interviewing brainstorming Dr. Ruchika Malhotra (Ph.D) Ashwini Sir (M. Tech, DTU) Anshuj Kumar Nidhi Kapoor Sahaj Biyani Tanuj Mittal
Date Version
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.
Student
login
mark attendance
view attendance
Generate Reports
CLASS DIAGRAM
LoginInterface
LoginController
LoginEntity
StudentInterface
DeoInterface
FacultyInterface
AdminInterface
StudentController
MaintainStudentDetailsC ontroller
MaintainMemberDetailsC ontroller
GenerateReportsControlle r
DeoEntity
FacultyEntity
StudentEntity
AttendanceDetailsEntit y
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 students library account details.
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 universitys 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.1.1. Login
Username Password
Alphanumeric. Minimum length of 6 characters. No special character except underscore is allowed. Alphanumeric. Minimum length of 8 characters.
Name Program Roll No. Reg. No. Year of Admission Address Contact No. E-Mail Address
Text with spaces allowed. Text with spaces allowed. Alphanumeric text with forward slashes allowed. Alphanumeric text with forward slashes allowed. Numeric with value between 2000 and 2100. Text. Numeric with minimum length 10. One + and - allowed. E-Mail address standard.
Name Department Designation Contact No. E-Mail Address Address Qualification 3.1.14. Add Faculty
Text with spaces allowed. Text with spaces allowed. Text with spaces allowed. Numeric with minimum length 10. One + and - allowed. E-Mail address standard. Text. Text.
Text with spaces allowed. Text with spaces allowed. Text with spaces allowed. Numeric with minimum length 10. One + and - allowed. E-Mail address standard. Text. 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 students 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.6ALTERNATE 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).
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 subflow 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. 3.7 SPECIAL REQUIREMENTS None 3.8 RELATED USECASES Login
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 The user should be logged on to the system. 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. 4.7 SPECIAL REQUIREMENTS None 4.8 RELATED USECASES Login
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
6.6.2 Alternate flow 2 Wrong details entered for report generation. Use case returns to beginning. 6.6.3 Alternate flow 3 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 The user should be logged on to the system. 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 Name Course Code Roll No. Year Type Text Char(10) Numeric Numeric Description Comment Name of the student Course code Roll no of the student in Unique universitys records Year of enrollment in
university Residential address Contact no. E-mail address Current semester of student May several be
3.4.2. Member Data Entity Data Item Name Designation Phone Number Address Department Identification No. Type Text Text Integer Description Name of the faculty Designation Contact number Comment
May several
be
Alphanumeric Residential address Integer Department of teacher Integer Unique identification Unique number of faculty in universitys records
3.4.3. Course Data Entity Data Item Course ID Type String Description Comment Unique identification number Unique of course in universitys records Departments name Credits for the course
Text Integer
3.4.4. Batch data entity(created new every year) Data Item Student roll Type String Description Comment Roll number of students in Unique and the batch last row contains number of classes held for a course Course code for course
Course code 1
Integer
Course code 2 Course code 3 Course code 4 Course code 5 Course code 6
Course code for course Course code for course Course code for course Course code for course Course code for course
3.4.5. Short attendance list Data Item Roll number Branch Semester Course code Type String Integer Integer String Description Comment Student roll number Unique Branch for which scheme is designed Semester for which scheme is designed Course in which attendance is short
3.4.6. Paper Data Entity Data Item Paper Code Type Description Comment Alphanumeric Unique identification code Unique for paper in universitys records Text Subjects name Text Syllabus for the paper Integer Credits for the paper Integer Scheme for which paper is May be designed several
3.4.7. login Data Entity Data Item Account Type Actor name Username Password Type Integer Description Comment Type of account: Student, Faculty, Administrator, DEO string Actor who owns the account Unique Alphanumeric Username of account holder Unique 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.
schedule Member Details Interface For faculty member only Course Details Interface Course Entity
Member Entity
Admin/DEO Admin
1 1 Login Interface Login Controller Admin/DEO Faculty view attendancecontrol Admin/DEO/Faculty 1 student only Login Details
Batch Entity
Login Administrator
Student
Mark Attendance
View Attendance
Generate Reports
[details=invalid]
[details=valid]
login unsuccessful
[member=faculty]
[member=DEO]
[choice=add] [choice=update] add faculty details update faculty details [choice=add] add DEO details update DEO details [choice=update] delete DEO details
[choice=delete] [choice=add]
[choice=add]
[choice=update]
[choice=delete]
1: enter login id 2: enter password 3: enter role 4: enter(login id, password, role)
user : admin
: LoginInterface
7: validated
1: enter login id 2: enter password 3: enter role 4: enter(login id, password, role)
: LoginInterface
7: invalid (login id, password, role) : LoginController 6: validate(login id, password, role)
: LoginEntity
3: Maintain Student Details 9: add 17: enter(name, roll no, sem, branch)
: DEO
: DeoController
: MaintainStudentDetailsController
11: successful creation 19: record added successfully 5: Add/Delete/Update 13: enter details 21: record added successfully 2: Maintain Student Details 8: add 16: enter(name, roll no, sem, branch) 1: Maintain Student Details 7: add 15: enter(name, roll no. sem, branch)
: DeoInterface
: DEO
: DeoInterface
5: Add/Delete/Update 11: enter roll number 19: deleted 4: Add/Delete/Update 10: enter roll number 18: deleted : MaintainStudentDetailsController
: StudentEntity
1: Maintain Student Details 7: edit student details 13: roll number 23: update(roll no, name, sem, branch)
: DEO
: DeoInterface
2: Maintain Student Details 8: edit student details 14: roll number 24: update(roll no, name, sem, bra
4: Add/Delete/Update 10: enter roll number 20: details 17: validated 19: details : MaintainStudentDetailsController 3: Maintain Student Details 9: edit student details 15: roll number 25: update(roll no, name, sem, branch) 16: validate(roll no) 18: fetch details 26: update record : DeoController
: StudentEntity
: DeoInterface
: MaintainStudentDetailsController
: StudentEntity
1: Maintain Student Details 7: add 15: enter(roll no, name, sem, branch)
: DEO
: DeoInterface
2: Maintain Student Details 8: add 5: Add/Delete/Update 16: enter(roll no, name, sem, branch 13: creation successful. enter details 21: redundancy 4: Add/Delete/Update 12: creation successful. enter details 20: redundancy : MaintainStudentDetailsController 3: Maintain Student Details 9: add 17: enter(roll no, name, sem, branch) : DeoController 11: cretion successful. enter details 19: redundancy 10: create student object 18: enter(roll no, name, sem, branch)
: StudentEntity
: DEO
: DeoInterface
5: Add/Delete/Update 11: enter roll number 19: roll number not found 4: Add/Delete/Update 10: enter roll number 18: roll number not found
: MaintainStudentDetailsController
: DeoController
: StudentEntity
: DEO
: DeoInterface
5: Add/Delete/Update 11: enter roll number 19: roll no. not found 2: Maintain Student Details 8: edit student details 14: roll number
4: Add/Delete/Update 10: enter roll number 18: roll no. not found
: MaintainStudentDetailsController
: DeoController
: StudentEntity
: DEO
: DeoInterface
: MaintainCourseDetailsController
: DeoController
: CourseEntity
: DeoInterface
: MaintainCourseDetailsController
: DeoController
: CourseEntity
1: Maintain course Details 7: edit course details 13: course code 23: update(course code, name, sem, branch, faculty)
: DEO
6: add/ delete/ update 12: enter course code 22: details 5: Add/Delete/Update 11: enter course code 21: details
: DeoInterface
2: Maintain course Details 8: edit course details 14: course code 24: update(course code, name, sem, branch, faculty)
: MaintainCourseDetailsController
3: Maintain course Details 9: edit course details 15: course code 25: update(course code, name, sem, branch, faculty)
: DeoController
: CourseEntity
: DeoInterface
: MaintainCourseDetailsController
: DeoController
: CourseEntity
: DEO
: MaintainCourseDetailsController
: DeoController
: CourseEntity
: DEO
: DeoInterface
: MaintainCourseDetailsController
: DeoController
: CourseEntity
: DEO
6: add/ delete/ update 12: enter course code 5: Add/Delete/Update 11: enter course code 19: course code not found 4: Add/Delete/Update 10: enter course code 18: course code not found
: DeoInterface
: MaintainCourseDetailsController
: DeoController
: StudentEntity
: DEO
: DeoInterface
: MaintainCourseDetailsController
: DeoController
: CourseEntity
: DEO
: DeoInterface
: MaintainMemberDetailsController
4: Add/Delete/Update 10: Faculty/DEO 18: enter details 26: record added successfully
5: Add/Delete/Update 11: Faculty/DEO 19: enter details 27: record added successfully
3: Maintain Member Details 9: add 15: Faculty 23: enter(username,password,name) 16: create faculty object 24: add new record : DeoController 17: successful creation 25: record added successfully
: FacultyEntity
1: Maintain Member Details 7: delete 13: username : DEO 6: add/ delete/ update 12: username
3: Maintain Member Details 9: delete 15: username : MaintainMemberDetailsController 16: delete faculty object
: DeoEntity
: DEO
: DeoInterface
5: Add/Delete/Update 11: enter username 21: details 4: Add/Delete/Update 10: enter username 20: details
: MaintainMemberDetailsController
: DeoController
: MemberEntity
: DEO
: DeoInterface
5: Add/Delete/Update 11: Faculty/DEO 19: enter details 27: record added successfully 2: Maintain Member Details 8: add 14: DEO 22: enter(username,password,name)
: DeoController
4: Add/Delete/Update 10: Faculty/DEO 18: enter details 26: record added successfully
: MaintainMemberDetailsController
: DeoEntity
: MaintainMemberDetailsController
: DeoController
: DeoEntity
: DEO
: DeoInterface
5: Add/Delete/Update 13: enter details 21: username already exists 4: Add/Delete/Update 12: enter details 20: username already exists
: MaintainMemberDetailsController
: DeoController
: DeoEntity
1: Maintain member Details 7: add : DeoInterface 6: add/ delete/ update : DEO 5: Add/Delete/Update 13: unsuccessful creation
: DeoController
: FacultyEntity
: DEO
: DeoInterface
5: Add/Delete/Update 13: enter details 21: username already exists 4: Add/Delete/Update 12: enter details 20: username already exists
: MaintainMemberDetailsController
: DeoController
: FacultyEntity
1: Maintain Member Details 7: delete 13: username : DEO 6: add/ delete/ update 12: username : DeoInterface 5: Add/Delete/Update 11: username 19: username invalid
: DeoController
4: Add/Delete/Update 10: username 18: username invalid 3: Maintain Member Details 9: delete 15: username
: MemberEntity
: DEO
: DeoInterface
4: Add/Delete/Update 10: enter username 18: username invalid : MaintainMemberDetailsController 3: Maintain Member Details 9: update 15: username 16: validate(username)
: DeoController
: MemberEntity
: Faculty
: FacultyInterface
: MarkAttendanceController
: FacultyController
: AttendanceDetailsEntity
TC2
Faculty
valid
valid
TC3
DEO
valid
valid
TC4
Admin
valid
valid
TC5
Login Basic Flow Scenario 2 Login Alternate Flow Scenario 2 Login Alternate Flow Scenario 2 Login Alternate Flow
Logged In Student Invalid Valid/invalid Invalid Username Username doesnt exist in database Password doesnt exist in database Username and Password doesnt exist in database Password doesnt exist in database
TC6
Faculty
valid
invalid
Invalid Password
TC7
DEO
Invalid
TC8
Administrator Valid
invalid
Invalid Password
TC2
TC3
TC4
TC5
TC6
TC7
TC8
SCENARIO AND DESCRIPTI ON NAME Scenario 1Maintain Course Detail Basic Flow Scenario 1Maintain Course Detail Basic Flow Scenario 1Maintain Course Detail Basic Flow Scenario 2Maintain Course Detail Alternate Flow Scenario 3Maintain Course Detail Alternate Flow Scenario 4Maintain Course Detail Alternate Flow Scenario 4Maintain Course Detail Alternate Flow Scenario 5Maintain Course Detail Alternate Flow
Operati on Add
Branc h valid
Facult y valid
EXPECTE D OUTPUT Course detail added successful ly Course detail deleted successful ly Course detail modified successful ly Could not add course detail
Delete
valid
valid
valid
valid
valid
Modify
valid
valid
valid
valid
valid
Add
valid
invali d
valid
valid
valid
Already exists
Add
valid
valid
valid
valid
valid
Unsuccessf ul Creation
Delete
valid
invali d
valid
valid
valid
Delete
valid
valid
valid
valid
valid
Unsuccessf ul Deletion
Modify
valid
invali d
valid
valid
valid
Not found
TC2
Facult y
Delete
valid
valid
valid
TC3
Facult y
Modify
valid
valid
valid
TC4
DEO
Add
valid
valid
valid
TC5
DEO
Delete
valid
valid
valid
TC6
DEO
Modify
valid
valid
valid
Faculty detail added successfull y Faculty detail deleted successfull y Faculty detail modified successfull y DEO detail added successfull y DEO detail deleted successfull y DEO detail
TC7
TC8
TC9
TC1 0
TC1 1
TC1 2
TC1 3
TC1 4
Maintain DEO Detail Basic Flow Scenario 3Maintain Faculty Detail Alternate Flow Scenario 4Maintain Faculty Detail Alternate Flow Scenario 5Maintain Faculty Detail Alternate Flow Scenario 3Maintain Faculty Detail Alternate Flow Scenario 3Maintain Faculty Detail Alternate Flow Scenario 3Maintain Faculty Detail Alternate Flow Scenario 4Maintain Faculty Detail Alternate Flow Scenario 5Maintain Faculty Detail Alternate Flow
Facult y
Add
valid
valid
valid
Facult y
Delete
--
Invalid
--
Facult y
Modify
--
Invalid
Facult y
Modify
valid
valid
valid
DEO
Add
valid
valid
valid
Already Exists
DEO
Add
valid
valid
valid
DEO
Delete
--
Invalid
--
TC1 5
Facult y
Modify
valid
valid
valid
REMARKS (I Any)
TC2
Delete
valid
valid
valid
valid
TC3
Modify
valid
valid
valid
valid
TC4
Add
valid
invalid
valid
valid
TC5
Add
valid
valid
valid
valid
Unsuccessfu Creation
TC6
Delete
valid
invalid
valid
valid
Could not delete Student detail Could not delete Student detail Could not modify Student detail
TC7
Delete
valid
valid
valid
valid
Unsuccessfu Deletion
TC8
Modify
valid
invalid
valid
Valid
CASE
TC1
valid
: LoginInterface
: LoginController
: LoginEntity
enter password
enter role
enter(login id, password, role) enter(login id, password, role) validate(login id, password, role) validated
: LoginInterface
: LoginController
: LoginEntity
enter password
enter role
enter(login id, password, role) enter(login id, password, role) validate(login id, password, role)
invalid (login id, password, role) invalid (login id, password, role)
: DEO
: DeoController
: MaintainStudentDetai...
Add/Delete/Update
add
add
add
enter(name, roll no. sem, branch) enter(name, roll no, sem, branch) enter(name, roll no, sem, branch)
: DEO
Add/Delete/Update
delete
delete
enter(roll number)
enter(roll number)
enter(roll number)
delted deleted
: DEO
Add/Delete/Update
enter(roll number)
enter(roll number)
enter(roll number)
details
details
details
update(roll no, name, sem, branch) update(roll no, name, sem, branch) update(roll no, name, sem, branch) update record update successful update successful update successful
: DEO
: DeoController
: MaintainStudentDetai...
Add/Delete/Update
: StudentEntity
add
add
add
: DeoInterface
: DeoController
: MaintainStudentDetai...
add
: StudentEntity add add create student object cretion successful. enter details creation successful. enter details creation 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 redundancy redundancy
: DEO
Add/Delete/Update
delete
delete
enter(roll number)
enter(roll number)
enter(roll number)
: DEO
Add/Delete/Update
enter(roll number)
enter(roll number)
enter(roll number)
: DeoController
: MaintainCourseDetai...
Add/Delete/Update Add/Delete/Update
add
add
enter details
enter(course name, course code,sem,branch,faculty) enter(course name, course code,sem,branch,faculty) enter(course name, course code,sem,branch,faculty)
: DeoInterface
: DeoController
: MaintainCourseDetai...
course code
course code
course code
deleted deleted
: DeoController
: MaintainCourseDetai...
Add/Delete/Update Add/Delete/Update add/ delete/ update edit course details edit course details
course code
course code
course code
details
details details update(course code, name, sem, branch, faculty) update(course code, name, sem, branch, faculty)
details
: DeoController
Add/Delete/Update Add/Delete/Update add/ delete/ update add add : CourseEntity Create Course Object Created Successfully enter details
add
enter(course name, course code,sem,branch,faculty) enter(course name, course code,sem,branch,faculty) enter(course name, course code,sem,branch,faculty)
course code already exists course code already exists course code already exists
: DEO
: DeoController
: MaintainCourseDetai...
add
: DeoInterface
: DeoController
: MaintainCourseDetai...
course code
course code
course code
: DeoController
: MaintainCourseDetai...
course code
course code
course code
: DeoController
: MaintainCourseDetai...
Add/Delete/Update Add/Delete/Update add/ delete/ update edit course details edit course details
course code
course code
course code
: DEO
: DeoController
: MaintainMemberDeta...
Add/Delete/Update
add Faculty/DEO
Faculty/DEO Faculty/DEO Faculty Faculty Faculty : FacultyEntity create faculty object successful creation
enter details
enter(username,password,name)
enter(username,password,name)
enter(username,password,name)
: DeoInterface
: DeoController
MaintainMe
delete username
: DEO
: DeoController
: MaintainMemberDeta...
username
username
username
details
details
: DEO
: DeoController
: MaintainMemberDeta...
add Faculty/DEO
: DeoEntity
enter details
enter(username,password,name)
enter(username,password,name) enter(username,password,name)
: DEO
: DeoController
: MaintainMemberDeta...
add
: DEO
: DeoController
: MaintainMemberDeta...
Add/Delete/Update Add/Delete/Update add/ delete/ update add add : DeoEntity add Create member Object Created Successfully enter details
: DEO
: DeoController
: MaintainMemberDeta...
add
: DEO
: DeoController
: MaintainMemberDeta...
Add/Delete/Update Add/Delete/Update add/ delete/ update add add : FacultyEntity add Create member Object Created Successfully enter details
: DeoInterface
: DeoController
: MaintainMemberDeta...
delete username
: MemberEntity delete member object username invalid username invalid username invalid
: DEO
: DeoController
: MaintainMemberDeta...
username
username
username
: Faculty
: FacultyController
: MarkAttendanceController
Mark Attendance Mark Attendance Select Subject Code Select Subject Code Select Subject Code
Subject Code
: AttendanceDetailsEntity
Subject Code List of Students List of Students List of Students List of Students