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.

FEASIBILITY REPORT AND BASIC COST-BENEFIT ANALYSIS

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. Executive Summary

The Student Attendance Management System (SAMS) is a proposed web-based application designed to automate student attendance recording, storage, calculation, and reporting. In a traditional attendance system, teachers may record attendance manually, calculate attendance percentages using spreadsheets, and prepare reports separately. These activities can consume time and introduce errors.

The proposed system will allow authorized teachers to record attendance for their assigned courses and sections. Academic administrators will be able to manage student, course, and section information, while the system will automatically calculate attendance percentages and generate reports.

This report evaluates the technical, economic, operational, schedule, and legal feasibility of the proposed system. A basic cost-benefit analysis is also conducted using illustrative financial estimates.

The preliminary assessment indicates that the project is potentially feasible as a small academic prototype, provided that the necessary technical resources, institutional approval, data protection measures, and user training are available.

2. Introduction

2.1 Background

Attendance management is an important administrative activity in educational institutions. Accurate attendance records help teachers monitor student participation and support academic decision-making.

Manual attendance management can create several problems:

• Time-consuming attendance calculations.
• Difficulty maintaining organized historical records.
• Errors in attendance percentages and reports.
• Delays in identifying students with low attendance.
• Difficulty retrieving attendance information for a particular course or date.

A computerized attendance management system can reduce these difficulties by maintaining centralized records and automating routine calculations.

2.2 Problem Statement

The existing manual or spreadsheet-based attendance process may require teachers and academic staff to perform repetitive data-entry, calculation, and reporting tasks. Records may be scattered across paper documents or separate files, making verification and retrieval difficult.

Therefore, a centralized Student Attendance Management System is proposed to improve efficiency, consistency, and accessibility.

2.3 Project Objectives

The main objectives are to:

1. Develop a web-based attendance management application.
2. Maintain student, course, section, and teacher information.
3. Allow authorized teachers to record daily attendance.
4. Automatically calculate attendance percentages.
5. Generate student-wise, course-wise, section-wise, and date-range reports.
6. Reduce repetitive administrative work.
7. Improve the accuracy, security, and availability of attendance records.

3. Project Scope

3.1 Included Features

• User login and role-based access.
• Student information management.
• Course and section management.
• Teacher and course assignment.
• Attendance recording and correction by authorized users.
• Attendance percentage calculation.
• Attendance reports and low-attendance identification.
• Database backup and basic recovery procedures.

3.2 Excluded Features

• Biometric or facial-recognition attendance.
• GPS-based attendance verification.
• Automatic integration with external university ERP systems.
• Online fee payment.
• Advanced predictive analytics.
• Mobile applications for Android or iOS.

These features may be considered in future versions if required and approved.

4. Feasibility Study

A feasibility study determines whether the proposed system can be developed and operated successfully within the available resources, budget, time, and institutional constraints.

4.1 Technical Feasibility

Technical feasibility evaluates whether the required hardware, software, technical skills, and infrastructure are available.

Proposed technology stack:

Component	Proposed Technology
Frontend	HTML, CSS, JavaScript
Web application	JavaServer Pages (JSP) and Java
Database connectivity	JDBC
Database management system	Oracle Database
Application server	Apache Tomcat or a compatible server
Hardware	Existing computers and a suitable server
Network	Local network or internet connection

The project can be developed using commonly available development tools. However, the team must have sufficient knowledge of Java, JSP, JDBC, SQL, database design, and web application security.

The technical implementation should include authentication, input validation, authorization, database constraints, secure database credentials, backups, and protection against unauthorized modification of attendance records.

Assessment: Potentially technically feasible, subject to confirming the availability of the required software, infrastructure, and development skills.

4.2 Economic Feasibility

Economic feasibility evaluates whether the expected benefits justify the development and operating costs. For this report, the financial estimates are hypothetical and are used only to demonstrate the analysis.

4.2.1 Estimated Initial Cost

Cost Item	Estimated Cost (BDT)
Development effort	30,000
Setup and configuration	5,000
Training and documentation	5,000
Total Initial Cost	40,000

These figures represent an illustrative budget for a limited project. Actual costs may vary depending on development effort, existing infrastructure, staff rates, and licensing requirements.

4.2.2 Estimated Annual Operating Cost

Cost Item	Annual Cost (BDT)
Hosting or server maintenance	6,000
Backup and storage	2,000
Technical support and maintenance	4,000
Total Annual Operating Cost	12,000

The estimates assume that the institution already has access to suitable computers and that any required database licensing or institutional infrastructure costs have been assessed separately.

4.2.3 Estimated Annual Benefits

