Software Requirement Specification Report

Purpose of Project
This project is part of the requirement in completing the Software Engineering course, which is a module in the Bachelor of Science degree program done at ASeT / EXED in Kingston, Jamaica, for the period 2002-2004. The purpose of the project is to demonstrate the application of software engineering in a practical scenario and to prove full understanding of the subject and its function and relevance.

Project Definition
This project is aimed at creating an island wide computerized telephone call-time purchasing system in Jamaica for pre-paid cellular service. The system is aimed at making it possible to use any credit or debit card for the purchase of cellular telephone call-time. There are many Automated Teller Machines (ATMs) all over Jamaica. They all accept credit and debit cards. They are open and accessible 24 hours a day. As a result, this technology can be utilized to make it easier to access credit for pre-paid cellular telephone calls. This project aims to achieve that goal.

Description of Existing System & Problems

There are three major cellular telephone companies in Jamaica one of which offers land line service. However, the problem is with the cellular service for pre-paid customers. There are several packages for service and payment. The most common of which is the pre-paid service. The pre-paid service is the most economical to consumers. It allows a customer to own a telephone and can always receive calls free of any charge. To make calls, the customer has to purchase call-time in advance as opposed to making calls and paying a bill at the end of the month. To obtain credit each Page 1 of 15

company produces a separate card. Cards have different monetary values. Each card has a unique id number. Each company installs an automated telephone service that, accepts a call, validates the id given and applies the appropriate credit to the customers account. After this the customer can make calls until the credit expires. The problem that arises is that places which sell phone cards are numerous but most are closed late at nights and on public holidays to include Sundays. As a result people are forced to ensure they have credit in advance for these occasions. Notwithstanding, credit often runs out, which is a problem and inconvenience in emergencies. This project is based on utilizing present technologies of available ATMs and making it possible for customers to gain credit anytime and anywhere there is an ATM by using a credit or debit card.

Scope of Project
The project will utilize available resources and will not require the purchase of additional equipment. No additional personnel will be required by the telephone companies or banks. Only available ATMs will be used. The project is aimed at aiding cellular telephone owners, who have pre-paid packages and are capable of using an ATM. They should not be visually impaired and they should be able to read. The project is not for bill payment, only purchase of advance talk-time. Talk-time credit will be subject to the same conditions as applicable to cards. This includes limited duration after purchase to utilize the credit. The minimum credit will be the same as cards ($50) and have no maximum limit as opposed to cards. For persons with credit or debit cards where ATMs are accessible, this system will eliminate the need for phone cards. However, for customers who do not have credit or debit cards, they will have to continue purchasing phone cards. Also, in areas where there is no ATM, phone cards will be necessary. So, this project will not eliminate but minimize the need for phone cards which is costly to produce. Telephone companies will benefit from the reduced costs. When a customer

Page 2 of 15

attends an ATM for other transactions, time and money can be saved by performing telephone transactions at the same time and place. Customers will be required to be in good standing with their banks and have sufficient funds to use the service successfully. No new interface will be setup ATMs, only an additional item on the menu to purchase call-timer credit. One will only need to follow the instructions as with other transactions. No experience, training or change in procedures will be required.

Functional Requirements
a) Pre-requisites Activated credit/debit card with PIN (Personal Identification Number) A bank a/c with sufficient funds if using debit card ($100 or more) A cellular telephone with pre-paid service from a local provider b) Input Requirements 7 digit telephone # Dollar quantity of credit required Telephone company name/id Telephone company a/c # Telephone # to call respective phone company c) Output Requirements Transfer of correct sum from customers a/c to Telephone companys a/c Transaction receipt Credit automatically added to customers phone a/c d) Procedure (Operation of System) Use appropriate card at ATM to access system Select option of Phone Credit from main menu Select a/c to use depending on type of card Select phone company from list Page 3 of 15 For use of ATM

 Enter customer telephone #. The system will call the phone company and check its db to verify the validity of the given phone number and a/c type. Enter credit amount required. The system will check balance of the customers a/c for sufficient funds. The system will automate a transfer of funds from customers to phone companys a/c. Production of receipt will signal end of transaction. Appropriate error messages where applicable.

