Software Requirements Specification for Billing System of Electricity PDF

Software Requirements Specification for Billing System of Electricity Version Group No.: < Arvind a/l Gopalakrishna Thevar > < 1211104071 > < Afrian Rizki Anugrah> < 1221302886 > < Fika Shafira Triyuniarti> < 1221302249 > < Dinesh a/l Jayakumar > < 121110628...

Software Requirements Specification for Billing System of Electricity Version Group No.: < Arvind a/l Gopalakrishna Thevar > < 1211104071 > < Afrian Rizki Anugrah> < 1221302886 > < Fika Shafira Triyuniarti> < 1221302249 > < Dinesh a/l Jayakumar > < 1211106280 > 1  Contents CONTENTS 2 REVISIONS 3 1 PROJECT INTRODUCTION 4 1.1 TEAM MEMBERS 4 1.2 PROBLEM STATEMENT 4 1.3 PROJECT PLAN 4 2 SYSTEM OVERVIEW 5 2.1 DESCRIPTION 5 2.2 ACTORS 5 2.3 ASSUMPTIONS AND DEPENDENCIES 5 2.4 USE CASE DIAGRAM 5 3 SCENARIO – BASED MODELING 6 3.1 ACTOR 1 6 3.2 ACTOR 2 6 3.3 ACTOR 3 6 4 REQUIREMENTS MODELING 7 4.1 CLASS DIAGRAMS / ERD 7 4.2 CLASSES / ENTITIES 7 5 BEHAVIORAL & FLOW MODELING (OPTIONAL) 8 5.1 SEQUENCE DIAGRAMS 8 5.2 STATE DIAGRAM 8 5.3 DATA FLOW DIAGRAM 8 6 OTHER REQUIREMENTS 9 2  Revisions Version Primary Author(s) Description of Version Date Completed Draft Type Full Name Information about the revision. This table does not 00/00/00 and Number need to be filled in whenever a document is touched, only when the version is being upgraded. 3  1. Project Introduction 1.1 Team Members Name Actor/Processes Arvind a/l Gopalakrishna Thevar Manager Afrian Rizki Anugrah Customer Fika Shafira Triyuniarti Admin Dinesh A/L Jayakumar Staff 1.2 Problem statement The manual approach to looking into electricity bills is cumbersome and easily prone to mistakes which leads to little or no transparency at all. Customers’ problems are the delay in notifications, cut off access to certain information and other support problems centered on fault resolution. Electric companies are able to supervise issues such as payment defaults, smooth and timely production of bills, and even customer service calls. There is need for automated generation of bills that will be able to allow electronic payment for transactions, forwarding of transaction histories, responding to customer orders and equipping managers with reporting tools with which they can manage unpaid accounts and accounts performance. With the introduction of this system completion of jobs will be more accurate, there will be less procedures, and clients will be satisfied more. 1.3 Project Plan 4  2. System Overview 2.1 Description The Electricity Billing System makes it easier to handle billing for residential and commercial customers. It has four main users: customers, admin, staff, and managers. Customers can create an account, log in, and use features like checking account details, making secure payments, viewing transaction histories, and filing complaints. Admins manage user accounts, send payment reminders, fix system problems, and oversee account registration and logins. Staff members take care of customer complaints, manage bills for homes and businesses, and report unresolved technical issues to higher authorities. Managers set the default price per kilowatt-hour, help with escalated customer questions, track overdue payments, issue warnings, and create performance reports to evaluate the system. By working together, the system ensures accurate billing, clear record-keeping, and smooth communication among everyone involved. 2.2 Actors Actor Use Cases Customer User Registration & Authentication, Search Functionally, Payment Processing, Transaction History, Complaint. Admin Managing User Registration & Authentication, Managing User, Handling Payment Reminder, Addressing system issue. Staff Customer complaint, Escalate system issues, Bill management for residential customers, Bill management for commercial customers. Manager Determining the Default Value Per Kilowatt, Handling Customer Inquiries Escalated by Staff, Monitoring Overdue Payments and Issuing Warnings, Generating Performance Reports 2.3 Assumptions and Dependencies Assumption: 1. Each staff, admin, customer, and manager are given unique id and passwords 2. Customer could make payment via online banking, EWallet or debit card 3. Customer account will be updated upon completion of payment 4. The customer will receive no electricity if they do not make any payments for 3 months Dependencies 1. Payment gateway required for online transaction \ 2. Customer needs to send a complaint for the staff to solve it 3. Admin will block users only if the manager instructs them to do 4. The admin will escalate system issues if only there is a ticket raised 5 2.4 Use Case Diagram 6 2.4.1.1 Use Case 1 (Customer) The Customer use case in the electricity billing system provides a seamless experience for managing accounts, payments, and complaints. It begins with User Registration, where customer details are validated and reviewed by the Admin during a manual Verification Process. Approved accounts grant access to features like Transaction History, enabling customers to view and search past payments and bills with ease. For Payment Processing, customers input payment details, which are verified to ensure secure and accurate transactions, with notifications sent upon success. If issues arise, customers can use the Complaint feature to report problems directly to staff via live chat, ensuring prompt and personal resolution. This system combines secure account verification, transparent transaction tracking, and responsive. 7 2.4.2 Use Case 2 (Admin) The use case diagram shows the different tasks the admin can perform in the system. The admin can manage user accounts by adding, updating, or deactivating users. They can also handle payment reminders by generating, sending, and tracking them. The admin addresses system issues by reporting, logging, and resolving them. Additionally, they manage user registration and authentication, which includes validating credentials and helping with password recovery. 8 2.4.3 Use Case 3 (Staff) The handles customer complaint, Bill management for residential customers, Bill management for commercial customers and escalate system issues. 9 2.4.4 Use Case 4 (Manager) This use case diagram helps us to identify the roles and functions associated with the Manager in the electricity billing management system. The Manager performs four functions: setting the base parameter value for each kilowatt, managing customer complaints that have been raised by the Staff, collection of overdue debts and warning debtors and d reporting on the performance of the organization. These activities help the Manager to maintain the smooth running of the organization, attend to clients and carry out other functions which require data on costs and operations. There is a narrative in each use case about the administrative activity and the dominance of this function in management. 10  3. Scenario – Based Modeling 3.0 Login This activity diagram illustrates the login process as applied in an electricity bill management system. The process begins with the user attempting to log in. After that, users provide the system with their respective credentials to be authenticated. Based on the given credentials, the user is switched to one of several roles namely: Manager, Staff, Admin, or Customer. Each role is then granted access to the functionalities designed for their duties. When their activities are fulfilled, it follows that this process ends. Hence, the system’s login procedure complies with the role-based access control feature together with secured entry points. 11 3.1 Actor 1 (Customer) 3.1.1 Use Case 1 (User Registration & Verification The User Registration and Verification process begins with the customer submitting their details, which are validated for completeness and accuracy. If the details are valid, they are sent to the admin for verification. If the admin rejects the request (answer is "No"), the process loops back to the Validate Details step, allowing the customer to correct and resubmit their information. If approved (answer is "Yes"), the customer's account is activated, granting them access to the system. This ensures a secure and accurate registration process, with opportunities to fix errors if needed 12 3.1.2 Use Case 2 (Search Functionally) Once registered, customers can use the Search Functionality to find specific information related to their bills, payments, or transaction records. They can enter search criteria such as a date range, transaction type, or amount to narrow down results. If no specific criteria are entered, the system displays no previous transaction. 13 3.1.3 Use Case 3 (Payment Processing) Customers proceed to pay their bills by entering payment details such as account numbers or card information and selecting a payment method (e.g., credit card or bank transfer). The system validates these details, and if they are invalid, the process loops back to allow the customer to re-enter the correct information. Once valid, the payment is processed. If the payment fails (e.g., due to insufficient funds or incorrect details), the customer is notified and looping back to the processing step. Upon successful payment, a receipt is generated, and the customer is notified via email or SMS, confirming the transaction. This ensures accuracy and provides opportunities to correct errors or retry failed payments. 14 3.1.4 Use Case 4 (Transfer History) After making a payment, customers can access their Transaction History to review past payments. They can view all transactions or filter results based on criteria such as dates or amounts, helping them track their financial records and verify payment statuses. If the customer is prompted with a Search Transaction? option and selects No, the process loops back to the View Transaction History, allowing them to decide again. This ensures a user-friendly experience for navigating transaction records. 15 3.1.5 Use Case 5 (Complaint) If customers encounter issues, they can file a complaint through the system. Customers provide details about the issue and are directly connected to staff via a Live Chat feature for real-time assistance. Once connected, the complaint is resolved directly during the chat, ensuring a quick and effective solution for handling customer problems. 16 3.2 Actor 2 (Admin) 3.2.1 Use Case 4 (User Registration and Authentication) The user registration process begins with submitting a registration form; if the details are valid, the system sends a verification link or OTP, and successful verification activates the account, while any errors prompt the user to make corrections. For user authentication, individuals enter their credentials, and valid entries grant access, whereas invalid ones result in a denial and an alert to the user. In the case of password recovery, the user requests a reset, and the system sends a verification code; if the code matches, the user can set a new password, but mismatches cause the process to fail. 17 3.2.2 Use Case 5 (Managing User) Adding a new user begins with the admin entering the user's details; if all mandatory fields are filled, the system validates the information to check for duplicates or errors. Upon successful validation, the system assigns an account number, any validation failures or incomplete fields prompt the system to request corrections. For updating user details, the admin retrieves the existing information and inputs the necessary updates, which the system then validates for accuracy and compliance with defined parameters; if valid, the changes are saved, and the user record is updated, otherwise, the admin is prompted to correct any errors. To deactivate a user, the admin selects the user and provides a reason, with the system seeking confirmation before proceeding; upon confirmation, the user is notified of the deactivation, while any lack of confirmation results in the process being canceled. Finally, when viewing user details, the admin can search for a user by ID or name, and the system retrieves and displays the relevant information without requiring further decision-making steps. 18 3.2.3 Use Case 6 (Handling Payment Reminder) The payment reminder process begins with the system identifying accounts with due payments; if such accounts exist, reminders are generated, and if not, the process concludes. Next, the admin or system selects notification channels, such as email or SMS, to send the reminders, with the system logging the activity for tracking purposes. For reminders that remain unacknowledged, the system identifies them and requests admin approval to resend; if approved, the reminders are resent, while disapproval halts the process. Additionally, the system continuously tracks user acknowledgments and payment statuses, marking reminders as resolved when payments are completed or continuing the tracking if they remain outstanding. 19 3.2.4 Use Case 7 (Addressing System Issues) The process of reporting a system issue begins when a user submits an issue report via a support form, which the system validates for completeness. If the form is valid, the issue is logged, and the issue is generated, allowing the admin to assign the issue to a technician. The technician then applies a solution; if the fix is successful, the issue is marked as resolved; if not, the technician reassesses the problem and attempts another solution. Once the issue is resolved, the system notifies the user, and the issue is subsequently closed. 20 3.3 Actor 3 (Manager) 3.3.1 Establishing the Default Value Setting a base price for one unit is the focus of this activity workflow. It begins with screening the energy market and regulatory aspects to ensure orderly conduct of business. There is a decision point that determines the stability of market trends. If stable, the default value is set; otherwise, the obtained trends are rescrutinized. The activity ends when a legally and economically reasonable price is developed. 21 3.3.2 Handling Customer inquiries Raised by Staff Concerning a customer question by staff that is raised with the supervisor renders the process clear as per the activity workflows. This process begins with the received the cut-off question, and this is again followed by concern on the natures and even the importance of the question. There were aspects that led a resolution to be developed and then to be explained to the customer. The Axis of end is where the problem suffers resolution and the customer is happy. 22 3.3.3 Monitoring overdue payments and issue warnings The aim of this activity diagram is to explain how overdue payments are followed up repayments are made. It starts with the analysis of payment documents to determine if there are any payable accounts that are outstanding. A decision point determines follows if overdue amounts go above the limitation set up. Since this case is considered actionable, a warning notice is sent to the customer and preventive measures are taken in the future. The process finishes with all overdue payments being removed. 23 3.3.4 Generating performance report The purpose of this activity diagram is to show how performance assessment documentation is prepared. For a start, data on performance of operations is isolated and gathered from relevant locations. This data is reviewed for the purpose of giving insights. The results are integrated into a report in a report format and made available to the relevant personnel. The processes of the post reporting are the distribution and the completion of the report. 24 3.4 Actor 4 (Staff) 3.4.1 Use Case 1 (Customer Complaints) The activity diagram for customer complaint on the website is shown in the component below. The customer complaint will be received by the staff. The staff will identify the problem and try to resolve it. If the staff cannot resolve the problem, then the staff will forward the complaint to the manger to handle. 25 3.4.2 Use Case 2 (Bill management for residential customers) The activity diagram for Bill management for residential customers on the website is shown in the component below. The staff will be handling all the billings for the residential customers. The staff will calculate the kilo watt spent for the month by calculating it with the default amount per kilo watt. The staff will check if the customer got any pending payments. If the staff do means it will be added to the bill and then the bill will be generated and sent to the customer. 26 3.4.3 Use Case 3 (Bill management for commercial customers) The activity diagram for Bill management for commercial customers on the website is shown in the component below. The staff will be handling all the billings for commercial customers. The staff will calculate the kilo watt spent for every 6 months by calculating it with the default amount per kilo watt. The staff will check if the customer got any pending payments. If the staff do means it will be added to the bill and then the bill will be generated and sent to the customer. 27 3.4.4 Use Case 4 (Escalate system issues) The activity diagram for escalate system issues on the website is shown in the component below. When the staff encounters any issues in the system, the staff will raise a ticket and sent it to the admin to figure out what are the issues is. 28 4.1 Class Diagram ERD 29 4.2 Classes / Entities Class / Entity Description User Attributes: User_ID: String Name: String Email: String Password: String Role: String Operations: Login Register ViewProfile Customer Attributes: Customer_ID: int Operations: Search ViewTransactionHistory SubmitComplaint Manager Attributes: Manager_ID: int Operations: SetDefaultValuePerKilowatt HandleEscalatedInquiries MonitorOverduePayments GenerateReport Admin Attributes: Admin_ID: int Operations: ManageUsers SendPaymentReminders HandleSystemIssue Staff Attributes: Staff_ID: int Operations: LogComplaint ManageBillResidential ManageBillCommercial escalateIssue 30 Report Attributes: Report_ID: int DateGenerated: Date PerformanceData: String Operations: GeneratePerformanceReport Payment Attributes: Payment_ID: int TransactionDate: Date Amount: Float Status: String Operations: ProcessPayment checkOverduePayments Bill Attributes: Bill_ID: String Customer_ID: String Amount: Float DueDate: Date Type: String Operations: GenerateBIll payBill Complaint Attributes: Complaint_ID: String Description: String Status: String Operations: SubmitComplaint EscalateComplaint System Attributes: System_ID: String Status: String Operations: AuthenticateUser sendReminders 31