virtual shopping and payment processing centre

University of Portsmouth

Technology Extended Campus

Master’s project undertaken in partial fulfilments of the requirements for the

MSc Degree in Internet Systems Development

Virtual Shopping and Payment Processing Centre

by

Srđan Popović

HEMIS No. 353328

Supervisor: Mr M.J. Lynch

Project unit code: PJ60P December 2007

Volume 1 – Project Report

University of Portsmouth

Technology Extended Campus

Master’s project undertaken in partial fulfilment of the requirements for the MSc Degree in Internet Systems Development

Virtual Shopping and Payment Processing Centre

by

Srđan Popović

HEMIS No. 353328

Supervisor: Mr M.J. Lynch

Project unit code: PJ60P December 2007

Volume 1

Abstract This project is about providing economically viable business-to-consumer e-commerce capability to micro and small enterprises in middle income countries. The report outlines why these companies are not using standard e-commerce practices as used in developed countries and describes a solution involving a virtual shopping centre with product presentations submitted directly by shops. The requirements for this application are obtained through interviews with small shops and analysis of their business practices, legal obligations and restrictions. These requirements have been analysed using UML notation, with use cases and sequence diagrams, and they have lead to a full system design. The application was developed and tested. The report concludes that, although there is a room for improvement and implementation of additional features, this application would provide added value for micro and small enterprises requiring ability to offer their products over the Internet without prior investment. As the application is build around the idea of a potentially profitable business model, for an online service provider it could represent a significant business opportunity. Keyword List E-commerce, development, developing countries, micro enterprises, small enterprises, shops, shopping, retail, payment processing

Acknowledgements I would like to thank interview respondents for all the hours they have spent providing valuable information and insight that helped determine software requirements for this project. I would like to thank my project supervisor, Mr Mike Lynch, for all the guidance and advice. I would like to thank my wife, Marinês Bortolete Popović, for her continued support in making this possible.

Declaration I confirm that the enclosed assignment including any associated software is entirely my own work except where explicitly stated otherwise. I further declare that when such other work is used it only supports my own work and its inclusion is in accordance with normal scholarly conventions. Signed: __________________________________ Date ___________

Table of Contents Abstract .............................................................................................................................................................. 1 Keyword List....................................................................................................................................................... 1 Acknowledgements ............................................................................................................................................ 2 Declaration ......................................................................................................................................................... 3 Table of Contents............................................................................................................................................... 4 List of Figures..................................................................................................................................................... 5 1 Introduction .................................................................................................................................................. 6

1.1 Background..........................................................................................................................................6 1.2 Problem Definition ...............................................................................................................................6 1.3 Speculation of Problem Causes and Possible Solution Routes ...........................................................6 1.4 Personal Theory on the Best Solution Route .......................................................................................7 1.5 Real World Target................................................................................................................................7 1.6 Application Description ........................................................................................................................7 1.7 Expected Project Outcome ..................................................................................................................8 1.8 Project Scope, Constraints and Boundaries ........................................................................................8 1.9 Project Aim ..........................................................................................................................................9 1.10 Project Objectives................................................................................................................................9 1.11 Logistics...............................................................................................................................................9 1.12 Risk....................................................................................................................................................10 1.13 Values................................................................................................................................................10

2 Background Literature Review ....................................................................................................................11 2.1 Introduction........................................................................................................................................11 2.2 Obstacles to E-Commerce.................................................................................................................11 2.3 An Urban Phenomenon .....................................................................................................................11 2.4 Technical and Financial Resources ...................................................................................................11 2.5 Online Credit Card Payments ............................................................................................................12 2.6 Foreign Markets.................................................................................................................................12 2.7 Other Obstacles.................................................................................................................................12 2.8 Earnings Potential..............................................................................................................................13 2.9 Summary ...........................................................................................................................................13

3 Requirements Collection Process ...............................................................................................................14 3.1 Interviews...........................................................................................................................................14 3.2 Adjacent Systems ..............................................................................................................................15 3.3 Standards ..........................................................................................................................................15 3.4 Legislation and Legal Issues..............................................................................................................16 3.5 Best Practice E-Commerce Solutions................................................................................................17 3.6 Payments, Guarantees and Trust ......................................................................................................18

4 Requirements Model ...................................................................................................................................20 4.1 Functional Requirements ...................................................................................................................20 4.2 Non-Functional Requirements ...........................................................................................................21

5 Further Requirements Analysis and Preliminary Design Choices ...............................................................25 5.1 Elaboration on Technology Requirements .........................................................................................25 5.2 From Use Cases to Programming Code: Using UML Sequence Diagrams .......................................25

6 System Design............................................................................................................................................28 6.1 Database ...........................................................................................................................................28 6.2 Interface.............................................................................................................................................28 6.3 Application Programming...................................................................................................................28

7 Testing ........................................................................................................................................................31

8 Implementation ...........................................................................................................................................32 9 Evaluation ...................................................................................................................................................33

9.1 Evaluation of Project Product.............................................................................................................33 9.2 Evaluation of Practice and Methods ..................................................................................................34

10 Conclusions ................................................................................................................................................36 11 Future Work ................................................................................................................................................37

11.1 Payments and Finances ....................................................................................................................37 11.2 Functional Requirements and Interface .............................................................................................37 11.3 Implementation ..................................................................................................................................37 11.4 Research ...........................................................................................................................................37 11.5 Testing...............................................................................................................................................37 11.6 Outreach............................................................................................................................................37 11.7 Business Planning .............................................................................................................................38 11.8 Other..................................................................................................................................................38

12 References..................................................................................................................................................39 13 Table of Contents of Volume 2 (Appendices)..............................................................................................42 List of Figures Figure 1.1: Examples of minimal fee structure for existing e-commerce options available to small shops..........6 Figure 1.2: Broad overview of activities by user class .........................................................................................7 Figure 3.1: Triangle of Trust ..............................................................................................................................19 Figure 5.1: Struts Sequence Diagram ...............................................................................................................26 Figure 5.2: Simplified Sequence Diagram for Requirements Analysis ..............................................................27 Figure 6.1: Global Relations Diagram for Project Database..............................................................................29 Figure 6.2: Web application start page with sample products and shops..........................................................30

of 43 – Srđan Popović HEMIS No. 353328 Submission Date: 2007/12

1 Introduction 1.1 Background With the increasing competition in application development, Web hosting and credit card processing services, the cost of selling goods and services online has been reduced to the level broadly acceptable to micro and small enterprises (MSE) in the developed world, even to those for whom the Internet is not the primary market. However, their counterparts in developing countries typically have smaller sales in hard currency terms and these costs represent a greater percentage of their revenue. UNCTAD (2004, p. XX) report identifies perceived lack of profitability as the main reason for low adoption of information and computer technologies (ICT) among small companies in developing countries. This clearly applies to e-commerce, where existing solutions require

• advance setup fees, • regular fixed payments and • transaction processing fees

(see Figure 1.1), and where due to lower Internet penetration and less common use of credit cards locally oriented MSEs have smaller potential markets. With weak chances of profitability, reluctance to make advance investment is understandable. It is important to mention that the term “developing countries” is very wide. While the heavily indebted poor countries (HIPC) do not meet basic preconditions for successful implementation of e-commerce (Oderdra-Straub, 2003, pp. 1-2; Verhovek, 2000), middle income countries (MIC), as defined by their income per capita by the World Bank (2006a), in general have the necessary electronic, transport and payment infrastructures, in particular in urban areas. 1.2 Problem Definition Expected return on investment in business-to-consumer (B2C) e-commerce for MSEs in developing countries is in most cases below the point of economic viability. 1.3 Speculation of Problem Causes and Possible Solution Routes As mentioned above, this problem is caused by investment expenses being high in comparison to income expectations within small potential markets. How can these investment costs be reduced? The services needed for implementation of B2C e-commerce cannot be offered for free or below market cost as they themselves require investments and work. Common sense would tell us that a sustainable solution has to be within market economy principles. Could the service providers offer B2C infrastructure to MSEs in return for a percentage of sales revenues, instead of fixed amounts? Yes, but if individual MSEs are reluctant to make investments because of low profitability potential, why would service providers take this risk?

Figure 1.1: Examples of minimal fee structure for existing e-commerce options available to small shops Source: see Appendix F.

Virtual Shops: Yahoo Small Business Solutions: $39.95/month + $50 setup + 1.5% transaction fee Amazon Webstores: $59.95/month + 7% sales fee Network Solutions: $49.95/month + $49 setup fee + fees for credit card payments with external partners eBay ProStores: $29.95/month + 0.5% commission

Auctions and Many-to-Many E-Commerce Sites: eBay: Insertion fee from $0.20 to $4.20 per item + up to 5.25% final value fee Etsy.com: Insertion fee $0.20 per quantity of one + 3.5% commission


1.4 Personal Theory on the Best Solution Route Solution has to be in economies of scale. If a large number of high-risk individual enterprises would share common resources the new platform would represent a low-risk enterprise. 1.5 Real World Target To build a web application providing virtual shopping centre facilities and B2C e-commerce capability to MSEs in middle income countries. 1.6 Application Description The main characteristics of the proposed application are the following:

• It will an international virtual shopping centre. • It will be a single global online application. • It will be permanently open to participation of new shops, however, they will have to go through

registration and approval process by the shopping centre administration. • The shoppers will be able to browse or search for products by keyword, category, shop, country or

product description language. • All product information will be submitted by the participating shops. • The shops will be responsible for product delivery. • The shopping centre will be responsible for managing financial transactions. • It will have capacity for accepting credit card payments. • It will enable management of shop cash accounts. • There will be no setup or participation fees. • The solution would be financed through a small percentage of each sale. • In case of no online sales, there would be no cost for MSEs. • As there would be no required minimal sales volume, this could also be used by MSEs that expect only

sporadic Internet sales. The diagram below provides a very broad overview of activities by user class.

Figure 1.2: Broad overview of activities by user class

Shoppers: search for products browse product categories browse shops register and sign in add a product to their shopping cart go to checkout and pay request more information complain or return products view account details with orders and payments history

