Software Measurements, Metrics, and Modelling

Lab.
ITE-311P

Submitted by: Submitted to:

Yash Goel Dr. Arshi Husain
B.Tech (IT-5th Semester)
Enrollment No: 00816401522

University School of Information and Communication Technology

Guru Gobind Singh Indraprastha University
New Delhi-110078
August 2024- January 2025
 INDEX

S. No. Program Date Remarks

How can we systematically develop a software project

1. through requirements, design, implementation, testing,
deployment, and maintenance?
How can we effectively perform requirements engineering by
identifying tasks, gathering requirements, using QFD, and
2. addressing elicitation challenges?

What steps are needed to create a comprehensive Software

3. Requirements Specification (SRS)?

What steps are needed to create function-oriented diagrams

4. like DFDs and Structured Charts?

5. Create a use case diagram using Visual Paradigm UML

Create a class diagram using Visual Paradigm UML

6.

7. Create an object diagram using Visual Paradigm UML

8. Create a Sequence diagram using Visual Paradigm UML

Create a collaboration diagram using

9. Visual Paradigm UML
Experiment No. 1: How can we systematically develop a software project
through requirements, design, implementation, testing, deployment, and
maintenance?

1. Design Phase

The design phase focuses on how to turn the gathered requirements into an
actionable blueprint for your system.

1.1 System Architecture Design

 Overview: Design the system architecture, deciding how different

components (like face recognition, database, and UI) will interact.
 Components:
o Face Recognition Module: Use a deep learning model (e.g., OpenCV,
FaceNet, or Dlib) to handle the face detection and recognition.
o Database: Set up a database (e.g., MySQL, MongoDB) to store student
details and attendance logs.
o User Interface: Develop a UI that allows students to mark attendance,
and allows admins/teachers to monitor the attendance data.
o API Layer: Optional REST APIs for handling face recognition, attendance
recording, and data management.

1.2 Detailed Design

 Database Design: Create an Entity-Relationship Diagram (ERD) to define how

student data (names, IDs, facial images) and attendance logs will be
structured.
 Face Recognition Flow: Design the flow of face recognition (e.g., capturing
an image, processing it, matching it against the database).
 UI Design: Design wireframes for the student-facing attendance page and
the admin dashboard for viewing reports.
 Security Design: Ensure that security measures (e.g., encryption, secure
logins) are incorporated.
2. Implementation Phase

This phase involves writing the code and actually building the system according to
the design specifications.

2.1 Setup the Development Environment

 Install necessary software like Python, OpenCV (for face recognition),

Flask/Django (for web framework), MySQL/PostgreSQL (for database), and
any other tools needed for your project.

2.2 Face Recognition Module

 Preprocessing: Implement image preprocessing steps such as resizing,

grayscale conversion, and noise removal.
 Face Detection: Use a face detection model (e.g., OpenCV’s Haar Cascade or
Dlib’s HOG-based detector) to detect faces in the video stream.
 Face Recognition: Use a model like FaceNet or a pre-trained deep learning
model (e.g., ResNet, VGG) to match the detected face against the database
of student images.
 Attendance Recording: Upon recognition, update the student’s attendance
record in the database.

2.3 Database Setup

 Create Database: Define tables for students, attendance records, and any
additional data.
 Data Storage: Implement functions to store and retrieve student data, such
