In this article, we will take a look at the key features a fee management system needs to offer, its high-level, low-level design, database design, and some of the features that turnkey software solutions offer.
Table of contents:
- Fee Management System
- System Requirements
- Functional Requirements
- Non - Functional Requirements
- Software Requirements
- High-Level Design
- For a small setting
- For a large setting
- Low-Level Design and Classes
- Database Design of Fee Management System
- Turnkey Software Solutions
Fee Management System
A fee management software is a software that automates the collection of fees and generation of receipts. For example in a school environment, the system manages tuition fees, miscellaneous fees, project fees and other charges for student services. It helps the school administrator to automate the fee collection, generate receipts, refunds and invoice reminders. It increases efficiency and reduces the cost needed for maintaining manual records and saves time and effort for both the user and the school administrator.
The key requirements that need to be offered by the fee management system can be classified into functional and non-functional requirements.
- Allow the school administrator to add and remove new students.
- Allow the school administrator to add and manage the subjects and the associated fees.
- Users can retrieve invoice and make payment.
- The system should notify the user and school administrator about the overdue invoices.
A more detailed list of key features that need to be supported by the system is given in the use case diagram.
There are 3 actors in the use case diagram. The User, the School Administrator and the System.
User - The user can log in, make payment for the invoice, print a copy of the invoice for their records.
School Administrator - The School Administrator registers new student account, calculate the fees payable and print out the invoices to issue to the students.
System - The system is the fee management system itself. It keeps track of the invoices and sends notifications to the user and school administrator about the overdue invoices.
Non - Functional Requirements
Usability is the main non-functional requirement for a fee management system. The user interface (UI) should be simple enough for everyone to understand and get the relevant information without any special training. Different languages can be provided based on the requirements.
Accuracy is another important non-functional requirement for the fee management system. The fees calculated should be correct, consistent, and reliable.
The System should be available at least during the academic year and must be recovered within an hour or less if it fails. The system should respond to the requests within two seconds or less.
The software should be easily maintainable and adding new features and making changes to the software must be as simple as possible.
- A server running Windows Server/Linux OS
- A backend language such as like Java, Python to do the computation of the fees
- Front-end frameworks like Angular/React/Vue for the user interface.
- Relational DBMS such as MySQL, PostgreSQL.
- Containers and orchestration services like Kubernetes (for a large setting such as a University).
High Level Design
For a Small Setting (School):
In a school environment, the users are the students. Hence, the traffic is usually pretty low with an estimated 1,000 concurrent users at the peak. A group of servers each with 16GB of RAM and a capable processor should be able to handle the load. Each server may need to handle several requests at a time. The requests can be queued and a reply can be sent to the user while the request is being processed.
The user can access the system through a client site or app with a registered account. The school administrator can access the admin dashboard and interface using the admin account.
Handling the authentication is done by a separate service. The authentication service has direct access to the accounts on the database. The notification service checks the database for any overdue invoices and alerts the user and the school administrator.
Since the data stored are mostly relational, like user accounts, details on fees, a relational database like MySQL can be used. The database servers can be set up in master-slave configuration for backup and availability.
For a Large Setting (University):
For some Universities, the number of concurrent users can get up to 10,000 and above at its peak. These systems can also have separate user and admin interfaces for students from different faculty.
The servers may be distributed across different regions in the country with load balancers to distribute the traffic. Reverse proxy servers may be deploy for web acceleration using techniques such as compression, SSL termination and caching request. Services such as authentication and notification may be deployed as separate containers. This allows scaling much more easily and simplifies the addition of new services.
The database can also be distributed with the regional data such as different campus location being stored in that region.
Low-Level Design and Classes
Now, let us take a look at a little bit lower-level design of the fee management system by exploring the various classes and methods involve
class Person: def __init__( self, first_name: str, last_name: str, gender: str, address: str, phone: int ): class Student(Person): def __init__( self, userid: str, email: str, password: str): def login(self, email: str, password: str): def logout(self): def payInvoice(self, invoice_id: int): class Administrator(Person): def __init__( self, userid: str, email: str, password: str): def login(self, email: str, password: str): def logout(self): def createInvoice(self, student_id: int, amount: int):
Person class is the base class and contains fields for the basic information such as name, address, etc. The
Student class inherits the
Person class and adds fields such as a unique user id, login email, and password and also methods to login and logout. Both the
Administrator classes inherit the Person class. The student can pay for the invoice and the school administrator can create invoices for the students.
Database Design in Fee Management System
The above image shows one possible database schema for the fee management system.
The users table stores the user details such as a unique user id, name, contact, and login information. The admin table references the user id as a foreign key and stores the role of the admin such as Supervisor, Assistant, etc.
The studentBill table contains the information about the id of the Student, the amount payable, category of the fees and a brief description of the invoice. The category table stores the charges corresponding to the invoice category. The payment table stores the amount paid and when the payment was made.
Turnkey Software Solutions
Below are some of the turnkey software solutions available:
In general, the features provided by the turnkey software solutions include report generation facility such as fee receipts, fee payment reports that allow tracking of outstanding invoices. The software provide both automatic online and offline data backup facilities. In addition, the system is able to sync with payment gateways for a secure transaction. Real-time notification in the form of SMS, email, push notifications keep the students informed about fee dues and financial transactions.
With this article at OpenGenus, you must have a strong idea of System Design of Fee Management System.