MSEs: apply for a virtual shop provide background and contact information add, remove and modify their products receive orders from shoppers confirm shipments of ordered products view their account request payment via bank transfer, check or credit view account details with orders and transfers history

Shopping centre administration: approve or deny applications for virtual shops allow or reject product presentations charge shoppers’ credit cards apply commission send money to MSEs mediate in case of conflict (between MSEs and shoppers) view all data


The major differences between the project application and existing e-commerce sites with multiple buyers and sellers, for example eBay.com, Etsy.com or MercadoLibre.com.br, can be summarized as follows:

Other sites: • Charge commission on sales. • Charge virtual shops for placement of their products.

(This fee depends either on product price or on the quantity of items.) • Do not provide any money return guarantees to the shoppers.

(All guarantees are responsibility of participating shops only.) • Require participating shops to have credit cards or PayPal accounts.

This application: • Will charge shops only commission on successful sales. • Will require participating shops to have bank accounts only (where they could receive money from

the shopping centre administration). • Will provide money return guarantee to the shoppers. • This will be based on shopping centre administration withholding payments during guarantee period

defined by law in administration’s legal residence. • In cases when this is not acceptable by participating shops, it will be based on commission

premium or security deposits. 1.7 Expected Project Outcome The application will provide MSEs with an affordable solution for B2C e-commerce. For many of them the ability to offer their goods over the Internet without prior investment could provide financial benefits. For an entity prepared to invest in application commercialisation and implementation this could represent a business opportunity. 1.8 Project Scope, Constraints and Boundaries The requirements collection and analysis process will without doubt lead to identification of a large number of potentially desirable components and functionalities (see below), but in the project application, due to time constraints, only the essential functionality will be implemented. However, potential for future work will be indicated. Examples of project restrictions include, but are not limited to, the following:

1. The application interface will be in English language only. Participating shops will decide on the language in which they wish to present their products. The commercial application would have to provide interfaces in at least several languages, including the widely spoken ones like Spanish, French or Portuguese. Mechanisms for interface localisation will be explained.

2. Options for delivery cost will be limited.

The cost of delivery will be provided by shops, however, the only options that will be allowed will be for sending items within the same town, country or internationally. There will be no further price differentiation based on delivery methods or speed.

3. There will be no customer targeting.

Customer shopping preferences will not be analysed and used for offer customization.

4. Help and tutorials will contain only placeholder text. Most elements of the application interface will have a link to appropriate help items, however, due to time restrictions the actual content for these sections will not be written. While a comprehensive help manual is an important part of the final application, it will not be written within the project and will be left for future work.


5. Maximum of one photograph per product will be allowed.

6. Credit Card verification and processing will only be simulated. The full implementation of the application would require creation of multiple Internet Merchant Accounts for at least the most popular credit cards. Other options are to work in cooperation with, or to outsource this task to, existing banking or payment institutions. In all cases the credit card data would be passed to external systems for verification and payment collection. Within the University project there will be only a simulation of this data being sent and processed.

7. Outgoing payments will also only be simulated.

In the commercial implementation information on payments to shops would be sent to financial staff or to a bank. In the project application they will only be recorded into the database and as of that moment will be considered executed. The same applies for returning money to the customers.

8. Credit card payments in partial instalments will not be supported.

Although a very popular feature, this would add unnecessary complexity to the academic project and it can be implemented at a later stage.

9. For development purposes all server software and data will be located on one machine.

Separation of tasks would increase application performance. Furthermore, in order to meet Payment Card Industry Data Security Standards it is necessary to store customer credit card information on a computer behind a firewall and not on the same server as the web application. Nevertheless, for development and demonstration purposes all databases will be on the same server.

10. The project will not use SSL certificates.

Use of SSL is necessary for confidential transmission of customer data, however no actual certificates will be purchased or installed for the demonstration.

1.9 Project Aim To create a web application based on client-controlled content, enabling access to business-to-consumer e-commerce to micro and small enterprises in middle income countries. 1.10 Project Objectives

• To produce requirements model with use cases for all user classes and list of all requirements (Chapter 4 and Appendix I)

• To produce a functional design of the e-shopping centre (Chapters 5 and 6 and Appendix K) • To design and document database (Section 6.1 and Appendix L) • To design web interface (Section 6.2 and Appendices M and N) • To produce full source code listings (Appendix O) • To produce Javadoc report for the source code (accompanying CD) • To produce application testing report (Chapter 7 and Appendix P) • To product implementation guidelines (Chapter 8) • To produce application evaluation report (Chapter 9) • To deliver full project report

1.11 Logistics The requirements collection process will include interviews outside the author’s town of residence and all travel arrangements have been made. The application will be developed on Dell Workstation under MS Windows XP environment. All development tools, such as Tomcat, NetBeans, MySQL as well as image editing and Web design software have been installed. Virtual Web server and Internet domain, to be used for demonstration purposes, have been purchased.


1.12 Risk This is a large project involving a complex application, so providing the results in time represents a challenge. For this reason, they will be built in a way that enables future developments. 1.13 Values This project is built around the values of free enterprise and market economy, where rational users can choose a cost-efficient and risk-free solution.


2 Background Literature Review 2.1 Introduction Although it is widely accepted that small and medium enterprises “play a major role in the economies of developing countries” (Oderdra-Straub, 2003, p. 2) and although UNCTAD (2004, p. XX) report points out that small companies “have been found to have the greatest potential for productivity gains through e-business”, the latter report explains that the main beneficiary of e-commerce in the developing world are large enterprises. This view is supported by UNCTAD (2005, p. XVII) report that shows that the “proportion of enterprises selling online decreases with size” as well as by recent articles by Sharma (2006, pp. 627-630) and Toland (2006, pp. 309-311). For small companies “in many cases Internet use is limited to the owner or managers” (UNCTAD, 2004, p. XX), and their “main use of the Internet is for email; there is relatively little business-to-consumer e-commerce.” (Toland, 2006, p. 310). Even in rare occasions when micro and small companies in developing countries do have their websites this tends to be for presentation purposes only and it is indeed very unusual to see that they directly sell their products or services online. 2.2 Obstacles to E-Commerce What are the main obstacles for successful implementation of B2C e-commerce by micro and small enterprises in developing countries? Some of the reasons mentioned in literature (Sharma, 2006, pp. 627-628; Toland, 2006, p. 310; Humphrey, Mansell, Paré & Schmitz, 2003, p. 34) are:

• high cost of technical infrastructure, • poor transport infrastructure, • unreliable postal service, • unstable power supplies, • inadequate payment systems and • lack of technical knowledge.

However, as mentioned in the introduction chapter, the term “developing countries” is very wide as they range from middle income countries in most of Latin America, East Europe and parts of Asia to low income and heavily indebted poor countries, mostly in Africa. Oderdra-Straub (2003, pp. 1-2) echoes the famous view of Bill Gates (Verhovek, 2000) and explains that most of the poorest countries are not ready to benefit from almost any form of e-commerce and that these opportunities apply only to “more advanced developing countries” or “emerging economies”. It would be difficult not to agree with this point as the power, telecommunications, banking and transport systems in the poorest countries are below necessary thresholds, while in the middle income countries they are much better developed and cause less obstacles to e-commerce. 2.3 An Urban Phenomenon Another geographic limitation is related to location within the country. Toland (2006, p. 312) argues that in the developing countries “business-to-consumer e-commerce growth will be largely an urban phenomenon, and rural areas will participate at much lower rates”. While the rural areas may have less developed supporting infrastructure, the importance of this limitation is diminished by the fact that, according to the World Bank (2006b, p. 166), in most middle income countries and in particular in Latin America and Eastern Europe over 80% of the population lives in cities. Nevertheless, even in urban areas of more advanced developing countries there are barriers to adoption of B2C e-commerce by micro and small enterprises. Let us look further and try to identify them. 2.4 Technical and Financial Resources Many authors (Sharma, 2006, pp. 626-628; Toland, 2006, pp. 310-311; Egea & Menéndez, 2006, p. 532) agree that one of the main problems is the high cost of technical infrastructure. Resources required for

• server hardware, • development or purchase of software applications,


• connectivity and • hiring or training of staff

are beyond the financial capabilities of most micro and small enterprises in developing countries. Furthermore, they cannot borrow the money at reasonable rates as their access to growth capital “is not only limited but often prohibitively costly” (World Bank, 2006c, p. 2). The cost of leased lines to the Internet in many developing countries is very high, in particular for connections to international backbones. Nicol (2003, p. 37) shows that while the cost of basic and broadband access to the Internet is comparable with the developed countries, having an international leased line is several times more expensive as these prices are “kept artificially high in unliberalised markets” (Nicol, 2003, p. 37). Tigre & O’Connor (2002, p. 17) point to “natural monopolies” and explain that many countries have recently privatized their telecommunication services, yet in order to achieve desired privatization price they have guaranteed monopoly position to private sector buyers. While it is unlikely that the cost of leased lines is going to be significantly reduced in the near future, we have to ask ourselves how important is this for micro and small enterprises? Even a quick Internet search can reveal a number of other available options. For instance, setting a B2C e-commerce website with a well known provider in the developed world, like Yahoo or Network Solutions, is possible at the fraction of the above described costs. 2.5 Online Credit Card Payments Toland (2006, pp. 310-311), Mann (2000, pp. 7-8) and Sharma (2006, p. 628) point out that one of the barriers is the lack of ability to process credit card payments. However, credit card processing can also be provided by a number of international companies, often as part of e-commerce web hosting packages. Of greater importance is the fact, explained by the same authors, that the credit cards have a very low penetration in developing countries and the customers are not used to online purchasing. Toland (2006, p. 311) explains that “in order for e-commerce to take off the number of users needs to reach a critical mass”. It is easy to agree that the precondition for more significant participation in e-commerce by companies in developing countries is to have a growing number of customers capable of making online credit card payments, and that at this stage the potential for profit, at least in local markets, is limited. 2.6 Foreign Markets There are, of course, foreign markets, and indeed a study by Clarke & Wallsten (2004, p. 17) determines a causal correlation between adoption of Internet technologies and export, however Egea & Menéndez (2006, p. 532) argue that opening to foreign markets cause a different set of problems, including “linguistic and specific skills to deal with foreign customers and partners” and “perceived market risk or distribution and logistic complexities”. It is necessary to add that not everything can be successfully exported and, obviously, local markets are of particular importance to small retailers who sell imported products. 2.7 Other Obstacles Among other mentioned reasons are lack of trained staff (Sharma 2006, pp. 627-628, Toland, 2006, p. 310, Mansell, 2001, p. 286, Lefebvre & Lefebvre, 2002, p. 321) and managerial awareness (UNCTAD, 2004, p. XX), but how specific is it for developing countries? Or can we agree with UNCTAD (2004, p. 30) that in developing countries small companies are disadvantaged because “shipping and handling costs decrease with the volume of the transaction”? Is the lack of trust in online payments (World Bank, 2006c, pp. 11, 66, Humphrey, Mansell, Paré & Schmitz, 2003, p. 34, Tigre & O’Connor, 2002, p.33, Sharma, 2006, p. 628) an important factor? Yes, these arguments are certainly valid, but the same barriers exist in the developed world and they are not specific to developing countries. Where does this lead us? So far we have identified only the low credit card usage as an obstacle to e-commerce in the middle income countries, as all other ones are either relevant only to the poorest countries or also present in the developed world. To proceed, we have to look at earnings potential of MSEs in the developing countries and their profit expectations from e-commerce.


