TOWARDS ENHANCED AUTOMATED SUPPORT FOR COLLABORATIVE SOFTWARE REQUIREMENTS MANAGEMENT Michael Lang 1, Jim Duggan 2
Abstract The development of information systems is not merely a difficult technological challenge, but is also a complex social process within which the effectiveness of communication between stakeholders is vital to a successful outcome. In particular, the communication of software requirements is extremely problematic. This paper is founded on the proposition that, because the System Requirements Specification (SRS) is a highly dynamic document that grows and evolves throughout an IS development project, and is of interest in a variety of ways to a multi-disciplinary and potentially distributed team of stakeholders, its management ought to be a collaborative process supported by an automated tool. Furthermore, such a tool must anticipate and consider communication issues that arise within multi-disciplinary teams. We argue that most commercial requirements management tools presently available do not provide adequate support for communication and collaboration within multi-disciplinary teams. In view of the shortcomings of commercial tools, we present a series of recommendations that aim to guide tool developers towards the provision of enhanced automated support for collaborative software requirements management. 1. INTRODUCTION The objectives of the software requirements management process are to develop a shared, documented understanding of the requirements (in the form of the SRS), and to enforce a mechanism to control volatility so that the system satisfactorily fulfils requirements at the time of its delivery (Faulk, 1996). Inadequacies in the SRS can have a crippling effect, - it is therefore vital that requirements be carefully managed on an ongoing basis. Individually, requirements should be feasible, precise, complete, consistent, and verifiable. As a whole, a set of requirements should be complete, prioritised, organised in a clear structure, traceable, and 1
Department of Accountancy and Finance, National University of Ireland, Galway. University Road, Galway, Ireland. Email:
[email protected] Tel.: +353 91 750301 Fax: +353 91 750565 2 Department of Information Technology, National University of Ireland, Galway. University Road, Galway, Ireland. 1
2
M. LANG, J.DUGGAN
maintainable. Above all, requirements must be communicable (Davis et al, 1993; Faulk, 1996; Kar and Bailey, 1996). The root causes of software’s “chronic crisis”, - ambiguous requirements, unclear objectives, unrealistic expectations, absence of appropriate contact with users, and difficulties in co-ordinating the development team, - are requirements management issues. Fundamentally, these are problems of ineffective communication or ineffective collaboration. Of course, for collaboration to be effective, communication must also be effective, hence communication and collaboration are inextricably bound concerns. It is therefore surprising that such little attention has been explicitly directed towards issues of human communication in mainstream IS development literature, or to how those issues impact upon IS development. Many of the beliefs and values that underpin current IS development practice are so culturally embedded that they have almost become accepted as de facto truisms. Moreover, the legacy of earlier generations has been subliminally perpetuated within this set of beliefs, even though the profile of IS development has changed profoundly over the years (Fitzgerald, 1999). For example, the traditional “waterfall” SDLC model was devised in an era when online interactive information systems barely existed, yet this model and its variants remain in popular usage (Barry and Lang, 2001), despite its well acknowledged communicational shortcomings (Grudin, 1993). There also remain the questionable beliefs that systematic, formalised methods and techniques are good, necessary and sufficient, and that analysis and design activities can and should be separated. At one level, these may be considered to be process issues, but at a more basic level, they are issues of communication and collaboration, both between the development team and the client, and within the development team. In many ways, IS development methodologies are essentially communication methodologies (AlRawas and Easterbrook, 1996). At present, IS development is again undergoing another radical shift as systems are moving into the Web-based world and embracing multimedia technologies (Lytinnen et al, 1998; Barry and Lang, 2001). More so than ever before, software development teams are composed of individuals from multiple disciplines. Furthermore, these teams are often geographically distributed. Of course, skills diversity is not unique to Web-based systems development, - many “conventional” projects, particularly large ones, necessitate the integration of various knowledge domains (Walz et al, 1993). However, participants in conventional systems development tend to be primarily “computer professionals”, which is typically not the case with multimedia / Web-based development. In particular, there are paradigmatic differences between “artistic” disciplines, such as graphic design, and “scientific” disciplines, such as software engineering, whereby these rival communities appear to operate in distinctively different worlds (Gallagher and Webb, 1997). Within this emerging context, it is fitting to re-examine the underlying models and metaphors which shape our thinking of IS development. We submit that because legacy perspectives of IS development failed to give adequate consideration to multi-disciplinary communication issues, those issues have not been anticipated in the construction of tools, techniques, and methods for IS development. 2. RESEARCH METHOD Drawing from the literature in the areas of requirements management, communications theory, and co-operative work systems, the authors derived a core set of requirements that a tool for collaborative software requirements management should address. The next step was then to assess the extent to which currently available requirements management tools fulfil these requirements. There are so many commercially available tools
TOWARDS ENHANCED SUPPORT FOR COLLABORATIVE REQUIREMENTS MGT
3
that claim to support the requirements management process, or part of it, that it was impractical to perform a detailed assessment of them all. We therefore adopted an evaluation methodology with the objective of reducing this extensive set of tools to a select few “best-inclass” products. Tools that did not meet mandatory requirements were automatically eliminated. The remainder underwent closer inspection, based on the match of product features to prioritised requirements. From this assessment, a shortlist of about ten leading tools was compiled, each of which were subjected to detailed evaluation. On the basis of this evaluation, we present a number of recommendations which we hope shall inform the future design of requirements management tools.
Literature Trawl: •Requirements Management •Co-operative Work •Communications Theory
Requirements of a Tool to Support Collaborative Requirements Management
Features of Commercial Requirements Management Tools
Evaluation of Currently Available Tools
Recommendations for Enhancement
Requirements Management Tools Data: •Datasheets •Brochures •Demonstrations •Evaluation Releases
Figure 1. Research method.
3. SYNTHESIS OF COMMUNICATION ISSUES Human communication has been the subject of research and experimentation by philosophers and social scientists from the times of Aristotle to the present day. As such, it is a mature field of study, and there is general agreement on a model of human communication, although the components of that model, and the process itself, are complex and not fully understood (Adler, 1988). Initially, thoughts are formed within the human brain as unverbalised mental pictures. Human communication commences when an individual starts to encode these mental pictures into a recognised language that is understandable by others. Once a message is encoded, it is then transmitted via one or more channels to the receiving party. When the recipient receives the message, he must decode and interpret it. This is the reverse of encoding, and it presupposes that the sender and the recipient use a common, shared language. Normally, the recipient of a message would then send some discernible response; that is, feedback. We illustrate this process by the simplified model presented in Figure 2, an adaptation of the wellknown framework proposed by Shannon and Weaver (1949). This model suggests that, if the communication is successful, both participants should form similar mental pictures of the message subject after an appropriate period of interaction and incremental refinement.
4
M. LANG, J.DUGGAN
A key factor in the effectiveness of communication is the similarity between the “environments” of the sender and the recipient of a message, – that is, the closeness of their respective backgrounds and cumulative experience. Individuals with different environments perceive things differently, and this is a principal cause of misunderstandings. In Figure 2, the ovals denote the scope of the environments of the participants in the communication process. The overlap between these environments signifies shared knowledge and experience, – the greater this overlap, the more effective the communication.
Noise
Noise
Encodes
Message
FIRST PARTICIPANT
Decoded by Channel(s) SECOND PARTICIPANT
Channel(s)
Response
Decodes
Noise
Noise
Encodes
Noise
Noise
Figure 2. Model of interactive human communication.
The effective communication of software requirements is a formidable challenge, and requirements definition in particular is a communication-intensive process wherein difficulties abound (Hutinski et al, 2001). Misunderstandings in IS development are common, and that they frequently cause disturbances (Curtis et al, 1988; Enquist and Makrygiannias, 1998). The communication model presented above provides us with a useful basis upon which to reason about these misunderstandings. Firstly, it is very difficult to form a mental picture of a software product. Information systems are amongst the most complex artefacts that humans have ever created, and are becoming increasingly more sophisticated as “our ability to imagine complex applications will always exceed our ability to create them” (Booch, 1994). The use of metaphors, such as the popular “desktop” metaphor used by GUI designers, has proven useful in the past in helping to visualise the conceptual architecture of information systems. However, the use of physical metaphors in this way is greatly constrained by the fact that software is entirely unlike anything in the physical world. Rather, it exists in an abstract virtual world that is largely intangible, arbitrary, malleable, amorphous, indeterminate, and in constant flux. It is becoming increasingly difficult to devise appropriate metaphors to describe this virtual world, as is evidenced for example by the debate on the nature of the Internet and cyberspace (Palmquist, 1996). Secondly, there arises the matter of a common lingua franca. Software requirements management necessitates ongoing communication between stakeholders from a diversity of disciplinary backgrounds, all with different interests, priorities, and levels of expertise (Faulk,
TOWARDS ENHANCED SUPPORT FOR COLLABORATIVE REQUIREMENTS MGT
5
1996; Enquist and Makrygiannias, 1998; Holtzblatt and Beyer, 1995). Specification techniques that were devised primarily for communication amongst teams of analysts/programmers are not appropriate for communicating with non-technical stakeholders. In particular, the use of formalised§ modelling techniques has long been popular in IS development. The chief advantage of such techniques is that, because the semantics and semiotics of the modelling notations are rigorously defined, they do not readily lend themselves to multiple interpretations, and can be automated and validated by CASE tools. On the other hand, these techniques are rather abstract and can be difficult to understand. While certain authors assert that most formalised modelling techniques may be easily learnt by “computer-naïve personnel” (Davis, 1988), there is a strong counter argument supported by empirical evidence that non-technical stakeholders are disadvantaged when asked to validate models, and that such techniques may therefore be insufficient, or even useless, as communication aids (Holtzblatt and Beyer, 1993; Bødker et al, 1993; Enquist and Makrygiannias, 1998). Furthermore, it is important to emphasise that logical design models are not the end deliverable of an IS development project, rather they are a means to the end, which is of course a functional system. Given that developers now often find themselves having to rapidly turn around projects in compressed timeframes (Barry and Lang, 2001; Fitzgerald, 1999), working with “I’ll know it when I see it” requirements, it is perhaps not surprising that there is a trend towards the increased use of intuitive, informal techniques such as prototyping and storyboard sketches (Barry and Lang, 2001; Landay and Myers, 2001). It may be argued that, rather than pondering over terse models, developers should “just do it!”. While this may seem the very antithesis of disciplined approaches, it is not such an abominable notion as it may at first appear. Here, we refer back to our earlier point regarding the entrenched beliefs that permeate IS development literature, - the use of formalised modelling techniques is often assumed to be good and necessary, and, moreover, the failure to use formalised modelling techniques is often assumed to be bad and “sloppy”. It would appear that the rationale behind the use of formalised modelling techniques is that (1) it is possible to reduce the problem context into a conceptual representation that is both accurate and complete; (2) it is possible to then implement this representation; and (3) it is wrong to begin implementation without having first explicitly defined a conceptual representation. These assumptions may all be turned on their heads, given that developers now have rapid, visual, component-based construction tools at hand. What may have been true in the COBOL era is no longer necessarily true in the Visual Basic era. It is now possible to build, validate, rebuild and reverse engineer software applications so comparatively easily and quickly that conceptual modelling and physical implementation effectively overlap. The advent of these visual development tools mean that requirements may now be communicated at a higher level of abstraction that is much more natural than that afforded by formalised modelling techniques based on symbol sets. Thirdly, there is the matter of the proximity of the “environments” of the participant stakeholders to each other. It is typically the case in requirements definition that, at the outset of a project, the end-user has an expert understanding of the operational context, and the developer has a well-informed grasp of technology, but each may be a comparative novice in the environment of the other (Hofmann, 1993). As earlier stated, given that development teams are becoming increasingly multi-disciplinary, there is also the problem, particularly in Web-based / multimedia IS development, of reconciling the “artistic” traditions, such as graphic design and media production, with the “scientific” traditions, such as software §
Throughout this paper, we prefer to use the word “formalised” as opposed to “formal” to refer to systematic techniques, to avoid potential confusion with that set of techniques known in the literature as “formal methods”.
6
M. LANG, J.DUGGAN
engineering. Communication in requirements management must therefore be an ongoing process, whereby users, developers and other stakeholders continually exchange knowledge, thereby altering perceptions, shifting expectations, and eradicating false assumptions (Holtzblatt and Beyer, 1993). Fourthly, there is the issue of the use of communication channels in requirements management. Human communication rarely takes place via a single channel; rather, it is common to use many channels, often simultaneously (Adler, 1988). In IS development, it is important that many direct channels of communication are kept open between users and developers (Keil and Carmel, 1995). Of course, it is also vital that channels be open amongst the development team. Traditional barriers include geographic separation; the potentially alienating impact of task specialisation; organisational reporting structures; and closed, proprietary standards and protocols. In recent years, the development of Internet-based workgroup systems has greatly overcome these barriers by opening channels that were theretofore blocked or non-existent. There remains however the problem that communication channels in IS development are often one-way, yet another relic of the traditional SDLC approach and the “throw it over the wall” mentality that it encouraged (Al-Rawas and Easterbrook, 1996). 4. ASSESSMENT OF REQUIREMENTS MANAGEMENT TOOLS Most of the advances in software development tools and techniques over the last three decades have focused on productivity rather than quality, and have been primarily concerned with the work of individuals. Given that IS development is a team-based process, what is now required is a means to boost the productivity and quality of work performed by teams. Quite often, IS development teams are dispersed at geographically distributed sites, which greatly complicates communication and collaboration. On account of the size and complexity of modern IS development projects, the use of an automated tool to support the difficult process of managing requirements is believed to be potentially beneficial. It is not surprising therefore that reported sales of requirements management tools have been growing steadily in recent years (Standish Group, 1998). There are so many tools currently on the market that claim to support the requirements management process, or part of it, that it is neither reasonable nor possible to perform a detailed assessment of them all. In order to conduct a meaningful assessment, it is therefore necessary to firstly identify the core requirements of a tool for collaborative requirements management, and then to evaluate the features of commercial requirements management tools against these requirements. The requirements of a requirements management tool are well established in the literature, in the form of good practice guidelines (Sommerville and Sawyer, 1995), critical evaluations of existing tools (James, 1996; Grady, 1996), use case scenarios (Gabb, 1997), and tool selection criteria (Jones et al, 1995; Gabb, 1997). In consideration of these requirements, the authors conducted a review of vendor offerings. A shortlist of currently available “best-inclass” requirements management tools was compiled. These tools were then evaluated in detail so as to determine overall strengths and weaknesses. While most of the short-listed tools fulfil all or nearly all of the requirements with varying degrees of coverage, a number of prevalent weaknesses were observed, outlined as follows.
TOWARDS ENHANCED SUPPORT FOR COLLABORATIVE REQUIREMENTS MGT
7
4.1. Usability Issues There are copious examples of requirements management tools becoming “shelfware”, primarily because of incompatibilities with existing processes or because of a perception that the advantages the tools provide do not outweigh the difficulty and effort in using them (Gabb et al, 1997). As earlier discussed, stakeholders in the requirements management process may come from a diversity of background disciplines. If we accept the argument put forward by the proponents of participative and democratic development approaches in favour of the merits of inclusiveness, it follows that any tool to support requirements management must anticipate and cater for different types of stakeholder profiles. However, some tools that are marketed as requirements management tools would better be classified as CASE tools, in the sense that they are intended for use by skilled specialists who are proficient both in software engineering methods and the functionality of the tool itself. Because of the complexity of such tools, and of the artefacts that they produce, they are impractical for communicating with non-technical stakeholders. 4.2. Imbalanced Choice of Specification Techniques It is recommended practice that requirements should be described using both userfavoured methods, such as natural language, and developer-favoured methods, such as formalised model diagrams, to enhance communication and to achieve a balance between technical clarity and general understandability (Sommerville and Sawyer, 1995). Few of the tools evaluated achieve this balance. Some, akin to enhanced word processing tools, are document-based with support for narratives, annotations and semi-structured natural language descriptions, but provide little or no modelling / prototyping capabilities. Others, more akin to CASE tools, have strong modelling capabilities but are restrictively rigorous, as they do not permit natural language or other highly expressive media such as rich pictures. Very few support compound multimedia documents. This apparent dichotomy between, on the one hand, rigorous engineering tools, and on the other, loose and expressive documentation tools, has also been observed by others (Gabb et al, 1997). The differences in priorities and emphases means that essentially they may be categorised as (1) tools for those who have “experience with requirements rather than specifications”, or (2) tools for those who have “experience with specifications rather than requirements”. Of course, an obvious workaround for this difficulty is, rather than using a single all-inclusive tool that encompasses informal and semi-formal specification techniques alongside formalised techniques and prototyping capabilities, to use an integrated toolkit of two or more specialised tools that dovetail together as a suite, - for example, a documentation component, a modelling component, a prototyping component, and so forth. This is fine in theory, but in practice it has always been difficult, both technically and operationally, to achieve effective integration, as is evidenced by the findings of Hutinski et al (2001). 4.3. Lack of Support for Collaborative Work The orientation of quite a few tools is towards the stand-alone work of individual users, even though the importance of technological support for co-ordinated teamwork is widely accepted. None of the tools evaluated provide appropriate support for the collaborative work of a multi-disciplinary, distributed team where the stakeholders have diverse skills and needs. This issue has a number of aspects. Firstly, as earlier outlined, there is the imbalance between
8
M. LANG, J.DUGGAN
formalised and informal specification techniques, which tends to alienate technical stakeholders from non-technical stakeholders. Secondly, there is the problem of incompatible data interchange formats and incompatible or closed operating environments, - for instance, some of the tools run only under Microsoft Windows or specific versions of UNIX, or are founded upon proprietary database standards, - meaning that those tools are not interoperable or openly accessible. Thirdly, few tools provide adequate support for collaborative authoring, remote access, or distributed data. This would involve the definition of stakeholder profiles, privileges and roles, as well as the engagement of appropriate locking and synchronisation mechanisms. 5. RECOMMENDATIONS We see the aforementioned shortcomings as the most significant impediments to effective collaborative requirements management. In view of these shortcomings, we present a number of recommendations which we hope shall inform the future design of requirements management tools. 5.1. Provide a Mix of Specification Techniques In the earlier discussion, we identified requirements communicability as a paramount concern. Communicability has two aspects, - firstly, that a requirement is unambiguous, and secondly, that it is understandable. Unfortunately, these two aspects are often in conflict, - the most unambiguous specification techniques tend to be based on mathematical or scientific notations, and hence are not understandable to untrained readers, whereas the most understandable technique, natural language, is prone to ambiguity. The restricted expressiveness of software engineering notations has been observed by others as being problematic and not conducive to effective communication with non-technical stakeholders (Al-Rawas and Easterbrook, 1996). We therefore recommend that requirements be documented using a mix of formalised and informal techniques. For example, a user may create an initial description of a requirement using natural language, an interface sketch, or a rough flowchart. A software engineer may prefer to paraphrase the requirement in technical language, such as a pseudocode routine, interaction diagram, or decision table. It should also be possible to describe the requirement by means of a prototype, - be it an animated simulation, mock-up screen capture, or interactive applet. By using a combination of techniques to describe the same requirement or group of requirements, communication may be improved and usability issues overcome. We also recommend the use of rich media, - such as freehand drawings, full colour mock-ups of screens and reports, and animated sequences, - to describe requirements that could not be easily or adequately specified using natural language or a formalised diagramming technique. 5.2. Provide Traceability from Source through to Implementation Following on from our first recommendation, it is imperative that wherever multiple specification techniques are used in conjunction with each other to communicate requirements, those separate descriptions must be linked together. It should therefore be possible to trace a description of a requirement, as expressed in the “voice of the customer”, through to its implementation as a process specification and/or prototype. The trace should
TOWARDS ENHANCED SUPPORT FOR COLLABORATIVE REQUIREMENTS MGT
9
operate in both directions, from source through to implementation, and from implementation back to source. We also recommend that the rationale behind a requirement be documented, as well as all suggestions, comments, and change requests pertaining to that requirement. Above all, it is important to record the sources of requirements by individual’s name, so that a requirement can be fully traced back if necessary. The absence of these traceability mechanisms and the failure to record decision rationales is a common flaw in IS development (Al-Rawas and Easterbrook, 1996). 5.3. Provide Support for Collaborative Work of Potentially Distributed Teams Given that project teams consist of many stakeholders, and that it is likely they shall not all be co-located, a requirements management tool must provide adequate mechanisms to support the collaborative work of distributed teams. There are a number of aspects here. Firstly, a requirements management tool must have a facility to define different types of stakeholders, as well as associated privileges, roles, and authentication mechanisms. Secondly, it must be possible to grant multiple users concurrent access to the requirements data, while ensuring that the integrity of that data is not compromised. Thirdly, it must be possible to securely access the data from a remote workstation. In essence, this means that the requirements management tool must be based upon a robust database management system. Another aspect is that a requirements management tool should provide an electronic messaging facility, so that all stakeholders can openly access feedback and discussion channels, by means of one-to-one e-mail, broadcast e-mail, suggestion / comment forums, change requests, and so forth. Furthermore, it is important in the context of collaborative work that a requirements management tool support open and interoperable standards, such as multiplatform access, open database connectivity, and shared file formats for importing and exporting data. 5.4. Provide Flexible Process Support Numerous studies, - for example, Fitzgerald (1999), and Barry and Lang (2001), - reveal that formalised IS development methodologies are not being widely used in practice, and that more often than not practitioners are using their own in-house methods. There is a lesson here for designers of requirements management and CASE tools. Tools that codify methods may become so cumbersome and difficult to use that they soon become discarded. There is convincing support for the proposition of IS development as an improvised, situated activity, contingent upon the characteristics of the project at hand (Ciborra, 1999; Suchman, 1987; Stolterman, 1992). We therefore recommend that requirements management tools do not attempt to force a particular methodology upon potentially unwilling users. Rather, they should provide a mix of standard techniques, - such as Unified Modelling Language, Structured Systems Analysis, Information Engineering, legacy techniques such as flowcharting, as well as natural language and rich media descriptions, - and permit these techniques to be mixed-and-matched. Returning to our earlier point in Section 3.2 on modelling techniques, we recommend that while a requirements management tool should provide formalised techniques, it should not demand that any of these techniques be actually used. The use of rapid prototyping components, backed up optionally by reverse engineering capabilities, may in practice be a more effective and productive way to generate and validate models of an information system.
10
M. LANG, J.DUGGAN
5.5. Recognise Different Roles of Stakeholders As earlier set forth, requirements management necessitates ongoing communication between stakeholders from a diversity of disciplinary backgrounds, all with different interests, priorities, and levels of expertise. It is important that requirements management tools recognise this diversity, and the fact that stakeholders perform a variety of different roles. For example, technical design is not the domain of end users, and it should neither be expected nor demanded of them that they have to validate formalised models. We therefore recommend that, in the design of requirements management tools, the various categories of stakeholders should be identified, as well as the various tasks and roles that they perform. If requirements management tools are to be usable, such a user-centred approach must be taken towards their development. It is insufficient that software engineers should merely construct a tool that is suited to the needs of that community they know best, - their own. This has been the case with a number of currently available requirements management tools on the market, which initially started as in-house projects before being extended into commercial products for the external market. 5.6. Implement as a Web-Based Hypermedia Database In view of these recommendations, it becomes clear that the most suitable implementation for a requirements management tool is as a Web-based hypermedia database. By availing of the hypermedia capabilities of the Web, it is possible to have a fully open, distributed system that is platform-independent, location-independent, and takes advantage of de jure standards for documentation, data interchange, graphic file formats, multimedia, communication protocols, and application development, - such as HTTP, CGI, CORBA, HTML, SMIL, XML, RDF, GIF, JPEG, and Java. In addition, there are a number of popular plug-ins and de facto standards such as PDF, DHTML, CSS, ActiveX, Javascript and Macromedia Flash that facilitate the production of rich documentation and the rapid development of interactive applications. Most of the leading vendors of relational and object-relational databases have “Web-enabled” their products in recent years, and it is not surprising that there is now a flurry of interest in the potential use of the Internet as a platform for distributed software engineering. 6. CONCLUSIONS AND FURTHER WORK The dramatic expansion of the international market for commercial requirements management tools in recent years is reminiscent of that for CASE tools about a decade ago. Many of those early adopters of CASE tools had the unfortunate experience that their initial enthusiasm soon changed to bitter disillusionment, as the tools frequently did not deliver according to expectations and consequently fell into disuse. In this paper, we present a critique of currently available requirements management tools, and argue that for the most part they suffer from shortcomings which impair their support for effective communication and collaboration within multi-disciplinary project teams. In view of these shortcomings, we present a number of recommendations for enhancement. Accordingly, we have designed a prototype tool based upon a multi-user Web-based hypermedia database, to effect the recommendations we set forth. Early experiences from the use of this tool in a case study are promising, as reported in Lang and Duggan (2001). It is hoped that this prototype, once refined, shall inform the future design of commercial requirements management tools.
TOWARDS ENHANCED SUPPORT FOR COLLABORATIVE REQUIREMENTS MGT
11
Further empirical work is necessary to examine the impact of communication issues in IS development. In particular, the challenges of multi-disciplinary collaboration become significant and daunting as information systems begin to enter the Web-based world. To date however, this critical issue has been largely ignored within the literature. 7. REFERENCES Adler, R. B., 1988, Understanding Human Communication, Holt Rinehart & Winston, New York. Al-Rawas, A., and Easterbrook, S., 1996, Communication Problems in Requirements Engineering: A Field Study, in: Proceedings of the First Westminster Conference on Professional Awareness in Software Engineering, Royal Society, London, February 1-2 1996, pp. 47-60. Barry, C., and Lang, M., 2001, A survey of multimedia and Web development techniques and methodology usage, IEEE Multimedia. 8(3): 52-60. Bødker, S., Grønbæk, K., and Kyng, M., 1993, Cooperative design: techniques and experiences from the Scandinavian scene, in: Readings in Groupware and Computer-Supported Cooperative Work: Assisting HumanHuman Collaboration, R. M. Baecker, ed., Morgan Kaufmann, San Mateo, California, pp. 215-224. Booch, G., 1994, Coming of age in an object-oriented world, IEEE Software. 11(6): 33-41. Ciborra, C. U., 1999, A theory of information systems based on improvisation, in: Rethinking Management Information Systems, W. L. Currie and B. Galliers, eds., Oxford University Press. pp. 136-155. Curtis, B., Krasner, H., and Iscoe, N., 1988, A field study of the software design process for large systems, Communications of the ACM. 31(11): 1268-1287. Davis, A. M., 1988, A comparison of techniques for the specification of external system behavior, Communications of the ACM. 31(9): 1098-1115. Davis, A., Overmeyer, S., Jordan, K., Caruso, J., Dandashi, F., Dinh, A., Kincaid, G., Ledeboer, G., Reynolds, P., Sitaram, P., Ta, A., and Theofanos, M., 1993, Identifying and measuring quality in a software requirements specification, in: Proceedings of 1st International Software Metrics Symposium, IEEE Computer Society, Los Alamitos, pp. 141-152. Enquist, H., and Makrygiannis, N., 1998, Understanding misunderstandings, in: Proceedings of 31st Hawaii International Conference on System Sciences, Vol. 6. Kohala Coast, Hawaii, USA, January 6-9, 1998. Faulk, S. R., 1996, Software requirements: a tutorial, in: Software Engineering, R. H. Thayer and M. Dorfman, eds., IEEE Computer Society, Los Alamitos, pp. 82-103. Fitzgerald, B., 1999, Systems development methodologies: the problem of tenses, Information Technology & People. 13(3): 174-185. Gabb, A. P., Maheswaran, N., and Allwright, Alan M., 1997, Requirements Management Tools Evaluation User Needs and Evaluation Criteria, Report DSTO-GD-0139, Electronic and Surveillance Research Laboratory, Information Technology Division, Australian Department of Defence. Gallagher, S., and Webb, B., 1997, Competing paradigms in multimedia systems development: who shall be the aristocracy?, in: Proceedings of Fifth European Conference on Information Systems. Cork, Ireland, June 19-21 1997. Grady, J. O., 1996, An open letter to the tool companies, in: Proceedings of 6th Intl Symposium of the National Council on Systems Engineering, Boston, Massachusetts, USA. INCOSE. Grudin, J., 1993, Obstacles to participatory design in large product development organizations, in: Participatory Design: Principles and Practices, D. Schuler and A. Namioka, eds., Lawrence Erlbaum Associates, Hillsdale NJ, pp. 99-119. Hofmann H.F., 1993, Requirements engineering: a survey of methods and tools, Working Paper No. 93.05 March 1993, Institut für Informatik der Universität Zürich. Holtzblatt, K., and Beyer, H., 1993, Making customer-centred design work for teams, Communications of the ACM. 36(10): 93-103. Holtzbatt, K., Beyer, H. R., 1995, Requirements Gathering: The Human Factor, Communications of the ACM. 38(5): 31-32. Hutinski, Z., Vrcek, N., and Bubas, G., 2001, Communication in Complex Information System Development Projects, in: Proceedings of Informing Science Conference, Krakow, Poland, June 19-22 2001. James, L., 1996, What’s wrong with requirements management tools?, Requirements Engineering Journal. 1(3): 190194. Jones, D. A., York, D. M., Nallon, J. F., and Simpson, J., 1995, Factors influencing requirement management toolset selection, in: Proceedings of 5th Intl Symposium of the National Council on Systems Engineering. Vol 2, INCOSE. Kar, P., and Bailey, M., 1996, Characteristics of good requirements, in: Proceedings of 6th Intl Symposium of the National Council on Systems Engineering, Boston, Massachusetts, USA.
12
M. LANG, J.DUGGAN
Keil, M. and Carmel, E., 1995, Customer-developer links in software development, Communications of the ACM. 38(5): 33-44. Landay, J. A., and Myers, B. A., 2001, Sketching interfaces: toward more human interface design, IEEE Computer. 34(3): 56-64. Lang, M., and Duggan, J., 2001, A tool to support collaborative software requirements management. Working Paper, National University of Ireland, Galway (forthcoming in Requirements Engineering Journal). Lyytinen, K., Rose, G., and Welke, R., 1998, The Brave New World of development in the internetwork architecture (InterBCA): or how distributed computing platforms will change systems development, Information Systems Journal. 8(3): 241-253 Palmquist, R. A., 1996, The search for an Internet metaphor: a comparison of literatures, in: Proceedings of the ASIS Annual Meeting. Vol. 33 pp. 198-202. Shannon, C., and Weaver, W., 1949, The mathematical theory of communication. University of Illinois Press. Sommerville, I., and Sawyer, P., 1995, Requirements engineering: a good practice guide,Wiley, Chichester. Standish Group International, 1998, Special COMPASS Report on Requirements Management Tools. Stolterman, E., 1992, How system designers think about design and methods: some reflections based on an interview study, Scandinavian Journal of Information Systems. 4: 137-150 Suchman, L. A., 1987, Plans and Situated Actions. Cambridge University Press. Walz, D. B., Elam, J. J., and Curtis, B., 1993, Inside a software design team: knowledge acquisition, sharing, and integration, Communications of the ACM. 36(10): 63-77.