as names, IDs, and facial embeddings (if you're storing face vectors).
 Integration: Integrate the face recognition system with the database to store
attendance data (date, time, student ID).

2.4 UI Development

 Student Interface: Develop the web interface that allows students to stand
in front of the camera, trigger face recognition, and mark their attendance.
 Admin Interface: Build a dashboard for teachers and administrators to view
attendance reports, add/remove students, and monitor system
performance.
2.5 Security and Authentication

 Implement user authentication for the admin and student login.

 Ensure that data is encrypted where necessary (e.g., student images and
sensitive attendance information).

3. Testing Phase

Testing ensures that the system works as expected, identifying bugs and ensuring it
meets the requirements.

3.1 Unit Testing

 Test individual modules or components of the system, such as the face

recognition logic, database CRUD operations, and UI functionality.

3.2 Integration Testing

 Test the interaction between different system components (e.g., checking if

the face recognition module correctly interacts with the database to store
attendance data).

3.3 System Testing

 Test the entire system as a whole to ensure that all the components work
together seamlessly.

3.4 Performance Testing

 Face Recognition Accuracy: Test the accuracy of the face recognition system
under various conditions (lighting, angle, etc.).
 System Performance: Check the system's ability to handle multiple students
at once, especially if you expect a large number of users (e.g., in a classroom
setting).
 Response Time: Test how fast the system recognizes faces and marks
attendance (aim for under 5 seconds).
3.5 User Acceptance Testing (UAT)

 Have real users (students, teachers, admins) test the system to ensure that it
meets their needs and expectations. Gather feedback and make necessary
improvements.

4. Deployment Phase

Deployment involves preparing the system for use by the intended audience.

4.1 Deployment Planning

 Choose the deployment environment (e.g., cloud service like AWS or local
servers).
 Prepare for system scaling, backup solutions, and ensure data security
(especially face data).

4.2 System Deployment

 Web Deployment: Deploy the web application using a platform like Heroku,
AWS, or a local server.
 Face Recognition Model Deployment: Ensure the face recognition model is
properly deployed and accessible from the server, capable of processing
incoming data in real-time.
 Database Deployment: Set up and deploy the database on a secure server
or cloud platform.

4.3 Configuration and Setup

 Set up monitoring tools to track system performance.

 Ensure that all security configurations (e.g., SSL certificates for web traffic,
firewalls for the database) are in place.
 Ensure that backups of attendance data and student information are
regularly taken.

4.4 User Training and Documentation

 Provide training for users (students, teachers, and admins) on how to use the
system.
  Create user manuals and technical documentation for system administrators.

5. Maintenance Phase

Maintenance is the ongoing process of ensuring that the system runs smoothly,
remains updated, and is improved over time.

5.1 Bug Fixes and Updates

 Regularly monitor the system for any bugs, errors, or performance issues
and resolve them promptly.
 Keep the system up-to-date with the latest libraries, face recognition models,
and security patches.

5.2 System Monitoring

 Use system monitoring tools to track the performance of the system,

including face recognition accuracy, server uptime, and database
performance.
 Regularly check for system load to prevent downtimes, especially during
peak usage times.

5.3 User Feedback and Feature Updates

 Collect feedback from users (students, teachers) to identify areas for

improvement.
 Implement new features or improvements based on user needs (e.g., adding
additional authentication methods or improving facial recognition under
challenging conditions).

5.4 Scalability Improvements

 As the number of users grows, monitor the system's scalability and make
improvements, such as optimizing database queries, or shifting to more
robust cloud infrastructure to handle more users.

5.5 Security Enhancements

 Continuously monitor and enhance security features, especially related to

data privacy laws, encryption, and unauthorized access.
Experiment No. 2: How can we effectively perform requirements engineering by
identifying tasks, gathering requirements, using QFD, and addressing elicitation
challenges?

1. Requirement Gathering & Analysis

 Task 1.1: Gather user requirements (e.g., stakeholders' needs, expectations

for accuracy, and ease of use).
 Task 1.2: Define system specifications (e.g., hardware requirements like
camera, software, and algorithms).
 Task 1.3: Analyze the dataset (e.g., face image datasets for training the
recognition model).

2. System Design

 Task 2.1: Design the overall system architecture (e.g., components involved
like face detection, recognition, and database interaction).
 Task 2.2: Design the user interface (UI) to display attendance results and
manage student records.
 Task 2.3: Design the database schema (e.g., tables for storing student
information, attendance records).

3. Data Collection & Preprocessing

 Task 3.1: Collect face images for training (e.g., images of students with
labels).
 Task 3.2: Preprocess the images (e.g., resizing, normalization, and
augmentation).
 Task 3.3: Split data into training and testing datasets.

4. Face Recognition Module Development

 Task 4.1: Implement face detection (e.g., using OpenCV, Dlib, or a similar
library).
 Task 4.2: Implement face recognition (e.g., using a deep learning model like
CNN or pre-trained models like FaceNet).
  Task 4.3: Integrate the recognition system with the database to compare the
detected face with stored records.

5. Attendance Database Development

 Task 5.1: Set up a database to store student information and attendance

records (e.g., SQL or NoSQL database).
 Task 5.2: Implement CRUD operations for attendance (e.g., adding, updating,
and retrieving attendance records).

6. User Interface (UI) Development

 Task 6.1: Design the interface for student login/attendance registration.

 Task 6.2: Implement the UI to display attendance status (e.g., “Attendance
Marked” or “Face Not Recognized”).
 Task 6.3: Develop feedback messages for users (e.g., alerts for recognition
failure or attendance already marked).

7. Integration & Testing

 Task 7.1: Integrate all modules (face detection, recognition, database, and
UI).
 Task 7.2: Perform unit testing for each module (e.g., face recognition
accuracy, database queries, UI responsiveness).
 Task 7.3: Perform integration testing to ensure smooth interaction between
components.
 Task 7.4: Conduct end-to-end testing (e.g., simulate real-world scenarios of
face recognition and attendance marking).

8. Deployment & Optimization

 Task 8.1: Deploy the system to a server or local machine.

 Task 8.2: Optimize system performance (e.g., improve face recognition
speed, optimize database queries).
 Task 8.3: Ensure system scalability and robustness (e.g., handle multiple
users efficiently).

9. Documentation & Reporting

 Task 9.1: Document the code and system design.

  Task 9.2: Write a project report explaining the methodology, results, and
challenges.
 Task 9.3: Create user manuals or guides for the system (e.g., how to use the
attendance system).

10. Maintenance & Updates

 Task 10.1: Monitor the system after deployment for any issues.
 Task 10.2: Provide updates to improve accuracy or add features (e.g., multi-
user attendance, additional security features).

Gathering Requirements:
1. Stakeholder Identification

 End Users: Students, teachers, or faculty members who will interact with the
system.
 System Administrators: People who will manage the system, e.g., updating
student records, monitoring the system, etc.
 Developers: Those involved in the development and maintenance of the
system.
 Institution/Organization: The educational institution or organization
implementing the system.

2. Functional Requirements

Functional requirements describe what the system must do.

 Attendance Marking:
o The system should be able to mark attendance based on facial
recognition.
o It should compare the detected face with the student database to
verify identity.
o The system should update the attendance record in real-time.
 Face Detection:
o The system should detect faces in different lighting conditions (e.g.,
daylight, artificial lighting).
o It should be able to detect faces from multiple angles (e.g., frontal,
profile).
  Face Recognition:
o The system should be able to match faces accurately with the student
database.
o The recognition process should be fast and reliable (within a few
seconds).
o It should handle cases of false positives/negatives (e.g., incorrect
recognition or unrecognized faces).
 Database Management:
o The system should store and manage student information (name, ID,
face image).
o The database should store attendance records for each student
(present/absent with timestamps).
 User Interface (UI):
o The system should have an intuitive interface for students to mark their
attendance.
o Teachers/admins should have access to view the attendance logs and
student records.
o Feedback messages (e.g., “Attendance Marked”, “Face Not
Recognized”) should be clearly displayed.
 Data Security:
o The system should ensure the privacy of student data (especially face
images).
o Sensitive data (like student IDs) should be encrypted in the database.
o Access control should be in place for different types of users (e.g.,
admin access vs. student access).
 Scalability:
o The system should handle multiple users simultaneously without
significant performance degradation.
o The system should be scalable to accommodate large student
databases.

3. Non-Functional Requirements

Non-functional requirements describe how the system performs, rather than what it
does.

 Performance:
o The face recognition process should take less than 5 seconds to identify
a student.
 o The system should be able to handle a large number of users (e.g.,
hundreds of students in a class).
 Reliability:
o The system should be available and operational 24/7 with minimal
downtime.
o The system should have a backup mechanism for storing attendance
records.
 Usability:
o The user interface should be easy to use for both students and admins.
o It should be intuitive, with minimal instructions required for usage.
 Compatibility:
o The system should work on commonly used devices (e.g., desktops,
tablets, smartphones).
o It should support integration with other tools or platforms (e.g.,
learning management systems).
 Maintainability:
o The system should be easy to maintain and update, with clear
documentation and modular code.
 Security:
o The system should prevent unauthorized access (e.g., secure login for
admin users).
o Data should be securely stored and transmitted (e.g., SSL encryption).

4. System Constraints

Constraints define limitations or conditions under which the system must operate.

 Hardware Constraints:
o The system must work with standard webcams or cameras that are
available on laptops or mobile devices.
o The system should work with relatively low-quality images, especially
in case of poor lighting conditions.
 Software Constraints:
o The system should be developed using open-source libraries (e.g.,
OpenCV for face recognition, SQL for database management).
o The system should run on commonly used operating systems
(Windows, Linux, macOS).
 Budget and Time Constraints:
 o The project should be completed within a certain time frame (e.g., 3–6
months).
o The budget for the project is limited, so the choice of tools and
resources should be cost-effective.

5. Use Case Identification

Use cases describe the interaction between users and the system. For your Face
Recognition Attendance System, potential use cases include:

 Use Case 1: Student marks attendance

Actor: Student
Description: The student approaches the system, the camera captures their
face, and the system recognizes the student’s identity, marking their
attendance.
 Use Case 2: Admin manages student records
Actor: Admin/Faculty
Description: The admin adds/removes students from the system, uploads
face images, and manages the attendance logs.
 Use Case 3: Teacher views attendance report
Actor: Teacher
Description: The teacher views the attendance report for a class or session.

6. Acceptance Criteria

Acceptance criteria define the conditions that must be met for the system to be
considered complete and functional:

 The system should accurately recognize 95% of the students’ faces under
normal conditions.
 The system should mark attendance within 5 seconds of face detection.
 The UI should display the attendance status to the student within 3 seconds
of recognition.
 The attendance database should record each student's presence with
timestamps.
Using QFD:
1. Customer Requirements (CR)

These are the needs and expectations of the stakeholders (students, teachers,
administrators). The CRs are typically gathered during the requirements gathering
phase.

2. Technical Requirements (TR)

These are the technical features or specifications that will meet the customer
requirements.

3. House of Quality Matrix

The House of Quality matrix is the central tool used in QFD. It connects the
customer requirements with the technical requirements.

Explanation of the Matrix

 Customer Requirements (CR): These are the key needs of the stakeholders.
For example:
o Accurate Face Recognition: The system must accurately recognize faces
in various conditions.
o Quick Attendance Marking: The system must quickly recognize the
face and mark attendance.
o Easy-to-Use Interface: The system should have a simple and intuitive
user interface.
o Real-Time Data Update: Attendance data should be updated
immediately after recognition.
o Robust Security: The system must ensure data privacy and secure
access.
o Scalability: The system should be able to handle a large number of
users efficiently.
o Reliability: The system must be reliable and have high uptime.
 Technical Requirements (TR): These are the technical features or solutions
to meet each customer requirement. For example:
o Face Recognition Accuracy: Implement a deep learning-based
recognition model for high accuracy.
 o Database Speed: Use fast, efficient database queries and indexing.
o UI/UX Design: Design a user-friendly and simple interface for students
and admins.
o Data Security: Use encryption for face images and other sensitive data,
implement secure login mechanisms.
o System Scalability: Leverage cloud-based infrastructure to scale the
system.
o Performance: Ensure the system is responsive with low latency.
 Weight: Each customer requirement is assigned a weight (1-10), representing
its importance to the success of the system.
 Technical Requirements (TR) Scores: The technical requirements are rated
(usually 1 to 5) on how well they meet the customer requirements, with the
following possible values:
o 1: Low importance in meeting the requirement.
o 2: Medium importance in meeting the requirement.
o 3: High importance.
o 4: Very high importance.

Elicitation Challenges:
1. Lack of Clear Communication from Stakeholders

 Challenge: Stakeholders may not always clearly communicate their needs,

which can lead to misunderstandings about what is required. They might
assume certain features are self-evident or fail to articulate specific needs.
 Solution: Use multiple communication channels (e.g., interviews,
questionnaires, observation, prototypes) to ensure clear understanding.
Active listening and follow-up questions can help clarify any ambiguities.

2. Conflicting Stakeholder Requirements

 Challenge: Different stakeholders may have conflicting requirements. For

example, a teacher might want the system to mark attendance as quickly as
possible, while the system administrator might prioritize security features
over speed.
 Solution: Prioritize requirements based on importance and feasibility, and
facilitate discussions between stakeholders to resolve conflicts. Use
techniques like voting or consensus-building to reach agreements.
3. Incomplete or Evolving Requirements

 Challenge: Stakeholders may provide incomplete or vague requirements, or

their needs may evolve over time as they learn more about the system or
their priorities shift.
 Solution: Use iterative development approaches (e.g., Agile) where
requirements are refined and updated as the system progresses. Regular
reviews and feedback sessions help ensure the requirements remain aligned
with the stakeholders' needs.

4. Limited Access to Stakeholders

 Challenge: Stakeholders might not be readily available for interviews or

feedback sessions, especially in busy environments like educational
institutions where teachers, students, and admins have limited time.
 Solution: Schedule meetings well in advance, and consider using surveys,
focus groups, or feedback from representatives if direct communication is
not possible. Leverage virtual tools for asynchronous communication.

5. Lack of Technical Knowledge from Stakeholders

 Challenge: Non-technical stakeholders (e.g., teachers, administrators) may

struggle to articulate technical requirements, making it difficult to translate
their needs into feasible technical solutions.
 Solution: Educate stakeholders about the capabilities and limitations of the
system early on, and ensure that technical jargon is explained in simple
terms. Involve technical experts in the discussions to help bridge the gap.

6. Difficulty in Defining Performance Metrics

 Challenge: Defining performance metrics such as accuracy, speed, and

usability can be difficult. For instance, what level of face recognition accuracy
is acceptable? How fast should the attendance be marked?
 Solution: Use industry benchmarks or research to define realistic
performance goals. Work with stakeholders to establish measurable,
quantifiable criteria for the system’s performance and ensure that
expectations are aligned.
7. Balancing Functional and Non-Functional Requirements

 Challenge: While functional requirements (e.g., marking attendance) are

easy to define, non-functional requirements (e.g., system performance,
security, and scalability) can be more abstract and harder to specify.
 Solution: Use techniques such as prototyping or scenario-based analysis to
help stakeholders understand non-functional requirements. Ensure that
these are discussed early in the elicitation process and given proper
attention.

8. Unrealistic Expectations

 Challenge: Stakeholders may have unrealistic expectations regarding what

the system can achieve, especially in terms of accuracy, speed, or the level of
automation (e.g., expecting the system to work perfectly under all
conditions).
 Solution: Manage expectations by setting clear boundaries on the
capabilities of the system and providing realistic estimates for delivery.
Highlight potential limitations early in the project and use prototyping to
demonstrate what is feasible.

9. Cultural and Organizational Differences

 Challenge: Stakeholders from different departments (e.g., faculty, IT staff,

administration) may have different cultural or organizational perspectives
that influence their requirements and priorities. This can lead to
disagreements or misalignment.
 Solution: Facilitate open discussions between different groups to understand
their unique perspectives and needs. Focus on the overall goal of improving
efficiency, and find ways to compromise when necessary.

10. Changing Regulations or Legal Constraints

 Challenge: For projects involving personal data (e.g., students' images), legal
requirements such as data privacy laws (e.g., GDPR, CCPA) can complicate
the elicitation process, especially when handling sensitive data like facial
images.
 Solution: Involve legal or compliance experts early in the process to identify
any constraints or requirements related to data privacy and security. Make
sure the system complies with relevant regulations.
11. Limited Time and Resources

 Challenge: The time and resources allocated for requirements gathering

might be limited, leading to rushed or incomplete elicitation activities.
 Solution: Use prioritization techniques such as MoSCoW (Must have, Should
have, Could have, Won’t have) to focus on the most critical requirements.
Also, break the elicitation process into manageable phases to ensure
important aspects are thoroughly addressed.

Strategies to Overcome Elicitation Challenges

1. Use Prototyping: Creating simple prototypes or mockups can help

stakeholders visualize the system and provide more concrete feedback. This
is particularly useful for UI/UX design and for clarifying user needs.
2. Workshops and Focus Groups: Conduct workshops or focus groups with a
variety of stakeholders to encourage brainstorming and collaboration, which
can help uncover hidden requirements or conflicting viewpoints.
3. Surveys and Questionnaires: For large groups (e.g., students), surveys or
questionnaires can be effective in gathering feedback on their expectations
for the system.
4. Stakeholder Mapping: Identify key stakeholders and understand their roles,
needs, and expectations. This helps prioritize who should be involved at each
stage of the elicitation process.
5. Iterative and Incremental Elicitation: Break down the requirements into
smaller chunks and refine them over time. This approach is especially useful
in Agile methodologies, where requirements evolve as the project progresses.
6. Clear Documentation: Keep detailed records of all requirements and
feedback gathered. This documentation serves as a reference and ensures
nothing important is missed.
Experiment No. 3: What steps are needed to create a comprehensive Software
Requirements Specification (SRS)?
Software Requirement Specification SRS :
Product Scope:
Facial Recognition Module:a)Implementation of a robust facial
recognition system for identity verification.b)Integration of face
detection and recognition algorithms to accurately identifyindividuals.
Real-Time Database Integration:a)Integration with a real-time
database system (e.g., Firebase) to store attendancedata securely
and efficiently.b)Real-time synchronization of attendance records for
immediate access byauthorized users.
User Interfaces:Development of user-friendly interfaces for different
user roles:AttendeeInterface: for marking attendance using facial
recognition.
Authentication and Authorization:a)User authentication and
authorization mechanisms to control access andpermissions.b)Secure
access for administrators to manage attendance data.
Reporting and Analytics: a)Generation of absentee reports.
Scalability: a)Design for scalability to accommodate varying numbers
of attendees and check-inpoints.b)Consideration for future expansion
and integration with other systems.