2.8 Earnings Potential If we compare definitions of micro enterprises in the European Union (European Commission, 2006) and in Brazil (Finance Ministry of Brazil, 2006), where “entrepreneurship is often seen as a way to escape unemployment” (Hekl & Waack, 2001, p. 2), we can see that the micro enterprises in the developed world and in the developing countries have annual revenues with a different order of magnitude. In a more general discussion on adoption of information technologies and Internet among small companies in developing countries, UNCTAD (2004, p. XX) points out that studies show that the key to willingness to adopt these technologies and go online is the profitability and not necessarily only cost. This certainly applies to B2C e-commerce as well. The available options for implementation of technological infrastructure and payment processing are relatively inexpensive, however the potential return on investment is perceived as low and the risk as high. 2.9 Summary Companies in the developing world that are participating in e-commerce are mostly large enterprises, while MSEs are not using online sales in any significant numbers. Main obstacles to e-commerce in the poorest countries have been identified, however, they are less relevant to middle income countries, in particular in urban areas. Higher cost of technical infrastructure and restricted access to growth capital in these countries also do not have to represent major barriers to e-commerce for small shops. Low penetration of credit cards in the general population in the developing countries, together with their lower income in comparison to the developed world, are important factors limiting potential domestic buyers. As exports are not always feasible, MSEs have relatively limited online market. Low expectation of profitability has been identified as the main reason why MSEs in developing countries tend not to use online sales. Micro and small enterprises in developing world have scarce resources and uncertain potential for earnings through e-commerce. Therefore, in most cases they are not willing to invest any financial resources until there is a recognized customer base and potential for profit.


3 Requirements Collection Process The proposed project application is based on the assumption that if the MSEs would be able to offer their products online without any prior investment and paying only a percentage of each successful sale transaction, they would be more interested in participation in e-commerce as this would involve no financial risk. This solution could use the economy of scale so that commissions on small individual revenues of a large number of MSEs would be sufficient for financing shared e-commerce infrastructure. So the primary application requirement, coming out of the definition of problem, is that the participation should be offered to MSEs with no advance fees. This leads us to another major requirement: MSEs should be able to post and update information about their offer without technical assistance from the application provider. For the reasons that will be mentioned later the provider would need to approve if the product can be presented or not, but would not have to help with page design or uploading of product images. This should be simple, intuitive and easy to learn. This requirement is necessary in order to keep the costs of running the application sufficiently low, to allow for commissions to be attractive and the entire system profitable. The basic functional requirements for the application are given in Figure 1.2. This was confirmed by interviews and further developed and formalised in DFDs and STD in the Appendices C and G. Further information is obtained by studying legal sources and best practice implementations in other areas of e-commerce. 3.1 Interviews For the applied methodology, coverage and detailed interview notes please see Appendix D. The interview respondents noted several issues specific to the developing countries that make operations of standard e-commerce applications difficult.

1. The primary concern of all respondents was security. In this they did not refer only to technical security in terms of data confidentiality, integrity and non-repudiation, but to the more general uncertainty of doing business in the environment of weak rule of law, corruption and underdeveloped banking systems, present in most developing countries. The sellers cannot rely on the courts making buyers fulfil their financial obligations, nor can the buyers feel truly protected by the consumer protection system. Both sides can initiate legal proceedings, but according to the interviewers this is usually futile as these cases would drag for years and it would take a long time to get money or products returned, if ever.

(Concern about inefficiency of legal system, expressed by interview respondents, is also supported by the World Bank (2006d) report which states that “in Latin America … average time spent enforcing a contract is over a year and costs amount to more than 30% of the debt. … The judicial system in Brazil is perceived as slow, time consuming and unpredictable. … Trials can last for years; multiple appeals are common, increasing costs and uncertainty. ... As a result, small businesses avoid judicial processes as much as possible.” (World Bank, 2006d, pp. 11-12))

2. Other important issues included credit card security and fraud prevention. In Brazil, in particular, there

are many duplicated credit cards held by the organised crime, together with the security code and owner address and telephone number.

3. Also in Brazil, there are many companies registered and shut almost overnight, or sometimes totally

non-existent, whose purpose is to lure consumers into making orders without any intention of delivery. Sometimes this involves receiving payments, but often the aim is only to collect credit card numbers and other related information.


4. The mechanisms for determining if the companies really exist, what is their legal status and if there is any history of fraud or non-payments were discussed and appropriate solutions were agreed. This also helped to determine a practical system of guarantees that the consumer can rely on in case of non-delivery, if the product was delivered broken or if it is materially different to what was advertised. These solutions are further discussed later this report.

5. Particular attention needs to be paid to documentation necessary for various inspections and for the

financial police. The respondents claimed that incomplete documentation accompanying the product can be a reason for Brazilian financial police to confiscate the shipment. It was agreed that the application has to provide detailed information necessary for bookkeeping and order processing, which often goes beyond what is sufficient for product delivery.

6. Possible name for the virtual shopping centre was discussed and the number of options were

reviewed. The respondents liked the idea of MigoMart, agreeing that at least in Latin America it sounds very friendly and easy to remember. It is based on words “Amigo” (friend in Portuguese and Spanish) and “Mart” (recognisable from Wall-Mart and K-Mart), but easier to pronounce without the initial “A”.

7. While the interviews conducted in Brazil have led to clear requirements, the interview in Bosnia and

Herzegovina has demonstrated that there may be further challenges in attempts to reconcile legal and bookkeeping obligations of the shopping centre administration and the virtual shops in some of the cases when they have different legal residencies. It helped to identify flexibility and possibility to adopt to different country specific circumstances as necessary requirements. For details please see Appendix D.

3.2 Adjacent Systems 3.2.1 Credit Card and Banking Institutions The system needs to interact with credit card and banking institutions in order to obtain verification for shopper’s credit cards and to reserve and charge appropriate amounts. Therefore, it was necessary to learn about online credit card payments and to determine what information is required for processing. The major sources in this process were Visa (2005), Visa (2006), Visa (2007a) and MasterCard (2007a). 3.2.2 Credit Rating Institutions An important step when deciding on approval of MSE applications will be to obtain information about their credit risk rating or any history of fraud, as explained in the interview notes in Appendix D. However, this information can only point to previous misconduct, but cannot help to identify any companies recently created with the aim of committing fraud. For this reason, a minimal number of years in operation should be introduced as a precondition for MSE application approval. 3.2.3 Product Delivery Participating shops will be responsible for delivery of ordered items and the shopping centre administration will not provide any assistance in this regard, except practical advice. However, if the shops do not deliver ordered products in good condition and on time, they will not be paid and the customers will be reimbursed. For more details see Section 3.6. 3.3 Standards 3.3.1 Payment Card Industry Data Security Standards (PCI DSS) The Payment Card Industry Security Standards Council (PCI SSC) was founded by American Express, Discover Financial Services, JCB, MasterCard Worldwide, and Visa International. This organisation has developed Payment Card Industry Data Security Standards (PCI DSS).


“The PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data.” (PCI SSC, 2006) It is important to note that storage of cardholder name, card number and expiration date is permitted only in encrypted form. Storage of card-validation code (CVC2/CVV2/CID) is not permitted and it must not be stored subsequent to authorization (even if encrypted). Transmission of cardholder data over public networks, as well as transmission and storage of all passwords, must be encrypted. With close to two hundred specified standards, PCI DSS is a major source of requirements for security planning and implementation. They are grouped in measures for building and maintaining a secure network, protecting cardholder data, maintaining a vulnerability management program, implementing strong access control measures, regularly monitoring and testing networks and maintaining an information security policy. They are not optional, as PCI SSC members require compliance with all specified data security standards. Compliance validation, including annual data security assessment or self-assessment and quarterly network scan, is mandatory for all merchant and service provider levels. Due to large volume of text these requirements will not be repeated in this report. However, the reader is encouraged to read them in PCI SCC (2006). 3.4 Legislation and Legal Issues Discussion on legal issues related to project application is presented in Appendix E and in this section only the major points are summarised. As the author of this project is a resident of Brazil, let us assume that the virtual shopping centre will have the same corporate legal residency and be subject to Brazilian legislation, in particular to Consumer Defence Code (CDC, 1990). The virtual shopping centre will be the entity that charges consumers, so it will be legally considered as “supplier” and have a role beyond being only a media for product advertising. As such it would share: a) Responsibility for accuracy of product descriptions, b) Liability for damages caused by products and c) Responsibility for sales of prohibited items. This can be resolved as follows: i) The shopping centre administration will have to approve the presentation content for each product, ii) MSE will be contractually obliged to compensate the shopping centre for any damages caused by joint

