Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Analysis
Users/clients should not be allowed to think that requirements analysis can be skipped for e-business systems because "there's not enough time." Studies show that spending more time on analysis up front considerably reduces the chances of the system failing later on. Because requirements for e-business systems can be critical—customer or business partner expectations often include reliable, available (24 * 7 * 365), secure systems that are scalable, able to perform under high load, and able to cope with cross-country and cross-organizational transactions—it's vital to spend plenty of time up front getting these systems right.
It's a good idea to design, build, and prototype the technical architecture for critical e-business systems ahead of writing any other code, to ensure that the technical architecture really can support the requirements.
Architecture can be a massive task, for example involving getting a Web server, an application server, a content-management system, and a customer-relationship management system talking to one another. Or it might involve constructing an architecture that will support a collaborative workflow across many organizations, integrating a number of systems.
A typical e-business system may need to support any or all of the following:
-
CRM features. A great deal of interaction with the user; building up a personal profile of each customer and tailoring Web site features to meet that profile; providing self-service facilities, chat rooms, discussion groups, rating facilities.
-
PRM facilities. Shared processes/workflows across many organizations; sending parts of or whole transactions securely between organizations (WebEDI, XML); sharing data and ideas securely between organizations.
After the technical architecture requirements are gathered, the business requirements need to be gathered. Initial broad-brush impressions can be gathered in brainstorming meetings and JAD sessions. Iterative prototyping is a good way of subsequently refining requirements quickly when under pressure to meet tight deadlines, while still maintaining close interaction with users to ensure that the system does what it should.