THE PROCESS OF DERIVING REQUIREMENTS : LEARNING FROM PRACTICE

Jennie M. Carroll1 Paul A. Swatman2 School of Information Technology Swinburne University of Technology 2 School of Management Information Systems Deakin University Abstract The process by which systems analysts, or requirements engineers, derive requirements is poorly understood. The research reported in this paper involves studying professional requirements engineers at work in their everyday environments. The findings include the identification of a number of influences on requirements engineerspractice and elucidation of several roles that they play during the analysis process. Further areas for research are also highlighted.
1

Keywords Requirements Engineering, Case Study

INTRODUCTION
The research reported in this paper is part of a research program aimed at improving the process of deriving requirements, often called systems analysis or requirements engineering (RE). We believe that it is necessary to develop understanding of the RE process before concentrating on tools, techniques and methods to be used to improve this process. The case outlined here is the first in a series of case studies directed at building knowledge and theory about the practice of real-life requirements engineers working within their everyday environments. The findings constitute some learning about how RE is performed, and point to areas of RE practice into which further research is needed. A high-quality process for deriving requirements is critical for developing successful information systems (IS). Constructing a usable, effective and efficient business solution necessitates clear understanding of what is required, by which stakeholders, within the given constraints. This understanding needs to be communicated to the stakeholders - to check whether their needs have been accurately and completely comprehended - as well as the technical staff involved in developing systems - who need clear, concise and unambiguous specifications in order to deliver what the stakeholders require. Successful requirements engineers need a range of personal, social and technical skills. They deal with a variety of stakeholders having different views of the proposed system,

investigate the domain in which the system will operate, evaluate present and future influences on the success of the system and model possible problem solutions in a range of formats. Exactly how they use these skills to produce a requirements specification is not clearly understood. This is partly because practising requirements engineers appear unable to describe how they transform stakeholders needs into a formal specification document (Lubars, Potts and Richter 1993), partly because the process is creative and cognitive and so has few external markers, and partly because of the nature of existing research. Much of the literature on the RE process has shortcomings, most acutely in its relationship with the practices of professional requirements engineers working in the real world. Much of the published research has some or all of the following characteristics - it examines students rather than practitioners, studies the solution of contrived problems (where the scenario is already derived rather than dealing with conflicting viewpoints held by a range of stakeholders), and presents cases performed in a laboratory rather than in the field (see, for example, Adelson and Soloway 1985, Guindon 1990, Sutcliffe and Maiden 1992, Vessey and Conger 1994). This research project aims to study requirements engineers operating in context to increase our understanding of RE.

THE RESEARCH METHOD

This research project aims to build knowledge and theory about requirements engineering. A case study approach is appropriate because the research emphasis is on how requirements engineers operate in their real-life environment. The case selected involves the RE phase in the development of an Information Broker, a Web-based application to locate and supply heavy machinery (see Hunt and Swatman 1997). The idea for the application originated with a consultant having extensive experience in dealing with large mining and engineering companies. He saw that the purchasing and supply of heavy equipment could be facilitated by the Internet, and conceived a mental model of how such an application could operate. The consultant was seeking to transform these ideas into a formal set of requirements that could be given to a software house to build the application. He worked with an assistant who had previously worked in the Defence industry. They are the clients in the case study, and were backed financially by an organisation having experience in providing business applications, but without experience in the Internet. The case of the Information Broker was selected for convenience and its characteristics include: it involves developing a new and relatively simple application the application is market-driven rather than customised for any one group of users only one set of stakeholders is involved in the RE process, so there is no viewpoint analysis or conflict resolution between stakeholders there are no identified users; rather, one client has a view of the type of organisations which would be interested in the new application some hardware and software had already been purchased, and the client expressed interest in using object oriented methods.