The principal measurable benefit in this example is the value of administrative time saved.

Assume that the system saves a combined total of 10 staff-hours per month through reduced manual calculation, report preparation, and record retrieval.

Benefit Calculation	Amount
Estimated time saved per month	10 hours
Illustrative value per staff-hour	BDT 300
Estimated monthly benefit	BDT 3,000
Estimated Annual Benefit	BDT 36,000

Calculation:
Annual Benefit = Hours Saved per Month × Value per Hour × 12
= 10 × BDT 300 × 12
= BDT 36,000

This is an estimated economic value of time saved, not necessarily a direct cash saving. The actual benefit should be validated by observing the existing attendance process.

4.2.4 Annual Net Benefit

Annual Net Benefit = Annual Benefit − Annual Operating Cost

= BDT 36,000 − BDT 12,000

= BDT 24,000

Therefore, the estimated annual net benefit is BDT 24,000 under the stated assumptions.

4.3 Operational Feasibility

Operational feasibility determines whether the proposed system can function effectively within the institution's daily activities.

The intended users include:

• System Administrator: Manages accounts, roles, and system settings.
• Academic Administrator: Maintains student, course, section, and teacher information.
• Teacher: Records attendance and generates course reports.
• Management: Reviews authorized attendance summaries and reports.
• Technical Support Staff: Maintains the application, database, and backups.

The system should provide a simple interface so that teachers can record attendance without unnecessary steps. Training should be provided before deployment.

Operational risks include incorrect data entry, resistance to a new process, forgotten passwords, and unauthorized changes. These risks can be reduced through training, role-based permissions, validation, audit logs, and clear correction procedures.

Assessment: Potentially operationally feasible if users receive appropriate training and the institution establishes clear responsibilities for data entry, verification, and maintenance.

4.4 Schedule Feasibility

Schedule feasibility evaluates whether the project can be completed within the available time. The proposed project duration is 12 weeks.

Week	Activities
1–2	Requirements gathering and feasibility study
3–4	System design, database design, and login module
5–6	Student, course, section, and teacher management
7–8	Attendance recording and validation
9–10	Attendance calculation and report generation
11	Integration, security checks, and testing
12	Documentation, demonstration, and final presentation

The schedule is suitable as an initial plan for a limited academic prototype. The actual duration will depend on the developer's experience, project complexity, testing requirements, and access to users for feedback.

Assessment: Potentially schedule-feasible if the scope remains limited and development and testing activities are completed according to plan.

4.5 Legal and Regulatory Feasibility

Legal feasibility considers whether the system can be developed and operated consistently with applicable laws, institutional rules, software licences, and data protection requirements.

1. Student privacy: Collect and process only the student information necessary for attendance management.
2. Access control: Restrict personal information and attendance records to authorized users.
3. Data integrity: Maintain reliable records and record significant changes to attendance information.
4. Data retention: Follow the institution's approved retention and deletion policies.
5. Software licensing: Verify that the application server, database, development tools, and other software are used under appropriate licences.
6. Institutional authorization: Obtain permission before using actual student data or connecting the system to institutional infrastructure.
7. Applicable laws: Review current Bangladeshi legal requirements and relevant institutional policies before production deployment.

For development and classroom demonstration, sample or anonymized student data should be used wherever possible.

Assessment: Potentially legally feasible, subject to institutional approval, appropriate software licensing, and verification of applicable legal and privacy requirements.

5. Basic Cost-Benefit Analysis

This section summarizes the estimated costs and benefits of the proposed system.

5.1 Financial Summary

Item	Amount (BDT)
Initial development and setup cost	40,000
Annual operating cost	12,000
Estimated annual benefit	36,000
Estimated Annual Net Benefit	24,000

5.2 Payback Period

The payback period estimates how long it takes for cumulative net benefits to recover the initial investment.

Payback Period = Initial Cost ÷ Annual Net Benefit

= BDT 40,000 ÷ BDT 24,000

= 1.67 years, approximately 20 months

This simple calculation assumes that the annual net benefit remains constant and that benefits and costs occur evenly. It does not account for discounting, taxes, unexpected expenses, or changes in usage.

5.3 Three-Year Cost-Benefit Projection

Assuming the initial cost is incurred in Year 0 and annual benefits and operating costs remain constant:

Period	Benefits (BDT)	Costs (BDT)	Net Benefit (BDT)
Year 0: Initial investment	0	40,000	-40,000
Year 1	36,000	12,000	24,000
Year 2	36,000	12,000	24,000
Year 3	36,000	12,000	24,000
Three-Year Operating Total	108,000	36,000	72,000

Three-Year Cumulative Net Benefit After Initial Investment

