INTERVIEW QUESTIONS AND STAKEHOLDER ANALYSIS REPORT

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 important administrative activity in educational institutions. Teachers must record student attendance, maintain historical records, calculate attendance percentages, and prepare reports for academic purposes.

In a manual attendance system, teachers may use paper sheets or spreadsheets. These methods can make record retrieval difficult, require repetitive calculations, and create opportunities for data-entry errors.

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

1.2 Purpose of the Report

This report aims to:

1. Identify the stakeholders of the proposed SAMS project.
2. Analyze their roles, interests, and information needs.
3. Prepare interview questions for the major stakeholder groups.
4. Present an illustrative interview report and potential findings.
5. Convert potential findings into proposed system requirements.
6. Develop a plan for validating findings with stakeholders.

1.3 Project Objectives

• Maintain student, teacher, course, and section information.
• Allow authorized teachers to record student attendance.
• Calculate attendance percentages automatically.
• Generate student-wise and course-wise attendance reports.
• Control access to attendance records.
• Support authorized attendance corrections.
• Maintain a history of significant changes.

2. Project Overview

2.1 Project Name

Student Attendance Management System (SAMS).

2.2 Proposed System

SAMS will be a web-based application that allows authorized users to manage student attendance through a centralized database.

The proposed technology stack is Java Server Pages (JSP), Java, JDBC, and Oracle Database. These are preliminary technology choices and may be revised after technical feasibility analysis.

2.3 Project Scope

Included features:

• User login and role-based access.
• Student and course information management.
• Section and teacher-course assignment management.
• Attendance recording.
• Attendance percentage calculation.
• Attendance report generation.
• Authorized attendance correction.
• Audit history for significant changes.

Excluded from the initial version:

• Facial recognition.
• Biometric attendance devices.
• GPS-based attendance.
• Online tuition fee payment.
• Integration with external ERP systems.

These features may be considered in a future version.

3. Stakeholder Identification

A stakeholder is any person or group that uses, manages, approves, supports, or is affected by the proposed system.

Stakeholder	Role	Main Interest
Teachers	Record attendance and review reports.	Fast and accurate attendance entry.
Students	View their own attendance, if enabled.	Access to accurate attendance information.
Academic Administrator	Maintain academic records and course assignments.	Consistent and organized records.
Department Management	Review authorized attendance summaries.	Reliable information for academic decisions.
System Administrator	Manage accounts and system permissions.	Secure and controlled access.
IT Support Staff	Maintain the application and database.	System reliability and recoverability.

3.1 Primary Stakeholders

Teachers and academic administrators are primary stakeholders because they directly interact with the attendance process and its supporting records.

3.2 Secondary Stakeholders

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

3.3 Stakeholder Analysis

Stakeholder	Power / Influence	Interest	Engagement Strategy
Teachers	High	High	Interviews, workflow observation, prototype review.
Academic Administrator	High	High	Detailed interviews and policy validation.
Students	Low to Medium	High	Questionnaires and usability feedback.
Department Management	High	Medium to High	Requirements review and approval.
System Administrator	High	High	Security and account-management discussions.
IT Support Staff	Medium to High	High	Technical feasibility and maintenance review.

The influence levels are preliminary estimates for this example project. They should be reviewed according to the actual institution and its decision-making structure.

4. Interview Plan

4.1 Interview Objectives

The interviews will investigate:

1. The current attendance-recording process.
2. Problems with the existing method.
3. Required information and reports.
4. Rules for correcting attendance.
5. User roles and access permissions.
6. Security, reliability, and usability expectations.
7. Constraints affecting implementation.

4.2 Proposed Interview Participants

Interview Code	Participant	Proposed Duration	Purpose
INT-01	Course Teacher	20–30 minutes	Understand attendance recording and reporting.
INT-02	Academic Administrator	20–30 minutes	Understand academic records and approval procedures.
INT-03	Student Representative	15–20 minutes	Identify student information needs.
INT-04	System Administrator / IT Staff	20–30 minutes	Identify security and technical requirements.
INT-05	Department Management Representative	15–20 minutes	Understand reporting and oversight needs.

These are proposed interviews, not evidence that the participants have already been interviewed. Actual participants and durations should be documented after the interviews take place.

5. Interview Questions for Teachers

Interview Code: INT-01

Objective: Understand how teachers record attendance and prepare reports.

1. How do you currently record student attendance?
2. How do you obtain the enrolled student list for each course and section?
3. What information do you record during each class session?
4. How do you distinguish present, absent, late, or other attendance statuses?
5. How do you calculate attendance percentages?
6. What difficulties do you experience when recording attendance?
7. How much time does attendance recording usually take for one class?
8. How do you retrieve attendance records from previous classes?
9. How do you correct an attendance entry if a mistake is discovered?
10. Who should be permitted to approve or perform attendance corrections?
11. What types of attendance reports do you need?
12. Should the system allow report filtering by student, course, section, and date?
13. What should happen if the database or network becomes unavailable while attendance is being saved?
14. What features would make the system easier to use?
15. What additional requirements should the analyst consider?

Expected output: A documented teacher workflow, attendance-entry requirements, reporting requirements, and correction procedures.

6. Interview Questions for Academic Administrators

Interview Code: INT-02

Objective: Understand how academic records and attendance-related policies are managed.

1. How are student records currently maintained?
2. How are courses, sections, and course offerings defined?
3. How are teachers assigned to courses and sections?
4. How does the department obtain the official enrolment list?
5. How are changes to student registration handled?
6. What attendance reports are required by the department?
7. What attendance calculation rules must the system follow?
8. Are there institutional rules for excused absences or cancelled classes?
9. Who can authorize attendance corrections?
10. How should correction requests be documented?
11. What information must be included in an official attendance report?
12. Should reports be exportable to CSV, Excel-compatible formats, or PDF?
13. What records should be retained for historical reference?
14. Which users should be permitted to view or modify academic information?
15. What approval process should be followed before the system is deployed?

Expected output: Academic data requirements, business rules, report formats, access policies, and approval procedures.

7. Interview Questions for Students

Interview Code: INT-03

Objective: Identify student needs regarding attendance information.

