SEIT Team 4

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications

Version <1.2>

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc>

Version: <1.2> Date: <2004/7/14>

Revision History
Date
2003/9/23 2003/9/24 2003/9/24 2003/9/24 2003/9/28 2003/9/28 2003/9/28 2003/9/28 2003/9/28 2003/9/28 2003/12/10 2003/12/10

Version
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 1.1 1.2

Description
Added Scope in Introduction Added Introduction Added Purpose and Definition, Acronyms, and Abbreviations Added Overview Added Specific Requirements Updated Purpose and Definition, Acronyms, and Abbreviations Added References Added Functional Classification, Modified 3.1.4.5.3 Added Overall Description First Version Fixed typos and redundant paragraphs Modified 2, 3 according to TAs comments

Author
Benjamin Tsai Iung-hsin Shih Chih-yu Chao Chitra Kalyanaraman Chih-yu Chao Chih-yu Chao Chih-yu Chao Benjamin Tsai Chitra Kalyanaraman Chih-yu Chao Chih-yu Chao Chih-yu Chao

Confidential

SEIT Team 4, 2004

Page 2

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc>

Version: <1.2> Date: <2004/7/14>

Table of Contents
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview Overall Description 2.1 Product perspective 2.1.1 System Interfaces 2.1.2 User Interfaces 2.1.3 Hardware Interfaces 2.1.4 Software Interfaces 2.1.5 Communication Interfaces 2.1.6 Memory Constraints 2.1.7 Operations Product functions User characteristics Constraints Assumptions and dependencies Requirements subsets 4 4 4 4 5 5 6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 12 12 12 14

2.

2.2 2.3 2.4 2.5 2.6 3.

Specific Requirements 3.1 Functionality 3.2 Use-Case Specifications 3.3 Supplementary Requirements Classification of Functional Requirements Appendixes

4. 5.

Confidential

SEIT Team 4, 2004

Page 3

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc>

Version: <1.2> Date: <2004/7/14>

Software Requirements Specifications

1. Introduction
Electronic Bill Presentment & Payment Application (EBPP) is a web-based application which helps biller and their customers settle their transactions online without any paperwork involved. Briefly speaking, billers can issue bills (e-bill) on line and send them to their customer electronically. Customers can see their bills in their inbox and can make payment to specific bills. EBPP also support multiple languages, that is, users can select to view and pay their e-bills in multiple languages. This system will also keep transaction history between billers and customers. 1.1 Purpose The purpose of this document is to describe the requirement specifications for an electronic billing presentment and payment application. The intended audience of this document includes the prospective developers of the application and the technical assessment personnel of the client organization. 1.2 Scope
This SRS document will describe the software required to allow billers to send e-bills to customers. It will be divided into four main components.

1. 2. 3. 4.

User Interface Billing Logic Information Storage Payment Engine

The Use-Case models associated with this document please refer to Use Case Specification.

1.3 Definitions, Acronyms, and Abbreviations 1. 2. 3. 4. 5. 6. 7. 8. ACM: Administrator Client Module Administrator: A registered user who has the full access to the database, and has the right to view and change the account information, billing information of all users. BCM: Biller Client Module Biller: A registered user who can issue bills to the customers. Browser: A browser is a software which allows the user to visualize and interact with all the information presented and flowing through the World Wide Web. CCM: Customer Client Module Customer: A registered user who can pay bills to the billers. E-bill: The electronic billing information that billers send to their customers. The information includes o o o Confidential bill number biller's user name customer's user name SEIT Team 4, 2004 Page 4

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc> o o o o 9. date issued amount payment due date current payment status

Version: <1.2> Date: <2004/7/14>

EBPP: EBPP (Electronic Bill Presentment and Payment) Application is a web application that helps billers and their customers settle their transactions online without any paperwork involved. Engine: In software or in a computer, engine is the term used for smaller programs executing specific functionalities and useful tasks for other programs or software. GUI: Graphical User Interface HTML: HTML (Hypertext Markup Language) is a text-based programming language using many symbols and codes interpreted statically by a web browser. Java: Java is a programming language mainly used in an internet-distributed environment, Java is based on C++ language but is much simpler to use and suggests an object-orient model. JSP: JSP (Java Server Pages) is a technology used to control dynamically the content of web pages by using small programs / applications called Servlet. The information is managed, controlled, and changed on the web server first and then displayed in its final shape to the end-user. Servlet: A technology that generates dynamic web pages but differs from JSP. Servlets are precompiled JAVA code blocks. SM: System Module SRS: Software Requirement Specification UCM: Unregistered Client Module UCS: Use-Case Specifications