Definition:
The system typically works as follows:
A camera captures a video stream of the individuals whose
attendance is to betaken.
The face detection algorithm in the system identifies and locates the
faces in thevideo stream.
The face recognition algorithm in the system compares the detected
faces to the faces in the database.
If a match is found, the system marks the individual as present and
stores their attendance data in the database. Otherwise, the system
marks the individual as absent.
The real-time database ensures that the attendance data is always up-
to-date and can be accessed by authorized admin at any time.
The system ensures that is the student is absent then an automatic
email should be sent to the registered mail id informing the parents
that he/she is not attendingthe classes.
HARDWARE INTERFACE
The hardware interface of a face attendance system using a real-time
databasetypically consists of the following components:
a) Camera: A camera/webcam is used to capture images of the faces
ofindividuals. The camera should be high-resolution and have a wide
field ofview to ensure that it can capture clear images of faces from a
variety ofangles and distances. (recommended webcam-Logitech HD
pro webcam).
b) Computer/Laptop: A computer/laptop is used to run the face
detectionand recognition algorithms.c)Network connection: A
network connection is required to connect thedevice to the real-time
database. The network bandwidth and latencyrequirements will
depend on the number of users and the amount of databeing
transferred

SOFTWARE INTERFACE
a) Attendance tracking screen:An attendance tracking screen where
users can mark their attendance.It includes the Face Registration
Screen with camera view on the leftpane.
After the face recognition, it shows the details of the student on
theright pane ,which include the Name of the student ,Roll number
,Branch,Current Year and the current updated attendance.
After marking the attendance ,it shows ‘MARKED’.
If same face is detected again ,it shows ‘ALREADY MARKED’.