1. How do you currently check your attendance?
2. How frequently do you need to check attendance information?
3. What attendance information would be most useful to you?
4. Would you prefer to see attendance by course or as an overall summary?
5. Should the system display the total number of classes conducted?
6. Should students be able to view individual present and absent records?
7. How should a student report a suspected attendance error?
8. Would notifications about attendance changes be useful?
9. What devices would you normally use to access the system?
10. What difficulties might you face while using an online attendance portal?
11. What security or privacy concerns would you have?
12. What improvements would you suggest?

Expected output: Student portal requirements, usability expectations, and a proposed process for reporting attendance discrepancies.

8. Interview Questions for IT Support Staff

Interview Code: INT-04

Objective: Identify technical, security, deployment, and maintenance requirements.

1. What server and database infrastructure is currently available?
2. Can the proposed application be hosted on the institution's existing infrastructure?
3. What authentication and authorization mechanisms are required?
4. How should passwords and sensitive information be protected?
5. What backup frequency is appropriate?
6. How will database restoration be tested?
7. What monitoring and error-logging facilities are needed?
8. What level of concurrent usage should the system support?
9. Which browsers and devices should be supported?
10. What are the expected availability requirements?
11. How should software updates be deployed?
12. Who will be responsible for ongoing maintenance?
13. What security risks should be addressed before deployment?
14. What technical training will users and administrators require?
15. What infrastructure limitations may affect the project?

Expected output: Technical feasibility information, security requirements, deployment constraints, and maintenance requirements.

9. Interview Questions for Department Management

Interview Code: INT-05

Objective: Identify management expectations and reporting requirements.

1. What decisions should attendance reports support?
2. Which attendance summaries are required for departmental review?
3. How frequently should these reports be generated?
4. Who should have access to summary and individual-level reports?
5. What institutional policies must the system follow?
6. How should attendance disputes be handled?
7. Which system features are essential for the first release?
8. What are the major project constraints?
9. What criteria will be used to evaluate project success?
10. Who will approve the final requirements and authorize deployment?

Expected output: Management reporting needs, priorities, governance requirements, and acceptance criteria.

10. Illustrative Interview Report

Important: The following is a sample report showing how interview results could be documented. The findings are illustrative and must not be presented as actual interview results unless they have been confirmed through real interviews.

10.1 Sample Interview Summary

Interviewee Role	Illustrative Finding	Potential Requirement
Teacher	Preparing attendance summaries may require repetitive manual work.	Generate attendance reports automatically.
Teacher	Finding old records may be difficult when records are kept separately.	Provide searchable attendance history.
Academic Administrator	Course and student lists must be consistent.	Maintain structured student and course records.
Student Representative	Students may want to check attendance without repeatedly contacting teachers.	Provide a personal attendance view, if approved.
IT Support Staff	Access to attendance records should depend on user responsibilities.	Implement role-based access control.
Department Management	Reports should be available for authorized academic review.	Provide controlled summary reports.

10.2 Sample Interview Notes: Course Teacher

Interview Code: INT-01

Topic: Attendance Recording Process

Status: Illustrative example only

Question: How is attendance currently recorded?

Illustrative response: Attendance may be recorded using paper sheets or spreadsheets, depending on the current departmental process.

Analyst's interpretation: The system should support structured digital attendance entry.

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

Question: How are attendance percentages calculated?

Illustrative response: The teacher may calculate percentages manually or use spreadsheet formulas.

Analyst's interpretation: The calculation process should be consistent and follow approved institutional rules.

Proposed requirement: The system shall calculate attendance percentages using the approved attendance calculation policy.

Question: How should attendance mistakes be corrected?

Illustrative response: A correction procedure may be required to prevent unauthorized changes.

Analyst's interpretation: Corrections should be permission-controlled and traceable.

Proposed requirement: The system shall record authorized attendance corrections with the responsible user's identity, timestamp, and relevant change details.

10.3 Sample Interview Notes: Academic Administrator

Interview Code: INT-02

Topic: Academic Data and Reports

Status: Illustrative example only

Question: What information is needed to maintain course and section records?

Illustrative response: The system may need course codes, course titles, academic terms, sections, assigned teachers, and enrolled students.

Analyst's interpretation: The database should represent courses, course offerings, sections, teachers, and students using appropriate relationships.

Proposed requirement: The system shall maintain course-offering and enrolment information so attendance can be linked to the correct academic context.

Question: Which reports are needed?

Illustrative response: The department may require student-wise, course-wise, section-wise, and date-range reports.

Analyst's interpretation: Reports should support the required filters and access restrictions.

Proposed requirement: The system shall generate attendance reports using approved filters and user permissions.

11. Analysis of Interview Findings

Issue Identified	Analysis	Proposed Action
Manual attendance processing	May create repetitive work and calculation errors.	Develop a digital attendance-entry module.
Separate attendance records	May make retrieval and consolidation difficult.	Use a centralized database.
Inconsistent correction practices	May affect data reliability.	Define a correction workflow and audit trail.
Difficulty obtaining reports	May delay academic review.	Provide searchable, filterable reports.
Different user responsibilities	Users need different access levels.	Define roles and permissions.
Unclear attendance policies	System calculations may not match institutional rules.	Obtain formal policy clarification before implementation.

These issues should be confirmed through interviews, observation, document analysis, or other appropriate fact-finding methods before they are treated as established facts.

12. Proposed System Requirements

12.1 Functional Requirements

ID	Requirement
FR-01	The system shall allow registered users to log in using valid credentials.
FR-02	The system shall allow authorized administrators to create, update, and retrieve student records.
FR-03	The system shall maintain course offerings, sections, teacher assignments, and enrolment information.
FR-04	The system shall allow authorized teachers to record attendance for a selected class session.
FR-05	The system shall calculate attendance percentages according to the approved institutional policy.
FR-06	The system shall generate attendance reports by student, course, section, and date range.
FR-07	The system shall allow authorized users to correct attendance records according to the approved procedure.
FR-08	The system shall maintain a history of significant attendance changes, including the responsible user and timestamp.
FR-09	If approved, the system shall allow each student to view their own attendance information.
FR-10	The system shall restrict operations and reports according to user permissions.