Non-Functional Requirements
a) Developmental Constraints The system will depend on the existing banking services provided at ATMs. However, minor additions will be made to accommodate the phone service. It involves being limited to the interface of ATMs in terms of screen size, option buttons, locations and working with the systems of the bank and telephone companies. The user interface will have to be consistent with that of the banks. Permission must also be granted by these entities. The telephone companies must have accounts for transfers to be made. The system of the phone companies must also be configured to accept the transactions by adding the time paid for to respective telephone accounts. The systems of the banks, telephone companies and call-time purchasing must be integrated to work. b) Constraint on Services The only service the system will provide is that of call-time. It will be restricted to pre-paid customers because that is where the problem is confined. It is not for bill payment for calls already made. Customers must make a minimum purchase ($50), which for economy must exceed tax and charges.

Page 4 of 15

c) Data Constraint Most data requirement will be built-in. Only telephone # and a dollar amount in figures will be required as input by the customer, which will be subject to validation. A minimum sum is required but no maximum or increments. d) Time Constraint The system is confined to be completed in less than 2 months. The team only had a part of each weekend to develop the project. A schedule was worked out and described in the schedule feasibility. Teams were also small, which made it even more challenging. This team only has to persons.

System Design
Architecture of Application

Customer Input data, get receipt & credit ATM Verify a/c, update a/c DB

Bank

Phone Co.

DB Verify Ph. #, assign credit

Page 5 of 15

Dataflow Diagram

Customer

Visual displa y confir m

Bank ATM Services Select Ph. Co. Enter Ph. # Select a/c Enter $ amt.

Check customer a/c bal.

Update customer bank bal.

Verify Ph. #

Update customer Credit a/c

Transaction receipt

Tables Customer Card# phone# phone id

Phone Co. Phone id name

Developer a/c # bank name

Card Customer card# Bank Name card id PIN bank id

Phone Phone # a/c Name a/c # owner name time bal.

Page 6 of 15

ERD

Phone# has Belongs to

Customer performs has

Transaction

Phone Co

Bank

a/c

has

joins

Belongs to

Unique Ph. id

Developer

Card

Data Dictionary Entity Customer Name Card# a/c# phone# PIN Ph. Co. Ph id # Name Developer a/c# bank name A/c
Owner name a/c #

Field Type Primary Foreign Foreign Foreign foreign primary

Data Type Integer

Relationship 1:M

Integrity Not Null NN NN NN NN

Description

Assigned by bank Ph Co bank

chosen by custom Chosen by ph. Co

1:M Alphanum. string integer Foreign Primary 1:M Foreign Primary String integer NN NN
Ass. At creation Generated by bank

NN NN 1:M NN

string

Assigned by bank Chosen by develop.

Page 7 of 15

Phone Phone #
Owner name

1:M Primary foreign Integer String time 1:M Primary Foreign primary Primary foreign Integer 1:M String Integer NN NN
Chosen by bank Gen. by bank

NN NN Unlimited NN

Ass. By ph. Co. Adopted from owner Gen. by ph. Co.

Time bal. Card Card# a/c# PIN Bank Name Card id#

Ass. By bank Gen. by bank Ass. By customer

start B end
no yes

end

Input card & PIN at ATM

Select phone option

Select phone Co.

Input phone #

Page 8 of 15

Dial unique ph. id for company

Access ph. Sys. db no Is Ph. # valid yes no Is card a debit card yes Select a/c Input $ amt. Access customer a/c from banks db yes C Is sufficient funds in a/c Error message B

no

Page 9 of 15

Dial ph. Co. unique #

Access ph. Sys. db

Update customer call-credit

Access a/c of ph. Co. and update a/c

Access a/c of developer and update a/c

Inform user of a/c phone call-time update

Print receipt

Page 10 of 15

***Prototype****** Testing
Black box Testing The system will be tested independently of the developers using all possible data values (valid and invalid) to ensure that the correct results are obtained at all times. The system can not be allowed to do anything undesirable because a lot of money can be lost. White box Testing The logics of the system will be put to the full test. The software must integrate and interact with the other systems as desired. The logics must be free of fault. There should be no way that the system can be manipulated by anyone. Integration Testing How the system works with that of the banks and phone companies will be put to rigorous testing. There should be no undue delay, crash or errors. The software must work as expected with each of the other systems. System Testing

The entire system when integrated must be harmonious and produce the desired results. It must be fast and produce good error messages where applicable. Any logical or system error which was undetected before must be ironed out at this last stage.