10. 11. 12. 13.

14.

15. 16. 17. 18. 19. 1.4 References

Robillard and Kruchten, Software Engineering with the UPEDU, Chapter 1, Pearson Addison Wesley, 2002 Time Monitoring Tool - Software Requirements Specifications Version 1.0, cole Polytechnique de Montral, 2002 Time Monitoring Tool - Use Case Specifications Version 1.0, cole Polytechnique de Montral, 2002

1.5 Overview The rest of the SRS document includes an overall description of the EBPP applications, describing interfaces, product functions, characteristics and constraints, as well as other factors that affect the product and its requirements. This is followed by the specific system requirements, including functionality; use case specifications, and any other supplementary requirements.

Confidential

SEIT Team 4, 2004

Page 5

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc>

Version: <1.2> Date: <2004/7/14>

Overall Description

2.1 Product perspective 2.1.1 System Interfaces The system consists of the client module, the server, and the database. The client module has a web based interface, and the client interacts only with this. The server module does not have a user interface except a command to launch it. There are no user interfaces directly to the database, and all database accesses are done from the server. 2.1.2 User Interfaces Users fall into three categories: Biller, Customer, and Administrator. All three users will interact solely through an internet browser. There is no user interface directly to the database or server. 2.1.3 Hardware Interfaces The system must support a terminal that can display a browser with a minimum of 800x600 pixels, specifically a personal computer. 2.1.4 Software Interfaces The CM will run on a web browser, and must support Microsoft Internet Explorer and Netscape. The system will run on a server running JWSDK (including Tomcat) and will use dynamic content technology (Java, JSP, JDBC and servlet). 2.1.5 Communication Interfaces The client communicates with the server over TCP/IP connection to allow users to connect through a web browser using HTTP requests. Both the database and the server should be on the same host. 1.2.6 Memory Constraints Not applicable now. 2.1.7 Operations The operations of the client modules must be easy and intuitive for administrators and EBPP users to use. The server should be maintained without the interaction of other software. No specific technical skill should be needed from a network administrator in order to maintain the system. Backup operations have yet to be defined. Recovery operations due to network failure, user-machine failure, or database failure have yet to be defined. 2.2 Product functions The main function of the EBPP system is to allow Customers and Billers to use a WWW browser to settle transactions online without paperwork. Billers can issue e-bills to customers electronically, and customers can make full or partial payments to specific bills. EBPP also stores a transaction history of previous sent and paid bills. All the bills and transaction history can be displayed in any of the supported languages. E-bill records and user information and configurations are stored in a MySQL database and are updated and altered through interaction with the users browser interface. Further definitions of the components of this project can be found in the Definitions, Acronyms, and Abbreviations section (section 1.3) of this document. 2.3 User characteristics Users are administrators, billers, or clients who should be familiar with Web technology. All users should be knowledgeable about online intake forms, e-mail, and the procedure and security of Confidential SEIT Team 4, 2004 Page 6

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc>

Version: <1.2> Date: <2004/7/14>

online payment. Administrators should have a good understanding of the different components of the EBPP system and should have the ability to maintain and update the database as necessary. 2.4 Constraints The system should enforce user authentication and secure payment processing. 2.5 Assumptions and dependencies Bank account validation, credit card account validation, and transactions depend on Payment Engine. 2.6 Requirements subsets