b) Reporting screen: A reporting screen where administrators can view

reports on attendance data.This is basically for the
administrator’s view , which shows the details ofall the students and
their respective attendance including the lastattendance time.
DEPENDENCIES
The dependencies of a face attendance system using a real-time
database canbe divided into two categories: hardware dependencies
and softwaredependencies.
In addition to the above dependencies, the face attendance system
may alsodepend on other software components such as operating
systems, webservers, and application servers.
We must ensure that the system is compatible with the existing
hardware andsoftware environment.

CONSTRAINTS
Budget: The cost of developing and deploying a face attendance
system canvary depending on the size and complexity of the system,
the hardware andsoftware requirements. It is important to set a
budget for the project and tomake sure that the design and
implementation are within the budget constraints.
Timeline: The time required to develop and deploy a face attendance
systemcan also vary depending on the complexity of the system and
the resourcesavailable. It is important to set a realistic timeline for the
project and to trackprogress regularly to ensure that the project is on
track.
Expertise: The development and deployment of a face attendance
systemrequires expertise in a number of areas, such as computer
vision and databasemanagement. It is important to have thenecessary
expertise in-house or to hireexternal consultants.
Hardware and software requirements: The face attendance system
willrequire access to specific hardware and software components. It
is important tomake sure that the necessary hardware and software
is available before startingthe project.

