The development of EC/EB systems is a new challenge for the IT departments of companies doing business in various fields, as well as for software companies that actually develop these systems. Until now, the companies' IT departments develop, maintain and adapt conventional application software systems that are specific to their field of business. They use conventional methods, tools and programming languages within a software development process that employs a conventional distribution of tasks among roles - e.g. tasks are performed iteratively and incrementally in different phases by the system designer, the developer and the programmer or other roles. However, since the market conditions are changing constantly, companies have to adapt the existing application software systems accordingly or develop new application software systems. EC/EB systems constitute one class of these new software systems. The IT departments have to face these new challenges with new methods, concepts and practices on the basis of an adapted software development process.

Electronic commerce is any kind of business transaction or market process where the involved parties (merchant and client) communicate electronically over a data network. Market processes comprise the market transactions pre-sales support, sales, distribution and after-sales support for products and services. Products and services that can be sold via electronic commerce - i.e., digital and semi-digital products and services [5], [2] - are finance services (insurances, stocks, fonds etc.), computer programs (software, shareware), cultural goods (admission tickets, magazines, books, videos, audio CDs) and travel services (train, plane and ferry tickets, hotels).

Depending on the involved parties, electronic commerce can be distinguished into "business-to-consumer (B2C) electronic commerce" or "business-to-business (B2B) electronic commerce" [12]. While the client is a private consumer in B2C, it can be a company or a government institution in B2B (the latter is also termed e-government). In both cases, we assume that the merchant is a company.

Electronic commerce systems support the involved parties in the electronic completion of their business transactions. Looking at the technical aspect, electronic commerce systems differ in many characteristics ranging from client/server architecture, network type, topology and distribution to communication protocols and services, as well as security concepts [13], [14].

Not all electronic commerce systems support all market processes electronically, but only various market transactions within one market processes. For example, catalog and shop systems are mainly suitable for pre-sales support and the actual sale. EDI systems or connected inventory systems focus on the sale in a narrower sense, rather than on pre- or after-sales support. Electronic commerce systems that solely handle pre- or after-sales support without actually offering products or services are systems that only present information, e.g. news, stock market information, weather data etc.

Depending on the way the client interacts with these systems, push or pull systems can be distinguished. In these systems, pre- and after-sales support are performed by advertising in e-mails, discussion forums, newsletters, banners or affiliate programs. Payment systems (e.g. homebanking systems or the paybox) support only the aspect of payment processing during the sale.

In the same way that conventional application software systems are developed according to conventional software development processes, special software development processes are necessary to describe the development of electronic commerce systems [3], [8]. These software development processes for electronic commerce systems partially differ from software development processes for conventional application software systems regarding the types of tasks, the order in which tasks are performed, the roles that perform tasks, and the software tools used.

In software development projects where a conventional application software system is developed, the role sales usually just has the task to sell a service (i.e. the development of a software system) and to initiate the software development project that way. While conventional application software systems are usually not used as a marketing tool but just serve sales to acquire new clients, an electronic commerce system is in part a marketing tool. For this reason, marketing is heavily involved in the requirements analysis to define the project's goal.

While conventional application software systems gain user acceptance mainly through their functionality and can be positioned against the market's competition that way, a special class of electronic commerce systems (in this example, a shop system) can gain their user (i.e. client) acceptance only through their user interface. The user interface not only presents content in a certain layout, but also guides and supports the user.

The roles that are involved in the requirements analysis of the software development process are defined based on the way the electronic commerce system is acquired and used by the merchant ("make-buy-or-rent"). Distinguished roles are manufacturer, merchant, provider and client. A manufacturer develops and distributes (directly or indirectly) a software system that a provider can use to realize an electronic commerce system. A merchant uses a software system with its given functionality to realize an electronic commerce system according to the goal he defined. A merchant can also decide to build an individual electronic commerce system by developing the software on his own. A provider provides the software and hardware infrastructure for running the electronic commerce system. For example, a provider for shop systems might be an internet service provider (ISP); a provider for EDI systems might be a clearing center (CC). A provider can be a merchant at the same time. A client uses the electronic commerce system to electronically perform market processes with a merchant (within the capabilities of the electronic commerce system).

Depending on the course of action within the software development process, the different roles are using different software tools, such as shop systems (Intershop, Openshop etc.), content management systems (Hyperwave, Gaus Inprise, Pirobase etc.) or software development/programming environments (JDK, Together J, etc.).

Because of the multitude of software systems that enable the realization of electronic commerce systems, the task of goal-oriented systems analysis, evaluation and selection during the requirements analysis has crucial significance. For example, while the merchant is responsible for maintaining the contents and the presentation of a shop system when he is simultaneously acting as provider, he only has to define the contents when he is renting a system from a provider. For rented electronic commerce systems, the provider supplies the hardware and network infrastructure and also the software tool to build the electronic commerce system. Since in this constellation, the provider strives to provide this infrastructure to several merchants in order to increase his own productivity and return on investment, he commonly uses only one software tool to realize different EC/EB systems for different merchants. In consequence, the effort for the realization of an EC/EB system can be reduced for both the merchant and the provider. On the downside, each merchant also has less opportunities for the individual presentation of his system's content.

The tasks concerning the selection of content and its presentation are associated with the systems design phase. These tasks are not included in a conventional software development process. The roles performing them are specialists for software ergonomics, didactics, graphic design and psychology.

If the integration of the EC/EB system into an existing infrastructure is necessary, methods, concepts and software tools for the integration must be available to use. Also, it must be decided if market processes for products or services should be electronically supported by an electronic commerce system. If support for products is required, the electronic commerce system has to be integrated with an open or closed inventory system of the merchant. An integration with conventional field-specific, highly individual application software systems is usually required when supporting market processes for services. These individual application software systems, termed legacy systems, are used by insurance companies, communal agencies, banks, power companies, etc. ("...back-office integration enables two or more systems to communicate with each other, and one of these systems is a company's back-office." [9] In this paper, the term "back-office" is equivalent to the term "legacy system."). In contrast, inventory systems are often offered through ERP systems of different software manufacturers (e.g. SAP, Oracle, Baan, Sage, PeopleSoft etc.). These ERP solutions provide interfaces (APIs) for the integration with other software systems. For example, this makes it possible to offer integrated solutions between Intershop and SAP, OpenShop and Sage or Oracle.

In some circumstances, the integration of several different inventory systems or individual application software systems may be necessary. This is usually the case for the implementation of electronic commerce malls or electronic commerce portals. However, an integration of systems may not be required when following the concept of "just-in-time" delivery. In this case, the integration is not performed on the level of the systems or software tools, but on the level of the user interface of the electronic commerce system.

The methods, concepts and software tools used, as well as the roles involved, depend on the way the integration is performed. For example, security aspects (use of firewalls, cryptography etc.) might have to be taken into account. These security aspects then not only have to be observed during the implementation, but also during the system draft and system design of the electronic commerce system. As another example, during pre- and after-sales support, dynamic client profiles can provide valuable information. To realize these profiles, several techniques are available (cookies, URL encoding, server-based profiles etc.) which have to be selected based on legal and technical implications.

2. The IPSI electronic commerce portal >