3 Specific Requirements
3.1 Functionality 3.1.1 Unregistered Client Module (UCM) 3.1.1.1 The user shall be able to load the Unregistered Client Module within Netscape or Internet Explorer. 3.1.1.2 The UCM shall support the registration request from users. 3.1.1.2.1 The initial window of the UCM shall contain a field for a (preferred) user name and a button labeled "New Member - Register". The password field shall be a "secret" field, which does not display what the user types. 3.1.1.2.2 When a user clicks the "New Member - Register" button, the UCM shall send a request to the SM to register the user. 3.1.1.2.3 The UCM shall be able to receive the error message from the SM and display appropriate messages to the user when the preferred user name has been used by another user. 3.1.1.3 If the registration request from a user is granted, the UCM shall display the registration interface. 3.1.1.3.1 The registration interface shall always display the user name of the user currently granted the registration request. 3.1.1.3.2 The registration interface shall contain fields for a password, password verification, the user's first name, last name, e-mail address, telephone number, cell phone number, mailing address; the interface shall also contain a radio button group indicating the identity that the user intends to register as (e.g. Biller or Customer). The password and password verification fields shall be "secret" fields, which do not display what the user types. 3.1.1.3.3 In addition to the components mentioned in 3.1.1.3.2, the registration interface shall contain appropriate fields, choosers, and buttons for the user to fill in his/her credit card type, credit card number, expiration date, bank name, bank routing number, bank account number, and account type (e.g. checking or savings account). 3.1.1.3.4 The registration interface shall also contain two buttons labeled "Cancel Registration" and "Submit", so that when the user clicks the "Cancel Registration" button, the information entered by the user shall not be saved, and the UCM shall go back to the initial window; when the user clicks the "Submit" button, the information entered by the user shall be sent to the SM for further process. 3.1.1.4 When the registration information is verified by the SM, the UCM shall display a confirmation message, informing the user that the registration process has been completed.

Confidential

SEIT Team 4, 2004

Page 7

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc>

Version: <1.2> Date: <2004/7/14>

3.1.2 Biller Client Module (BCM) 3.1.2.1 The user registered as Biller shall be able to load the Biller Client Module within Netscape or Internet Explorer by logging in from Biller Login webpage. 3.1.2.2 The BCM shall support the logging of users. 3.1.2.2.1 The initial window of the BCM shall contain a field for a user name, a field for a password, and a button labeled "Registered User - Login". The password field shall be a "secret" field, which does not display what the user types. 3.1.2.2.2 The BCM shall be able to receive the error message from the SM and display appropriate messages to the user when the user name and password do not match what is saved in the system database. 3.1.2.3 If the logging of a user is successful, the BCM shall display the "Biller - main" interface. 3.1.2.3.1 The "Biller - main" interface shall always display the user name of the user currently logged in. 3.1.2.3.2 The "Biller - main" interface shall contain buttons labeled "Issue Bills", "View Transaction History", "Manage Account Information", "Contact Administrator", and "Logout", so that the user can be directed to the associated webpage to issue bills, view transaction history, manage account information, contact the administrator, and logout by clicking the buttons. 3.1.2.4 The "Issue Bills" interface shall support the entry of new bills. 3.1.2.4.1 The "Issue Bills" interface shall contain a field for the customer's user name, a field for the amount of money (in US dollar) the customer should pay, a field for description of the merchandise/service the customer should pay for, a field for payment due date, a field for the rate of penalty fee (percentage of the balance), and a field for the period of applying the penalty rate (in days). 3.1.2.4.2 In addition to the components mentioned in 3.1.2.4.1, the "Issue Bills" interface shall also contain two buttons labeled "Cancel" and "Submit", so that when the user clicks the "Cancel" button, the information entered by the user shall not be saved, and the BCM shall go back to the "Biller main" interface; when the user clicks the "Submit" button, the information entered by the user shall be sent to the SM for further process. 3.1.2.4.3 The user shall be able to choose to enter the bill in one of the supported languages (e.g. English, Portuguese, Thai, or Turkish). 3.1.2.4.4 When the billing information is verified by the SM, the BCM shall display a confirmation message, informing the user that the billing process has been completed, and the user shall be given a bill number for each bill. 3.1.2.5 The "View Transaction History" interface shall display all the past transaction records of the user. 3.1.2.5.1 Each past transaction displayed on the "View Transaction History" interface shall include bill number, date issued, Customer's user name, amount, merchandise/service description, payment due date, the rate of penalty fee, the period of applying the penalty rate, and payment status. 3.1.2.5.2 The user shall be able to choose to view the transaction history in one of the supported language (e.g. English, Portuguese, Thai, or Turkish). The user shall also be able to sort the history by bill number, by date issued, by Customers' user names, by amount, by merchandise/service description (alphabetically), by payment due date, by the rate of penalty fee, by the period of applying the penalty rate, or by payment status.

Confidential

SEIT Team 4, 2004

Page 8

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc>

Version: <1.2> Date: <2004/7/14>