12.2 Non-Functional Requirements

ID	Category	Requirement
NFR-01	Security	Protected functions shall require authentication and appropriate authorization.
NFR-02	Usability	The attendance-entry interface shall be understandable and efficient for trained teachers.
NFR-03	Reliability	The system shall provide clear feedback when an attendance operation fails and shall not report success unless the data has been saved.
NFR-04	Maintainability	The application shall separate presentation, application logic, and database operations.
NFR-05	Backup and Recovery	The database shall be backed up according to an approved schedule, and restoration shall be tested periodically.

These are proposed requirements. Specific performance targets and institutional rules must be validated before approval.

13. Stakeholder Validation Plan

After the interviews, the analyst should share the findings and proposed requirements with the relevant stakeholders.

Validation Activity	Responsible Participants	Expected Outcome
Review attendance workflow	Teachers	Confirm or correct the documented process.
Validate academic data	Academic Administrator	Confirm required fields and relationships.
Review student access	Student Representative and Management	Decide whether a student portal is required.
Review security requirements	IT Support Staff and System Administrator	Confirm access and protection requirements.
Review reports	Teachers and Department Management	Approve report contents and filters.
Approve business rules	Authorized institutional representatives	Confirm attendance calculation and correction policies.
Final requirements review	Project Supervisor and stakeholders	Identify approved requirements and unresolved issues.

Requirements should be updated when stakeholders identify missing, conflicting, or incorrect information.

14. Ethical and Professional Considerations

During fact-finding, the system analyst should:

1. Explain the purpose of each interview.
2. Obtain appropriate permission before collecting information.
3. Respect participant confidentiality.
4. Avoid collecting unnecessary personal information.
5. Record responses accurately without changing their intended meaning.
6. Separate actual findings from assumptions and recommendations.
7. Avoid presenting illustrative responses as real interview evidence.
8. Confirm important business rules with authorized stakeholders.

15. Conclusion

This report identifies the major stakeholders of the proposed Student Attendance Management System and provides structured interview questions for teachers, students, academic administrators, IT support staff, and department management.

The stakeholder analysis helps the system analyst understand different expectations and responsibilities. The interview plan supports systematic information collection, while the illustrative interview report demonstrates how responses can be analyzed and converted into proposed system requirements.

The next step is to conduct the interviews, document actual findings, validate the requirements, and use the approved requirements to guide system design and implementation.

16. References

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

17. Submission Checklist

• Replace the cover-page placeholders.
• Conduct interviews if the assignment requires primary research.
• Replace illustrative responses with actual, accurately documented findings.
• Include interview dates and participant roles where permission allows.
• Confirm institutional attendance policies and report requirements.
• Review and approve the final requirements with the relevant stakeholders.

Academic integrity note: Sample answers and findings in this report are illustrative. Do not represent them as actual interview evidence unless you have collected and verified the information.

Fact-Finding Techniques in System Analysis and Design

Topic: Interviews, Questionnaires, Observation, and Document Analysis

Example Project: Student Attendance Management System (SAMS)

Learning Objective: Understand how a system analyst collects reliable information from users and existing records before designing a new information system.

1. Introduction to Fact-Finding

Fact-finding is the systematic process of collecting information about an existing system, its users, business processes, problems, and requirements. It is an important activity in the System Analysis and Design (SAD) process.

Before developing a new system, an analyst must understand how the current system operates, what difficulties users experience, what information they need, and what improvements they expect.

For example, before developing a Student Attendance Management System, the analyst needs to understand how teachers record attendance, how attendance percentages are calculated, who can correct records, and how attendance reports are prepared.

1.1 Why Is Fact-Finding Necessary?

• To understand the existing business process.
• To identify problems and their causes.
• To identify users and other stakeholders.
• To collect functional and non-functional requirements.
• To discover missing, duplicated, or unnecessary activities.
• To verify assumptions before designing the system.
• To reduce misunderstandings and costly changes during development.

1.2 Example: The Existing Attendance Process

Suppose a department records attendance using paper sheets or separate spreadsheets. Teachers calculate attendance percentages manually, and students contact teachers to check their records.

The analyst may investigate the following questions:

• How does a teacher obtain the enrolled student list?
• How is attendance recorded for each class?
• How are absent and present students identified?
• How are attendance percentages calculated?
• Who approves attendance corrections?
• How are reports prepared for academic management?

The answers provide the foundation for the requirements of the proposed system.

2. Four Major Fact-Finding Techniques

Technique	How It Works	Example in SAMS	Primary Benefit
Interview	Direct conversation with stakeholders.	Discuss attendance problems with teachers.	Detailed explanations and follow-up questions.
Questionnaire	A structured set of questions distributed to many people.	Ask 100 students about attendance-report access.	Collects comparable feedback from many respondents.
Observation	Watch a real process as it is performed.	Observe a teacher recording attendance.	Reveals actual practices and workflow problems.
Document Analysis	Examine existing forms, reports, rules, and records.	Review attendance sheets and report formats.	Identifies existing data fields, rules, and outputs.

3. Interview Technique

3.1 Definition

An interview is a fact-finding technique in which the system analyst asks questions directly to stakeholders to understand their needs, experiences, problems, and expectations.

Interviews may be conducted face-to-face or through an online meeting. They are especially useful when an analyst needs detailed information or wants to clarify an answer.

3.2 Types of Interviews

Type	Description	Example
Structured	Uses a predetermined list of questions.	Ask every teacher the same questions about attendance recording.
Unstructured	Uses a flexible conversation guided by the topic.	Discuss general difficulties with a department administrator.
Semi-structured	Uses prepared questions while allowing follow-up questions.	Ask standard questions and explore unexpected problems.

3.3 Interview Process

Step 1: Identify the interviewee.
Choose stakeholders who understand the process, such as teachers, academic administrators, or IT staff.

Step 2: Define the purpose.
Decide what information is needed from the interview.

Step 3: Prepare questions.
Write clear, neutral questions and arrange them in a logical order.

Step 4: Conduct the interview.
Explain the purpose, ask questions, listen carefully, and ask follow-up questions where necessary.