The application is now being built by a software house, with project management of the development being performed by the clientsbacking company. A weakness of case studies, and qualitative research generally, is a perceived lack of rigour. Suggestions for overcoming this centre on the use of additional structure (Checkland 1991, Dick 1992). A variant of case study research, called structured-case (Carroll, Dawson and Swatman 1998), is used in this research. It assists researchers in focusing and ordering the research process as well as evaluating and justifying the outcomes of this process as follows: a conceptual framework is specified prior to entering the research site The conceptual framework determines what is to be examined and guides the collection, analysis and interpretation of data (Miles and Huberman 1994). The conceptual framework for this project was developed as a result of four influences: the research themes, the researcher s theoretical foundations, the existing literature and insights from a requirements engineer. it has an iterative research cycle Once the conceptual framework is defined, a cycle of planning, data collection, analysis and reflection provides structure to ensure rigour as well as the flexibility to include unexpected outcomes. The research cycle, adapted from action research (see Susman and Evered 1978), is used to expand, enrich and validate the conceptual framework, laying the foundations for theory building. it focuses on theory building In this iterative, cyclical method, the research is planned, research propositions refined, data collected, analysed and interpreted and the outcomes evaluated. Reflection on the implications of the outcomes of data analysis for the overall research project may result in changes in the conceptual framework before another cycle is started. This is how theory is built: the conceptual framework represents the current state of theory and changes in it represent the theory built to date. The Initial Conceptual Framework The conceptual framework (see Figure 1) defines the areas of interest of the research, in this case the stakeholders of the system within context and the transformation of data about the problem domain by the requirements engineer. The stakeholders (all those with a stake or interest in the new system) are represented within the problem domain, as their needs can only be understood in context. Influences within the problem domain include the environment, existing domain knowledge, technology, organisation and theories about computing. Data about the problem domain is transformed by the elicitation, representation and validation sub-processes (for further details, see Carroll and Swatman 1997). Data Collection and Analysis The requirements engineer was employed to assist with specifying the requirements, so that system development could be contracted out to a software house. The researcher was a participant observer: welcome to participate in the process, make

Problem domain Organisation

Environment

Stakeholders

Theories

Technology
Domain knowledge and requirements Knowledge

Existing domain knowledge

Models and requirements Informal & formal

Elicitation

Representation Analyst s domain

models

Validation

Figure 1

The initial conceptual framework, CF1

comments and suggestions as well as ask questions. For the first two days, the requirements engineer examined documentation developed by the clients, giving background of the system and their views of the requirements. Data recorded included notes from observation, representations sketched by the requirements engineer and the researcher s reflections on the process. During the next two days, the requirements engineer worked with the two clients to define the requirements for the new system. Data was collected by observation and interview, comprising detailed notes of conversations and the representations used by the requirements engineer; the researcher s interpretations noted during the sessions, as a result of reviewing the notes at the end of each day, as well as at the end of the process; a videotape of one session; and notes made of an interview with the requirements engineer after the final session. Initial analysis of the data was performed using coding (see Miles and Huberman 1994). Each concept in the conceptual framework was used as a code, plus an any other code in each section to allow for unexpected findings. The initial coding was used to retrieve and organise chunks of transcripts. Analysis is an ongoing, iterative process: at first the codes were used to match concepts and sub-processes from the problem domain with sections of the text. On re-reading the text, further analysis and interpretation led to adding new codes. Therefore, the process of reading, re-reading and interpreting the data led to reviewing and revising the codes.

FINDINGS
The findings are presented in relation to the main aspects of the conceptual framework: the problem domain, the analyst s or requirements engineer s domain, and the interaction between the two. It should be noted that, due to the characteristics of the application being developed, not all influences or concepts in the initial conceptual model could be observed. Some

of the findings may be related to the characteristics of the Information Broker application or the relative simplicity and brevity of the RE process. The Problem Domain Four of the influences depicted in the problem domain in the initial conceptual framework were observed: environment The influence of government and legislative requirements was observed. A far stronger influence, which pervaded the entire RE process, was that of commercial imperative. Commercial pressures - in particular, the need to gain competitive and strategic advantage - meant that time and speed to market were of great importance to the clients. organisation The importance of the business rules of the backing organisation to the clients view of the system were critical. The client reiterated the aims and rules he believes are important to the operation of the Information Broker; often discussing the business context gave rise to further requirements. technology The software and hardware purchased for the Information Broker had some influence on the RE process, particularly later in the process when the requirements became clearer. During discussions about whether the purchased software could handle drawings, the requirements engineer stated that [It is] Not a requirements analysis issue - but a detailed design issue. However, the requirements engineer could not ignore the constraints that existing technology placed on the system. theories One client expressed a preference for using object oriented (OO) methods for the project, citing advantages of reusability and better engineering. This influenced the direction of the RE process for three and a half days; it was only during the last half day that OO was rejected in favour of conventional data base technology. The requirements engineer argued that the system would be made much more difficult by choosing OO. A basic database is all we need....Tried and trusted technology. An additional influence on the clients was observed: the stakeholders existing knowledge of computing. One of the clients is a specialist in electronic commerce, and so has extensive knowledge of the standards, protocols and technology available for Web-based electronic commerce. This meant that the client had superior technical knowledge to the requirements engineer in a very narrow area of the problem domain, which was valuable when discussing constraints to possible solutions. The Analyst s Domain Influences on the Requirements Engineer It is clear that, just as the stakeholdersrequirements need to be understood in context, so too the requirements engineer s actions can only be understood within context. Aspects of the analyst s context include: theories about IS and RE; the world-view of the analyst