3.1.2.5.3 The "View Transaction History" interface shall contain a link or navigation button which enables the user to go back to "Biller - main" interface. 3.1.2.6 The "Manage Account Information" interface shall contain editable fields that display all the information the user entered for registration. 3.1.2.6.1 The user shall be able to change any information displayed on the "Manage Account Information" interface except the user name. 3.1.2.6.2 The "Manage Account Information" interface shall contain two buttons labeled "Cancel/Do Not Update" and "Update", so that when the user clicks the "Cancel/Do Not Update" button, the information updated by the user shall not be saved, and the BCM shall go back to the "Biller - main" interface; when the user clicks the "Update" button, the information updated by the user shall be sent to the SM for further process. 3.1.2.6.3 When the updated information is verified by the SM, the BCM shall display a confirmation message, informing the user that the account information has been updated. 3.1.2.7 The "Contact Administrator" interface shall enable the user to send e-mail messages to the administrator regarding disputes, canceling bills, issuing refunds, comments, and other questions. 3.1.2.8 By clicking the "Logout" button, the user shall be directed to a confirmation page indicating that he/she has been logged out, while the BCM sends a logout request to the SM. 3.1.3 Customer Client Module (CCM) 3.1.3.1 The user registered as Customer shall be able to load the Customer Client Module within Netscape or Internet Explorer by logging in from Customer Login webpage. 3.1.3.2 The CCM shall support the logging of users. 3.1.3.2.1 The initial window of the CCM shall contain a field for a user name, a field for a password, and a button labeled "Registered User - Login". The password field shall be a "secret" field, which does not display what the user types. 3.1.3.2.2 The CCM shall be able to receive the error message from the SM and display appropriate messages to the user when the user name and password do not match what is saved in the system database. 3.1.3.3 If the logging of a user is successful, the CCM shall display the "Customer - main" interface. 3.1.3.3.1 The "Customer - main" interface shall always display the user name of the user currently logged in. 3.1.3.3.2 The user registered as Customer shall be able to perform the following actions by clicking on the links or buttons displayed on the interface: pay bills, view transaction history, manage account information, contact administrator, logout. 3.1.3.4 The "Pay Bills" interface shall support the payment of the user's unpaid and partially-paid bills. 3.1.3.4.1 The "Pay Bills" interface shall display all the unpaid and partially-paid bills, the information of which includes bill number, date issued, Biller's user name, amount (in US dollar), merchandise/service description, payment due date, the rate of penalty fee (percentage of the balance), the period of applying the penalty rate (in days), and current payment status. 3.1.3.4.2 The user shall be able to choose to view the bills in one of the supported language (e.g. English, Portuguese, Thai, or Turkish). The user shall also be able to sort the bills by bill number, by date issued, by Billers' user names, by amount, by merchandise/service description (alphabetically), by payment due date, by the rate of penalty fee, by the period of applying the penalty rate, or by payment status.

Confidential

SEIT Team 4, 2004

Page 9

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc>

Version: <1.2> Date: <2004/7/14>