= BDT 72,000 − BDT 40,000

= BDT 32,000

5.4 Return on Investment (ROI)

The simple return on investment compares the cumulative net benefit after the initial investment with the initial investment.

ROI = (Cumulative Net Benefit After Initial Investment ÷ Initial Investment) × 100

= (BDT 32,000 ÷ BDT 40,000) × 100

= 80%

This ROI is an illustrative, undiscounted estimate based on the stated assumptions. It should not be interpreted as a guaranteed financial return.

5.5 Non-Financial Benefits

In addition to the estimated time savings, SAMS may provide the following benefits:

• More consistent attendance calculations.
• Faster access to historical records.
• Better monitoring of students with low attendance.
• Reduced dependence on paper records and separate spreadsheets.
• Improved accountability through controlled access and change tracking.
• Better support for academic reporting and decision-making.

These benefits are important but are not assigned separate monetary values in the calculations above, to avoid double-counting.

6. Risk Assessment and Mitigation

Risk	Possible Impact	Mitigation
Incorrect attendance entry	Inaccurate records	Input validation and authorized correction
Unauthorized access	Exposure or alteration of data	Role-based access and secure authentication
Database failure	Loss of records	Scheduled backups and recovery testing
User resistance	Low adoption	Training and user feedback
Project delay	Late completion	Limited scope and milestone monitoring
Unexpected expenses	Higher project cost	Confirm quotations and maintain a contingency budget
Incorrect benefit estimates	Misleading economic conclusion	Measure existing workload and validate assumptions

7. Overall Feasibility Assessment

Feasibility Area	Preliminary Assessment	Main Condition
Technical	Potentially feasible	Required skills and infrastructure must be available.
Economic	Potentially feasible	Estimated time savings must justify actual costs.
Operational	Potentially feasible	Users must be trained and responsibilities defined.
Schedule	Potentially feasible	The project must maintain its limited scope.
Legal	Conditional	Applicable laws, licences, and institutional rules must be verified.

The project should proceed to detailed planning and prototype development only after the assumptions, resources, costs, and institutional requirements have been reviewed.

8. Recommendation

Based on the preliminary feasibility assessment and illustrative cost-benefit analysis, the Student Attendance Management System is a reasonable candidate for development as a small academic project.

The estimated initial investment is BDT 40,000, while the illustrative annual net benefit is BDT 24,000. Under these assumptions, the simple payback period is approximately 20 months, and the estimated three-year cumulative net benefit after the initial investment is BDT 32,000.

However, the project should not be approved solely on the basis of these illustrative calculations. Before production deployment, the institution should validate the expected time savings, obtain actual cost estimates, confirm technical resources, test user acceptance, and review data protection and licensing requirements.

Final Recommendation: Proceed with a limited prototype, validate its usability and benefits through a pilot, and make a production deployment decision after reviewing the pilot results and actual costs.

9. Conclusion

The feasibility study indicates that a web-based Student Attendance Management System may improve attendance recording, calculation, and reporting in an educational institution. The proposed technologies are suitable for a small academic implementation, while the project scope and schedule can be managed through careful planning.

The basic cost-benefit analysis suggests a potentially positive economic outcome under the assumptions used. Nevertheless, the actual feasibility of the project depends on real development costs, operating expenses, measurable time savings, user acceptance, and compliance with institutional and legal requirements.

A pilot implementation is therefore recommended before the system is adopted for regular institutional use.

10. 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. Oracle. Oracle Database Documentation. https://docs.oracle.com/
4. Apache Software Foundation. Apache Tomcat Documentation. https://tomcat.apache.org/

Important Note: The financial figures in this report are illustrative academic assumptions, not verified market quotations. Update the figures and references as required by your institution before submission.

Feasibility Study in System Analysis and Design

Learning objectives

After completing this tutorial, students should be able to:

• Explain the purpose of a feasibility study.
• Distinguish technical, economic, operational, schedule, and legal feasibility.
• Evaluate a proposed software project using practical criteria.
• Prepare a basic feasibility study report.
• Recommend whether a project should proceed, be revised, or be rejected.

1. What Is a Feasibility Study?

A feasibility study is a systematic evaluation of a proposed project to determine whether it can reasonably be implemented and whether proceeding with it is justified.

Before an organization invests significant time, money, and resources in software development, it should examine the project's technical requirements, costs and benefits, operational needs, time constraints, and legal obligations.

A feasibility study does not guarantee that a project will succeed. Instead, it identifies major constraints, uncertainties, costs, and risks before the organization commits to full development.

Why Is a Feasibility Study Important?

