The paper presents a e-Prototyping and shows how it helps to reveal the users' requirements in Web Engineering projects.
Prototyping, Web Engineering, Software Development.
According to Lowe and Eklund a major problem that occurs in Web Engineering projects is that the users get to know how to express their requirements very late in the process, i.e. after design artifacts have appeared [6]. The authors see the development process as a learning process among the stakeholders in which the users ability of expressing their needs enable them to understand and develop their own functionality needs. Yet, a well-founded understanding of the users' needs is a key factor for the successful development of Web-based systems [5]. Thus stakeholders and their requirements need to be identified very carefully. Many software engineering approaches use prototypes as a learning vehicle to establish communication and to build a common understanding of an application domain. Web Engineering is different from traditional software engineering [4]. Therefore, a number of questions arise when trying to adapt a prototyping, participatory, or user-driven approach to the Web, concerning e.g. how prototypes for the Web users can be built, deployed, and presented in order to support the learning process of all stakeholders of a project, how user feedback can be collected and distilled to reveal user requirements, and concerning the consequences for prototyping approaches when moving to Web Engineering.
The e-Prototyping approach has been developed in a number of iterations within two projects: the development of a Web-based community system named CommSy and an interactive municipal Web-site. Our evaluation of the projects showed that the same questions arose repeatedly and pointed at substantial problems concerning the definition of the (initial) requirements for Web-based applications, the systematic requirements gathering from the unknown or vaguely describable Web users, the promotion of communication developers and users to reveal requirements, and the question of which actors should participate in the process and how. We claim that these problems arise in many other Web projects as well but focus on public corporate Web sites.
The classical approach of building prototypes is not reasonable within Web Engineering because any software released to use on the Web will be treated as a productive system. In addition the feedback rounds with users are much more time consuming while shorter development cycles are necessary because Web users expect new versions regularly. We experienced that more different groups of actors (acting in certain arenas) are involved in Web-Projects. A crucial task and challenge is acknowledging their different perspectives by bringing the relevant perspectives into the development process within a Web project as well as giving them a voice by the use of the new channels and media.
E-Prototyping is a synthesis of the participatory, evolutionary, and cyclic software engineering approach STEPS and the view of prototyping described in [2], which differs a little from the more mainstream view on prototyping [7]. The prototyping steps Functional Selection (defining the prototypes' functionality), Construction, Evaluation (use and collection of information), and Decision on Further Use ("throw it away" or use parts of it for the real product) are being framed by the four parts of a STEPS-cycle: (1) Project/Revision Establishment, (2) production,(3) Releasing a System Version, and (4) Application of the version [3].
Figure: The e-Prototyping process as part of a cyclic development process
1. The functional selection is based on requirements gathering. However, in the area of Web applications "traditional" approaches fall short as, e.g., the user group cannot be (clearly) determined beforehand so that a systematic approach is practically impossible. The initial requirements therefore have to be anticipated by the stakeholders (members of the development teams, the (Web) provider organization, and of business partners), the so-called "steering board" (see figure). In order to reduce the time to market, to face a public discussion with the users of the new system version, and to integrate users into the development process as soon as possible, the plan for the first usable version should cover only essential functions that can easily be handled by the developing team.
2. In each cycle, construction focuses on technical and functional requirements selected. After construction the software will be released and treated as a productive system by users, although it is regarded as a prototype from the development perspective and used as "a learning vehicle". In contrast to "traditional" prototypes, it is being used in real life conditions, and is not labeled as such. Thus e-Prototypes must meet higher standards on the quality of the software, which puts an additional emphasis on the quality of the technical design.
3. The evaluation relies heavily on communicational means established in parallel to the use of each e-Prototype/release. Feedback concerning the current software version may consist of error reports (from users and system administrators), usability problems, and additional requirements of the users. The feedback is collected through communication channels. Calls for new 'strategic' applications from stakeholders to gain a competitive advantage are collected and discussed in the steering board (see figure).
4. Decisions on the further use of the software version result from taking into account the evaluation. The views of users, providers, and other stakeholders are integrated in the development process, but in the end decisions are taken from the management perspective (steering board) and form the basis of the next cycle's functional selection.
These four steps can be regarded as one cycle in an evolutionary software development process steered by the prototyping approach. The decisions taken after evaluation are input for the next cycle starting with functional and technical selection prior to the construction of the next version. Functionality of the follow-up version should be limited in such a way that the construction of the next version will not take longer than three months.
As communication between users and developers is essential for driving the prototyping process, we need communicational means to help establish some interaction with the (mostly) "unknown" Web users. This can be done by special email addresses, call-centers, or some sort of user friendly bug tracking systems. As far as possible, all contributions and calls have to be answered so that the users feel that they are taken seriously.
The management of development processes that use e-Prototyping must strive for short releases, communication, and innovation. Updates of a running Web-based application should be made at short intervals. Frequent bug fixes are required to keep the above-mentioned feedback channels clear of bug reports which leaves room for the essentials. To manage the outlined process, all feedback collected must be evaluated by a steering board.
In order to reveal the Web users' requirements basic preconditions have to be fulfilled. E.g. both sides, the developers and the users, must be willing to communicate with each other. As shown before in [1], e-Prototyping helps to build up the communication by promoting quick responses to user inquiries or notification when there is a system change related to them. In this way the users feel taken seriously and are motivated to continue communication with the developers. Short release-cycles also help to reveal user requirements by reducing white noise (e.g. bug reports) from the communication channels. Less bugs give users and developers more time to "learn" from each other. The learning process is also supported by e-Prototyping in promoting an initial system with small functionality that will extend with each system iteration.
E-Prototyping offers a way of building and deploying prototypes on the Web. It supports the learning process and presents an artefact to communicate about through the different channels suggested. It is applicable both for all programming language oriented Web projects as well as for the adaptation of commercial off the shelf products. On the one hand revealing user requirements through e-Prototyping has the disadvantage that it is combined with a loss of control on the side of the developers. On the other hand revealing user requirements and letting users participate is a precondition for a better (in the sense that it addresses the real user needs) and therefore more successful Web system. This makes e-Prototypes flexible for various project settings and enables it to be applied in combination with other Web Engineering methods which need to be tested in future projects.