Payment and Cashiering System

3.1 Software Requirements Specification Document

Page 29

Payment and Cashiering System 1. Introduction 1.1 Goals and objectives The purpose of this document is to describe requirements for the Payment and Cashiering System (PACS) software application that will serve as a base for the final output. It is essential that the arrangement of these requirements be reached on every user of the software application so that everyones expectation will be met. This document uses written explanations as well as various types of modeling diagrams to illustrate the high level construction of the application. This gives different stakeholders and users a view of the requirements that is better suited to their area of responsibility. A Web based solution will be made on this project so that users can access the system on their desired computer web browsers. By designing and making a standardized web page using Java programming language, the software application will run on most computer web browsers. In addition, a centralized database will be connected to the Internet that will allow the employees to easily share more information over the Internet. The Payment and Cashiering System application software is intended to provide a computer based application software that will be used in the Local Government Units. Many of the typical operations and functions involving operations on the treasurers office will be automated through software to improve the operational workflow of the office. All the processes on the treasurers office will be automated such as accepting of payments and processing of payments. The Requirements Specification will describe these as well as many other features of the software in greater detail. 1.2 Statement of Scope This section contains a general description of the software functionality followed by detailed requirements that will be traced throughout the project. Taxpayers have to comply with all the necessary requirements to get an order of payment. Completion of requirements and order of payment will be coming from different departments depending on the type of fee.

Page 30

Payment and Cashiering System To gain access on PACS (Payment and Cashiering System) an employee will be required to enter their username and password. Their position will determined their access privileges on the system. The administrators will have all the privileges in accessing the system, while the teller and other employees will have their own specific access. The administrators will be capable of adding and editing new types of fees and taxes. They are allowed to register new accounts as well as viewing and editing of their information. Payer will have to complete the necessary requirements such as filling up form. After the requirements are complied, the administrator will create a new record for new payer and update an existing record for old payer. Payer will go to assigned window in the city treasurers office together with the order of payment. The teller will verify the payers record by entering their PIN number. Payers record will be updated and the teller will accept the payment. The system will create a receipt of payment for the payer. Administrators and managers can access reports generated by the system such as total collections over a specific period of time and financial statements. They can also view those payers who have unsettled accounts like real property and business tax. ditto yung ibang features. The following tables are requirements needed with indication whether it must have a high and low priority. High priority indicates that the requirement must be implemented and low priority can be eliminated. Table 1.2.2 User Requirements for Payment and Cashiering System Req. No Access Privileges R1 High There will be three levels of access; one for tellers and other employees, one for Priority Reference Description

Page 31

Payment and Cashiering System manager and one for administrator R2 High Teller can only be allowed to update a payers record when payment is received. R3 High The administrators are allowed to enter and edit all the needed data. R4 Medium Only the administrators and manager are allowed to view and print reports. Security R5 High Each user will be required to enter a unique user name and password to access the system. R6 Low Password shall have at least six alpha numeric characters. R7 Medium A user will be locked out of the system after having more than five unsuccessful attempts in entering a username and password.
Page 32

Payment and Cashiering System R8 High A new password will be assigned if a user forgets the password. R9 Low The user shall be logged off the system if there is no activity for 10 minutes. Accepting Payment R10 High Taxpayer shall have the order of payment from designated department. R11 High Only the teller is allowed to accept payment. R12 High The teller shall input the right amount given by the payer. R13 High The exact amount of change shall be given in every transaction. Issuance of Receipt

Reports

Account Information High When the teller update the payers account, audit trail must contain the date,

Page 33

Payment and Cashiering System time and the changes done and shall be recorded on the database. High The payers account shall contain the following information:

High

Employees shall contain the following information: 1. Employee No. 2. Full Name 3. Birthday 4. Address 5. Email 6. User name 7. Password

High

The system shall support the ability to enter, store and update the employee and payers information.

User Interface High The system shall respond to all user requests within 20 seconds.

Page 34