3.1.3.4.3 There shall be a field at the end of each bill listed on the "Pay Bills" interface to enable the user to enter the amount he/she wants to pay for the bill. The interface shall also contain two buttons labeled "Cancel/Do Not Pay" and "Submit Payment", so that when the user clicks the "Cancel/Do Not Pay" button, the information entered by the user shall not be saved, and the CCM shall go back to the "Customer - main" interface; when the user clicks the "Submit Payment" button, the information entered by the user shall be sent to the SM for further process. 3.1.3.4.4 When the payment information is verified by the SM, the CCM shall display a confirmation message, informing the user that the payment process has been completed, and the user shall be given a confirmation number for each payment. 3.1.3.5 The "View Transaction History" interface shall display all the past transaction records of the user. 3.1.3.5.1 Each past transaction displayed on the "View Transaction History" interface shall include bill number, date issued, Biller's user name, amount, merchandise/service description, payment due date, the rate of penalty fee, the period of applying the penalty rate, and payment status. 3.1.3.5.2 The user shall be able to choose to view the transaction history in one of the supported language (e.g. English, Portuguese, Thai, or Turkish). The user shall also be able to sort the history by bill number, by date issued, by Billers' user names, by amount, by merchandise/service description (alphabetically), by payment due date, by the rate of penalty fee, by the period of applying the penalty rate, or by payment status. 3.1.3.5.3 The "View Transaction History" interface shall contain a link or navigation button which enables the user to go back to "Customer - main" interface. 3.1.3.6 The "Manage Account Information" interface shall contain editable fields that display all the information the user entered for registration. 3.1.3.6.1 The user shall be able to change any information displayed on the "Manage Account Information" interface except the user name. 3.1.3.6.2 The "Manage Account Information" interface shall contain two buttons labeled "Cancel/Do Not Update" and "Update", so that when the user click the "Cancel/Do Not Update" button, the information updated by the user shall not be saved, and the CCM shall go back to the "Customer main" interface; when the user clicks the "Update" button, the information updated by the user shall be sent to the SM for further process. 3.1.3.6.3 When the updated information is verified by the SM, the CCM shall display a confirmation message, informing the user that the account information has been updated. 3.1.3.7 The "Contact Administrator" interface shall enable the user to send e-mail messages to the administrator regarding disputes, comments, and questions. 3.1.3.8 By clicking the "Logout" button, the user shall be directed to a confirmation page indicating that he/she has been logged out, while the BCM sends a logout request to the SM. 3.1.4 Administrator Client Module (ACM) 3.1.4.1 The user registered as Administrator shall be able to load the Administrator Client Module within Netscape or Internet Explorer. 3.1.4.2 The ACM shall support the logging of users. 3.1.4.2.1 The initial window of the ACM shall contain a field for a user name, a field for a password, and a button labeled "Registered User - Login". The password field shall be a "secret" field, which does not display what the user types.

Confidential

SEIT Team 4, 2004

Page 10

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc>

Version: <1.2> Date: <2004/7/14>

3.1.4.2.2 The ACM shall be able to receive the error message from the SM and display appropriate messages to the user when the user name and password do not match what is saved in the system database. 3.1.4.3 If the logging of a user is successful, the ACM shall display the "Administrator - main" interface. 3.1.4.3.1 The "Administrator - main" interface shall always display the user name of the user currently logged in. 3.1.4.3.2 The "Administrator - main" interface shall display two groups of buttons, which are for the user management and the billing management. 3.1.4.4 The ACM shall support user management. 3.1.4.4.1 The user management buttons shall include "Add New Administrators" and "Manage User Account Information". 3.1.4.4.2 Clicking the "Add New Administrators" button shall direct the user to the associated interface which enables the user to creating an administrator account by filling the fields with first name, last name, user name, password, password confirmation, and e-mail address. The password and password verification fields shall be "secret" fields, which do not display what the user types. The interface shall also contain two buttons labeled "Cancel" and "Submit", so that when the user clicks the "Cancel" button, the information entered by the user shall not be saved, and the ACM shall go back to the "Administrator - main" interface; when the user clicks the "Submit" button, the information entered by the user shall be sent to the SM for further process. 3.1.4.4.3 When the new administrator account information is verified by the SM, the ACM shall display a confirmation message, informing the user that the registration process has been completed. 3.1.4.4.4 Clicking the "Manage User Account Information" button shall direct the user to the associated interface which enables the user to search a user account by typing the user name, first name, last name, e-mail address, mailing address, telephone number, or cell phone number. The interface shall also provide a link for each returned result, so that clicking the link shall display the corresponding account information. 3.1.4.4.5 The user account information shall be displayed in editable fields with all the information the said user entered for registration, along with user identity (e.g. Biller or Customer), and the administrator shall be able to change any information displayed on the interface, which shall also contain two buttons labeled "Cancel/Do Not Update" and "Update", so that when the administrator clicks the "Cancel/Do Not Update" button, the information updated by the administrator shall not be saved, and the ACM shall go back to the "Administrator - main" interface; when the administrator clicks the "Update" button, the information updated by the administrator shall be sent to the SM for further process. 3.1.4.4.6 When the updated information is verified by the SM, the ACM shall display a confirmation message, informing the administrator that the said user's account information has been updated. 3.1.4.5 The ACM shall support billing management. 3.1.4.5.1 The billing management buttons shall include "View Transaction History" and "Revoke Transaction". 3.1.4.5.2 Clicking "View Transaction History" button shall direct the user to the associated interface which enables the user to search a bill by typing the bill number, Biller's user name, Customer's user name, and date issued, amount, payment due date, and current payment status. The interface shall also provide a link for each returned result, so that clicking the link shall display the corresponding transaction record.