liability, iii) Shopping centre will work only with MSEs with no negative record with Serasa (see Section 3.2.2) and iv) Shopping centre will react to any misinformation by removing the product offer, warning the MSE or

blocking the associated account. In case of products being defective or materially different than advertised, customers are entitled to full money return or product exchange as long as the complaint is submitted within 90 days of product delivery. Shopping centre administration is jointly responsible for these guarantees with the participating shops. Given its legal and ethical responsibility vis-à-vis the shoppers, the shopping centre will have to directly offer full money return guarantee, both for defective items and for cases of no delivery, in a manner described in Section 3.6 below.


3.5 Best Practice E-Commerce Solutions 3.5.1 Introduction Through the interviewing process it was possible to determine how the respondents do their work and what are their business requirements. However, most respondents were not familiar with possible options and the best practice solutions in e-commerce and, therefore, a study of a number of existing websites was necessary. 3.5.2 Website Analysis This analysis started with the most popular e-commerce websites like Amazon, Dell and eBay, including both United States sites and local versions for a number of countries. E-commerce options available for small merchants were seen through Yahoo and Network Solutions. Amazon Business Solutions, on the other hand, is a good example of integration of small businesses into a wider network provided by a major company. Of particular interest for this project were large e-commerce websites in middle income countries. Over thirty websites in Argentina, Brazil, Bulgaria, China, India, Mexico, Russia and South Africa were analyzed. While the major US sites have provided insight into advanced functionality elements, study of websites from middle income countries provided significant input into usability requirements, as they were mostly designed for and used by shoppers in these countries. 3.5.3 Target Groups In the project application, the customer target group will mostly overlap with those for the existing sites. The shoppers will be those who probably already have some experience with Internet purchases and have credit cards. In developing countries, this often translates to a growing category of young urban middle class. However, the virtual shopping centre will be more internationally oriented than the majority of examined sites, who often target domestic markets only. (Nevertheless, recognising that there might be cases when international sales are not feasible for sellers due to licensing issues, exporting permits or potential complexity of required documentation, the application will allow an option to offer sales only domestically.) At the core of this project is an attempt to offer online sales to those shops who find that existing e-commerce costs are higher than potential revenues. Therefore, the initial clients will most likely be new to Internet sales. However, the application will also try to gain seller market share from other many-to-many e-commerce sites, as many of the existing sellers could be expected to rationally choose solution with less risk. 3.5.4 Technical Assistance Some familiarity with Internet and e-commerce is a precondition for sellers, as well as the ability to understand their tasks, including, for example, entering data in forms and uploading product images. No matter how well the interface is designed, it will still require basic computer knowledge. Administration could, therefore, benefit from cooperation with institutions providing educational and organisational support to MSEs. The best example of such an institution in Brazil is SABRAE (Brazilian Support Service for Micro and Small Enterprises), mentioned by interview respondents, who could explain the benefits of using the application to local MSEs and help to educate them in basic computer and Internet skills. 3.5.5 Expanding Market Outreach In further steps interaction with local communities should go beyond government agencies and involve activity groups within religious institutions, humanitarian, charity and other non-governmental organisations. 3.5.6 Advertising and Product Promotions While it was not uncommon to see advertisements for products on external sites and sponsored links in search results, the project application will remain focused on products provided by member shops only, and will have no links, advertising banners or search results leading to other sites. It will be possible to search for products


based on keywords, category, country of origin or description language and the products with equal results accuracy will be sorted by popularity, based on previous orders. An option was considered to include promotion of products on major pages or higher placements in search results for shops who pay for this kind of advertisement, however, it is left as optional and subject to testing on how acceptable it would be by the participants who expect equal treatment within the application promise of “no prior investment”. 3.5.7 Vendor Ratings Many sites offering items from multiple sources make it possible for buyers to provide ratings on sellers and a similar suggestion was also introduced by one of the interview respondents. The project application will support virtual shop ratings. Buyers will be allowed to rate the shops from which they have ordered items and the average rating and number of votes will be visible to all visitors. List of all e-commerce solutions analysed in this exercise is provided in Appendix F. 3.6 Payments, Guarantees and Trust Interview respondents expressed concern that the shoppers might refuse to pay once they receive the items and insisted on mechanism that would protect them from dishonest action. The accepted solution is that the shoppers pay for ordered product using their credit cards, with the application reserving these amounts with the card issuing banks at the time of ordering. The credit cards will be charged at the time of shipment and the shoppers will not have an option not to pay. Of course, they will have an option to contest the charge with their banks, but only if they have valid reasons, which can be verified. As mentioned in Section 3.4, shoppers must be entitled to full money return or product exchange if they make justifiable complaints about product condition within 90 days of delivery. The safest way for the shopping centre to enforce this guarantee by MSEs is by withholding payments at the shopping centre account until the expiration of shoppers’ right to complain. Allowing additional ten days for delivery, this can be set at 100 days. This guarantee will also apply for delivery itself. If before the end of this period customers complain that the products were not delivered and if the shops cannot prove otherwise, they will not be paid and the money will be returned to customers. If customers complain that the products are defect or materially different from what was advertised, the shopping centre administration will actively participate in problem resolution. If there is no resolution, it will review any supporting evidence and reach appropriate decision at its discretion, possibly involving reimbursing the customer. The administration could potentially spend a lot of time arbitrating, but that is the risk that has to be taken. It is similar to Amazon.com protection for products sold by their partner sellers, as they also have to review case by case and make decisions. However, they can rely on the rule of law to enforce cooperation, and this is not the case in developing countries, where the best way to achieve this is by controlling the money. If we look at the application from the perspective of trust, since there are three parties involved in each transaction, we have a triangle. While Figure 1.2 explained what each participant does, Figure 3.1 shows why they would trust each other.


Figure 3.1: Triangle of Trust Trust is a key component of the project application and it is of value to all participants. While both buyers and sellers can be trusted because of imposed limitations, trust in the administration is implicit. Therefore, for the administration it is invaluable to gain trust by other two parties and it should be highly valued and protected. Building reputation will take time, absolute integrity and dedication to flawless and timely transactions. While the above described represents the safest way to guarantee partner cooperation, less restrictive and potentially more attractive solutions, as well as other ways of handling delivery and payment procedures, have also been explored and could at a later stage be further analysed and implemented. For discussion on these solutions please see Appendix H.

Shoppers: Pay for orders with credit cards, subject to approval by credit card companies. Amounts are reserved to they cannot decide not to pay. Use customer complaints procedure. Their complaints will have to be based on reality and reviewed by the shopping centre administration. Responsible for their personal data security.

Virtual Shops: Do not get paid until statutory guarantee period expires. Their product presentations approved by the administration. Responsible for security of their data and any customer data they have, but not given credit card data.

Shopping centre administration: Meets all legal standards and requirements. Provides money return guarantee by holdings shopper amounts for statutory period of 100 (90+10) days. Handles all complaints efficiently. Takes sales provision and transfers money to virtual shops. It is a reliable partner that is not going to disappear and will always be there on the next day. Has high data security based on PCI DSS standards.


4 Requirements Model 4.1 Functional Requirements 4.1.1 Introduction Conallen (2002, p. 173) mentions that “functional requirements often require greater detail in order to clearly understand them” and that “use cases are a powerful technique for capturing and expressing detailed system behaviour”. Bennett, McRobb & Farmer (2002, p. 134) describe use cases as “descriptions of functionality of the system from the users’ perspective” and use case diagrams as showing “functionality that the system will provide” and “which users will communicate with the system in some way to use that functionality”. In this project use case diagrams, expressing use cases “in relation to the actors that invoke them” (Conallen, 2002, p. 176), were used together with textual descriptions. Larman (2001, p. 60) argues that use cases should be “at the level of elementary business processes (EBP)”, defined as “a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state” (Larman, 2001, p. 60). However, Bennett, McRobb & Farmer (2002, p.135) state that use case “describes the interaction as the user sees it” and they differentiate between essence and real use cases. While the first group is in line with the EBP guidelines, real use cases “describe the concrete detail of the use case in terms of its design” (Bennett, McRobb & Farmer, 2002, p.137). In this project an effort was made to stay with the essence use cases, however, there are occasions where the use cases violate the EBP guideline as a more granular approach, with separate use cases representing steps within a base use case, helped to better facilitate requirements analysis. The table below shows functional requirements and the associated use cases. A comprehensive Use Case Analysis with diagrams and activity descriptions is presented in Appendix I. These requirements have also been used as the basis for application testing, presented in Chapter 7 and Appendix P. 4.1.2 Requirements List No Requirement Use Cases F1 To allow MSEs to apply for virtual shops Apply for virtual shop F2 To allow secure sign-in for MSE staff MSE sign-in; Request forgotten user code or password F3 To allow MSEs to manage their profile and

contact information Modify background information; Modify contact information

F4 To allow MSEs to manage their products Add new product; Modify product information; Remove product

F5 To allow MSEs to manage their accounts Change password; Manage orders; Manage finances; Request payment; Contact Shopping Centre about the account

F6 To allow MSEs to view and manage orders

View order history; View individual orders; Confirm order; Reject order; Confirm shipment; Contact shopper about the order; Contact Shopping Centre about the order

F7 To allow shoppers to register and sign-in Register; Sign-in; Request forgotten password F8 To allow shoppers to find and buy

products Find products; Browse categories; Search for product; See featured products; See product information; Add product to shopping cart


No Requirement Use Cases F9 To allow shoppers to find shop

information, products and contact details and to provide ratings for shops

Find shops; Browse shops; Search for shop; Access shop page; View offered products; View shop background and contact information; Add shop rating

F10 To allow shoppers to view and manage their shopping cart

View shopping cart; Update product quantity or remove products; Go to checkout

F11 To allow shoppers to go to checkout, review order and provide necessary information

Provide delivery address; Review items and delivery cost; Provide billing information; Review and confirm order

F12 To allow shoppers to manage their accounts

Add or change personal information and default delivery address; Change password; View order history; View individual orders; Cancel order for items that are not yet shipped; Contact the shop about the order; Contact the shopping centre about the order