User Characteristics :
Age: The system can be used by people of all ages, from children to
adults.
Technical expertise: The system is designed to be easy to use, even for
peoplewith limited technical expertise.
Physical characteristics: The system should be able to identify and
verify thefaces of individuals with a variety of physical characteristics,
such as differentskin color and hair color.
1. Functional requirements
• A login portal connected to the institute login, to be used by
students, professors and administrators.
• A dashboard for students and professors to view attendance
details for any class or course taken by them.
• An easy way for professors to make minor changes to
attendance policy for a class or the entire course directly from
the dashboard without needing to go through the
administration.
• An option on the dashboard for the administration to
manually override faulty attendance results.

2. Non Functional Requirements

The system should perform the process accurately and precisely
to avoidproblems.
The system should be easy to modify for any updates. Any
errors or bugs thatare identified should be easy to mend.
The system should be secure and maintain the privacy of the
students.
Experiment No. 4: What steps are needed to create function-oriented diagrams
like DFDs and Structured Charts?

DFD:

Attendance List

Student Details

Scan Face Face Admin

Student Attendance
System
Attendance
marked

Send mail to
absentee

Mail

a) Context Diagram
Level 1:

Scan Face

Register Mark
Generate the
employee Attendance absentee list

Mail

Level 2:

Generate Compare