It is expected that requirements engineers views of their role will influence their actions. In the Information Broker case, while the requirements engineer worked cooperatively with the clients, his view is that of the problem-solver (and he resisted efforts of the client to solve the problem or look at design issues until the requirements were clearly understood). familiarity with the domain The requirements engineer is not an expert in the problem domain, Web-based electronic commerce; consequently, time was spent gathering information about it. Domain knowledge is seen as important for developing software (Curtis, Krasner and Iscoe 1988) as well as problem solving generally (Mayer 1992:390). If analysts and designers lack such knowledge, there may be significant costs in learning about it (Walz, Elam and Curtis 1993). In the case of the Information Broker, the process of deriving requirements was similar to the sub-processes performed when developing off-the-shelf software, although a range of additional issues such as providing services for the marketing function, the tight time constraints and adding value to an existing business process meant that the requirements engineer was working outside his domain of specialised knowledge and experience. The requirements engineer overcame this by using similarities with previous situations - seeking commonality not difference - and when faced with an unfamiliar situation, being very careful to discover exactly what needed before attempting to provide a solution. familiarity with the type of problem Problems may vary in whether they are structured or unstructured, soft or hard (see Checkland and Scholes 1991); the specific nature of problems means that different approaches are needed. Mayer (1992:413) argues that problem solvers discriminate between problem types to categorise problems based on solution plans. In the case of the Information Broker, the requirements engineer solved the problem when he categorised the Web-based commerce application as a data base problem. As such, the requirements engineer s unfamiliarity with the problem domain was not a critical factor in the RE process; seeking similarities in the type of problem caused the breakthrough in the solution of the problem. experience in RE A requirement engineer s experience is a vital influence on practice. This experience needs to cover a range of areas: business contexts, types of systems, representations and problem types as Breadth of experience is a better predictor of individual performance than years of experience. (Walz, Elam and Curtis 1993:74). The requirements engineer s broad experience in systems analysis enabled him to overcome his lack of familiarity with Web-based electronic commerce; similarities with previous problems encountered helped him work towards resolution of this problem. This was evident when discussing project management of the Information Broker development which he emphasised that it could not be done as quick and dirty. He argued that the system would evolve over time, so its foundations must be sound, with clear standards to guide current and future development. learning and problem-solving approach In practice, learning and problem solving are not distinct, but rather learning is an essential part of problem solving. Learning involves collecting data and then analysing it to develop the information and knowledge which is the basis of problem-solving. There was a clear point during the Information Broker case when a breakthrough occurred and the problem was solved; this happened during the second session of the final day. The requirements engineer realised that the Information Broker was

basically a simple system; a data base solution was chosen, presented and then evaluated. The requirements engineer sketched the outlines of the application which would solve the problem, and reiterated the solution many times (to educate the client about this new view of the system). The clients subjected the solution to a SWOT analysis, then eventually moved on to discuss project management of the system development (in its new form): the solution was evaluated and accepted. existing domain knowledge Many problem domains are well-understood, with an existing body of knowledge which a requirements engineer can access. It was noticeable in this case that - as the Web is relatively new with scant existing knowledge - the requirements engineer was reliant on the clients for domain knowledge and had no recourse to any larger, more general body of domain knowledge. How the RE sub-processes are performed The initial conceptual framework depicts the requirements engineer as driving interaction with the stakeholders through the elicitation, representation and validation sub-processes. The performance of these sub-processes was seen as unstructured, ad hoc and possibly chaotic, rather than systematic (Carroll and Swatman 1997:461). Observations of the sub-processes in the Information Broker case occurred on two different levels: moving from sub-process to sub-process (the pattern of elicitation, representation and validation), and performing the sub-processes on different parts of the problem (movement between the areas of the problem being analysed). The pattern of elicitation, representation and validation Initially, much attention was placed on determining the system s constraints: what was needed to be delivered and by when. This was performed in question-and-answer mode. Once the deliverables and their deadlines were established, the requirements engineer focused on the functionality needed for the application. A fairly orderly, sequential pattern of eliciting then validating chunks of information was observed: elicitation, elicitation, elicitation, perhaps some representation, then validation, to give understanding of a fragment of the problem. Not much representation was seen occasional sketches and diagrams were used, and verbal representations of sections of the problem were presented for validation. It should be noted that this pattern of performing the sub-processes, and the lack of diagrammatic representations, may be due to the simplicity of the system being studied. Movement between the areas of the problem being analysed Examining the areas of the problem being tackled through the elicitation, representation and validation sub-processes gives a different view of the RE process. The requirements engineer spends some time on one area, fills in some detail, moves on to another area then back to the first area. A common theme throughout the RE process (noted by plotting this movement diagrammatically, as shown in Figure 2) is that one problem area is not solved before the requirements engineer moves on to another area. The requirements engineer commented in the post-process interview that he may leave a difficult area for a while and move on - to approach it later from a different angle or with a new insight.