• Prevents investment in technically impractical projects.
• Helps estimate development and operating costs.
• Determines whether users and the organization can adopt the system.
• Checks whether the project can meet its deadline.
• Identifies legal, licensing, privacy, and security obligations.
• Supports evidence-based management decisions.

2. Five Types of Feasibility

Type	Main Question	Focus
Technical feasibility	Can we build and operate it?	Technology, infrastructure, skills, integration, and security.
Economic feasibility	Is it financially worthwhile?	Development costs, operating costs, savings, and benefits.
Operational feasibility	Will it work in the organization?	Users, workflows, training, acceptance, and support.
Schedule feasibility	Can it be completed on time?	Tasks, resources, dependencies, deadlines, and testing time.
Legal feasibility	Can it operate lawfully?	Applicable laws, privacy, licenses, contracts, and institutional rules.

3. Sample Project: Student Attendance Management System

Project overview

Project name: Student Attendance Management System (SAMS)

Purpose: Develop a web-based application for recording, storing, calculating, and reporting student attendance.

Target users: Teachers, authorized administrators, students with permitted access, and academic management.

Proposed technology: JSP, Java, JDBC, and Oracle Database.

Initial scope: Login, student and course management, attendance recording, and attendance reports.

The following sections evaluate whether this proposed system is feasible. The findings are illustrative assumptions for a student project, not verified facts about any particular university.

4. Technical Feasibility

4.1 Definition

Technical feasibility determines whether the required technology, infrastructure, expertise, and technical resources are available to develop, deploy, secure, and maintain a proposed system.

4.2 Questions to Investigate

• Does the development team have the necessary programming skills?
• Are the required software and database platforms available?
• Can the system run on the available computers and servers?
• Can the application handle the expected number of users and records?
• Can the system protect attendance data from unauthorized access?
• Can the proposed system integrate with existing university services if required?

4.3 Technical Feasibility of SAMS

Requirement	Proposed Solution	Assessment
Web interface	HTML, CSS, JavaScript, and JSP.	Feasible if the developer has the necessary skills.
Application logic	Java running in a compatible application server.	Feasible with a supported Java and server configuration.
Database	Oracle Database accessed through JDBC.	Feasible if a suitable database environment is available.
Data security	Authentication, role-based permissions, secure connections, and validation.	Requires appropriate design and testing.
Backup and recovery	Scheduled database backups and tested recovery procedures.	Feasible if backup storage and administrative support are provided.
Performance	Indexes, appropriate queries, and realistic load testing.	Must be verified against expected workload.

4.4 Technical Feasibility Conclusion

SAMS appears technically feasible as a small academic web application, provided that the student can use the required technologies and has access to a compatible development environment. Production deployment would require additional verification of server capacity, security, backup, and recovery arrangements.

5. Economic Feasibility

5.1 Definition

Economic feasibility determines whether the expected benefits of a project justify its development, implementation, operation, and maintenance costs.

It considers both direct financial costs and measurable benefits such as reduced administrative effort, fewer calculation errors, and faster report preparation.

5.2 Common Project Costs

• Developer and analyst time.
• Hardware and hosting.
• Software licenses and support fees, if applicable.
• Training and user documentation.
• Data migration and deployment.
• Backup, maintenance, and technical support.

5.3 Example Cost Estimate

The following figures are hypothetical estimates in Bangladeshi taka (BDT) for illustrating the calculation. They are not vendor quotations or verified market prices.

Cost Item	Estimated Cost (BDT)	Type
Development effort	30,000	One-time
Setup and deployment	5,000	One-time
Initial training and documentation	5,000	One-time
Total initial cost	40,000	One-time
Hosting, backup, and support	12,000 per year	Recurring

5.4 Example Benefit Estimate

Suppose the university estimates that automation will save approximately 10 staff-hours per month. If the estimated value of administrative time is BDT 300 per hour, the annual time-saving benefit would be:

Annual Benefit = Hours Saved per Month × Value per Hour × 12

= 10 × BDT 300 × 12

= BDT 36,000 per year

For this example, assume the annual operating cost is BDT 12,000.

Annual Net Benefit = Annual Benefit − Annual Operating Cost

= BDT 36,000 − BDT 12,000

= BDT 24,000 per year

Ignoring discounting, taxes, and any unlisted costs, a simple payback estimate is:

Payback Period = Initial Cost ÷ Annual Net Benefit

= BDT 40,000 ÷ BDT 24,000

≈ 1.67 years

This calculation is illustrative. Time saved is not necessarily a cash saving. The university should validate the estimated hours, labor value, implementation cost, and recurring costs before making an investment decision.

5.5 Economic Feasibility Conclusion