Step 5: Record the findings.
Document the answers, issues, proposed requirements, and unresolved questions.

Step 6: Confirm the findings.
Share a summary with the interviewee to correct misunderstandings.

3.4 Sample Interview for SAMS

Interviewee: Course Teacher

Purpose: Understand the existing attendance-recording process.

Note: The following is a sample interview guide, not a record of an actual interview.

Q1. How do you currently record attendance?
Possible finding: Attendance is recorded on paper or in a spreadsheet.

Q2. How do you obtain the student list for a course section?
Possible finding: The teacher uses an enrolment list provided by the department.

Q3. How do you calculate attendance percentages?
Possible finding: Percentages are calculated manually or by spreadsheet formulas.

Q4. What problems do you experience?
Possible finding: Preparing reports and checking old records takes time.

Q5. Should teachers be able to edit attendance after submission?
Possible finding: Corrections may require authorization and a record of the change.

Q6. What reports do you need?
Possible finding: Student-wise and course-wise attendance reports are required.

3.5 Advantages of Interviews

• Provides detailed information.
• Allows immediate clarification.
• Helps discover unexpected problems.
• Allows the analyst to explore stakeholder expectations.
• Builds communication between users and the analyst.

3.6 Limitations of Interviews

• Can be time-consuming when many people are involved.
• Answers may be influenced by personal opinions or memory.
• Some interviewees may not describe their actual practices accurately.
• Findings need to be documented and validated carefully.

4. Questionnaire Technique

4.1 Definition

A questionnaire is a structured set of written questions used to collect information from a group of respondents. It may be distributed using online forms, email, printed sheets, or other approved channels.

Questionnaires are useful when the analyst needs comparable information from many people within a limited period.

4.2 Types of Questionnaire Questions

Question Type	Description	Example
Closed-ended	Respondents select from predefined answers.	Do you currently check attendance online? Yes / No.
Multiple-choice	Respondents choose one or more options.	Which report do you need? Student-wise / Course-wise / Both.
Rating scale	Respondents rate an opinion or experience.	Rate the difficulty of manual attendance recording from 1 to 5.
Open-ended	Respondents answer in their own words.	What improvement would you suggest for attendance management?

4.3 Sample Questionnaire for SAMS

Target respondents: Students

Purpose: Identify student needs for an attendance management system.

The questions below are examples. Responses should be collected before drawing conclusions about actual users.

Q1. How do you currently check your attendance?

• Ask the course teacher.
• Check a displayed attendance sheet.
• Use an existing online system.
• Other.

Q2. How frequently do you need to check your attendance?

• Every week.
• Several times during a semester.
• Only before examinations.
• Other.

Q3. Which information should the system display?

• Present and absent sessions.
• Total classes conducted.
• Attendance percentage.
• Course-wise attendance summary.
• All of the above.

Q4. How useful would online attendance information be?

• 1 — Not useful.
• 2 — Slightly useful.
• 3 — Moderately useful.
• 4 — Very useful.
• 5 — Extremely useful.

Q5. What concerns would you have about an online attendance system?

Answer: __________________________________________

Q6. What additional features would you suggest?

Answer: __________________________________________

4.4 Questionnaire Design Guidelines

• Use simple and unambiguous language.
• Ask one clear question at a time.
• Avoid leading questions that encourage a particular answer.
• Provide relevant answer options.
• Include an appropriate option such as “Other” where needed.
• Keep the questionnaire reasonably short.
• Test it with a small group before wider distribution.
• Explain the purpose and handle respondents' information appropriately.

4.5 Advantages of Questionnaires

• Can collect information from many respondents.
• Responses can be compared and summarized.
• Online questionnaires are relatively easy to distribute.
• Respondents can answer at a convenient time.
• Rating-scale responses can help identify patterns.

4.6 Limitations of Questionnaires

• Response rates may be low.
• Respondents may misunderstand a question.
• Open-ended answers may be difficult to analyze.
• The analyst cannot always ask immediate follow-up questions.
• A poorly designed questionnaire may produce misleading results.

5. Observation Technique

5.1 Definition

Observation is a fact-finding technique in which the analyst watches users perform their normal tasks to understand the actual workflow, tools, decisions, and difficulties involved.

People may describe a process differently from how they actually perform it. Observation helps the analyst identify such differences.

5.2 Types of Observation

Type	Description	Example
Direct observation	The analyst watches the process as it occurs.	Observe a teacher taking attendance in class.
Participant observation	The observer participates in some parts of the activity when appropriate.	Assist with a controlled demonstration of an attendance workflow.
Structured observation	The analyst uses a checklist of specific actions or events.	Record the steps and time needed to prepare a report.
Unstructured observation	The analyst records general behavior and issues without a rigid checklist.	Explore how staff handle unexpected attendance corrections.

5.3 Observation Example: Taking Attendance

Suppose the analyst observes a teacher taking attendance for a class of 50 students. The analyst records the workflow and notes where delays or errors may occur.

Observed Activity	Potential Issue	Possible System Requirement
Teacher finds the correct student list.	Lists may be stored in different locations.	Display the enrolled list by course and section.
Teacher marks each student.	Manual marking may take time.	Provide a simple attendance-entry interface.
Teacher calculates attendance totals.	Manual calculation may introduce errors.	Calculate attendance percentages automatically.
Teacher checks earlier records.	Historical records may be difficult to retrieve.	Provide searchable attendance history.
Teacher corrects a mistaken entry.	The correction may not be documented.	Provide authorized corrections with audit history.

5.4 Sample Observation Checklist

Observation Item	Finding / Notes
Process observed	Recording student attendance
Person performing the task	[Teacher role or approved identifier]
Tools used	[Paper sheet, spreadsheet, or existing application]
Sequence of activities	[Record each step in order]
Time required	[Record actual measured time]
Problems observed	[Document factual observations]
Potential improvement	[Describe possible improvement for validation]

5.5 Advantages of Observation

• Reveals the actual working process.
• Identifies unnecessary steps and delays.
• Helps discover exceptions and workarounds.
• Provides context for information gathered through interviews.
• Can help establish baseline task times.