F13 To allow all users to see general information

Contact shopping centre; See help; See terms and conditions; See privacy statement

F14 To allow Shopping Centre staff to review, approve or reject MSE applications for virtual shops, set commission or request more information

View all applications; View individual applications; Approve application; Set commission; Set initial password; Reject application; Request more information

F15 To allow Shopping Centre staff to access all information on products, to approve or reject products and to block products

See new products and products pending approval; Approve or reject product; Block product

F16 To allow Shopping Centre staff to access an moderate all information on individual shops, change commission, block shops.

See all shop information; Moderate shop information modifications; Change commission; Reset shop access password; Block shop; Contact shops

F17 To allow Shopping Centre staff to find information on shoppers

Search for shopper; View shopper information; View related orders; Contact shopper

F18 To allow Shopping Centre staff to manage orders

List orders; List orders for shop; List orders for shoppers; View individual orders; Change order status

F19 To allow Shopping Centre staff to manage product categories

See product categories; Add a category; Modify category; Remove category

F20 To allow Shopping Centre staff to see financial information

See balances; See all incoming payments; Register incoming payments; See outgoing transfers; Register outgoing transfers;

4.2 Non-Functional Requirements 4.2.1 Domain Rules

No Requirement D1 Initially the only way to pay for purchases will be with credit cards, as discussed in Section 3.6. For

each online order the system will verify if the shopper’s credit card company will allow the purchase. It will securely collect data necessary for this verification and transmit it to the credit card companies. What data is needed and how should this information exchange take place will be specified by the card companies.


4.2.2 Security

No Requirement Payment Card Industry Data Security Standards (PCI DSS) S1 The application must fully implement PCI DSS. This includes measures for building and maintaining a

secure network, protecting cardholder data, maintaining a vulnerability management program, implementing strong access control measures, regularly monitoring and testing networks and maintaining an information security policy. Detailed requirements are presented in PCI SCC (2006).

Other protection measures S2 Transmission of all sensitive data over network must be encrypted. This includes information related to

shopper’s account and orders, MSE account and products management and shopping centre staff activities.

S3 All activities that leave the system in changed state will be logged. S4 Shoppers will be identified by user name and password. MSE will be identified by their code, personal

identification number and password. S5 MSE will enter their user code and password though an on-screen keyboard using mouse clicks,

therefore reducing the threat of user credentials theft by key logger viruses and spyware programs. For shoppers this measure will not be introduced for usability reasons. Their exposure to fraud is lower and making orders will require more information than only user name and password.

Other credit card security measures S6 No orders will be forwarded to MSEs until the customer’s credit card is confirmed as valid and the

amount reserved. S7 Address Verification Service (AVS) will be used with every authorisation request. The result code will

indicate whether the billing address given by the cardholder matches the address on file with the Issuer and if it is not the case the application will not accept the order.

S8 Shoppers will have to fully enter their credit card information for all purchases as their previously used card information will not be displayed. Shopper’s credit card security code (CCV/CCV2) will never be saved in any database.

S9 Credit card alerts will be triggered for very high amounts or multiple orders within the same day. This should extend not only for orders from the virtual shopping centre but to all orders with this credit card, therefore requiring cooperation with credit card companies.

Consumer protection S10 The credit card will be charged only after the confirmation of shipment. S11 There will be order guarantee with the payment being held by shopping centre administration until the

expiration of guarantee time (90 days for durable items with additional 10 days allowed for delivery). If the customer complains within this period that the shipment has not been received or that it is materially different or in unsatisfactory condition, payment to MSE will be blocked and both sides will be encouraged to find a solution. If a solution it is not found the shopping centre administration will reach the decision at its discretion taking into account statements from both sides and any supporting evidence. (See Section 3.6.)

User protection S12 All users should be informed about phishing, spoofing and social engineering attacks


4.2.3 Legal and Standards

No Requirement L1 The system will follow consumer protection laws of the country or territory where the enterprise owning

the virtual shopping centre has been incorporated. As the corporate legal residency would be in Brazil it will be subject to Brazilian legislation and in particular to Consumer Defence Code (CDC, 1990).

4.2.4 Ethical

No Requirement E1 The key to success of this application is in building confidence between all involved parties. As the

system will be intermediary between buyers and sellers it will have to include conflict management and redress measures and particular attention will be devoted to prevention of fraud. (See Section 3.6.)

E2 Strong privacy will be guaranteed and all data will be kept confidential. 4.2.5 Usability

No Requirement U1 All web pages generated by the system will have fonts in a readable size and with text in dark colour

on white background. U2 Cross-browser support will have to be implemented and as a minimum the web pages will have to be

properly displayed and have correct functionality in Microsoft Internet Explorer, version 6 or higher, and Firefox, version 2 or higher.

U3 All website navigation and forms will have to be intuitive and search function should be easy. U4 The site will have a help section designed to provide practical assistance to user for all tasks and

situations they may encounter. This will reduce load on the website support staff. U5 All web pages will have to load in under 10 sec on 56K modem connections. 4.2.6 Technical

No Requirement T1 Programming language used for the online application will be Java, based on Sun Microsystems JDK

1.6.0. The system will be developed using NetBeans 5.5 IDE. T2 Servlet container will be Apache Tomcat 5.5.17. and it will use Apache Struts 1.29 framework. T3 Database server will be MySQL Server 5.0. (See section 5.1. for further information.) 4.2.6 Other

No Requirement O1 Performance: A simple client-side benchmark specified in requirement U5 (10 seconds rule) will have

to be satisfied in all cases. This will require not only using web page design rules aiming to reduce page downloading time, but also having server applications, hardware and network bandwidth capable of handling all users even at peak times. This will, therefore, require permanent system monitoring and potential network improvements or fine-tuning or modifications of web and application servers.


No Requirement O2 Reliability: The software will be tested for errors. Server and network reliability will depend on the

chosen hardware configuration, however, it will have to support a minimum of 99.9% operational uptime.

O3 Cost: While no specific cost target is set, licensing cost should be reduced by basing all supporting application software, as specified in 4.2.6 above, on Open Source solutions.


5 Further Requirements Analysis and Preliminary Design Choices 5.1 Elaboration on Technology Requirements Database server is this project is MySQL Server 5.0, selected not only because of free licence, compared to relatively high licensing cost for Oracle and MSSQL software, but also for performance, reliability and scalability. According to MySQL documentation it is fully multi-threaded, can use multiple CPUs if available, can handle large databases, can mix tables from different databases in the same query, supports referential integrity, cascading updates and deletions, replication and clustering, and supports Unicode characters. Furthermore, upgrading MySQL server has in the most recent versions been simple and without need to dump and restore the data. However, MySQL Server does not support views and stored procedures and they will not be used in this project. Application code will be written in Java programming language. It will use Tomcat Servlet container on Apache web server, both known for performance, reliability and security. Code will be based on Model-View-Controller pattern implemented through Struts framework. At the time of preparing this project Struts version 2.0, formerly known as WebWork, is already available. However, it is relatively new and not yet well documented. For this reason the project application code will be based on Struts 1.2.9, tested, reliable, well presented in numerous literature and supported by main Integrated Development Environments (IDEs). The IDE used in this project is NetBeans version 5.5. Struts framework provides numerous functionalities and two of them, server side data validation and support for localisation, are the reasons why it was chosen for this project. Using Struts Validator enables efficient server side validation of client submitted data in an easily controlled manner since the validation rules for the whole application are in a single XML file. Struts provides localisation mechanisms with struts-bean components, enabling insertion of text stored in properties files. Properties files can exist for various languages, so the task of translating the application can be reduced to translating property files. (However, for demonstration purposes all text will not be in properties file as this transfer should be the last step following other improvements outside the project scope.) URL addresses in Struts environment traditionally have extension “.do”, but this is not use in this project as there is no need to signal the technology to potential hackers. Neutral extension “.htm” will be used for all action servlets. Due to localisation mechanisms the application will have no static HTML pages, however, should a need for them arise in the future they can still use “.html” extension. All JSP pages will be in WEB-INF directory on Tomcat, and therefore not directly accessible. Some of the Struts components, including Dynamic Forms or Tiles, are not used in the project. Many of the JPS pages are too complex to benefit from usage of struts-html tags, and they will be used only for displaying data submission errors. 5.2 From Use Cases to Programming Code: Using UML Sequence Diagrams A wealth of information about using UML diagrams in designing Web applications is provided by Conallen (2002) and Rosenberg & Scott (2001). Martin (2003) has focused on UML and Java programming language, and UML for Struts, and in particular use of sequence diagrams, is covered in Roller (2003), Dudney & Lehr (2003) and Husted et al (2002). The easiest way to move from use cases and show interaction between the user and components (web server, controller servlet, form beans, model classes, JavaBeans and JSP pages) is to use UML sequence diagrams. Struts sequence diagram, which is a slightly modified version of a diagram adopted from Roller (2003), is shown in Figure 5.1.


Figure 5.1: Struts Sequence Diagram


However, in the requirements analysis for this project the diagram presented in Figure 5.2 will be used. If has been simplified and enables focus on project specific programming components.

Figure 5.2: Simplified Sequence Diagram for Requirements Analysis Please refer to Appendix J for discussion on adopted programming solutions. Diagrams used for streamlining data flow and design of programming objects are in Appendix K, where each previously determined use case is covered with sequence diagrams, description and list of related code listings.