Payment and Cashiering System 1.3 Software Context The iTAX system is used as a model in this document. iTAX stands for integratedtax administration software for assessment and collection. It is an integrated system that allows the administration of all taxes, on a national as well as a local level.integrated tax administration software for assessment and collection. It is an integrated system that allows the administration of all taxes, on a national as well as a local level. iTAX has been initially developed in a cooperation project between the Tanzanian Revenue Authority (TRA) and Deutsche Gesellschaft fr Technische Zusammenarbeit (GTZ) GmbH. Tanzania by now has introduced iTAX nationwide and starting in 2007, iTAX has been adapted to the needs of local government units in the Philippines. iTAX is therefore a software solution specifically designed for a developing country context. It is constantly improved, notably through South-South cooperation between the Philippines and Tanzania. Governments and public authorities in general have to act on behalf of society at large, notably in providing key public services. These include education, roads, health and social security, defense, and civil order forces. Public services are primarily financed through tax revenue, especially where a country does not have major natural resources at its disposal.
Formatted: Font: (Default) Times New Roman, 12 pt Formatted: Line spacing: 1.5 lines

The responsibility of the government to finance public services lies therefore at the heart of taxation. Applying criteria of efficiency, fairness, and transparency to tax systems and the spending of government resources creates a virtuous circle of improving fiscal performance, good governance, fair distribution of public goods and services, and ultimately strengthens state legitimacy.

Page 35

Payment and Cashiering System Indeed, understanding user demand is important to finding an adequate technical solution. Topdown approaches in iTAX strategies were frequently resulting in early failures. Resistance from civil servants is probably the biggest challenge to successful iTAXimplementations.iTAX
implementations.

High involvement of public authority staff will ensure a sustained administration

Formatted: Font: (Default) Times New Roman, 12 pt

effort for modernization. Hence, capacity development within the government is an important step for e-Government and its effective implementation. With the establishment of wellstructured plans that embrace employee participation throughout all stages of the process, civil servants will become key stakeholders of the reform.

There is no one-size-fits-allmodel for e-Government development. Each country needs to devise its own e-Government strategy and program, taking into consideration its political, economic and social priorities and its financial, human and technological capacities. The key to effective e-Government implementation is a multi-pronged approach based on technology as well as human development. The price for existing commercial tax administration software is based almost exclusively on IC price levels. Such solutions are too costly for most governments in DCs. As a consequence, most tax computation, assessment, and accounting in DCs is still done manually, using various loose leaf systems, index cards or folios. This neither enhances administrative transparency nor does it promote tax payer compliance.

Formatted: Line spacing: 1.5 lines

An IT system has the potential to help modernize the administrative processes. For example, in the Philippines, it may take up to four hours to inform a (waiting) tax payer about his tax bill. With the new IT system, this waiting period is reduced to 3 minutes, including issuing a proper tax or payment receipt.

Additionally, iTAX offers opportunities for the development of local ICT capacities that will in turn ensure the sustainability of the system. In order to comply with the need for cost effective solutions, the GTZ product predominantly uses open source software and focuses on their appropriate adaptation and implementation on the national and on the local community level.

Page 36

Payment and Cashiering System The objective of the program is to transform the real property tax system in every province into an equitable, revenue-productive and cost-effective system through process innovation. It is basically an organizational development program that seeks to use behavioral knowledge to change beliefs, attitudes, values, strategies, structures and practices so that the organization can better adapt to changing environment. The participatory approach utilized by the program was intended to influence a paradigm shift not only for treasury and assessment personnel, but most especially to elective officials and other major stakeholders like barangays and teachers including the public in general. This program is the first of its kind among the various interventions in the past on real property tax administration. 1.4 Major Constraints The Payment and Cashiering System will use JAVA programming language The Payment and Cashiering System will use MySQL for the database