A __________ __________ __________

A = eliciting what is needed, by what date. B __________ __________ __________ __________ B = giving advice about management of the project C __________ C = eliciting information about the interface with client software

__________ __________ Figure 2 A sample of movement between the areas of the problem being analysed

In the section of the RE process diagrammed in Figure 2, the requirements engineer starts at A (eliciting what is needed, by what date). After three chunks of information are gathered, the focus moves to B (giving advice about management of the project). After three areas of discussion about project management, the focus moves to C (eliciting information about the interface with client software). More discussion about project management precedes further elicitation of what is needed, by when. At intervals, the requirements engineer s understanding of the information gathered is validated, by presenting his views of the requirements to the clients; in this way, he constructs fragments of understanding of the problem. Consolidation of these validated fragments to create understanding of the problem as a whole appears unstructured and opportunistic, rather than incremental and evolutionary. Sometimes increased understanding of A leads to development of understanding of a large piece of the problem. Insights into the nature of the problem and its context lead to resolution of problem pieces and fitting them into the whole. The solution to the Information Broker case is an example of such insights: at one point the requirements engineer stated There s not much there. It s quite a simple little system and changed the focus of all subsequent discussions. The observed performance of the RE process is similar to opportunistic problemsolving, which is characterised by frequent discovery and/or adaptation of goals and activities, is response to changing circumstances (Khushalani, Smith and Howard 1994:13). Insights from working on parts of the problem lead to changes in the approaches to the problem. Thus, derivation of requirements is an ever-changing, everadaptive, non-structured and intuitive process, driven by what is best described as insights, opportunism and breakthroughs rather than incremental, evolutionary or even iterative methods (as insight may resolve a situation first up, or after repeated tries). These characteristics of the RE process can be understood in relation to two basic aspects of RE - the nature of the problems encountered (soft or unstructured, which cannot be defined and have no clear solution) and the nature of human problem solving which is dynamic and evolutionary, requiring continuous adaptation ... to deal with a broad spectrum of ideas (Khushalani, Smith and Howard 1994:14). Interaction Between the Domains

The initial conceptual framework modelled the interaction between the requirements engineer and the stakeholders in a limited way, showing the requirements engineer eliciting and representing information which is then validated with stakeholders. This suggests that the process is driven and controlled by the requirements engineer who performs a narrow range of activities. Observing the RE process for the Information Broker shows that the interaction is much more complex than this. The dominant impression of this RE process is that the requirements engineer is providing a service. This service takes many forms and, like all quality services, is responsive to the needs of the customer as well as fulfilling the professional responsibilities of a requirements engineer. It includes solving a business problem and deriving a requirements specification. This is not achieved solely as a result of the requirements engineer s actions. At times, the requirements engineer directed the process to a certain area, then the main client would take control and move to another area that he thought was important. The clients actively educated the RE team about aspects of the system and business which they felt were important and compelled the RE team to consider these issues. Thus, the interaction was more negotiated and co-operative than driven by the requirements engineer. The clients were not passive, supplying information and validation on request; rather they actively shared in control of the process.

IMPLICATIONS FOR THE CONCEPTUAL FRAMEWORK

These findings led to reviewing and revising the conceptual framework. Changes to the codes used in the analysis (derived from the concepts contained in the initial conceptual framework) were incorporated into the updated conceptual framework.. The concepts in the problem domain were revised - one was added and another moved to the analyst s domain. Influences in the analyst s domain were added, so that the context in which the requirements engineer operates is explicit. The representation of the interaction between the two domains was changed to reflect the dual input and control of the RE process. The first revision of the conceptual framework arising from the Information Broker case (CF2a) is shown in Figure 3.