Under the illustrative assumptions, the system may be economically worthwhile if the estimated time savings are realized and the project remains within budget. A real feasibility study should compare total costs and benefits over an agreed period, such as three to five years.

6. Operational Feasibility

6.1 Definition

Operational feasibility evaluates whether the proposed system will work effectively within the organization's actual procedures and whether the intended users can and will use it.

6.2 Questions to Investigate

• Will teachers find the attendance process easy to use?
• Will administrators accept the proposed workflow?
• Can existing student and course records be made available?
• Will users receive sufficient training?
• Who will handle incorrect records and access requests?
• Is technical support available when problems occur?

6.3 Operational Feasibility of SAMS

Operational Issue	Potential Problem	Proposed Action
User acceptance	Teachers may prefer existing paper records.	Demonstrate the system and collect user feedback.
Training	Some users may be unfamiliar with the interface.	Provide a short user guide and practical training.
Data accuracy	Incorrect attendance may be entered.	Provide validation and an authorized correction process.
Responsibility	Users may be uncertain who can correct records.	Define permissions and approval rules.
Technical support	System outages may interrupt attendance entry.	Establish backup, recovery, and temporary recording procedures.

6.4 Operational Feasibility Conclusion

SAMS appears operationally feasible if teachers and administrators accept the workflow, records can be maintained accurately, and training and support are available. A pilot test with representative users should be conducted before institution-wide adoption.

7. Schedule Feasibility

7.1 Definition

Schedule feasibility determines whether the project can be completed within the required deadline using the available people, resources, and working time.

7.2 Factors to Consider

• Project size and complexity.
• Developer experience and availability.
• Dependencies between database, interface, and reporting modules.
• Availability of sample data and user feedback.
• Time needed for integration, testing, and corrections.
• Academic deadlines and presentation dates.

7.3 Example: Twelve-Week Project Schedule

Weeks	Activities	Milestone
1–2	Requirements collection and feasibility confirmation.	Approved project scope.
3–4	System design, database design, and login development.	Initial working application.
5–6	Student, course, and section management.	Core record-management modules.
7–8	Attendance recording and validation.	Attendance module completed.
9–10	Attendance calculations and reports.	Reporting module completed.
11	Integration, system testing, and defect correction.	Tested release candidate.
12	Final corrections, documentation, and presentation.	Project submission.

7.4 Schedule Feasibility Conclusion

A twelve-week schedule may be realistic for a limited academic prototype developed by a student with the required skills. It may not be sufficient for a production-ready university-wide deployment involving data migration, security audits, extensive training, and integration with existing systems.

A schedule should include time for testing and corrections. If the development tasks already consume the entire deadline, the project plan is not realistically feasible without reducing scope or adding resources.

8. Legal Feasibility

8.1 Definition

Legal feasibility determines whether a proposed system can be developed and operated in accordance with applicable laws, regulations, licenses, contracts, and institutional policies.

8.2 Legal Questions for SAMS

• Is student information collected and processed under an appropriate legal basis?
• Who is authorized to view, modify, and disclose attendance records?
• Are applicable privacy and data-protection requirements being followed?
• Are software, database, and third-party components used under valid licenses?
• Are retention, backup, and deletion practices consistent with applicable requirements?
• Are records protected from unauthorized access or disclosure?
• Do university policies specify how attendance corrections and disputes must be handled?

8.3 Legal Feasibility of SAMS

Legal or Policy Area	Possible Risk	Proposed Control
Student privacy	Personal attendance data is disclosed without authorization.	Restrict access and establish approved data-handling procedures.
Software licensing	A component is used without appropriate permission.	Verify licenses and comply with their terms.
Record integrity	Attendance records are changed without authorization.	Apply access controls and retain suitable audit records.
Data retention	Records are retained or deleted contrary to requirements.	Define retention and deletion procedures with the institution.
Institutional policy	Attendance rules or correction procedures conflict with approved policy.	Obtain approval for system rules and workflows.

8.4 Legal Feasibility Conclusion

SAMS may be legally feasible if the institution authorizes its use, student data is handled lawfully, software licenses are respected, and appropriate access and record-management controls are implemented.

For deployment in Bangladesh, the project team should verify the applicable requirements in force at the time of implementation, including relevant data-protection, cybersecurity, contractual, and institutional obligations. This tutorial is an educational guide, not a legal opinion.

9. Combined Feasibility Assessment

The five feasibility dimensions should be evaluated together. A system that is technically possible may still be unaffordable, unacceptable to users, late, or legally noncompliant.