5.6 Limitations of Observation

• People may change their behavior when being observed.
• Observation may require considerable time.
• Some activities occur too rarely to observe during a short visit.
• The observer may misinterpret the reason for an action.
• Privacy and permission must be considered before observing real work.

6. Document Analysis Technique

6.1 Definition

Document analysis is the examination of existing documents, forms, spreadsheets, reports, policies, manuals, and records to understand the current system and identify information requirements.

Documents can reveal what data is collected, how it is organized, what rules apply, and what outputs users expect.

6.2 Documents for the SAMS Project

Document	Information to Identify	Potential Requirement
Attendance Sheet	Student identifiers, dates, attendance marks.	Store attendance by student and class session.
Student Enrolment List	Student ID, name, course, section.	Display the correct enrolled student list.
Course Offering List	Course, term, section, assigned teacher.	Maintain course and teacher assignments.
Attendance Summary	Sessions held, attendance totals, percentages.	Generate attendance statistics and reports.
Academic Attendance Policy	Calculation rules, thresholds, exceptions.	Apply approved attendance rules.
Correction Request Form	Reason for correction, approval, date.	Support controlled and traceable corrections.

6.3 Document Analysis Process

Step 1: Identify relevant documents.
Request only the documents needed to understand the attendance process.

Step 2: Check the source and version.
Determine whether each document is current, approved, and relevant.

Step 3: Identify data fields.
Record identifiers, dates, statuses, calculations, and relationships.

Step 4: Identify business rules.
Extract documented rules and distinguish official policy from informal practice.

Step 5: Compare documents.
Look for inconsistent field names, duplicated information, and conflicting rules.

Step 6: Validate findings.
Ask the responsible stakeholders to confirm interpretations and resolve conflicts.

6.4 Example: Analyzing an Attendance Sheet

Suppose an existing attendance sheet contains the following fields:

Student ID	Student Name	Course Code	Class Date	Status
2026-001	Example Student A	CSE-301	2026-10-01	Present
2026-002	Example Student B	CSE-301	2026-10-01	Absent
2026-003	Example Student C	CSE-301	2026-10-01	Present

From this sample, the analyst can identify potential data entities such as Student, Course Offering, Class Session, and Attendance.

The analyst should also investigate whether the course code alone uniquely identifies a course offering. If courses repeat across terms or sections, the database may need a separate course-offering identifier.

6.5 Advantages of Document Analysis

• Provides evidence of existing data structures and reports.
• Helps identify mandatory fields and data relationships.
• Can reveal official policies and business rules.
• Allows analysis without interrupting normal work.
• Helps compare written procedures with actual practices.

6.6 Limitations of Document Analysis

• Documents may be outdated or incomplete.
• Written procedures may differ from actual practice.
• Some business rules may not be documented.
• Different departments may use inconsistent formats.
• Access to confidential records may be restricted.

7. Comparison of the Four Techniques

Criteria	Interview	Questionnaire	Observation	Document Analysis
Direct interaction	High	Low	Varies	Usually low
Suitable for large groups	Less suitable	Highly suitable	Less suitable	Depends on documents
Detailed explanations	High	Limited to questions	Behavior-focused	Depends on content
Shows actual behavior	Indirectly	Indirectly	Directly	Usually indirectly
Identifies data fields	Sometimes	Sometimes	Sometimes	Very useful
Common limitation	Time required	Low response rate	Observer effect	Outdated documents

8. Combining Fact-Finding Techniques

A reliable system analyst should not depend on a single technique. Combining techniques helps verify information from different sources. This process is commonly called triangulation.

8.1 Combined Example for SAMS

Interview: A teacher explains that attendance reporting takes too much time.

Questionnaire: A wider group of teachers is asked whether report preparation is a common problem.

Observation: The analyst measures the actual steps and time required to prepare a report.

Document Analysis: Existing reports are examined to identify the required columns, calculations, and filters.

After comparing these findings, the analyst may propose the requirement:

Proposed Requirement: The system shall generate an attendance report for an authorized course and date range, displaying student identifiers, attendance totals, and attendance percentages.

The requirement should then be reviewed with stakeholders and checked for completeness, clarity, and feasibility.

9. From Fact-Finding to System Requirements

Fact-finding is not complete when information has merely been collected. The analyst must organize the findings and convert them into clear, testable requirements.

Finding	Analysis	Proposed Requirement	Possible Test
Teachers maintain separate attendance sheets.	Records may be difficult to consolidate.	The system shall maintain attendance records in a centralized database.	Verify records can be retrieved through the application.
Attendance percentages are calculated manually.	Manual calculations may introduce errors.	The system shall calculate attendance percentages using the approved formula.	Compare system results against known test cases.
Historical reports take time to prepare.	Users need searchable historical data.	The system shall generate reports using approved filters.	Check results for a selected course and date range.
Attendance corrections are not consistently recorded.	Changes may be difficult to audit.	The system shall record authorized changes with user and timestamp information.	Review the audit history after a test correction.

10. Sample Fact-Finding Plan

The following plan is an example for a student project. Actual participants, dates, and findings should be recorded during the investigation.

Activity	Target / Source	Output
Prepare interview questions	Teachers and academic administrators	Interview guide
Conduct interviews	Selected stakeholders	Interview notes and findings
Distribute questionnaire	Selected student or teacher respondents	Response dataset and summary
Observe attendance workflow	Approved classroom or administrative process	Workflow notes and measured timings
Analyze documents	Attendance sheets, course lists, policies	Data fields and documented rules
Validate findings	Relevant stakeholders	Confirmed requirements and open issues

11. Common Mistakes to Avoid

• Assuming that one person's opinion represents every user.
• Asking leading or ambiguous interview questions.
• Using a questionnaire without testing its clarity.
• Observing a process without recording evidence.
• Assuming every old document reflects the current policy.
• Confusing stakeholder suggestions with approved requirements.
• Failing to protect confidential information during fact-finding.
• Writing requirements that cannot be verified through testing.
• Claiming that interviews or observations occurred when they did not.

12. Student Exercises

Exercise 1: Identify the Technique

Choose the most appropriate primary technique for each situation.