Organisation Environment Theories

Stakeholders
Knowledge of computing

Technology

Elicitation

Representation

Validation

Familiarity with type of problem Existing domain knowledge

Theories - IS, RE and world view

Method used Familiarity with domain Experience in RE

Analyst
Problemsolving approach

Figure 3 The first revision of the conceptual framework, CF2a.

Additional analysis of the data led to the emergence of a number of themes related to the interaction between the requirements engineer and the clients including conflict resolution, education, technical and business advice and management of the RE process also occur. conflict resolution The positive role played by the clients in the RE process means that conflict resolution, between the clients and the requirements engineer rather than between different stakeholders, is important. At times, this is a complex and delicate task; the requirements engineer needs well-developed social skills to manage this interaction without offending the clients but still focusing on what was needed to derive the requirements. The requirements engineer avoided confrontation on contentious issues, but returned later to such issues, taking a slightly different tack. Walz, Elam and Curtis (1993) observe that conflict may facilitate learning in RE and design; conflict needs to be effectively managed to maximise benefits for the process. mutual education Requirement engineers have imperfect knowledge of the problem domain (and of the different stakeholdersviews of the critical issues). In the Information Broker case, this knowledge was added to by eliciting information; at other times, the clients actively educated the RE team, for example about the business, the domain in which the system will operate and the main client s conception of how the system will operate. The clients actively worked to fill in areas that seem to be lacking. The requirements engineer educated the clients about possible business, technical and process choices, drawing on his past experience and business and technical knowledge. For example, the requirements engineer spent considerable time discussing project management of the Information Broker project, the feasible options and their implications so that the clients could make an informed choice for managing the system development. technical and business advice

The requirements engineer offered a range of technical advice, especially after the decision to use data base technology was made. Advice on how to set up the data base and interface it with the Web reflected his expertise. Because the requirements engineer was not expert in the Web commerce domain, and the main client had considerable expertise in Web technology, the client offered technical advice in his area of expertise. The requirements engineer perceived various business opportunities of which the clients were unaware, and offered advice about maximising the financial benefits of the system. One example involved the requirements engineer s idea that there must be money in the order of the list, and suggesting that suppliers could pay to be on the top of the list of Information Broker suppliers. management of the RE process The requirements engineer sought to bound and focus the interaction, so that he could follow through a line of thought to its end. Also, he was concerned that the main client was trying to solve the problem prematurely rather than fully understand the requirements first. Developing the Information Broker was subject to time pressures beyond those common to all commercial systems development, and the concept of an Information Broker was already in the public domain (see Hunt and Swatman 1997). The requirements engineer warned against trying to go too fast and oversimplifying the requirements; he dealt with these pressures by keeping the interaction focused and bounded. The variety of the themes emerging from the data analysis indicates that several additional roles are performed by requirements engineers beyond eliciting, representing and validating information. These roles involve human and social skills, as well as technical skills: the requirements engineer uses a range of socio-technical skills when operating in a socio-technical environment. Depicting the richness of this interaction means that revision of the conceptual framework is needed. The full range of themes evident in the interaction between the problem and analyst domains has not been included, as they are still poorly understood; including them in an inclusive model of the RE process requires significant additional reflection as well as more detailed research and knowledge. However, management of the RE process is included in the second revision of the conceptual framework; the three sub-processes and other aspects of the interaction between requirements engineers and clients (conflict resolution, education and providing technical and business advice) must all be managed. The second revision of the conceptual framework, CF2b, is presented in Figure 4. SUMMARY AND CONCLUSION There has been significant learning from the Information Broker case. The process of evaluating the implications of the data analysis and reflecting on the observations highlighted omissions, errors and ambiguities in the initial conceptual model. Insights were gained as a result of observing practising requirements engineers and additional reading was undertaken to clarify these observations. As a result, the conceptual framework was twice modified, reflecting the incremental construction of knowledge.

Organisation Theories Environment

Stakeholders
Knowledge of computing

Technology

MANAGEMENT OF THE RE PROCESS Elicitation Representation Validation

Familiarity with type of problem Existing domain knowledge

Theories - IS, RE and world view

Method used Familiarity with domain Experience in RE

Analyst
Problemsolving approach

Figure 4

The second revision of the conceptual framework, CF2b.