Feasibility Type	Illustrative Finding	Condition or Next Step
Technical	Potentially feasible	Confirm skills, infrastructure, security, and database access.
Economic	Potentially feasible	Validate costs and time-saving assumptions.
Operational	Potentially feasible	Obtain user feedback and test the workflow.
Schedule	Potentially feasible for a prototype	Confirm scope and reserve testing time.
Legal	Feasibility not yet confirmed	Review applicable laws, licenses, privacy requirements, and institutional approval.

Preliminary Recommendation

Proceed to detailed planning and a limited prototype, subject to validation of the cost estimates, user requirements, infrastructure, and applicable legal obligations.

This is a preliminary recommendation based on illustrative assumptions. A final go/no-go decision should be made only after the relevant evidence has been collected and reviewed.

10. Sample Feasibility Study Report

The following sample can be adapted for an academic project proposal.

Project: Student Attendance Management System

Technical feasibility: The proposed system will use JSP, Java, JDBC, and Oracle Database. These technologies can support a web-based attendance application if suitable technical skills, software, and infrastructure are available.

Economic feasibility: The project may reduce time spent on manual attendance calculations and report preparation. The estimated development and operating costs must be compared with the value of the expected benefits.

Operational feasibility: Teachers and administrators should be able to use the system after appropriate training. A pilot demonstration and user evaluation will be conducted to identify workflow and usability problems.

Schedule feasibility: A twelve-week schedule is proposed for requirements analysis, design, development, testing, documentation, and presentation. The scope will be limited to core attendance functions to protect the deadline.

Legal feasibility: The system must follow applicable privacy, data-protection, licensing, security, and institutional requirements. The relevant requirements must be verified before real student data is used or the application is deployed.

Overall recommendation: The project appears suitable for further planning as an academic prototype, subject to confirmation of the assumptions and completion of the required checks.

11. Student Exercise

Select a real-world software project, such as a Library Management System, Hospital Appointment System, Online Shopping System, or University Examination Management System.

Prepare a feasibility study covering the following items:

1. Project name and objectives.
2. Technical requirements and available resources.
3. Estimated development and operating costs.
4. Expected benefits and how they will be measured.
5. User acceptance, training, and operational support.
6. Development schedule and major milestones.
7. Relevant legal, licensing, privacy, and institutional requirements.
8. Final recommendation: proceed, revise, or reject.

12. Knowledge Check

Question 1: Which feasibility type evaluates whether the necessary technology and skills are available?

1. Economic feasibility
2. Technical feasibility
3. Legal feasibility
4. Schedule feasibility

Show answer

Answer: b) Technical feasibility.

Question 2: Which feasibility type examines whether expected benefits justify project costs?

1. Operational feasibility
2. Schedule feasibility
3. Economic feasibility
4. Technical feasibility

Show answer

Answer: c) Economic feasibility.

Question 3: A project can be developed but cannot meet its required deadline with the available team. Which area is the main concern?

1. Schedule feasibility
2. Legal feasibility
3. Technical feasibility only
4. Data modeling

Show answer

Answer: a) Schedule feasibility.

Question 4: Which feasibility type examines whether users can adopt the proposed workflow?

1. Legal feasibility
2. Operational feasibility
3. Economic feasibility
4. Schedule feasibility

Show answer

Answer: b) Operational feasibility.

Question 5: A software component requires a license that does not permit the intended use. Which feasibility concern must be addressed?

1. Technical feasibility only
2. Operational feasibility only
3. Legal feasibility
4. Schedule feasibility only

Show answer

Answer: c) Legal feasibility.

13. Conclusion

A feasibility study helps an organization make an informed decision before committing substantial resources to a software project.

• Technical feasibility: Can the system be built and supported?
• Economic feasibility: Are the costs justified by the expected benefits?
• Operational feasibility: Will the system work for its users and organization?
• Schedule feasibility: Can the system be delivered within the required time?
• Legal feasibility: Can the system be developed and operated in compliance with applicable requirements?

For the Student Attendance Management System, a preliminary assessment suggests that a limited academic prototype may be feasible. However, actual implementation decisions should be based on verified requirements, realistic estimates, user feedback, and appropriate legal and security reviews.

---

Course: System Analysis and Design

End of Tutorial

Identifying a Real-World System: Components, Users, and Boundaries

Learning objectives

After studying this tutorial, students should be able to:

• Identify a real-world system and explain its purpose.
• Identify the components and resources of a system.
• Distinguish between system users and other stakeholders.
• Define a system's boundaries and external environment.
• Identify system inputs, processes, outputs, and feedback.
• Apply these concepts to a software project proposal.

1. What Is a System?

A system is a collection of interconnected components that work together to achieve a common objective. A system receives inputs, processes information or materials, produces outputs, and may use feedback to improve its operation.