Page 11 of 15

Feasibility Study Report

Technical Feasibility
The main technical issue is how the system will contact the telephone companies to access their db. The rationale is that the ATMs of different banks integrate by using the online concept. Since the ATMs are already networked via telephone lines then a simple phone call from the ATM to a phone company can access their system and db. Providing the banks and phone companies agree, then only minor modifications are required to both systems. The phone company will be required to accept a call with special parameters, verify given telephone number and update a customer call-time credit. The banks system must include an option for phone transaction, and in addition to its present checks update bank and developer a/c. The software will have to be implemented on the banks h/w and be an integral part of its ATM software which is already in place. The phone companies already have the technical expertise to upgrade their system and the development team is sufficiently skilled.

Operational Feasibility
Anything that will make life more comfortable is worth pursuing. The experience of this development team is sufficient proof that customers are experiencing difficulties obtaining cards at nights and public holidays to include Sundays. This system stands to benefit the phone companies significantly. If they can make more sales during slow periods, at practically no cost, there is no way they will refuse. The banks will receive payment for the use of their machines and system, which is fair. The developers will also earn per transaction. The system Page 12 of 15

is not complex and is a minor addition to existing systems. It is a win situation for all concerned and is not expected to be refused as the economic gains can be significant.

Schedule Feasibility
The limited time period only allowed a part of each weekend to be made available to this project. As a result there was insufficient time to tackle coding. The following time table was worked out.

Time Table
Task Planning Analysis System Design System Prototyping Coding System Testing (explanation) Time Period (wks)

05.06.2004 11.06.2004 (1) 12.06.2004 18.06.2004 (1) 19.06.2004 09.07.2004 (2) 10.07.2004 22.07.2004 (1) N/A 23.07.2004

Economic Feasibility
Intangible Benefits While all parties stand to benefit, the financial gains are not projected to be great. The convenience to customers is expected to be the most significant benefit. When customers are comfortable they invest more, which will benefit the investors. Tangible Benefits

Page 13 of 15

The cost of the project is estimated to be $120,000.00 for the main software being provided by the developers. The phone companies and banks have an interest in the project because they stand to benefit. The phone companies will have increased sales and the banks will earn a commission on each transaction. They will also maintain their machines. Modification to the systems of the banks can be done by the developers or by their own experts at no extra cost to the developers. A rough estimate of the costs is as follow: $50 $10 $10 $10 $80 min. phone credit bank charge tax (20% of phone credit) developers charge total

Customers will find it costing less for larger purchases. The bank and phone companies will compensate for their costs from their benefits. At 15% tax on earnings, the developers stand to gain minimum $8.50 per transaction. There are well over 1.5m cellular phones of which about 2/3 are pre-paid services (1m). Almost all phone owners have bank accounts and debit cards. It is reasonable to assume that there will be at least 1000 phone transactions at ATMs per month among the phone companies. At 8.5 * 1000 * 12 yields $102,000 per annum for the developers giving a payback period of under 2 yrs. And thereafter, pure profit, which will be for the life cycle of the software. The project appears viable.

Page 14 of 15

Implementation Plan
Arrange with bank to conduct system test to ensure that integration is smooth. First a Sunday will be chosen to do acceptance testing. This is a day when the machines are least used. Prepare conversion plan: To stay on the side of caution the smallest bank will be selected and the system implemented cold turkey method because of its simplicity. The system will be constantly monitored over its infancy. Training schedule will be prepared for bank and telephone companies. There is no db to implement. The db of the bank and phone company is all that is needed. Train internal users at bank and phone companies as to how the system works. Actions in case of problems and complaints. The likely problems that may occur. The developers are the owners of the system and will be on call to rectify faults. Training will be limited as there will be no significant change to the system in place, but to explain how the various accounts will be updated automatically and how to interpret these information for customers. All bank staff must be made acquainted so this will take some time and based on the number of banks seminars over a 2 months period will be implemented. Execute implementation plan in the order of training, acceptance testing, cold turkey execution and maintenance.

Conclusion & Recommendation

From the feasibility studies carried out it is conclusive that the project is feasible and will be economically viable. All parties involved including the customers stand to benefit. As a result it is the recommendation of this development team that the system can be completed and implemented.

Page 15 of 15