IDENTIFICATION AND DOCUMENTATION OF SYSTEM REQUIREMENTS

Student Attendance Management System (SAMS)

Course: System Analysis and Design

Project Type: Web-Based Information System

Prepared By: [Student Name]

Student ID: [Student ID]

Department: Computer Science and Engineering

Submitted To: [Teacher's Name]

Institution: [University Name]

Submission Date: [Date]

1. Introduction

1.1 Background

Attendance management is an essential activity in educational institutions. Teachers need to record student attendance, monitor participation, calculate attendance percentages, and prepare reports for academic purposes.

In a manual system, attendance may be recorded on paper or maintained in separate spreadsheets. This approach can lead to calculation errors, difficulties in retrieving historical records, duplicate entries, and delays in preparing reports.

The proposed Student Attendance Management System (SAMS) is a web-based application designed to centralize attendance records and automate routine attendance-related activities.

1.2 Purpose of the Document

The purpose of this document is to identify, analyze, and formally document the requirements of SAMS. It defines the system's expected functions, quality requirements, users, business rules, and acceptance criteria.

This document will serve as a foundation for system design, database development, implementation, and testing.

1.3 Project Objectives

Maintain student, teacher, course, and section information.
Allow authorized teachers to record attendance.
Calculate attendance percentages automatically.
Generate student-wise, course-wise, section-wise, and date-range reports.
Restrict access according to user roles.
Reduce manual calculations and repetitive administrative work.
Maintain accurate, secure, and retrievable attendance records.

2. Project Scope

2.1 In-Scope Features

User authentication and role-based access.
Student information management.
Teacher, course, and section management.
Teacher-course assignments.
Attendance recording for scheduled class sessions.
Attendance percentage calculation.
Attendance report generation.
Authorized attendance correction and change tracking.
Database backup and recovery procedures.

2.2 Out-of-Scope Features

Facial recognition or biometric attendance.
GPS-based attendance verification.
Online tuition fee collection.
Integration with external university ERP systems.
Predictive analytics.
Dedicated Android or iOS applications.

These features may be considered in a future version after evaluating user needs and project resources.

3. Stakeholder Identification

Stakeholders are individuals or groups who use, manage, approve, or are affected by the system.

Stakeholder	Role	Main Expectations
System Administrator	Manages user accounts, roles, and configuration.	Secure and manageable system.
Academic Administrator	Maintains student, course, section, and teacher records.	Accurate and updated academic information.
Teacher	Records attendance and prepares reports.	Fast and accurate attendance management.
Student	Views personal attendance information, if enabled.	Access to correct personal records.
Department Management	Reviews authorized attendance summaries.	Reliable information for academic decisions.
IT Support Staff	Maintains the application, server, and database.	Maintainable software and recoverable data.

3.1 Primary Stakeholders

The primary stakeholders are teachers and academic administrators because they directly interact with attendance records and academic information.

3.2 Secondary Stakeholders

Students, department management, and IT support staff are secondary stakeholders. Their needs influence reporting, privacy, security, and system maintenance requirements.

4. Requirement Elicitation

Requirement elicitation is the process of collecting information about what users need from the proposed system.

4.1 Interviews

Interviews with teachers and academic administrators can identify problems in the existing attendance process.

Sample interview questions:

How is attendance currently recorded?
What information is required before recording attendance?
How are attendance percentages calculated?
What types of reports are needed?
Who should be allowed to modify attendance records?
How should errors in attendance records be corrected?

4.2 Observation

The analyst can observe a teacher taking attendance and preparing a report to identify unnecessary steps, delays, and potential sources of error.

4.3 Document Analysis

Existing attendance sheets, course lists, section lists, and report formats can be reviewed to determine required data fields and output formats.

4.4 Prototype Review

A simple prototype of the login screen, attendance entry page, and report page can be shown to selected users. Their feedback can be used to refine the requirements.

Note: These are proposed elicitation methods and sample questions. They do not represent actual interviews or observations. A real project should record the participants, dates, findings, and approved decisions.

5. Functional Requirements

Functional requirements describe what the system must do. Each requirement has a unique identifier so it can be traced during implementation and testing.

ID	Functional Requirement	Priority
FR-01	The system shall allow registered users to log in using valid credentials.	High
FR-02	The system shall allow the administrator to create, update, and deactivate user accounts.	High
FR-03	The system shall allow authorized academic administrators to add, update, and retrieve student records.	High
FR-04	The system shall maintain course, section, teacher, and course-assignment records.	High
FR-05	The system shall display the enrolled student list for a selected course and section.	High
FR-06	The system shall allow an authorized teacher to record attendance for a selected class session.	High
FR-07	The system shall prevent accidental duplicate attendance records for the same student and class session.	High
FR-08	The system shall calculate attendance percentages according to the approved attendance policy.	High
FR-09	The system shall generate attendance reports by student, course, section, and date range.	High
FR-10	The system shall allow authorized users to correct attendance records according to institutional rules.	High
FR-11	The system shall record significant changes to attendance data, including the responsible user and timestamp.	High
FR-12	The system shall allow students to view their own attendance information if the student portal is enabled.	Medium
FR-13	The system shall allow authorized users to export attendance reports to an approved format, such as CSV or PDF.	Medium

5.1 Detailed Functional Requirement Example

Requirement ID: FR-06

Requirement Name: Record Student Attendance

Description: The system shall allow an authorized teacher to record attendance for a selected course, section, and class session.

Preconditions:

The teacher is logged in.
The teacher is assigned to the selected course offering.
The selected section and enrolled student list exist.

Main Process:

The teacher opens the attendance module.
The teacher selects a course and section.
The teacher selects the class date or scheduled session.
The system displays the enrolled students.
The teacher marks each student according to the permitted attendance statuses.
The teacher submits the attendance record.
The system validates the data.
The system saves the attendance records and displays a confirmation message.

Alternative Flow: If an attendance record already exists for the selected session, the system shall prevent an accidental duplicate and direct the teacher to the authorized correction process if an update is permitted.

Postcondition: Attendance data is saved and available for authorized reports.

6. Non-Functional Requirements

Non-functional requirements define the quality attributes and operating constraints of the system. The following numerical targets are proposed for the example project and should be reviewed against the actual infrastructure and user workload before implementation.

ID	Category	Requirement	Verification
NFR-01	Performance	Under an agreed workload of 100 concurrent users, 95% of ordinary page requests shall complete within 3 seconds, excluding external network delays.	Load testing
NFR-02	Security	All protected operations shall require authentication and role-based authorization.	Security testing
NFR-03	Usability	A trained teacher shall be able to record attendance for up to 50 students within 3 minutes under normal operating conditions.	Usability testing
NFR-04	Reliability	If saving attendance fails, the system shall display an error and shall not show a success message unless the records have been saved.	Failure testing
NFR-05	Availability	The production system shall target 99.5% monthly availability, excluding approved maintenance windows.	Availability monitoring
NFR-06	Maintainability	The application shall separate presentation, application logic, and database operations to simplify maintenance and testing.	Code review
NFR-07	Compatibility	The interface shall support the current and immediately preceding major versions of the browsers selected by the institution.	Cross-browser testing
NFR-08	Backup and Recovery	The production database shall be backed up at least once every 24 hours, and restoration shall be tested periodically.	Backup and recovery testing
NFR-09	Privacy	Users shall only access student information necessary for their authorized duties.	Access-control testing
NFR-10	Auditability	Significant attendance changes shall be attributable to an authenticated user and include a timestamp.	Audit-log inspection

6.1 Security Considerations

Secure password storage.
Session management and logout.
Role-based authorization.
Input validation.
Protection against common web application vulnerabilities.
Restricted database credentials.
Appropriate audit logging.
Regular backups and recovery tests.

7. Business Rules

Business rules define institutional policies that the system must follow. The following are proposed rules and must be confirmed by the institution before implementation.

Rule ID	Business Rule
BR-01	Every attendance record must be associated with a valid student, course offering, and class session.
BR-02	Only authorized users may create or modify attendance records.
BR-03	A student shall have no more than one attendance record for the same class session unless the approved data model explicitly supports multiple records.
BR-04	Attendance percentages shall be calculated according to the institution's approved policy.
BR-05	Attendance corrections shall follow the approved correction procedure and be recorded in the audit history.
BR-06	Teachers shall only manage attendance for course offerings assigned to them, unless additional permission is granted.
BR-07	Student users, if enabled, shall only view their own attendance records.
BR-08	Attendance reports shall only be accessible to users with the appropriate permissions.

7.1 Attendance Percentage Calculation

For this example, assume the institution calculates attendance based on the number of sessions attended divided by the total eligible sessions.

Attendance Percentage = (Sessions Attended ÷ Total Eligible Sessions) × 100

Example: 18 sessions attended out of 24 eligible sessions.
Attendance Percentage = (18 ÷ 24) × 100 = 75%

The institution must define how excused absences, cancelled classes, late arrivals, and other special cases are handled.

8. Data Requirements

The system must maintain the information needed to support attendance management.

Data Entity	Example Attributes	Purpose
User	User ID, username, password hash, role, account status	Authentication and access control
Student	Student ID, name, programme, section, status	Student identification
Teacher	Teacher ID, name, contact information, status	Teacher identification
Course	Course ID, course code, course title, credit hours	Course information
Course Offering	Offering ID, course ID, section, term, assigned teacher	Connects a course to a particular term and section
Class Session	Session ID, offering ID, session date, session status	Identifies a specific scheduled class
Attendance	Attendance ID, session ID, student ID, status, recorded time	Stores attendance results
Audit Log	Log ID, user ID, action, record reference, timestamp	Tracks significant changes

8.1 Data Integrity Requirements

Every primary identifier shall be unique.
Attendance records shall reference valid students and class sessions.
Required fields shall not be left empty.
Attendance statuses shall be restricted to approved values.
Database constraints shall prevent invalid relationships and accidental duplicate records.
Appropriate backups shall be maintained for production data.

9. Use Case Documentation

A use case describes how a user interacts with the system to achieve a goal.

9.1 Use Case: Record Attendance

Use Case ID: UC-01

Primary Actor: Teacher

Goal: Record attendance for a scheduled class session.

Preconditions:

The teacher is authenticated.
The teacher has permission to manage the selected course offering.
The class session and student enrolment records are available.

Trigger: The teacher selects the attendance-recording function.

Main Success Scenario:

The teacher selects the course offering.
The system displays the available class sessions.
The teacher selects a session.
The system displays the enrolled students.
The teacher records the attendance statuses.
The teacher submits the attendance.
The system validates the submitted data.
The system saves the records.
The system displays a successful submission message.

Alternative Scenarios:

If the teacher lacks permission, the system denies access.
If required data is missing, the system identifies the validation error.
If a duplicate submission is detected, the system prevents duplicate records.
If saving fails, the system displays an error and does not report success.

Postcondition: The attendance records are stored and available to authorized users.

9.2 Use Case: Generate Attendance Report

Use Case ID: UC-02

Primary Actor: Teacher or Academic Administrator

Goal: Generate an attendance report.

Main Success Scenario:

The user opens the report module.
The user selects the permitted course, section, student, or date range.
The system validates the selected filters and access permissions.
The system retrieves the matching attendance records.
The system calculates the required attendance statistics.
The system displays the report.
The user may export the report if authorized.

Postcondition: The requested report is displayed or exported according to the user's permissions.

10. Acceptance Criteria

Acceptance criteria define how the project team will determine whether a requirement has been implemented correctly.

Test ID	Related Requirement	Test Scenario	Expected Result
TC-01	FR-01	Enter valid login credentials.	The user can access permitted functions.
TC-02	FR-01	Enter an invalid password.	Access is denied and an appropriate error is displayed.
TC-03	FR-06	Submit valid attendance for a class session.	Attendance records are saved correctly.
TC-04	FR-07	Submit attendance twice for the same session.	Duplicate records are prevented or safely handled.
TC-05	FR-08	Calculate attendance for 18 attended sessions out of 24.	The system displays 75%.
TC-06	FR-09	Generate a report for a selected course and date range.	Only matching records are included.
TC-07	NFR-02	A teacher attempts to access an unassigned course.	Access is denied unless explicit authorization exists.
TC-08	NFR-04	Simulate a database save failure.	An error is displayed and no false success message appears.
TC-09	NFR-08	Restore a backup in a test environment.	The backup can be restored and the recovered data is verified.
TC-10	NFR-01	Run the agreed concurrent-user load test.	The response-time target is met or deviations are documented.

11. Requirement Traceability Matrix (RTM)

The Requirement Traceability Matrix connects requirements with their sources and verification activities.

Requirement ID	Requirement Summary	Source	Verification Method	Status
FR-03	Manage student records	Academic Administrator	Functional test	Planned
FR-06	Record attendance	Teacher interview requirement	Functional test	Planned
FR-08	Calculate attendance percentage	Approved academic policy	Calculation test	Planned
FR-09	Generate attendance reports	Teacher and management needs	Report test	Planned
NFR-01	Meet response-time target	Project performance target	Load test	Planned
NFR-02	Enforce authorization	Security requirement	Access-control test	Planned
NFR-08	Maintain and restore backups	Operational requirement	Recovery test	Planned

A requirement should not be marked complete merely because code has been written. Its implementation and verification results should be documented.

12. Assumptions and Constraints

12.1 Assumptions

Teachers and academic administrators will participate in requirement validation.
The institution will provide or approve access to required academic information.
Authorized users will receive basic training.
The institution will approve attendance calculation and correction policies.
The required development tools and infrastructure will be available.

12.2 Constraints

The initial version has a limited project scope.
Development must follow the approved academic schedule.
Student information must be protected.
Only approved software and services may be used.
Production deployment requires appropriate institutional authorization.
Performance and availability targets depend on the final infrastructure and workload.

13. Requirement Validation and Approval

Before implementation begins, the documented requirements should be reviewed by the relevant stakeholders.

The validation process should confirm that:

Each requirement reflects an identified user or business need.
Requirements are clear, consistent, and feasible.
Functional requirements have identifiable expected results.
Non-functional requirements have measurable acceptance criteria where appropriate.
Business rules match approved institutional policies.
Privacy, security, and access restrictions are defined.
Requirements are prioritized and linked to test cases.
Changes are recorded and approved by the responsible stakeholders.

Approval Record

Role	Name	Signature	Date
Student / Analyst	[Name]	________________	____________
Project Supervisor	[Name]	________________	____________
User Representative	[Name]	________________	____________

This is a proposed approval template. Signatures should be added only after the relevant people have reviewed the document.

14. Conclusion

This report identifies and documents the major requirements of the Student Attendance Management System. It defines the project scope, stakeholders, functional requirements, non-functional requirements, business rules, data requirements, use cases, acceptance criteria, and traceability relationships.

The documented requirements provide a foundation for designing the database, developing the application, preparing test cases, and evaluating the completed system.

Before implementation, the requirements should be validated with actual stakeholders, and the proposed business rules and performance targets should be approved. This will help ensure that the final system meets its intended objectives and operates within the institution's requirements.

15. References

Dennis, A., Wixom, B. H., and Tegarden, D. Systems Analysis and Design: An Object-Oriented Approach with UML. Wiley.
Satzinger, J. W., Jackson, R. B., and Burd, S. D. Systems Analysis and Design in a Changing World. Cengage Learning.
ISO/IEC/IEEE 29148. Systems and Software Engineering — Life Cycle Processes — Requirements Engineering. Consult the applicable edition for formal requirements documentation guidance.
Oracle. Oracle Database Documentation. https://docs.oracle.com/
Apache Software Foundation. Apache Tomcat Documentation. https://tomcat.apache.org/

Submission Note: Replace the cover-page placeholders with your actual details. The project assumptions, stakeholder findings, business rules, and performance targets should be validated for your chosen project before presenting them as approved requirements.