The latest version of the conceptual framework of the RE Process (CF2b) demonstrates this learning: the concepts in the problem domain have been refined and validated; a range of influences on the analyst has been included; the interaction between the domains now reflects its co-operative nature; and the importance of managing the RE process is acknowledged. In addition to confirming, adding and replacing concepts is the process of noting emerging themes, where deeper interpretation and reflection on the findings has led to ideas about the interaction between the problem and analyst s domains. A number of themes have been noted for further research; these include conflict resolution, education and technical and business advice. Requirement engineers bring theoretical and technical knowledge, along with breadth of experience, to the RE process. The stakeholders bring detailed knowledge of their domain and experience of the problem situation. Neither has superior knowledge, rather they are both experts in their own domains; it is the interaction between these two groups of experts that is the basis for the problem solving required from the RE process. It is in this area that further research and reflection will bring additional understanding of the RE process.

REFERENCES
Adelson, B. and Soloway, E. (1985) The Role of Domain Experience in Software Design, IEEE Transactions on Software Engineering, 11, 1351-1360 (Nov). Carroll, J.M. and Swatman, P.A. (1997) How Can the Requirements Engineering Process be Improved? in D.J. Sutton (ed.) Proceedings of the 8th Australasian Conference on Information Systems, Darlinghurst: The Australian Computer Society, 458-469. Carroll, J.M., Dawson, L.L. and Swatman, P.A. (1998) Using Case Studies To Build Theory: Structure and Rigour.

Checkland, P. (1991) From Framework through Experience to Learning: the Essential Nature of Action Research in H.-E. Nissen, H.K.Klein and R.Hirschheim (eds), Contemporary Approaches and Emergent Traditions, North-Holland, 397-403. Checkland, P. and Scholes, J. (1991) Soft Systems Methodology in Action. Chichester: Wiley. Curtis, B., Krasner, H. and Iscoe, N. (1988) A Field Sudy of the Software Design Process for Large Systems, Communications of the ACM, 31:11, 1268-1287 (Nov). Dick, B. (1992) So You Want To Do An Action Research Thesis? Internet document, University of Queensland. Guindon, R. (1990) Knowledge Exploited by Experts During Software System Design,International Journal of Man-Machine Studies, 33:3, 279-304 (Sept). Hunt, B.W. and Swatman, P.A. (1997) The Information Broker as an Alternative to Web Search Engines in Sourcing Potential Suppliers of Goods and Services in D.R. Vogel, J. Grizar and J. Novak (eds), Proceedings of the Tenth International Bled Electronic Commerce Conference: Global Business in Practice. Vol 1: Business. Kranj, Slovenia: Moderna Organizacija, 166-182. Khushalani, A., Smith, R. and Howard, S. (1994) What Happens When Designers Don t Play by the Rules: Towards a Model of Opportunistic Behaviour in Design, Australian Journal of Information Systems, 13-31 (May). Lubars, M., Potts, C. and Richter,C. (1993) A Review of the State of the Practice in Requirements Modeling , RE 93: Proceedings of the IEEE International Sdyposium on Requirements Engineering, Los Alamitos, CA: IEEE Computer Society Press, 214. Mayer, R.E. (1992) Thinking, Problem Solving, Cognition, 2nd ed. New York: W.H. Freeman and Company. Miles, M.B. and Huberman, A.M. (1994) Qualitative Data Analysis. 2nd ed. Thousand Oaks,CA: Sage. Susman, G.I. and Evered, R.D. (1978) An Assessment of the Scientific Merits of Action Research , Administrative Science Quarterly, 23:4, 582-603 (Dec). Sutcliffe, A.G. and Maiden, N.A.M. (1992) Analysing the Nove Analyst: Cognitive Models in Software Engineering, International Journal of Man-Machine Studies, 36, 719-740. Vessey, I. and Conger, S.A. (1994) Requirements Specification: Learning Object, Process and Data Methodologies, Communications of the ACM, 37:5, 102-113 (May). 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-76 (Oct). Yin, R.K. (1984) Case Study Research: Design and Methods, Beverly Hills,CA: Sage.

COPYRIGHT
Jennie M. Carroll and Paul A. Swatman 1998. The authors assign to ACIS and educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive licence to ACIS to publish this document in full in the Conference Papers and Proceedings. Those documents may be published on the World Wide Web, CD-ROM, in printed form, and on mirror sites on the World Wide Web. Any other usage is prohibited without the express permission of the authors.