Question 1: A teacher explains why attendance reports take too long.

Answer: Interview. It allows the analyst to ask follow-up questions and understand the reasons behind the problem.

Question 2: The analyst wants feedback from 200 students.

Answer: Questionnaire. It can collect comparable information from a large group.

Question 3: The analyst watches a teacher record attendance.

Answer: Observation. It reveals the actual workflow and possible delays.

Question 4: The analyst reviews an official attendance policy.

Answer: Document analysis. It helps identify documented business rules and institutional requirements.

Exercise 2: Develop an Interview Guide

Prepare ten interview questions for an academic administrator. Your questions should cover student records, course sections, attendance corrections, report generation, and access permissions.

Exercise 3: Design a Questionnaire

Prepare a questionnaire containing at least:

• Three closed-ended questions.
• Two multiple-choice questions.
• One rating-scale question.
• Two open-ended questions.

Exercise 4: Prepare an Observation Checklist

Design a checklist for observing a teacher recording attendance for a class of 40–50 students. Include the sequence of activities, tools used, errors, and actual time taken.

Exercise 5: Analyze a Document

Create a sample attendance sheet and identify its fields, possible data entities, validation rules, and potential database relationships.

Exercise 6: Write Requirements

Using the findings from the previous exercises, write five functional requirements and three non-functional requirements for the Student Attendance Management System.

13. Review Questions

1. What is fact-finding in System Analysis and Design?
2. Why is fact-finding necessary before software development?
3. What is the difference between structured and unstructured interviews?
4. When is a questionnaire more suitable than an interview?
5. How can observation reveal problems that interviews may miss?
6. What information can be obtained from document analysis?
7. What is triangulation, and why is it useful?
8. How can the analyst validate information collected from stakeholders?
9. Why must proposed requirements be measurable and testable?
10. What privacy considerations apply during fact-finding?

14. Conclusion

Fact-finding is a fundamental activity in System Analysis and Design. Interviews provide detailed explanations, questionnaires collect structured feedback from many respondents, observation reveals actual work practices, and document analysis identifies existing data structures and formal rules.

For the Student Attendance Management System, using all four techniques can help the analyst understand the existing attendance process and develop requirements that are more accurate, complete, and useful.

The final goal is not simply to collect information, but to transform validated findings into clear requirements that can guide system design, implementation, and testing.

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

1. Maintain student, teacher, course, and section information.
2. Allow authorized teachers to record attendance.
3. Calculate attendance percentages automatically.
4. Generate student-wise, course-wise, section-wise, and date-range reports.
5. Restrict access according to user roles.
6. Reduce manual calculations and repetitive administrative work.
7. 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:

1. How is attendance currently recorded?
2. What information is required before recording attendance?
3. How are attendance percentages calculated?
4. What types of reports are needed?
5. Who should be allowed to modify attendance records?
6. 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:

1. The teacher opens the attendance module.
2. The teacher selects a course and section.
3. The teacher selects the class date or scheduled session.
4. The system displays the enrolled students.
5. The teacher marks each student according to the permitted attendance statuses.
6. The teacher submits the attendance record.
7. The system validates the data.
8. 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:

1. The teacher selects the course offering.
2. The system displays the available class sessions.
3. The teacher selects a session.
4. The system displays the enrolled students.
5. The teacher records the attendance statuses.
6. The teacher submits the attendance.
7. The system validates the submitted data.
8. The system saves the records.
9. 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:

1. The user opens the report module.
2. The user selects the permitted course, section, student, or date range.
3. The system validates the selected filters and access permissions.
4. The system retrieves the matching attendance records.
5. The system calculates the required attendance statistics.
6. The system displays the report.
7. 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:

1. Each requirement reflects an identified user or business need.
2. Requirements are clear, consistent, and feasible.
3. Functional requirements have identifiable expected results.
4. Non-functional requirements have measurable acceptance criteria where appropriate.
5. Business rules match approved institutional policies.
6. Privacy, security, and access restrictions are defined.
7. Requirements are prioritized and linked to test cases.
8. 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

1. Dennis, A., Wixom, B. H., and Tegarden, D. Systems Analysis and Design: An Object-Oriented Approach with UML. Wiley.
2. Satzinger, J. W., Jackson, R. B., and Burd, S. D. Systems Analysis and Design in a Changing World. Cengage Learning.
3. ISO/IEC/IEEE 29148. Systems and Software Engineering — Life Cycle Processes — Requirements Engineering. Consult the applicable edition for formal requirements documentation guidance.
4. Oracle. Oracle Database Documentation. https://docs.oracle.com/
5. 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.

Requirement Engineering: Functional and Non-Functional Requirements

Course: System Analysis and Design

Example Project: Student Attendance Management System (SAMS)

1. Learning Objectives

After completing this tutorial, students should be able to:

• Explain requirement engineering and its importance in software development.
• Identify stakeholders and gather system requirements.
• Differentiate functional requirements from non-functional requirements.
• Write clear, measurable, and testable requirements.
• Prepare a basic Software Requirements Specification (SRS).
• Apply requirement engineering concepts to a real-world project.

2. What Is Requirement Engineering?

Requirement Engineering (RE) is the systematic process of discovering, analyzing, documenting, validating, and managing the requirements of a software system.

Before developing a software application, developers need to understand what users expect from the system, what problems must be solved, and what constraints must be followed. If requirements are incomplete or misunderstood, the finished system may not satisfy its users.

Why Is Requirement Engineering Important?

• It helps developers understand the actual needs of users.
• It reduces misunderstandings between developers and stakeholders.
• It helps estimate project cost, time, and resources.
• It provides a foundation for system design and testing.
• It reduces expensive changes during later development stages.
• It provides a basis for determining whether the completed system meets expectations.

3. Example Project: Student Attendance Management System

3.1 Project Overview

The Student Attendance Management System (SAMS) is a web-based application designed to maintain student attendance records for different courses and sections.

In a manual process, teachers may record attendance on paper, calculate attendance percentages separately, and prepare reports manually. The proposed application will centralize these activities and automate routine calculations.

3.2 Project Users and Stakeholders