2. Usage Scenario 2.1 User Profiles The following definitions describe the actors in the system. Administrator An Administrator is responsible for adding, viewing and editing all forms of the system setup and has the privilege to view all the reports of the system. Manager Teller A Manager views all the reports of the system. A Teller accepts the payment of the tax payer and updates the info of the payee in the system. System The System refers to the computer hardware and software that controls the application. It accepts user input, displays user output, and interfaces to the Web Server through the Internet. Web Server The Web server is a remote computer that maintains the database and serves Web pages to the system.

2.2 Use-cases
Page 37

Payment and Cashiering System The following use-cases are typical interactions between the external and the internal software system. Each use-case is described in section 2.2. 1. Log onto system 2. Accept payment 3. View account information 4. Update accounts to be settled 5. View report

2.2.1 Use-Case Diagram The use-case diagram in Figure 1 shows three actors that were described in section 2.1. In order to minimize the complexity of this diagram several connections were left out. For instance, every use-case will typically involve an interaction with the System and Web Server, but since this is secondary activity it is not shown in the drawing. The Employee could be an administrator, manager or teller. Instead of drawing separate connections to each of these actors, the Employee was added to make the diagram easier to read.

Page 38

Payment and Cashiering System

Formatted: Justified Formatted: Font: Times New Roman, 12 pt

Figure 1: Use-case diagram of Payment and Cashiering System

Page 39

Payment and Cashiering System

Formatted: Centered Formatted: Font: (Default) +Body (Calibri), 11 pt

Formatted: Justified, Indent: Left: 0"

2.2.2 Use-Case Descriptions Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario: Log on to System Employee To gain access to the System The employee has a valid user name and password An Employee needs to access the system to perform their job. 1. The System prompts the employee for their user name and password. 2. The employee enters their user name and password. 3. The system sends the user name to the web server. 4. The system verifies the password and sets the users authorization. 5. The employee is given access to the system to perform their job. Exceptions: The user name and password cannot be verified.

Page 40

Payment and Cashiering System Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario: Accept Payment Teller To settle the account of payer. The payer has the order of payment. A Payer needs to pay for the fee/taxes. 1. The payer renders to teller the order of payment which comes from the appropriate department. 2. The teller will verify the payers account information. 3. The teller will accept the payment when the account is verified. 4. The teller will update the payers account information. 5. The system will create an official receipt for the payer. Exceptions: The payers account information cannot be verified.

Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario:

View account information Teller To verify the account of payer. The payer has a pin number. The teller needs to verify if the payers account exist. The teller will search the payers account by entering the pin number. The system requests the record from the web server. A report of the record is displayed on the screen.

Exceptions:

The account does not exist.

Use-case: Primary actor: Goal in context: Preconditions: Trigger:

Update account to be settled Teller Settle the payers account. The payer has paid. The teller accepts the payment.
Page 41

Payment and Cashiering System Scenario: 1. The teller input to system the amount paid by the payer. 2. The system will compute if there is a change. 3. The system update the payers account and save to database. 4. The system will display the updated account. Exceptions: The account does not exist.

Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario:

View Report Administrator/Manager To view a report. Information required for the report has previously been entered. The administrator decided to view a summary of collected taxes and fees. 1. The Administrator logs on to the system. 2. The administrator selects Report from the main menu. 3. The administrator selects the name of the report from the report menu. 4. The report is displayed on the screen. 5. The administrator is given the option to close or print the report. 6. The report is closed or printed.

Exceptions:

The account does not exist.

2.3 Special Usage Considerations Billing fees cannot be changed

2.4 Activity Diagrams Figure 2 shows the steps taken as an employee logs on to the computer system. Access is only granted if the correct user ID / password combination is entered within the first five attempts. After the fifth attempt the user ID will be locked out and an administrator will need to issue new password. Once access is granted the employee can use the system according to their level of authorization.
Page 42

Payment and Cashiering System

Page 43

Payment and Cashiering System

Formatted: Font: (Default) Times New Roman, 12 pt

Figure 2 Activity Diagram for logging on to the system

Page 44

Payment and Cashiering System