Confidential

SEIT Team 4, 2004

Page 11

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc>

Version: <1.2> Date: <2004/7/14>

3.1.4.5.3 Clicking "Revoke Transaction" button shall direct the user to the associated interface which enables the user to search a bill by typing the bill number, Biller's user name, and Customer's user name. The interface shall also provide a link for each returned result, so that clicking the link shall display the corresponding transaction record and a button to revoke the transaction. 3.1.4.5.4 The transaction record shall be displayed with all the information of the bill, and the appropriate interface components which enable the user to cancel an unpaid bill, issue a refund for a paid or partially-paid bill, update the payment status, or delete the transaction record. The interface shall also contain two buttons labeled "Cancel" and "Submit", so that when the user clicks the "Cancel" button, the information updated by the user shall not be saved, and the ACM shall go back to the "Administrator - main" interface; when the user clicks the "Submit" button, the information updated by the user shall be sent to the SM for further process. 3.1.4.5.5 When the updated information is verified by the SM, the ACM shall display a confirm message, informing the user that the transaction has been updated or revoked. 3.1.5 System Module (SM) 3.1.5.1 The SM shall be the only intermediate between the client modules and the database. 3.1.5.2 The SM shall receive all the requests from the client modules and format the interface/ WebPages. 3.1.5.3 The SM shall accept all connections from the client modules. 3.1.5.4 The SM shall verify and execute all requests coming from the client modules. 3.1.5.5 Any error of verification, execution, communication or else shall be identified, and appropriate messages shall be sent to the client modules or to the users via e-mail. 3.1.5.6 The SM shall try to recover from most common errors. 3.2 Use-Case Specifications Refer to the document "Use-Case Specifications". 3.3 Supplementary Requirements None

4. Classification of Functional Requirements

Functionality 3.1.1.1 3.1.1.2.1 3.1.1.2.2 3.1.1.2.3 3.1.1.3.1 3.1.1.3.2 3.1.1.3.3 3.1.1.3.4 3.1.1.4 3.1.2.1 3.1.2.2.1 Type Essential Essential Essential Essential Essential Essential Essential Essential Essential Essential Essential

Confidential

SEIT Team 4, 2004

Page 12

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc>
3.1.2.2.2 3.1.2.3.1 3.1.2.3.2 3.1.2.4.1 3.1.2.4.2 3.1.2.4.3 3.1.2.4.4 3.1.2.5.1 3.1.2.5.2 3.1.2.5.3 3.1.2.6.1 3.1.2.6.2 3.1.2.6.3 3.1.2.7 3.1.2.8 3.1.3.1 3.1.3.2.1 3.1.3.2.2 3.1.3.3.1 3.1.3.3.2 3.1.3.4.1 3.1.3.4.2 3.1.3.4.3 3.1.3.4.4 3.1.3.5.1 3.1.3.5.2 3.1.3.5.3 3.1.3.6.1 3.1.3.6.2 3.1.3.6.3 3.1.3.7 3.1.3.8 3.1.4.1 3.1.4.2.1 3.1.4.2.2 3.1.4.3.1 3.1.4.3.2 3.1.4.4.1 3.1.4.4.2 3.1.4.4.3 3.1.4.4.4 3.1.4.4.5 3.1.4.4.6 3.1.4.5.1 3.1.4.5.2 3.1.4.5.3 3.1.4.5.4 Essential Desirable Essential Essential Essential Essential Essential Essential Essential Essential Desirable Desirable Desirable Essential Essential Essential Desirable Essential Essential Essential Essential Essential Essential Essential Essential Essential Essential Desirable Desirable Desirable Essential Essential Essential Essential Essential Desirable Essential Essential Desirable Desirable Desirable Desirable Desirable Essential Desirable Desirable Desirable

Version: <1.2> Date: <2004/7/14>

Confidential

SEIT Team 4, 2004

Page 13

EBPP - Electric Bill Presentment & Payment Software Requirements Specifications <791_SRS_04.doc>
3.1.4.5.5 3.1.5.1 3.1.5.2 3.1.5.3 3.1.5.4 3.1.5.5 3.1.5.6 Desirable Essential Essential Essential Essential Essential Desirable

Version: <1.2> Date: <2004/7/14>

5. Appendixes

Confidential

SEIT Team 4, 2004

Page 14