A system can be physical, organizational, biological, or computerized.

Examples include:

• A university examination system.
• A hospital patient management system.
• A banking transaction system.
• An online shopping system.
• A student attendance management system.

Example: A University Attendance System

A university needs to record whether students attend scheduled classes. Teachers collect attendance information, the university maintains student and course records, and authorized users review attendance reports.

A Student Attendance Management System organizes these activities in one software application.

2. Identify the Real-World System

The first task in system analysis is to select a real-world activity or problem that needs to be understood or improved.

Sample Project: Student Attendance Management System (SAMS)

System type: Web-based information system.

Primary purpose: To record, store, retrieve, and report student attendance for university courses and class sessions.

Problem being addressed: Manual attendance procedures can require considerable time for record keeping, percentage calculations, and report preparation. Paper records can also be difficult to retrieve or verify.

Proposed solution: Develop a centralized application that allows authorized teachers to record attendance and generate attendance reports.

2.1 Define the System's Objectives

The proposed system should:

1. Maintain student, teacher, course, and section information.
2. Allow authorized teachers to record attendance for class sessions.
3. Store attendance records in a database.
4. Calculate attendance summaries and percentages.
5. Allow authorized users to retrieve reports.
6. Protect attendance information from unauthorized access.

3. Identify the System Components

System components are the parts that work together to achieve the system's objectives. For a computerized information system, these commonly include hardware, software, data, procedures, people, and communication networks.

Component	Meaning	Example in SAMS
Hardware	Physical equipment used to operate the system.	Teacher's computer, server, and network equipment.
Software	Programs that implement system functions.	JSP pages, Java application logic, and database software.
Data	Information collected, stored, and processed.	Student IDs, course IDs, class dates, and attendance statuses.
People	Individuals who operate, manage, or use the system.	Teachers, authorized administrators, and students who view permitted information.
Procedures	Rules that define how activities are performed.	Attendance entry, correction approval, and report-generation procedures.
Network	Communication infrastructure connecting system users and services.	Campus LAN or internet connection used to access the application.

3.1 Functional Components of SAMS

The software can also be divided into functional modules.

Module	Responsibility
Authentication	Verifies users and applies access permissions.
Student Management	Maintains student profiles and identifiers.
Course Management	Maintains course offerings, sections, and teacher assignments.
Attendance Management	Records and retrieves attendance for individual class sessions.
Reporting	Calculates attendance summaries and produces reports.
Database Management	Stores and maintains consistent system records.

4. Identify the System Users and Stakeholders

A system user is someone who directly interacts with the system. A stakeholder is anyone who affects the system, is affected by it, or has an interest in its outcomes. Some stakeholders are direct users, while others may not log in to the application at all.

User or Stakeholder	Role	Possible Responsibilities
System Administrator	Manages system configuration and access.	Create authorized accounts, assign roles, and maintain settings.
Teacher	Records and reviews attendance.	Select a course, record attendance, and correct permitted errors.
Student	Views permitted personal attendance information.	Check attendance summaries and report possible discrepancies.
Department or Academic Administrator	Reviews attendance information for academic administration.	Review reports and monitor attendance according to policy.
University Management	Uses summarized information for decisions.	Review institutional attendance trends and policy compliance.
IT Support Staff	Supports the technical environment.	Resolve server, network, backup, and deployment issues.

The exact roles and permissions must be confirmed with the institution. For example, students should not be allowed to modify official attendance records unless an approved workflow explicitly permits it.

5. Identify the System Boundaries

A system boundary defines what is included in the system being analyzed and what remains outside it. It helps the analyst control project scope and clarify responsibilities.

For SAMS, the boundary separates the attendance application and its managed functions from external systems, people, and institutional processes.

5.1 Functions Inside the Boundary

• Authentication and role-based access.
• Student, course, section, and teacher records maintained by the application.
• Attendance-session creation and attendance entry.
• Attendance storage, retrieval, and correction under approved permissions.
• Attendance percentage calculations and reports.
• Application-level validation and audit records, where implemented.

5.2 Functions Outside the Boundary

• The university's official policy-making process.
• Physical classroom teaching and student participation.
• Official enrollment and registration processes, if handled by another system.
• The university's payroll and financial management systems.
• Campus internet infrastructure and third-party services not managed by SAMS.

Some outside systems may exchange information with SAMS in a future version. Integration does not automatically mean that the external system becomes part of the attendance application's boundary.

5.3 System Boundary Diagram

External Users
Teachers, Students, Administrators

↓ Inputs and requests

STUDENT ATTENDANCE MANAGEMENT SYSTEM
Login and Access Control
Student and Course Management
Attendance Recording
Attendance Calculation
Report Generation