Formatted: Font: (Default) Times New Roman, 12 pt

In Figure 3 the employee has contacted an administrator to make a new employee account. The administrator will first check the employee number. If the given employee number has already the account, the process will end. If the given employee number doesnt have any account, the system will create a record for them and then saves their information.

Page 45

Payment and Cashiering System

Formatted: Font: (Default) Times New Roman, 12 pt

Figure 3 Activity Diagram for New Account of Employee

Page 46

Payment and Cashiering System

Formatted: Font: (Default) Times New Roman, 12 pt

Figure 4 is the viewing and updating account information was depicted in Figure 6. As shown in the diagram all employees will be able to view account information but only administrators will be allowed to edit the information.

Page 47

Payment and Cashiering System

Formatted: Font: (Default) Times New Roman, 12 pt

Figure 4 Activity Diagram to View / Update Account Information

Page 48

Payment and Cashiering System

Formatted: Font: (Default) Times New Roman, 12 pt

Page 49

Payment and Cashiering System Figure 5 shows that only administrators and managers have access in viewing and printing reports. After the report is displayed on the screen it can be sent to a printer.
Formatted: Font: (Default) Times New Roman, 12 pt

Figure 5 Activity Diagram for Viewing and Printing Reports

Page 50

Payment and Cashiering System

Formatted: Font: (Default) Times New Roman, 12 pt

3. Data Model and Description 3.1 Data objects 3.2 Relationships

Page 51

Payment and Cashiering System User Data Object userid username password usertype status A unique identifier assigned to a user. The name of the user. The password of the user to be used in logging on the system. The type or position of the user. Describes whether the user is active or inactive.

Taxpayer Data Object taxpayer_id firstname middlename lastname gender height civil status date of birth place of birth contact no BIR TIN no occupation citizenship street purok address (street, purok, municipality) Barangay fee_type_id The municipality whereaddress of the taxpayer lives. The barangay where the taxpayer is residing. The identifier of the type of fee the taxpayer has the responsibility to pay.
Formatted Table

A unique identifier assigned to a taxpayer. The first name of the taxpayer. The middle name of the taxpayer. The last name of the taxpayer. The gender of the taxpayer. The height of the taxpayer. The civil status of the taxpayer. The date when the taxpayer is born. The place where the taxpayer is born. The contact number of the taxpayer.

Formatted Table

The occupation and source of income of taxpayer. The nationality of the taxpayer. The street where the taxpayer currently reside.

Fee TypeUser Data Object

Page 52

Payment and Cashiering System fee_type_iduserid The unique identifier assigned to fee type.The identification number of the user. fee_type_nameusername The name of the fee typeuser to be used in logging on the system. password usertype status The password of the user. The type or position of the user. Describes whether the user is active or inactive.

Fee Data Object fee _id fee _name fee_type_id fixed_cost status Terms of payment (quarter, annual, etc) The unique identifier assigned to fee. The name of the fee. The identifier of the type of fee. The cost of the fee. Indicates whether the fee is active or not.

Account Information Data Object taxpayer_id PIN The identifier of a taxpayer. The unique identifier of taxpayer account information. Property_id Business_id

Transaction Data Object transaction_id PIN The unique identifier assigned to a business. The identifier of a taxpayer account information. Date The date when the transaction occurs.
Page 53

Payment and Cashiering System payment_type amount_paid Balance Userid Specifies whether the payment is full or partial The amount paid by the taxpayer. The balance of the taxpayer if not fully paid. The identifier of the user who processed the payment.

3.2 Relationships 3.3 Complete data model The figure below show the relationships between the data objects describe in section 3.2. Figure 3.3.1 Relationship Diagram of PAC System

4. Functional Model and Description 4.1 Class DiagramDiagrams 4.2 Software Interface Description 4.2.1 External Machine Interfaces The software will be capable of printing invoices and reports on a local or a network printer. 4.2.2 External System Interfaces The ACCM system will communicate with a Web server on the internet through a high speed network connection such as DSL, cable, or a T1 line. 4.2.4 Human Interface The web pages shall permit complete navigation using he keyboard alone, in addition to using mouse and keyboard combinations.
Page 54

