Abstract
Keywords
1. Introduction
2. Current Practice and Research
3. Research Approach
4. Web Project Differences
5. Development Practices
6. Discussion
7. Conclusions and Future Work
Acknowledgements
Appendix 1: Interview Questions
Appendix 2: Survey Questions
References
Author Vitae
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 multi-disciplinary 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.
Web systems, specification, requirements, acceptance criteria, client needs
6200
Web systems are substantially different from more conventional software systems. They are developed in shorter timeframes and with smaller budgets, 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 multi-disciplinary team.
A key problem in Web development is that often the client will have difficulty articulating requirements at the commencement of project, particularly prior to any indication of possible solutions. They are often only able to express their requirements in terms of a solution, and are only able to formulate those requirements in any detail as the solution is developed.
In this paper we show how an iterative development process that incorporates client-developer joint exploration of partial designs facilitates the development of client understanding of their needs.
We begin in Section 2 by discussing current development processes and the limited research directions related to the development of Web systems, and in particular the limitations of this research. We also explore existing anecdotal evidence that provides a basis for the assumptions that Web development is indeed different and the claim that that partial designs have a role to play in the development of specifications. In section 3 we then describe an empirical research approach to allows us to provide stronger support for these claims.
In section 4 we then explore the collected experimental data, and justify our assertion that clients in Web projects often have difficulty understanding their needs as they relate to the technology, and how the resultant systems may impact on their business. We also look at the implications of these differences for commercial practice. In section 5 we consider the results related to current industry best practice and analyse what this tells us about which development approaches are appropriate - effectively providing evidence supporting the adoption of an iterative development of designs and requirements as a model for web development.
Finally, in section 6 we speculate about the nature of a development process that arises from the hypothesis, and then in section 7 conclude with some general observations and recommendations for ongoing work.
In this section we briefly explore the limitations of current research work and contrast this with commercially accepted development practices. We then discuss anecdotal evidence that supports an iterative development process incorporating client-developer joint exploration of partial designs to facilitate the development of client understanding of their needs.
The growing importance of Web-based systems to organisations has become increasingly evident within the last 5 years. The rapid and successful deployment of these systems is often critical to the business strategy of many organisations - particularly with respect to the way in which they interact with customers, clients, and/or business partners.
Despite this importance, these applications and the role that they can play within an organisation are often poorly understood, particularly during the early stages of their development [17]. In particular, there is significant anecdotal evidence that Web projects have particular characteristics that differentiate them from more conventional software systems [14, 15]. For example, these projects typically have tighter timeframes, increased visibility to customers, business partners and other third-parties, much finer-grained ongoing evolutionary maintenance, 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 multi-disciplinary team.
One of the more significant differences is related to the identification of requirements [16]. Web projects can be viewed as exemplars of an emerging class of applications where the client has difficulty in a priori articulating their specific needs as they relate to the system to be developed. Rather, the clients' understanding of their specific needs (indeed, the needs themselves) evolve as a system emerges and is utilised [6, 13]. We believe that this is, at least in part, a consequence of the fact that the systems extend beyond the organisational boundaries, to be utilised in a broader context. (For example, whereas a conventional software application will be utilised within an organisation to support it's business processes, most Web applications actually form the channel between the organisation and it's business partners or customers). This complicates the ability to clearly determine the system requirements.
This difficulty in clarifying requirements early in the development is partly evidenced in Web projects by the organic nature of Web systems development and especially system maintenance. Developers are increasingly adopting fine-grained incremental and iterative development cycles - facilitating early and ongoing feedback from the client that is woven into the ongoing development process [3, 8, 10, 22].
Indications were obtained in our earlier work [11, 12, 14, 15] that design artefacts actually play a crucial role in the development of the clients' understanding. If this is indeed true then these designs potentially become important in developing and clarifying the system requirements - something that is often considered anathema to conventional wisdom regarding the development process.
In traditional software development the project moves more clearly from a requirements/specification phase, through successive designs that are evaluated and refined, until the system is built. In Web development, there is far less clarity in these phases, with significant overlap. Designs are part of the build process, and lead through evaluation to a modification of specifications. Designs become successively deeper, moving from flat screens to functional prototypes, and there is an unclear distinction between the design process and the specification process, as in figure 1.
Even more fundamentally, whereas in a conventional iterative design approach the client may provide feedback on the applicability of design or build artifacts, in Web development these artifacts play a role in informing clients and supporting the formulation of their needs. In other words, the specification of the system emerges from the design, rather than preceding and driving the design. In fact, the design itself often serves as the specification in the documentation of the system.
These iterative models are believed to be appropriate at a general level for the commercial development of Web systems, however what appears to be particularly misunderstood is what features of the system should be specified and in what manner during the various stages of the development process, and how development can facilitate an understanding of client requirements. In this paper we investigate current commercial practice in specifying Web projects at various stages of development, and outline how this research has sought to gain insights into current commercial practice. We then describe a generic model for Web development, based on the survey of current commercial best practice, that incorporates the idea of client-developer joint exploration of partial designs as an integral part of the development of the system specification.
There is a small but growing body of research literature regarding the differences between Web systems and more conventional software systems. In general, this literature identifies unique characteristics of these systems that reflect technical, usability and organisational issues [3, 7, 16].
These include aspects such as: a tighter linkage between the business architecture (which are usually coupled to significant changes to the business model of the client) with both a complex information architecture and a highly component-based technical architecture [18]; increased importance of quality attributes (since applications are typically more visible externally); open modularised architectures; and rapidly changing technologies. Usability considerations reflect an increased emphasis on user interfaces and the requirement of the system to meet the needs of end users, who are more often a broader and more general demographic than for larger software systems. These considerations include both user acceptance of the system as well as making them usable - developed according to interface standards and matching user preferences and workflow. More fundamental than the technical or usability aspects are some of the developmental, or organisational, characteristics that are either unique or heightened in Web systems [3]. These include: uncertainty in the project domain; volatility of the client needs; a highly uninformed competitiveness; short delivery timeframes; and fine-grained evolution and maintenance [12, 14, 15].
Of most interest in this paper are the issues of domain uncertainty and requirements volatility. Domain uncertainty - i.e. a lack of understanding of the technology, its capabilities, and how it impacts on the way a client may operate - makes resolving requirements very problematic and the requirements that do exist tend to be very volatile. There is significant anecdotal evidence (though as of yet little hard research evidence) that clients' understanding of not only the technology's capabilities but also their own needs can change dramatically during the course of a project, as they learn more about the capabilities of the technology and how it will be likely to impact on their business processes and models. Many web projects are vision-driven rather than needs-driven leading to an initial lack of clarity. This is also coupled with business models that are non-existent, immature, or evolving rapidly as organisations migrate to an increased reliance on Web technologies [21]. These issues are exacerbated by the fact that Web projects tend to be driven by time-to-market pressures, and as a consequence shortcuts in process are used.
There is, as yet, little assistance from the research literature to be gained in addressing these issues. The design methods that have been emerging (for example, OOHDM [19] and more recently WebML [4], and various adaptations of UML [1, 5, 23]) have yet to become widely adopted, and focus on design approaches rather than understanding requirements. One exception is the work by IBM on patterns for e-Business [10], which identifies common business patterns that can form the basis of client discussions, but even this fails to address specific processes for resolving client and user requirements.
Existing software processes for eliciting, analysing and understanding requirements [20] assume that clients either understand their requirements, or at the very least understand the problem that is being addressed. Even when the client is not able to articulate their requirements precisely, they are at least able to understand whether a given design will address their needs. Our earlier work [13] supported the conclusion (that is widely held in commercial practice) that this is often not true in Web projects, where many clients not only have a poor understanding of what they want, but also of the problems being addressed by the new system. Many practitioners and researchers recommend that this problem can be addressed by the adoption of lightweight iterative and/or incremental approaches, such as eXtreme Programming (XP) [2]. These approaches allow a system to be built incrementally, thereby facilitating feedback from the client as the system develops. They do not, however, consider how the emerging designs can be used to explicitly improve clients understanding of their problem domain, and hence don't directly assist in the client's formulation of their needs.
One attempt to integrate support for Web projects directly into the development process is work on Web OPEN [9]. This extends OPEN (an object-oriented process framework) to include additional activities, tasks, and roles that are applicable to Web projects. Although a significant step forward, this work does not inherently provide guidance in structuring the process to deal with the requirements volatility.
In effect, conventional software engineering processes see requirements as preceding and driving the design process. Even where an iterative or incremental approach (such as XP) or a spiral approach (involving multiple feedback loops) is adopted the design is still viewed as a way of assisting in the identification and validation of requirements, but rarely does it help the client to actually formulate their needs. In other words (and somewhat simplistically) with conventional practices a developer is saying to the client "Do you think this design addresses your problem?" rather than the more desirable "Lets look at a design that might help you understand this technology and how it might help you".
In the context of this lack of a research focus on handling client uncertainty, and informed by our earlier work [12, 14, 15] we can speculate that design artefacts can play a crucial role in the development of the clients' understanding and consequently the system specification. We formalise this as the hypothesis that systems that result in greater client satisfaction can be developed by adopting an iterative approach that incorporates client-developer joint exploration of partial designs as an integral part of the development of the system specification.
In order to explore issues around Web specification processes and what characteristics are typically included in these specifications, we undertook an extensive set of industry interviews and surveys, followed by a detailed analysis of a number of commercial specifications. The interviews were primarily intended to identify general perceptions and qualitative trends, while the surveys captured more quantitative information. The specification analysis was intended to extract detailed information on the structure and contents of commercial Web system specifications. The overall goal was to understand current best-practice in the specification of Web systems.
The companies that indicated a high project success rate, and effective client interactions, were approached regarding obtaining samples of specifications for analysis. These companies covered multimedia development, Internet development, and intranet development. Their core businesses varied considerably from consulting and contract development to in-house development. The industries that they serviced also covered a broad spectrum: financial institutions, medical agencies, travel and tourism, legal, manufacturing, government, e-commerce retail, and consumer advisory services.
The interviews were conducted over a period of 6 weeks, primarily during April/May 2000, were typically 20-40 minutes and involved a series of questions focusing on interactions with clients and the processes for understanding client needs. Transcripts of the surveys were analysed to identify areas where there was either significant differences or significant congruence of opinion. Details of the questions asked in the interviews are given in Appendix 1. The survey questions are provided in Appendix 2.
A total of 23 interviews were carried out. The interviewees were selected based on a mailout request to 32 Web development companies and a subsequent telephone follow-up (i.e. a 72% response rate). The interview questions were designed by analysing the core issues identified in the literature. It is important to note that this stage of the research is not intended to prove or disprove specific hypotheses, but rather to provide sufficient information on which detailed hypotheses could be based for ongoing work.
Of the interviewees, 18 also completed the online survey. An additional 38 participants completed only the online survey. This gave a total of 56 responses (47 from an e-mail sent to 148 potential participants, with an additional 9 responses from unsolicited sources). All respondents were from within Australian industry and so care would need to be taken in extrapolating to an international context.
Prior to considering the core focus of this paper - the role of designs in supporting development of client understanding - we can comment briefly on the support within the empirical data for the key assumption that clients typically have a poor understanding of the ways in which the technology can be utilise to their advantage, and how this may impact on their business models. A more complete coverage of this issue, and the relevant survey and interview data, is given in [12].
The companies that took part in the research interviews covered a broad spectrum of development areas (multimedia, Internet, and intranet development), application domains (financial institutions, medical organisations, travel and tourism, legal, manufacturing, government, etc.), and company sizes. The projects of individual companies varied greatly in complexity and cost: the range was from $2,000 to $50 million with the average company working on contracts ranging from $100,000 to $1 million. Interestingly, there was generally a low correlation between cost and scale variables such as number of source documents and number of resultant client pages. The frequency of content changes had a surprisingly high correlation. Numerous respondents felt that hidden costs were a major issue in projects (average of 3.4 on a scale of 0=strongly disagree to 5=strongly agree), and that clients have difficulty understanding the implications or details of project bids (average of 3.4).
There was a very strong feeling (average rating 4.4 on a 0-5 scale) that clients did not well understand the capabilities of the technologies. Similarly it was felt (average rating 4.2) that clients did not understand their own needs as they related to the technology. Perhaps surprisingly, anecdotal evidence indicated that respondents felt that clients had a low understanding of their own organisations and existing processes (most of the time undocumented) that need to be changed to allow for the effective integration of the new system. There was a majority consensus (i.e. 83% responding as Strongly Agree or Agree) that there needed to be a process at the beginning of the projects focussed on educating their clients.
Almost all respondents (96%) stated that they interviewed clients as part of the process for identifying requirements. A much smaller number (58%) felt that interviewing potential users was important. The majority of respondents (84%) found that the look and feel and content issues were secondary to the business case. Interestingly, critical success factors (i.e. acceptance criteria or essential requirements) were brought up only by 5% of respondents as a vehicle for capturing the business case. The majority of respondents (78%) indicated the importance of getting the requirements and specification correct - though there was considerable divergence of opinion as to when this should occur. Most of the respondents attempt to capture requirements before they sign final contracts. It was also recognised (by 72%) that initial tendering often occurs before this point - leading to a two-step contract negotiation. Essentially all (94%) respondents recognised that client needs will change and evolve over the life of a project, despite a well-written requirements specification. Most respondents felt that this was a consequence of evolving client understanding.
Several respondents indicated that the client might dictate the specific process - though this was uncommon. Some clients were seen to be happy to commit to a budget (during the tender process) based on broad business objectives, and then finalise the contract at a later stage based on specific analysis of the detailed requirements. The scope of the contracted requirements is typically constrained by retaining a focus on the business case and establishing that there is good basis for specific detailed requirements.
One very important observation that needs to be made, and which might potentially impact on the approach taken to Web development is that the survey data indicates that clients have an initially poor understanding of their needs and this evolves during the project. It does not indicate that clients are aware of this problem! Indeed, the comments and data related to the need to educate clients would support the conclusion that clients are often not initially aware of these problems.
There were a number of areas where there was divergence of views. In particular, a number of these differences of opinion highlight potential uncertainty within the industry - and potential for incorrect assumptions regarding this research. The key statements that relate to this work and that generated significant differences in the levels of agreement were:
We interview the clients to determine requirements
We interview intended users to determine requirements
It is important to respond to changes in user requirements as they occur
Changes in the user requirements require the site or application to be renegotiated. We often have difficulty in the relationship with clients
We prefer a single client liaison
It is important to identify technologies to use as soon as possible
It is important to be able to modify the system once it is completed
These would seem to indicate a degree of confusion, not about client understanding, but about how that might potentially be addressed - though this would need further investigation to be confirmed.
Given that there is a reasonable degree of support for the conclusion that clients of Web projects have difficulty in understanding the way in which technological solutions can benefit them and how it might change their business, we need to consider how this can be addressed. We have hypothesised that systems that result in greater client satisfaction can be developed by adopting an iterative approach that incorporates client-developer joint exploration of partial designs as an integral part of the development of the system specification.
Expressed slightly differently, we can describe a design-driven specification process, where designs are jointly used by the developers and clients to develop an understanding of the required system. Given the lack of initial clarity, we would argue that this exploration needs to be iterative in order to allow suitable progressive refinement. So, can we find empirical evidence to justify the claim that such an approach is appropriate and effective? We again begin by looking at what the collected data tells us about industry practice.
The quantitative data from the survey provided some interesting results. We had a relatively strong negative correlation (-0.69) between agreement with the statement It is important to understand the user requirements totally before starting development and agreement with the statement The client is generally satisfied with the resultant system. Although correlation does not imply causality, it does support the conclusion that attempting to understand all requirements prior to commencing design actually creates a solution that does not satisfy (final) client needs. Further investigation on this point is, however, important. We also found a strong negative correlation (-0.73) between the level of agreement with the statement We usually undertake early stage prototyping and the level of agreement with the statement Our clients have difficulty understanding the implications or details our project bids. Both these results are consistent with the view that early prototyping of designs can assist in client understanding.
More qualitatively, in the transcribed interviews we found a very strong consensus (83%) that clients' typically need to see concrete designs in order to gain an adequate understanding of the detailed needs for a system and how it will impact them.
The interviewees were also asked whether they felt that clients typically have a poor understanding of their own needs and what the technology is capable of providing them? and whether this changed during the project. Anecdotally, the responses indicated that clients understood their needs poorly at the beginning of the project but that it developed during the project. This also came through in the response to the question: Do you find that client requirements, needs or expectations evolve significantly during the course of a project? What brings this about? How are these changes handled? The interviewees responses indicated that this was a consequence of an evolving client understanding, which in turn was a result of their ability to see the emerging system and how it related to their business.
The response to the question: Are most of the client needs captured before or after signing a contract for the project? was particularly interesting. A notable percentage (38%) of the developers indicated that they often adopted a two-step negotiation specifically because of client uncertainty. The first step involved a contract (usually based on an hourly rate or equivalent) for the development of a specification. The second step would then involve another contract (usually fixed price) for the system build.
By far the most significant observation from the interviews and surveys is that many aspects that would conventionally be regarded as "requirements" (in the sense that they express characteristics of the system that are desired by the client) emerge in commercial specifications after design artifacts have appeared. Indeed many of the requirements are actually expressed as part of a design.
This is consistent with the hypothesis that the design process plays a critical role in reducing the domain uncertainty inherent in most Web projects. It also confirms what is generally understood by experienced developers - that clients might understand their existing systems, but not necessary the nature of the problem that appears as a result of the emerging systems, and that therefore requirements cannot be elicited independently of any designs being presented.
It is also interesting to note that, apart from general performance constraints, broad architectural elements, and decisions about technical platforms, most of the functional characteristics often did not emerge until late in the specification process - being deferred to the specific build specification. Conversely, many of the informational characteristics emerged somewhat earlier in the process. For example, decisions about media types, interface metaphors, look and feel, content structure were all made at the architectural level, before the key system functionalities were finalised. This reflects a perception about the importance of the user experience in determining the ultimate quality of a Web system.
On the basis of the analysis of the survey, we propose a generic process of Web development that is both iterative and utilises design prototypes to assist the client in exploring possible solutions (and what these tell them about the problems being addressed) and hence formulating requirements.
We can model this process in various ways. Two representations that we have found particularly helpful are shown in Figures 2 and 3. In Figure 2 we can see that the process involves two key cycles. The first cycle - an exploration cycle - is where developers repeatedly build prototypes and explore them with the client, obtaining feedback and distilling from this information on the client needs in order to progressively build a specification. The purpose is very specifically to develop a joint understanding rather than building the system.
Once sufficient understanding has been developed a build contract can be negotiated and the build cycle commenced. This again will typically be iterative, and both the client understanding and the specification is likely to continue to change. The development in this case is aimed at actually constructing the system.
Figure 3 is an alternative view of the same process. In this view we can see that the exploration and build cycles essentially involve the same general activities - but serve different purposes.
In this paper we have analysed current commercial practice with regard to the management of requirements for Web projects. Specifically, we have focused on how and when requirements are identified. The work described is focused on investigating commercial practice and is empirical in nature.
The results have provided strong support for the hypothesis that the design process is critical in supporting not only the identification of client requirements, but also in the actual formulation of their needs. In other words, commercial practice can be described as a form of design-driven requirements elicitation, with many of the requirements being documented within the design space. This implies that the design activities need to be carried out in a way that actively allows volatile requirements to be supported and managed.
Indeed, the insights in this work can potentially inform the ongoing development of the emerging Web design notations and processes. We believe that it is not sufficient to be able to design a system to satisfy a known need. Rather, we need to be able to design solutions that allow the exploration of a range of possible solutions.
Considerable work still remains to be carried out in this area, both in terms of further validation of the underlying hypothesis, and in more detailed exploration of the proposed process. In particular, it would be important to understand how developers (and analysts in particular) can distil requirements from prototypes and the associated client feedback. This involves a clearer theoretical framework for understanding client uncertainty and how various prototypes reduce this uncertainty.
The authors wish to acknowledge the collaborative funding support from the Australian Research Council, Access Online Pty Ltd and Allette Systems Ltd. Under grant no. C4991-7612. In particular we wish to thank Vassiliki Elliott, Ross Jeffery, Louise Scott, Lucila Carvalho, John D'Ambra, Nick Carr and Marcus Carr for their contributions to this research project.
We also wish to acknowledge the valuable contributions of the numerous companies and individuals who participated in the industry interviews and surveys.
The following is the information collected, and questions asked, during the structured interviews.
Q0a: Company Name
Q0b: Respondents Name
Q0c: Respondents Position
Q1a: What is your primary business?
Q1b: Does your company target a specific business domain?
Q1c: Approx. how many employees would you have involved in interactive media or web development?
Q1d: What is the complexity of the applications that you develop? Can you describe the types of technologies you use and the scale of the projects that you typically handle?
Q2a: Does a single person handle all liaisons with clients for a specific project?
Q2b:If a developer finds an issue that isn't covered by the information available from the client, how is this typically resolved?
Q2c: Does the client explicitly sign-off on the requirements that you identify? At what stage does this occur?
Q2d: How are changing requests from the client handled once development is underway?
Q3a What types of things typically would you identify from the client? (Eg. Content, look and feel, existing information sources, current workflows, etc.)
Q3b: What aspects are clients typically least aware of?
Q3c: Which aspects make the biggest difference with respect to the cost of the project? The ultimate success of the project? Why?
Q3d: Do you feel that clients typically have a poor understanding of their own needs and what the technology is capable of providing them? Does this change during the project?
Q4a: Are most of the client needs captured before or after signing a contract for the project? What types of requirements are identified before? After?
Q4b: Do you find that client requirements, needs or expectations evolve significantly during the course of a project? What brings this about? How are these changes handles?
Q4c: Do you have a standard pro-forma for documenting client requirements? Is this adhered to consistently?
Q4d: Is the project evaluated against and then signed off against the original requirements at the end of a project?
Q4e:Is the documentation on client requirements typically maintained?
Q4f: At what point is the contract typically renegotiated?
The following is an illustrative subset of the questions asked in the online survey.
Question 5: Project Costing:
a. Rate each of the following according to the extent to which you agree with the statement (by circling the relevant number): [6 point scale from Strongly Disagree to Strongly Agree]
Question 7: General perceptions of process
a. Rate each of the following according to the extent to which you agree with the statement (by circling the relevant number): [6 point scale from Strongly Disagree to Strongly Agree]
Question 10: Development processes: Rate each of the following according to the extent to which you agree with the statement (by circling the relevant number): [6 point scale from Strongly Disagree to Strongly Agree]
Question 13: Client Interaction: Rate each of the following according to the extent to which you agree with the statement (by circling the relevant number): [6 point scale from Strongly Disagree to Strongly Agree]
Comments:
[1] Baumeister, H., Koch, N. and Mandel, L., Towards a UML Extension for Hypermedia Design. in UML 1999, (1999), 614-629.
[2] Beck, K. Extreme Programming Explained. Addison-Wesley, 1999.
[3] Burdman, J. Collaborative Web Development. Addison-Wesley, 1999.
[4] Ceri, S., Fraternali, P. and Bongio, A., Web Modeling Language (WebML): a modeling language for designing Web sites. in Proceedings of WWW9 Conference, (Amsterdam, 2000).
[5] Conallen, J. Building Web Applications with UML. Addison-Wesley, 1999.
[6] Dart, S. Configuration Management: The Missing Link in Web Engineering. Artech House, 2000.
[7] England, E. and Finney, A. Managing Multimedia: Project Management for Interactive Media. Addison-Wesley, 1999.
[8] Fournier, R. Methodology for Client/Server and Web Application Development. Yourdon Press, 1999.
[9] Henderson-Sellers, B., Haire, B. and Lowe, D. Adding Web Support to OPEN. Journal of Object Oriented Programming, 14 (3). 34-38.
[10] Lord, J. Patterns for e-business: Lessons learned from building successful e-business applications, IBM, 2000, 4.
[11] Lowe, D. A Framework for Defining Acceptance Criteria for Web Development Projects. in Murugesan, S. and Deshpande, Y. eds. Web Engineering: Managing Diversity and Complexity of Web Application Development, Springer-Verlag, 2001, 279-294.
[12] Lowe, D. and Eklund, J., Commercial issues in specification of Web systems. in AWRE'2001, (2001).
[13] Lowe, D. and Elliott, V.V. Web Requirements: An Overview. submitted to Requirements Engineering Journal.
[14] Lowe, D. and Henderson-Sellers, B., Impacts on the development process of differences between web systems and conventional software systems. in SSGRR 2001: International Conference on Advances in Infrastructure for Electronic Business, Science, and Education on the Internet, (L'Aquila, Italy, 2001), Scuola Superiore Guglielmo Reiss Romoli, 21.
[15] Lowe, D. and Henderson-Sellers, B. Web Development: Addressing Process Differences. Cutter IT Journal.
[16] Overmyer, S. What's Different about Requirements Engineering for Web Sites? Requirements Engineerng Journal, 5 (1). 62-65.
[17] Reifer, D.J. Web Development: Estimating Quick-to-Market Software. IEEE Software. 57-64.
[18] Russell, P., Infrastructure - Make or Break your E-Business. in TOOLS-Pacific 2000: Technology of Object-Oriented Languages and Systems, (Sydney, Australia, 2000).
[19] Schwabe, D. and Rossi, G. The Object-Oriented Hypermedia Design Model. Communications of the ACM, 38 (8). 45-46.
[20] Sommerville, I. and Kotonya, G. Requirements Engineering : Processes and Techniques. John Wiley and Sons, 1998.
[21] Stein, L.D. Profit, the Prime Directive. WebTechniques, 5 (11). 14-17.
[22] Thomas, D., Managing Software Development in Web Time Software. in XP2000, (Cagliari, Italy, 2000).
[23] Vilain, P., Schwabe, D. and Souza, C.S.d., A Diagrammatic Tool for Representing User Interaction in UML. in UML'2000, (York, U.K., 2000).
Associate Professor David Lowe is the Associate Dean (Teaching and Learning) in the Faculty of Engineering at the University of Technology, Sydney. He has active research interests in the areas of Web development and technologies, hypermedia, and software engineering. In particular he focuses on Web development processes and web project specification and scoping, and information contextualisation. He has published widely in the area, including several texts (Lowe and Hall, Hypermedia and the Web: An Engineering Approach, Wiley, 1999 and Wilde and Lowe, Transcluding the Web: Linking and XML, Addison-Wesley (currently in preparation)). He has published over 65 refereed papers. He is on numerous Web conference committees and is the information management theme editor for the Journal of Digital Information. He has undertaken numerous consultancies related to software evaluation, Web development (especially project planning and evaluation) and Web technologies. A/Prof Lowe can be reached at The University of Technology, Sydney; P.O. Box 123, Broadway, NSW 2007, Australia. Telephone +61-2-95142526; Email: david.lowe@uts.edu.au.
