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:
Collect information from stakeholders.
Identify conflicts, gaps, priorities, and constraints.
Document functional and non-functional requirements.
Check whether requirements are correct and testable.
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.
"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: 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:
- The teacher selects a course and section.
- The teacher selects the class date.
- The system displays the enrolled student list.
- The teacher marks each student as present or absent, with other statuses supported if approved by the institution.
- The teacher submits the attendance record.
- The system validates and saves the data.
- 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 |
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.
- Introduction: Purpose, scope, definitions, and references.
- Overall Description: Product perspective, user classes, assumptions, and constraints.
- Functional Requirements: Login, user management, attendance, calculation, and reporting.
- Non-Functional Requirements: Performance, security, usability, reliability, and maintainability.
- External Interface Requirements: User interface, database interface, and network requirements.
- Data Requirements: Student, teacher, course, section, attendance, and audit records.
- Acceptance Criteria: Conditions that must be satisfied for the system to be accepted.
- 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:
- Identify at least four stakeholders.
- Write at least eight functional requirements.
- Write at least six non-functional requirements.
- Assign a unique ID to every requirement.
- Write acceptance criteria for at least five requirements.
- Prepare a small traceability matrix linking requirements to tests.
- 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.
কোন মন্তব্য নেই:
একটি মন্তব্য পোস্ট করুন