6 System Design 6.1 Database Database design and implementation are mostly based on methodology described in Connolly & Beg (2005). As a first step a conceptual data model was built. This included identification of entity and relationship types. Attributes were identified and associated with these entity and relationship types, attribute domains were determined and candidate, primary and alternate keys were identified. Model was checked for redundancy and validated against user transactions and user needs, specified in requirements. In the second step a logical data model was built and validated. Relations were derived and validated using normalization and against user transactions. Integrity constraints were verified. In the third step the logical data model was translated for target DBMS, in this case MySQL server. Relations were designed with system specific attribute domains. The database system does not use derived data or controlled redundancy and user views are not supported. Security was implemented through Servlet container and through MySQL security mechanisms. Encryption methods were determined. The system was not tuned for a specific load estimate as it will depend on market acceptance, however, different implementation options are briefly discussed in Chapter 8. Global relations diagram is presented in Figure 6.1. Please refer to Appendix L for tables with entities and relations, description of implemented encryption methods and the SQL code which can be used to recreate the database. 6.2 Interface As described in Chapters 3 and 4, interface requirements from technical and usability points of view were obtained by working with interview respondents, by analysing similar and best practice e-commerce websites in developing countries and through literature research. The design aims to satisfy these requirements for different user classes: shoppers, virtual shop management and shopping centre administration staff. Detailed description of interface, in particular from ergonomics and usability side, is in Appendix M. Homepage screenshot is in Figure 6.2 and other application screenshots are in Appendix N. 6.3 Application Programming The application code consists of:

• Struts action classes • Struts forms holding user input • Java Server Pages providing view component • Properties files providing error messages and text in different languages • Struts Validator guaranteeing clear limits on allowed user input • XML configuration files putting everything together • Model objects, including JavaBeans for storing data, Connector for interaction between beans, database

and action instructions, and several auxiliary classes. Full code listings are provided in Appendix O. Please also refer to Appendices J and K.


Figure 6.1: Global Relations Diagram for Project Database


Figure 6.2: Web application start page with sample products and shops


7 Testing The chosen testing strategy is mainly based on work by Myers (2004). This second edition of 1989 classic goes beyond explaining fundamentals, like black box or regression testing, and allocates a whole chapter to a modern topic of testing Web applications. In general, Web applications have many additional challenges compared to traditional applications as the users can have different browsers, devices and operating systems, monitor sizes and resolutions, as well as different connection speeds. They may reside in different countries which might involve translations and currency conversions. In terms of security, the mere fact that the application is accessible by the whole world makes it more vulnerable to attacks. The only major discrepancy between this project and Myers (2004) is in disobeying the major rule that the application developer and the application tester must not be the same person, which for obvious reasons was not respected. According to Myers (2004, pp. 5-9), one of the “primary causes of poor program testing” is the fact that “most programmers test the programs trying to prove that errors are not present” and that “the program performs its intended functions correctly”. In this project testing started with the assumption that the program contains errors and that it should be tested in order to find as many of them as possible, and to fix them. The application was tested at presentation, business logic and data layers and within each layer a number of different testing activities were performed. This included layer-specific techniques, for example checking for broken links or data recovery possibilities, as well as common techniques like code inspection and black box testing for pre-determined test cases. Discovered errors were fixed as soon as possible and the testing continued until no more errors were found. In addition to this, a higher order testing was undertaken to see if “big picture” requirements were satisfied and load testing has led to code modification resulting in performance improvement. Application testing was thorough, although at a higher level it was incomplete as it was not conducted in a replica of production environment and included no independent user testing without the presence of author. For detailed information on performed testing, including test cases, errors, solutions, and discussion on load and acceptance testing, please refer to Appendix P.


8 Implementation The application works on variety of operating systems. Most commonly used operating systems in web server environment are MS Windows Server and various flavours of Unix and Linux. While Windows solutions are integrated, powerful and easy to use, Unix is generally considered to be more stable and reliable (Laudon & Traver, 2007, p. 208), and MySQL is most commonly used with Linux. However, this report will not try to impose the solution on operating system. As far as hardware is concerned, as a minimum web and database servers should be on separate systems. Laudon & Traver (2007, pp. 204-205) explain how server segregation can enhance page generation speed and that using a single server for these tasks can reduce this speed by up to 50%. Furthermore, PCI SSC (2006) specifies that the database with customer credit card information must be kept on the machine separate from the web server and placed behind the firewall. Hardware needs obviously also depend on the demand that the users put on the site and the important factors to consider are the number of simultaneous users at peak period, and the number of items served by the database server. The load on systems by users will also dictate the need for network components and internet connection speed. The initial capital investment does not necessarily have to be high. Application software, including database system, supports clustering. Implementation can start as a pilot project and, if there is acceptance by users, hardware can subsequently improve. This can include vertical scaling, by adding more processing power to servers, or horizontal scaling, by adding additional computers to be used as servers. The second option is more preferable as in general it is better to use higher number of balanced systems then to depend on small number of powerful machines. Attention needs to be paid to website maintenance. E-commerce websites “are always in process of change, improvement and correction” (Laudon & Traver, 2007, p. 204) as this is a very dynamic field. In terms of functionality it is very important to constantly seek and listen to user feedback, and to adopt accordingly. Only practice will demonstrate if the developed website contains sufficient appeal for users and it is natural to expect that some design and functionality adjustments will be required. It will also be necessary to verify application acceptance across a number of countries and see if any country specific issue will require modifications or additional functionality. In terms of server performance, it is necessary to build and implement a system monitoring plan, as well as compare the performance with the competition. Application provider will need permanent staff dedicated to site administration and maintenance. Administrative staff involved in approval of member shops and products moderation will need not only appropriate training in how to use the application, but also strict guidelines and sets of rules governing their work. The same applies to staff working with financial transactions. E-commerce security requirements go far beyond writing a secure code and there are a number of measures that have to be implemented. As mentioned in security requirements, the entire system must fully implement PCI DSS standards. They clearly specify measures for building and maintaining a secure network, protecting cardholder data, maintaining a vulnerability management program, implementing strong access control measures, regularly monitoring and testing networks and maintaining an information security policy. Once the site is up and running the work has only begun and in the next stage it is necessary to reach out to potential users. This involves attracting both participating member shops and their customers. While any efforts by member shops to attract visitors could certainly contribute, this responsibility should not be delegated to them as it is the shopping centre administration’s obvious benefit to have as many closed sales as possible. This outreach should involve not only search engine optimisation and submission to main search engines and directories, but also investment in paid advertising on Internet and in other media.


9 Evaluation 9.1 Evaluation of Project Product One of the major strengths of the application developed during this project is in its usability. All respondents involved both in early versions of the interface and in testing of the application were, except for language barriers, able to easily understand the functionality and perform necessary steps with minimal guidance. The project application does well what is designed to do, however, several issues can be identified related to functionalities that have not been included in design or have not been fully implemented. Accepting credit card payments and making transfers would require technical integration with supporting banks or credit card companies. Since such cooperation does not yet exist, this part was either simulated or not tackled at all, and is left to be done at a later stage. For the purpose of academic review the application interface is written in English language and due to time constraints it has not been translated. However, shops that are target of the application are in the developing countries where other languages are more widely spoken. For the application to be accepted the interface would need to be translated to other languages, including at least Spanish, Portuguese and French languages. Another issue, also related to languages, is that if a shopper uses interface in, for example, English language, and selects a product for which description was submitted in, for example, Portuguese, this product description will be displayed in original languages so there will be two different languages on the screen at the same time. Another option would have been to hide the products with descriptions in languages different than the selected interface, however, this idea was rejected in favour of enabling product exposure to as many customers as possible. Providing customised translation would have been too expensive, and automatic translation tools are not yet at the stage where they would be reliable enough for this usage. Having a website targeting users in many countries should involve more than translation and localised orthography. The application does not take into account geographic, cultural or economic differences and the same products are featured regardless of customer location. There is a reason why major websites have different versions for many countries and if this is not respected we can end up not only offering items unlikely to be sold, but also miss the opportunities to present targeted products to specific markets. A music CD highly popular in Brazil might go unnoticed in Asia, cricket equipment popular in India would be ignored in Brazil and beach sandals from Panama are very unlikely be bought in Russia, regardless of language in which they are presented. This goes beyond marketing and can have legal consequences. Some products are legal in one country and illegal in another. Shopping centre administration must approve all products before they are offered on the website, and in doing so they must rely on the legislation of its legal residence, in this case Brazil. Nevertheless, customers in other countries should at least be advised on any local legal issues, but how can the administration know what is or is not allowed in other places? This problem is even more pronounced with various international safety standards. Some of the requirements related to communication between parties have been implemented in a simplistic way. For example, transfer requests are not submitted through web forms and member shops should request them by email or telephone. It would have been easy to design secure communication through web forms, as this requires only trivial programming. However, although web forms can be useful in standardising information requirements, they can be limiting in the situations where international clients can request transfers to banks in different countries. Moreover, a method with clients only initiating communication and shopping centre administration subsequently contacting them through previously agreed contact channels and requesting Personal Identification Numbers is more secure, and seem to be accepted by international banks and brokerages. The same applies for other communication, for example order complaints, where forms would be


limiting. On the other hand, having standardized forms would have made it easier to record the communication in the database and keep it linked to relevant shoppers, shops or products. Perhaps a combination of web forms and others means of communication would have been a more suitable solution. All defined use cases are implemented and the application meets the specified requirements, within the mentioned constraints. All project objectives are met. The application is unique and cannot be directly compared with other applications in its class, however, it compares well with the major e-commerce sites in developing countries. From technical and programming perspective, the created code is robust. It is based on a widely accepted technology, Java Struts 1.2. Connections to the database were done with SQL queries and there is no use of Java Persistence API or Hibernate, which would have enabled a smoother programming integration through object-relational mapping. The program is not truly component based, however, it is flexible and additional functionality can be introduced without great effort. Of course, project application quality depends on the implementation. Meeting any benchmarks would strongly depend on choice and organisation of servers and connection speed, and this has been left vague. However, included technologies, from Java to MySQL server, support clustered servers and replication of databases, so the presented code can be implemented on scalable configurations. 9.2 Evaluation of Practice and Methods When the project proposal was first mentioned the initial reaction from the University was this it might be too big and too difficult for any single student to create, so a simplified version was submitted as official project proposal, and subsequently accepted. Although this project represents a major step in creation of a full product, due to a number of constraints, specified in the introductory chapter, it is not ready for commercial use. The project activities not only included themes from all units at the MSc Internet Systems Development course, therefore being useful for knowledge consolidation, but also made it necessary to do learn additional topics and to make independent research. This has presented a significant learning opportunity and the author has benefited from the newly acquired knowledge. Project plan was well designed and time well managed. At the initial stage the Data Flow Diagrams (DFDs) were designed and they have led to a full understanding of steps that needed to be followed. Presented literature review focused on problem from business perspective and not on technology. Possible technological solutions for a web application supported by database are numerous and the author felt that any attempt to contribute in this field would be superficial. It is the problem itself, weak position of small shops in developing countries in the regard to e-commerce, that needed to be addressed and demanded focused attention. Most of the interviews were conducted with small companies from Brazil and this was limiting. The process of collecting requirements from the potential participants was the most challenging part of the project. It was difficult to find them, and even harder to motivate them, as their assistance involved not simple questionnaires that can be answered quickly, but hours of joint analysis. Lack of profound international research will probably lead to identification of certain country specific issues during the implementation phase, which will result in need for partial application modifications and enhancements, possibly involving customisation based on MSE location.