Stakeholder	Role	Primary Requirement
System Administrator	Manages accounts and access permissions.	Control user accounts and system configuration.
Academic Administrator	Maintains student, course, and section information.	Manage academic records accurately.
Teacher	Records attendance and views reports.	Record and review attendance efficiently.
Student	Reviews personal attendance information, if the feature is enabled.	View accurate personal attendance records.
Management	Reviews authorized summaries.	Access reliable attendance reports.

4. Requirement Engineering Process

A typical requirement engineering process includes the following activities:

1. Requirement Elicitation
Collect information from stakeholders.

↓

2. Requirement Analysis
Identify conflicts, gaps, priorities, and constraints.

↓

3. Requirement Specification
Document functional and non-functional requirements.

↓

4. Requirement Validation
Check whether requirements are correct and testable.

↓

5. Requirement Management
Track changes throughout the project.

4.1 Requirement Elicitation

Requirement elicitation means collecting information about what the system should do and the constraints under which it must operate.

Common techniques include:

• Interviews: Ask teachers and administrators about their current attendance process.
• Questionnaires: Collect feedback from a larger group of users.
• Observation: Observe how attendance is currently recorded and reported.
• Document analysis: Review existing attendance sheets and report formats.
• Prototyping: Show a sample screen and gather feedback before implementation.

Example interview question:
"What information do you need when recording attendance for a course?"

Possible answer: The teacher needs the course, section, class date, student list, and attendance status for each student.

Requirement derived: The system shall display the enrolled student list for the selected course and section when an authorized teacher records attendance.

4.2 Requirement Analysis

During analysis, the development team checks whether the collected requirements are complete, consistent, realistic, and within the project scope.

For example, if teachers want to edit attendance but management requires protection against unauthorized changes, the team can specify that only authorized teachers may edit their own course records and that changes must be logged.

4.3 Requirement Specification

Requirement specification means documenting requirements in a clear and organized form. The resulting document is commonly called a Software Requirements Specification (SRS).

An SRS may include:

• Purpose and scope of the system.
• Stakeholders and user roles.
• Functional requirements.
• Non-functional requirements.
• External interface requirements.
• Data requirements and constraints.
• Acceptance criteria.

4.4 Requirement Validation

Requirement validation checks whether the documented requirements represent the stakeholders' actual needs and can be implemented and tested.

Validation techniques include reviews, walkthroughs, prototypes, and acceptance-criteria checks.

4.5 Requirement Management

Requirements may change as stakeholders gain a better understanding of the system. Requirement management records these changes, their reasons, their impact, and their approval status.

For example, students may initially be able to view only their attendance percentage. Later, the institution may request a date-wise attendance history. This change should be reviewed for its effect on scope, cost, schedule, privacy, and testing.

5. Functional Requirements

5.1 Definition

Functional requirements describe the services, actions, and behaviors that a software system must provide. They explain what the system must do.

Examples include logging in, adding students, recording attendance, calculating percentages, and generating reports.

5.2 Functional Requirements for SAMS

ID	Functional Requirement	Primary User	Acceptance Criteria
FR-01	The system shall allow registered users to log in using valid credentials.	All registered users	A valid account can access the permitted functions.
FR-02	The system shall allow the administrator to create, update, and deactivate user accounts.	Administrator	Changes are saved and reflected in the account list.
FR-03	The system shall allow authorized users to add and update student information.	Academic Administrator	Valid student records can be saved and retrieved.
FR-04	The system shall maintain course, section, and teacher assignment records.	Academic Administrator	Each course offering has the required course, section, and teacher information.
FR-05	The system shall display the enrolled student list for a selected course and section.	Teacher	The displayed list matches the selected course and section enrolment.
FR-06	The system shall allow an authorized teacher to record attendance for a class date.	Teacher	Attendance statuses are saved against the correct students, course, section, and date.
FR-07	The system shall prevent duplicate attendance records for the same student, course offering, and class session.	System	A duplicate record is rejected or handled through an approved correction process.
FR-08	The system shall calculate attendance percentages from the recorded attendance data.	Teacher, Student (if enabled)	The percentage matches the approved calculation rule.
FR-09	The system shall generate attendance reports by student, course, section, and date range.	Teacher, Academic Administrator	The report contains records matching the selected filters.
FR-10	The system shall record significant attendance changes with the user, date, and time.	System Administrator, Authorized Auditor	An authorized reviewer can inspect the recorded change history.

5.3 Example of a Functional Requirement in Practice

Requirement ID: FR-06
Requirement: The system shall allow an authorized teacher to record attendance for a class date.

Preconditions:

• The teacher has logged in.
• The teacher is assigned to the selected course and section.
• The course offering and enrolled student list are available.

Main process:

1. The teacher selects a course and section.
2. The teacher selects the class date.
3. The system displays the enrolled student list.
4. The teacher marks each student as present or absent, with other statuses supported if approved by the institution.
5. The teacher submits the attendance record.
6. The system validates and saves the data.
7. The system displays a confirmation message.

Exception: If the attendance record already exists for the same session, the system must prevent an accidental duplicate and provide an approved correction option where permitted.

6. Non-Functional Requirements

6.1 Definition

Non-functional requirements describe the quality attributes, operating conditions, and constraints of a software system. They explain how well the system must operate or what conditions it must satisfy.

Common categories include performance, security, usability, reliability, availability, maintainability, compatibility, and legal or organizational constraints.

6.2 Non-Functional Requirements for SAMS

ID	Category	Requirement	Verification Method
NFR-01	Performance	Under the agreed test 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 pages and operations shall require authentication and role-based authorization.	Security and access-control testing
NFR-03	Usability	A trained teacher shall be able to record attendance for a class of up to 50 students within 3 minutes under normal operating conditions.	Observed usability test
NFR-04	Reliability	The system shall validate attendance data before saving and shall not silently discard a submitted record when a save operation fails.	Failure and validation testing
NFR-05	Availability	For a production deployment, the 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 testing and maintenance.	Code and architecture review
NFR-07	Compatibility	The web 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-log and restoration checks
NFR-09	Privacy	Users shall only be able to access student information necessary for their authorized duties.	Permission and privacy review
NFR-10	Auditability	Significant changes to attendance records shall be attributable to an authenticated user and include a timestamp.	Audit-log inspection

