Abstract:
The nature of Web systems is substantially different from more conventional software systems. They are
developed in shorter timeframes, often act as the direct interface between multiple stakeholders, meet a
more generic set of requirements, and generally serve a less specific user group. They are often developed
very quickly from templated solutions, using coarse-grained authoring tools, and by the efforts of a multidisciplinary
team. There is often considerable uncertainty on the part of the client as to their own
requirements. The importance of defining the objectives of the system during the early stages of a project
are generally acknowledged to be important, but access to the tools and templates can encourage
developers to build too early. Often requirements are inadequately documented, or only emerge during
development, or change as development proceeds. The immaturity of the industry and the lack of
standardised processes in web development have been demonstrated by web-based solutions that in many
cases fail to meet fundamental requirements. Specifications for Web systems are consequently very
different from those for more conventional software systems. Apart from an increased emphasis on user
interactions and the underpinning content, they also reflect a blurring of the boundaries between
requirements, specifications and designs in the development process.
In this paper we offer an iterative model for Web systems development that incorporates the user of partial
design prototypes as a crucial stage in resolving requirements. This is derived from an analysis of the
results of a survey of commercial Web practice. In particular, we explore what this data tells us about the
nature of Web specifications, particularly looking at what is typically specified and the stage at which
certain characteristics emerge within the evolving specification. The results support the hypothesis that
within commercial Web development, design artifacts become a crucial element in supporting client
understanding and driving the formulation of requirements.