Study of legal sources focused on Brazil, assuming that this would be the corporate residence of the entity providing the application. However, the best practice solutions covered a wide range of developing countries and the rules and restrictions imposed by the relevant credit card authorities are international. The supporting technical solutions, including Apache Tomcat and MySQL server, were chosen not because they were the best, but at least partly because they were the most accessible. It is possible that a more reliable and efficient solution would use commercial products like Oracle or MSSQL server, with support for database views or data analysis. However, obtaining a licence was not foreseen in the project budget. As mentioned in the chapter with further requirements analysis, programming code is not fully object oriented. The chosen solution is flexible, but at the expense of model usability with a different controller and view. There is no escape from the fact that model was build with view in mind. Used procedure was to create interface prototypes which have naturally lead to view and controller classes followed by the design of model and as a result model and controller are too closely coupled. If the project were to be repeated this approach would have been changed and the focus placed first on model, and only then on building controller and view as one of the possible interfaces. This would be more time consuming, but the resulting code would have better quality. There was no testing configuration close to production environment. For testing purposes the product was deployed on a personal computer and on a shared server with a web hosting company in the United States. There were no dedicated servers and no deployment similar to any real world implementation. There was no beta testing with independent users who would take their time to review the application and provide comments and information on errors. Most of the testing was performed directly by the author and testing with potential clients was limited to only a several users using the application for less than one day. The author is very grateful to those who provided this support, however, the fact remains that more external users should have been involved in the testing process.


10 Conclusions This project was based around an idea for a solution to a problem common to micro and small enterprises in the developing world, who avoid participation in e-commerce and investing in online sales as they, often rightly, estimate that needed investment would be higher than potential benefits. The specified problem is real and covered in recent publications, as mentioned in the chapter with literature review. It has been widely acknowledged by the interview participants during the requirements collection process. The developing world is already on the path to wider adoption of e-commerce and it can be expected that, as income of the population, credit card penetration and online market in these countries improve, more and more MSEs will use online sales. However, at this stage investments in e-commerce by small shops are often not considered justified by market conditions. The proposed solution involved economy of scale and sharing of common resources, with costs associated with using e-shops being covered through a small percentage of successful sales, which eliminates the possibility of low financial return of investment for participating enterprises. Significance of this solution is in democratisation of online sales by allowing small shops in developing countries to take part in e-commerce, which is something they are currently doing only in rare instances. A key component of developed e-commerce application is confidence by both buyers and sellers. While a system of payment and guarantees was designed to ensure that they are treated honestly be each other, trust in the application administration will have to be earned over time, through fairness and dedication to absolute integrity. While it is the author’s firm belief that this solution can help to reduce the scope of the problem and open the door for many potential participants who were left outside the e-commerce revolution, it has not been proven in the practice and remains in the realm of theory. For this solution to work a lot of improvements are still needed, as specified in the project evaluation. The project of this size and in such an evolving area can never be finished and the work can only be postponed. Not only should the future work go beyond specified project constraints, it should also involve numerous functionalities yet to be discovered through user feedback and further research. The project application was built around e-commerce B2C model. It would be relatively simple to extrapolate parts related to online sales that could be reused in an application designed for a single shop, or for a group of co-operating shops. Classes and methods designed to enable submission of content by users, including product images, together with the developed product search algorithms could also be used for presentations that do not involve direct online payments, for example in sales of real estate, personals or auction sites. Of course, a different business model would be needed, but a great amount of created programming code could be adjusted and used. However, having thousands of lines of reusable code is not the key outcome, nor was creating a business opportunity the primary motivation for this project. Apart from technological and commercial aspect, there is another dimension, related to international development. The potential usage of the project solution targets economic inequality in a sustainable, self-financed manner, based on market principles. The created application may be imperfect, but if it points to the right direction, the project has achieved its purpose.


11 Future Work The following items have been identified as excluded from the project and meriting future work: 11.1 Payments and Finances

• Analyse alternative solutions for payments and guarantees, as specified in detail in Appendix H. • Liaise with banks and credit card companies to enable processing for all major credit cards. • Integrate credit card verification code into the application. • Allow payments in partial instalments. • Integrate code for outgoing transfers. • Write auxiliary application to help administration to retrieve encoded credit card data.

11.2 Functional Requirements and Interface

• Translate application interface to several languages, including Spanish, French and Portuguese. • Allow further price differentiation for delivery methods (priority, air, currier etc). • Allow several photographs for each product. • Write complete help pages and tutorials. • Write Terms and Conditions. • Write Privacy Statement. • Limit product search by price or delivery options. • Customer targeting: analyse orders, searches and browsing behaviour and promote products

accordingly. • Increase usage of web forms for communications and storage of messages.

11.3 Implementation

• Server segregation: separate database and Web / application servers. • Place database server behind the firewall. • Purchase and use SSL certificates. • Build and implement a system monitoring plan. • Develop staff training plan and work guidelines.

11.4 Research

• Verify with users if advertising would be acceptable. • Determine country specific issues through wider international research. • Determine if there is need for customisation based on MSE location and proceed accordingly. • Find best way to develop local versions targeting users in different countries.

11.5 Testing

• Testing by another person. • Testing in replica of production environment. • Beta testing with user working independently from the author.

11.6 Outreach

• Search engine optimisation and submission to main search engines and directories • Investment in paid advertising on Internet and in other media. • Explore other ways of marketing to buyers and sellers. • Obtain support from Sabrae and similar institutions (see section 3.5.4 and 3.5.5). • Explore potential of working with common interest groups, including activity groups within religious

institutions, humanitarian, charity and other non-governmental organisations. • Explore options for investment in technical education for micro enterprises.


11.7 Business Planning • Human resources. • Required assets. • Marketing costs. • Full cost estimate and profitability analysis. • Financing plan. • Presentation to investors.

11.8 Other

• Open Serasa account and integrate software with Serasa online services (see Appendix D).


12 References Barlas, P. (2006, June 9). More Money, More Rivalry. Los Angeles: The Investor Business Daily. Bennett, S., McRobb, S., & Farmer, R. (2002). Object Oriented Systems Analysis and Design Using UML. Maidenhead: McGraw-Hill Education. Burke, K. (2002). Intelligent Selling. The Art and Science of Selling Online. Petaluma: Multimedia Live. CDC (1990). Consumer Defense Code (Código de Defesa do Consumidor). Law No. 8078 as of September 11, 1990. Translation by Foundation for Protection of Consumer (Fundação de Proteção e Defesa do Consumidor – PROCON), São Paulo, Brazil Clarke, R. G. G., & Wallsten, S. J. (2004). Has the Internet Increased Trade? Evidence from Industrial and Developed Countries. (World Bank Policy Research Working Paper 3215). Washington: The World Bank Group. Comparing Wicket and Struts. Retrieved August 18, 2007 from http://wicket.apache.org Conallen, J. (2002). Building Web Applications with UML. (2nd ed.). Boston: Addison-Wesley. Connolly, T., & Begg, C. (2005). Database Systems. A Practical Approach to Design, Implementation and management. (4th ed.). Harlow: Pearson Education Limited. Dudney, B., & Lehr, J. (2003). Time Saving Solutions for Struts, Ant, JUnit and Cactus. Indianapolis: Wiley Publishing. Egea, J., M., O., & Menéndez, M. R. (2006). Global Marketing on the Internet. In Encyclopaedia of E-Commerce, E-Government and Mobile Commerce (Vol. 1, pp. 530-536), Hershey: Idea Group Publishing. European Commission (2006). Definition of Small and Medium Size Enterprises. Retrieved December 15, 2006 from the website of EC Directorate General for Enterprise and Industry: http://ec.europa.eu/enterprise/ enterprise_policy/sme_definition/index_en.htm Finance Ministry of Brazil (2006). Receita Federal: Sistema Integrado de Pagamento de Impostos e Contribuições das Microempresas e das Empresas de Pequeno Porte. Retrieved December 15, 2006 from the Finance Ministry’s Internal Revenue Service website: http://www.receita.fazenda.gov.br/TextConcat/ Default.asp?Pos=2&Div=GuiaContribuinte/Simples/ Goguen, J. A., & Linde, C. (1993). Techniques for Requirements Elicitation. In Fickas S. & Finkelstein A. (Eds.), Proceedings, Requirements Engineering '93 (pp. 152-164). San Diego: IEEE Computer Society. Hekl, J., & Waack, C. (2001). What works: ViaSebrae’s e-commerce solution for small businesses. Washington: World Resources Institute. Humphrey, J., Mansell, R., Paré, D., & Schmitz, H. (2003). The Reality of E-Commerce with Developing Countries. Brighton: Institute of Development Studies. Husted, T. N., Dumoulin, C., Franciscus, G., & Winterfeldt, D. (2002). Struts in Action. Building web applications with the leading Java framework. Greenwich: Manning. Krug, S. (2000). Don’t Make Me Think! A Common Sense Approach to Web Usability. Berkeley: New Riders Publishing. Larman, C. (2001). Applying UML and Patterns. (2nd ed.). Upper Saddle River: Prentice Hall. Laudon, K. C., & Traver, C. G. (2007). E-commerce. Business. Technology. Society. Upper Saddle River: Prentice Hall. Lefebvre, L. A., & Lefebvre, E. (2002). E-commerce and virtual enterprises: issues and challenges for transition economies. New York: Elsevier Science. Lenker, J. (2002). Train of Thoughts: Designing the Effective Web Experience. Berkeley: New Riders Publishing LGMPE (2006). Lei complementar nº 123, de 14 de dezembro de 2006. (Complementary Law No. 123 from December 14, 2006). Brasília: Presidência da República. Lynch, P., & Horton, S. (2002). Web Style Guide. (2nd Ed.). Yale: Yale University Press. Electronic version retrieved on April 20, 2007 from http://www.webstyleguide.com/ Mann, C., L. (2000). Electronic Commerce in Developing Countries. Issues for Domestic Policy and WTO Negotiations. Washington: Institute for International Economics. Mansell, R. (2001). Digital opportunities and the missing link for developing countries [Electronic version]. Oxford review on Economic Policy, 17(2). Martin, R.C. (2003). UML for Java Programmers. Upper Saddle River: Prentice Hall.