↕

Oracle Database
Student, Course, Session, Attendance Records

↓ Outputs

Attendance Reports, Percentages, and Status Summaries

Conceptual diagram: users interact with the application, which reads and writes authorized records in the database and produces outputs.

6. Identify Inputs, Processes, Outputs, and Feedback

A system can be analyzed through its input-process-output model. Feedback and control mechanisms help ensure that the system operates according to requirements.

Element	Explanation	SAMS Example
Input	Data or requests entering the system.	Student ID, course, class date, attendance status, and login credentials.
Process	Operations performed on the inputs.	Validate user permissions, save attendance, and calculate percentages.
Output	Information produced by the system.	Attendance register, student percentage, and course attendance report.
Feedback	Information used to identify and correct problems.	A teacher reports an incorrect record, and an authorized correction is processed.
Control	Rules and checks that keep operations within approved limits.	Role permissions, validation rules, and duplicate-record prevention.

Example Calculation

Suppose a student attends 18 out of 24 eligible class sessions.

Attendance percentage = (Sessions Attended ÷ Eligible Sessions) × 100

Attendance percentage = (18 ÷ 24) × 100 = 75%

The system can display the result in a student attendance report. The denominator and treatment of excused absences must follow the institution's attendance policy.

7. Define the Project Scope

The system boundary describes what belongs to the system; the project scope specifies the features and work that will be delivered in the current project.

Included in the Initial Project	Excluded from the Initial Project
User login and role management.	University-wide ERP replacement.
Student, course, and section records.	Financial accounting and tuition collection.
Manual attendance entry by authorized teachers.	Biometric or facial-recognition attendance hardware.
Attendance percentage calculations.	Automated examination eligibility decisions unless specifically approved and implemented.
Student-wise and course-wise reports.	Payroll, learning management, and unrelated academic modules.

Defining the scope prevents unnecessary features from expanding a small academic project beyond its available time and resources.

8. Real-World Scenario

Scenario: Recording Attendance for a Programming Class

A teacher conducts a programming class for a section of 40 students. The teacher opens SAMS, signs in, selects the course and section, and opens an attendance session for the class date.

1. The system verifies the teacher's access permissions.
2. The system retrieves the enrolled students for the selected section.
3. The teacher marks each student's attendance.
4. The system validates the entries and saves the records.
5. The system generates an attendance summary.
6. An authorized user later reviews the student's attendance percentage.

System input: Course, section, class date, and attendance statuses.

System process: Validation, database storage, and calculation.

System output: Saved attendance records and summary reports.

Boundary example: The teacher's actual classroom teaching is outside the software system, while recording attendance through the application is inside it.

9. Student Exercise

Choose one real-world system and identify its components, users, and boundaries.

Suggested systems:

• Library Management System
• Hospital Appointment System
• Online Shopping System
• University Examination Management System
• Banking Transaction System

Prepare your work using the following structure:

Task	What You Should Identify
1. System Name	Name the real-world system and explain its purpose.
2. Problem	Describe the problem the system addresses.
3. Components	Identify hardware, software, data, people, procedures, and networks where applicable.
4. Users and Stakeholders	List direct users and other stakeholders, with their roles.
5. System Boundary	Explain which functions are inside and outside the system.
6. Input-Process-Output	Give at least two examples of inputs, processes, and outputs.
7. Scope	List the features included in the proposed project and the features excluded.

10. Knowledge Check

Question 1: Which of the following is a system component?

1. Data
2. Software
3. People
4. All of the above

Show answer

Answer: d) All of the above. Data, software, and people can all be components of an information system.

Question 2: What does a system boundary define?

1. The system's color scheme
2. What is inside and outside the system being analyzed
3. The number of users only
4. The programming language only

Show answer

Answer: b). The boundary distinguishes the system under analysis from its external environment.

Question 3: In SAMS, who normally records class attendance?

1. Authorized teachers
2. Unrelated external customers
3. Payroll staff in every case
4. Internet service providers

Show answer

Answer: a) Authorized teachers. The final permissions should be defined by the university's approved workflow.

11. Conclusion

Identifying a real-world system requires more than naming a software application. A system analyst must understand the system's purpose, components, users, inputs, processes, outputs, feedback mechanisms, and boundaries.

In the Student Attendance Management System example, teachers and administrators interact with the application, attendance data is processed and stored in a database, and reports are produced for authorized users. Defining the boundary and scope makes the project easier to plan, design, and implement.

Key takeaway: A clear understanding of the system and its environment should come before detailed database design and programming.

---

Course: System Analysis and Design