Note: The numeric targets above are example acceptance targets for teaching purposes. They should be confirmed or adjusted after estimating the actual workload, infrastructure, security needs, and institutional service expectations.

6.3 Examples of Different Non-Functional Requirements

Performance: "The system shall display a class attendance report within 3 seconds for a section containing up to 100 students under the agreed test conditions."

Security: "A teacher shall not be able to modify attendance records for a course to which the teacher is not assigned."

Usability: "A trained teacher shall be able to locate the attendance-recording screen within two navigation steps from the dashboard."

Reliability: "If the database connection fails during submission, the system shall display an error and shall not show a success confirmation unless the record has been saved."

Maintainability: "Attendance calculation logic shall be implemented in a clearly defined module and covered by automated or documented tests."

7. Functional vs. Non-Functional Requirements

Comparison Point	Functional Requirements	Non-Functional Requirements
Main question	What should the system do?	How well must it work, or what constraints must it satisfy?
Focus	System services and behavior	Quality attributes and operating constraints
Example	The system shall generate an attendance report.	The report shall load within 3 seconds under defined test conditions.
Testing	Check whether the required operation works.	Measure quality, constraints, or behavior under specified conditions.
Typical categories	Login, attendance recording, record management, reporting	Performance, security, usability, reliability, maintainability

Important: A single feature can involve both kinds of requirements. For example, generating an attendance report is a functional requirement. The report's response time, access restrictions, and reliability are non-functional requirements.

8. How to Write Good Requirements

A good requirement should be clear, necessary, feasible, consistent, verifiable, and traceable to a stakeholder need.

8.1 Avoid Vague Requirements

Vague Requirement	Improved Requirement	Reason
The system should be fast.	95% of ordinary page requests shall complete within 3 seconds under the agreed test workload.	Defines a measurable performance target.
The system should be secure.	Protected operations shall require authentication and role-based authorization.	Identifies specific security controls.
The system should generate reports.	The system shall generate attendance reports filtered by student, course, section, and date range.	Defines the expected report functionality.
The system should be easy to use.	A trained teacher shall be able to record attendance for up to 50 students within 3 minutes under normal conditions.	Provides a testable usability target.

8.2 Use Unique Requirement IDs

Each requirement should have a unique identifier so that it can be tracked during design, development, testing, and maintenance.

• FR-01: Functional Requirement 1.
• FR-02: Functional Requirement 2.
• NFR-01: Non-Functional Requirement 1.
• NFR-02: Non-Functional Requirement 2.

9. Sample Requirement Traceability Matrix

A Requirement Traceability Matrix (RTM) links requirements to their sources and tests. It helps confirm that important requirements have been implemented and verified.

Requirement ID	Requirement	Source	Related Test	Status
FR-06	Teacher records attendance.	Teacher interview	TC-06: Save attendance	Planned
FR-08	System calculates attendance percentage.	Academic policy	TC-08: Verify calculation	Planned
NFR-01	Meet the agreed response-time target.	Project performance target	TC-N01: Load test	Planned
NFR-02	Enforce authentication and authorization.	Security requirement	TC-N02: Access-control test	Planned

10. Sample SRS Structure for the Project

The following outline can be used when preparing a basic Software Requirements Specification for SAMS.

1. Introduction: Purpose, scope, definitions, and references.
2. Overall Description: Product perspective, user classes, assumptions, and constraints.
3. Functional Requirements: Login, user management, attendance, calculation, and reporting.
4. Non-Functional Requirements: Performance, security, usability, reliability, and maintainability.
5. External Interface Requirements: User interface, database interface, and network requirements.
6. Data Requirements: Student, teacher, course, section, attendance, and audit records.
7. Acceptance Criteria: Conditions that must be satisfied for the system to be accepted.
8. Traceability Matrix: Links between requirements and their verification tests.

11. Student Exercise

Task: Prepare a requirement specification for the Student Attendance Management System.

Each student must complete the following activities:

1. Identify at least four stakeholders.
2. Write at least eight functional requirements.
3. Write at least six non-functional requirements.
4. Assign a unique ID to every requirement.
5. Write acceptance criteria for at least five requirements.
6. Prepare a small traceability matrix linking requirements to tests.
7. Identify any assumptions or constraints that need confirmation.

Requirement Writing Template

Field	Student's Answer
Requirement ID	FR-01 or NFR-01
Requirement Name	Name of the requirement
Requirement Description	The system shall...
Requirement Type	Functional or Non-Functional
Stakeholder / Source	Teacher, student, administrator, or policy document
Priority	High, Medium, or Low
Acceptance Criteria	How the requirement will be verified

12. Knowledge Check

Question 1: What is requirement engineering?

Requirement engineering is the systematic process of eliciting, analyzing, documenting, validating, and managing software requirements.

Question 2: Is login a functional or non-functional requirement?

Login is a functional requirement because it describes a service the system must provide. Authentication security rules are non-functional or security constraints associated with that feature.

Question 3: "The system shall generate attendance reports." What type of requirement is this?

It is a functional requirement because it describes an operation the system must perform.

Question 4: "The attendance report shall load within 3 seconds under agreed test conditions." What type of requirement is this?

It is a non-functional performance requirement because it specifies a measurable quality target.

Question 5: Why should requirements have unique IDs?

Unique IDs make requirements easier to trace across design, implementation, testing, change management, and maintenance.

Question 6: What is the purpose of a Requirement Traceability Matrix?

It connects each requirement to its source, implementation activities, and verification tests so that coverage can be monitored.

13. Conclusion

Requirement engineering is a fundamental activity in software development because it establishes what the system must do and the quality standards it must satisfy. Functional requirements describe system services and behavior, while non-functional requirements define quality attributes and operating constraints.

In the Student Attendance Management System, recording attendance and generating reports are functional requirements. Response time, security, usability, reliability, and backup expectations are examples of non-functional requirements.

Clear, measurable, validated, and traceable requirements provide a reliable foundation for system design, implementation, testing, and maintenance.