MasterCard (2007a). MasterCard Merchant Services. Retrieved May 12, 2007 from http://www.mastercard.com/ us/merchant/index.html MasterCard (2007b). What You Can Do To Protect Yourself As A Merchant. Retrieved May 12, 2007 from http://www.mastercard.com/us/merchant/security/what_can_do/beyond/index.html Myers, G.J. (2004). The Art of Software Testing (2nd ed.). Hoboken: John Wiley & Sons. Nicol, C. (ed) (2003). ICT Policy Handbook. San Francisco: The Association for Progressive Communications. Niederst, J. (1999). Web Design in a Nutshell. Cambridge: O’Reilly & Associates. Nielsen, J. (1999). Designing Web Usability. Berkeley: New Riders Publishing. Nielsen, J. (2004, September 13). The Need for Web Design Standards. Useit.com Alertbox. Retrieved April 15, 2007 from http://www.useit.com/alertbox/20040913.html Nielsen J., & Loranger, H. (2006). Prioritizing Web Usability. Berkeley: New Riders Press. Electronic version retrieved April 15, 2007 from http://www.webreference.com/programming/web_usability/ Odedra-Straub, M. (2003). E-Commerce and Development: Whose development? The Electronic Journal on Information Systems in Developing Countries, 11, retrieved October 25, 2006 from http://www.ejisdc.org/ojs2/ index.php/ejisdc/article/viewFile/60/60 Robertson S., & Robertson, J. (2006). Mastering the Requirements Process (2nd ed.). Boston: Addison Wesley Professional. Roller, J.M. (2003). Struts 1.1 Controller UML Diagrams. Retrieved August 22, 2007 from http://rollerjm.free.fr/ pro/Struts11.html Rosenberg, D., & Scott, K. (2001). Applying Use Case Driven Object Modelling with UML: An Annotated E-Commerce Example. Boston: Addison Wesley. Sabrae (2007). Guia de Prefeito Empreendedor. Lei Geral de Micro e Pequena Empresa. (General Law on Micro and Small Enterprises). Brasília, Serviço Brasileiro de Apoio às Micro e Pequenas Empresas. Sachs, T., & McClain, G. (2002). Back to the User: Creating User-Focused Websites, Berkeley: New Riders Press. Electronic version retrieved on April 8, 2007 from http://wdvl.internet.com/Authoring/Design/Back/ Serasa (2007). International credit risk reports. Retrieved May 14, 2007 from http://www.serasa.com.br/ Sharma, S. K. (2006). Inherent E-Commerce Barriers for SMEs. In Encyclopaedia of E-Commerce, E-Government and Mobile Commerce (Vol. 1, pp. 627-630), Hershey: Idea Group Publishing. Silva, M. M. A. C. (2001). E-commerce in Brazil: an overview. New York: United Nations. Tigre, P. B., & O’Connor, D. (2002). Policies and institutions for e-commerce readiness: what can developing countries learn from OECD experience? Working Paper No. 189. Paris: OECD. Toland, J., (2006). E-Commerce in Developing Countries. In Encyclopaedia of E-Commerce, E-Government and Mobile Commerce (Vol. 1, pp. 308-312), Hershey: Idea Group Publishing. Turban, E., King, D., Viehland, D. & Lee, J. (2006). Electronic Commerce. A Managerial Perspective. Upper Saddle River: Prentice Hall. PCI SSC (2006). Payment Card Industry Data Security Standards. Version 1.1. Payment Card Industry Security Standards Council. UNCTAD (2004). E-Commerce and Development Report 2004. New York and Geneva: United Nations Conference on Trade and Development. UNCTAD (2005). Information Economy Report 2005. New York and Geneva: United Nations Conference on Trade and Development. Verhovek, S. H., (2000, November 3). Bill Gates Turns Sceptical On Digital Solution’s Scope [Electronic version]. The New York Times. Visa (2005). E-Commerce Merchant Guide to Risk Management. Tools and Practices for Building a Secure Internet Business. Visa International. Visa (2006). Rules for Visa Merchants. Card Acceptance and Chargeback Management Guidelines. Visa International. Visa (2007a). Visa Information for Merchants. Retrieved May 12, 2007 from http://www.usa.visa.com/ merchants/index.html Visa (2007b). 12 Potential Signs of CNP Fraud. Retrieved May 12, 2007 from http://www.usa.visa.com/ merchants/risk_management/card_not_present.html Wiegers, E. K. (2003). Software Requirements (2nd ed.). Redmond: Microsoft Press.


World Bank (2006a). List of Economies, July 2006. Retrieved December 14, 2006 from the World Bank website: http://siteresources. worldbank.org/DATASTATISTICS/Resources/CLASS.XLS World Bank (2006b). World Development Indicators 2006. Washington: The World Bank Group. World Bank (2006c). Scaling up innovation and entrepreneurship in developing countries: the role of private sector finance. InfoDev report. Washington: The World Bank Group. World Bank (2006d). Doing Business in Brazil. Washington: The World Bank Group.


13 Table of Contents of Volume 2 (Appendices) Appendix A – Project Specification .................................................................................................................... 9 Appendix B – Project Plan.................................................................................................................................13 Appendix C – Data Flow Diagrams (DFD).........................................................................................................14 Appendix D – Interviews....................................................................................................................................32

Methodology ...............................................................................................................................................32 Coverage and Practical Issues ...................................................................................................................33 Interview Notes ...........................................................................................................................................34

Appendix E – Legislation and Legal Issues.......................................................................................................42 Product Presentation...................................................................................................................................42 Liabilities .....................................................................................................................................................42 Defective Products ......................................................................................................................................43 Delivery Guarantees ...................................................................................................................................43 Prohibited Items ..........................................................................................................................................43 Exporting.....................................................................................................................................................44 List of Sources ............................................................................................................................................44

Appendix F – Analysed Best Practice E-Commerce Solutions..........................................................................45 Appendix G – Product State Transition Diagram (STD) ....................................................................................47 Appendix H – Alternative Solutions for Payments and Guarantees...................................................................48 Appendix I – Use Case Analysis .......................................................................................................................50

Actors..........................................................................................................................................................50 Use Cases ..................................................................................................................................................50

Appendix J – Apache Struts and Object-Oriented Paradigm.............................................................................68 Appendix K – Further Requirements Analysis and System Design with UML Diagrams...................................69

MSE Registration and Approval ..................................................................................................................69 MSE Account Management ........................................................................................................................74 Shopper Registration and Sign-in ...............................................................................................................84 Shopper: Products and Shops ....................................................................................................................90 Shopping Cart and Checkout ......................................................................................................................98 Shopper Account Management.................................................................................................................102 All External Users .....................................................................................................................................106 Shopping Centre Staff Access ..................................................................................................................108 Shopping Centre Staff: Products and Shops.............................................................................................110 Shopping Centre Staff: Manage Information on Shoppers........................................................................113 Shopping Centre Staff: Manage Orders ....................................................................................................114 Shopping Centre Staff: Manage Categories..............................................................................................115 Shopping Centre Staff: Transactions and Financial Information ...............................................................116

Appendix L – Database...................................................................................................................................121 Entities ......................................................................................................................................................121 Relations ...................................................................................................................................................122 Data Encryption ........................................................................................................................................124 SQL Code to Re-create the Database ......................................................................................................125

Appendix M – Interface ...................................................................................................................................131 Appendix N – Screenshots..............................................................................................................................134 Appendix O – Code Listings............................................................................................................................143

Package com.migomart.web.....................................................................................................................143 Package com.migomart.struts...................................................................................................................150 Package com.migomart.struts.admin ........................................................................................................167 Package com.migomart.struts.mse.access...............................................................................................206


Package com.migomart.struts.mse.account .............................................................................................220 Package com.migomart.struts.shopper.access.........................................................................................246 Package com.migomart.struts.shopper.account .......................................................................................264 Package com.migomart.struts.shopper.cart..............................................................................................276 Package com.migomart.struts.shopper.checkout......................................................................................277 Package com.migomart.model..................................................................................................................290 Package com.migomart.model.beans .......................................................................................................376 Configuration Files ....................................................................................................................................420 Properties File...........................................................................................................................................443 JSP Pages ................................................................................................................................................445 Scripts .......................................................................................................................................................756 StyleSheets...............................................................................................................................................758

Appendix P – Testing ......................................................................................................................................767 Presentation Layer ....................................................................................................................................767 Business Logic Layer ................................................................................................................................769 Code Inspections and Walkthroughs.........................................................................................................769 White Box and Black Box Testing .............................................................................................................769 Data Layer ................................................................................................................................................772 Character Set Issues.................................................................................................................................773 Higher Order Testing.................................................................................................................................774 Limitations.................................................................................................................................................774 Load Testing .............................................................................................................................................775 Methodology .............................................................................................................................................775 Testing scripts...........................................................................................................................................775 Results and Modifications .........................................................................................................................795 Testing with Users: Usability and Acceptance Testing..............................................................................796

Appendix Q – List of Abbreviations .................................................................................................................797

virtual shopping and payment processing centre

Documents