Detect Face face generated

encoding
encoding with stored
encodings

Update

Detect Face attendance

Structured Charts:
Experiment No. 5: Create a use case diagram using Visual Paradigm UML

USE CASE DIAGRAM:

<<extend>>
Scan Face Attendace info

<<extend>> <<include>>
Student
Register Manager Info
Login System

<<extend>> <<include>>
Employee Status Register Employee info

,<<include>> Update attendance

Attendace Data <<include>>

override Admin
<<include>>

<<include>> Search attendance

<<include>>
Add employee ,<<extend>>
Scan Face
TimeTable info
Show timetable

Lecturer
Login:
Introduction: This use case describes how a employee attendance is
registered
Actors : i) Student ii) Manager iii) Admin
Pre Conditions : None
Post Conditions : If the use case is successful, the actor is logged into
the system. If not, the system state is unchanged
Basic Flow : This use case starts when the actor wishes to login to the
Attendance management system.
(i) System requests to scan the face.
(ii) Employee shows his/her face
(iii) System validates face and if finds correct it registers his
attendance
Alternate Flows
Invalid face If in the basic flow, the actor shows an invalid face, the
system displays an error message. The actor can choose to either
return to the beginning of the basic flow or cancel the attendance, at
that point, the use case ends.
Special Requirements: None
Use case Relationships: None
1.Maintain student details

3. Update a student
4. Maintain Result Details
5. Add Marks Records
6. View/Display resul
 Experiment No. 6: Create a class diagram using Visual Paradigm UML

CLASS DIAGRAM:

Manager User

Id : Char Id : Char
Name : Char Name: Char
Address : char
Provide: Sample()
Ph No.: Int

Qualification : Char
RequestToMatch()
Interacts With
Add Records()

UpdateRecords()

DeleteRecords()

ConvertImageIntoBinaryData()
//(-)section break

// Line break(/n) enter in

between text for line break
Experiment No. 7: Create an object diagram using Visual Paradigm UML
 Experiment No. 8: Create a Sequence diagram using Visual Paradigm UML

Interaction (Sequence) Diagram:

User

Face System Visitor

Attendance
records Records
recognition Information

Scan the face

Face Recognized
Record Attendance
Attendance Recorded

Face Unrecognized

Record as Visitor

Welcome Visitor
Experiment No. 9: Create a collaboration diagram using Visual
Paradigm UML