Payment and Cashiering System 4.2.3 Human Interface 4.2.44.2.5 Reports

Inventory of Generated Reports Reports Layout Data Dictionary for each report 5 Behavioral Models and Description 5.1 Description for Software behavior 5.1.1 Events Taxpayer Class Events Taxpayer present order of Payment Taxpayer pay Taxpayer receives official receipt

User Class Events User logs on to the system User logs off to the system User is no longer active
Formatted: Indent: Left: 0"

5.1.2 States Taxpayer States Fully paid Partially paid Description The taxpayer has paid all the balances due on their account. The taxpayer has partially paid the balances due on their

Page 55

Payment and Cashiering System account. Unpaid The taxpayer has a balance due on their account.

User States Online Offline Terminated

Description The employee has logged on to the system. The employee has logged off the system. The employee has been terminated and must be blocked from using the system.

5.2 Statechart Diagram 6 Restrictions, Limitations, and Constraints The system shall integrate within the existing LAN structure and with the existing systems, such as the database management systems. All HTML code shall conform to the HTML 4.0 standardJava. All server side code shall be written in JAVAAAAAAAA!!! Any other browsers can be used.

7 Validation Criteria Software validation will ensure that the system responds according to the users expectations; therefore it is important that the end users shall be involved in some phases of the test procedure. All tests will be traced back to the requirements in section 1.2.

7.1 7.1 Classes of tests

Formatted: List Paragraph, Outline numbered + Level: 2 + Numbering Style: 1, 2, 3, + Start at: 1 + Alignment: Left + Aligned at: 0.09" + Indent at: 0.34" Formatted: Font: Bold

Unit testing will be conducted on all of software subsystems including 1. Viewing and editing information 2. Viewing and printing reports
Page 56

Payment and Cashiering System 3. Logging on to the system 4. Updating accounts settled Acceptance testing will be conducted at the administartors side.

7.2 7.2 Expected software response The software should display an appropriate error message when a value outside the accepted limits is entered. The software should not be capable of deleting a taxpayer record with any other reasons that can lead to their extinction or unreliable consistency of transaction. The software should not be capable of deleting a type of fee whether it is categorized as an inactive transaction.

Formatted: List Paragraph, Outline numbered + Level: 2 + Numbering Style: 1, 2, 3, + Start at: 1 + Alignment: Left + Aligned at: 0.09" + Indent at: 0.34" Formatted: Bulleted + Level: 1 + Aligned at: 0.59" + Indent at: 0.84"

Formatted: Indent: Left: 0.34", Line spacing: 1.5 lines

7.3 7.3 Performance Bounds The system shall support up to 100 simultaneous users against the Website/Web Server at any given time. The system will provide access to the database management system with a latency of no more than 1 minute.

Formatted: List Paragraph, Outline numbered + Level: 2 + Numbering Style: 1, 2, 3, + Start at: 1 + Alignment: Left + Aligned at: 0.09" + Indent at: 0.34" Formatted: Bulleted + Level: 1 + Aligned at: 0.59" + Indent at: 0.84"

Glossary Account Administrator Browser HTML Manager Official Receipt Paid Teller Web Server

A reference for all of the information related to tax payer. A person on the administrative staff of Treasurers Office. A software application used to locate and display Web pages. Short for Hyper Text Mark-up Language, the authoring language used to create documents on the World Wide Web. A person that managers the department. The receipt given to tax payers given after the payment. The tax payer having settled payments. A person accepting payment from the tax payers. A remote computer connected to the internet that stores and delivers Web pages.

Issues List Should tax payers have access to PACS? Should there be a search function for retrieving records?
Formatted: List Paragraph, Indent: Left: 0.34", Line spacing: 1.5 lines Formatted: Font: Bold

Page 57