Requirements Engineering and Technology Transfer: Obstacles ...

Download PDF
16 downloads 6550 Views 147KB Size Report
Comment
... Rio de Janeiro, Brazil; hSoftware Engineering Institute, Carnegie Mellon. University, Pittsburgh, Pennsylvania, USA; iDepartment of Computer Science, .... 3Merriam-Webster Online; see http://www. ... advanced undergraduate or graduate level as part of their ... developing business systems and high assurance systems.
Requirements Eng (2002) 7:113–123 Ownership and Copyright ß 2002 Springer-Verlag London Limited

Requirements Engineering

Requirements Engineering and Technology Transfer: Obstacles, Incentives and Improvement Agenda Hermann Kaindla, Sjaak Brinkkemperb, Janis A. Bubenko Jrc, Barbara Farbeyd, f1 g2 Sol J. Greenspane, Constance L. Heitmeyerf1 , Julio Cesar Sampaio do Prado Leiteg2 , h i j Nancy R. Mead , John Mylopoulos and Jawed Siddiqi a Siemens AG O¨sterreich, PSE, Vienna, Austria; bBaan R&D, Barneveld, Netherlands; cRoyal Institute of Technology and Stockholm University, Stockholm, Sweden; dUniversity College London, London, UK; eManagement Strategies Inc., Boston, Massachusetts, USA; fNaval Research Laboratory, Washington, DC, USA; gDepartamento de Informa´tica PUC–Rio, Rio de Janeiro, Brazil; hSoftware Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, USA; iDepartment of Computer Science, University of Toronto, Toronto, Ontario, Canada; jSchool of Computing and Management Sciences, Sheffield Hallam University, Sheffield, UK

For many years, research results in requirements engineering (RE) have been developed without much interaction with, or impact on, industrial practice. Why is it so difficult to introduce RE research results into mainstream RE practice? This paper attempts to provide answers to this question by describing obstacles that researchers and practitioners have encountered when they attempted technology transfer. In addition, major incentives for using RE methods are discussed, along with ideas for improving current RE practice. The paper summarises, clarifies and extends the results of two panel discussions, one at the Twelfth Conference on Advanced information Systems Engineering (CAiSE’00) and the other at the Fourth IEEE Conference on Requirements Engineering (ICRE’00). Keywords: Requirements engineering; Technology transfer

1. Introduction In a 1993 evaluation of requirements engineering (RE) practice, Hsia et al. [1] found that most requirements specifications were still being written in natural 1

C. Heitmeyer’s research is funded by the Office of Naval Research. Part of this work was developed when on leave to Universita¨t Kaiserslautern and Fraunhofer IESE. Correspondence and offprint requests to: H. Kaindl, Siemens AG ¨ sterreich, PSE, Geusaugasse 17, A-1030 Vienna, Austria. Email: O [email protected]

2

language. Disappointingly, there seemed to be little use of the concepts, techniques and tools developed by RE researchers which had been developed specifically to address the complex requirements of large-scale systems development. The situation has improved since then, although no ‘silver bullet’ has been found, of course. For example, the emergence of the Unified Modeling Language (UML) [2] represents a recognition of the importance of seeking standard modelling languages that can support requirements modelling. On a related front, use cases/usage scenarios (e.g. [3–5]) are being accepted into practice to support RE efforts where little has been done before. Moreover, new COTS (commercial off-theshelf) tools for documenting requirements – such as DOORS, RequisitePro and RM-Caliber – facilitate requirements management, most notably the implementation of traceability policies. Other new tools – such as the SCR tools for specifying and analysing requirements [6,7] – are beginning to be used by companies (e.g. Lockheed Martin) that produce safety-critical software systems [8]. There is some evidence of the benefits of using RE results in industrial projects (e.g. [9,10]). Nonetheless, mainstream industrial RE practice still relies largely on word processors (for composing natural language descriptions of requirements) and drawing tools rather than the results of RE research. To gain a deeper understanding of this problem, two panels were organised in 2000: the first at the Twelfth Conference on Advanced information Systems Engineering (CAiSE’00) in Europe [11] and the second at the Fourth IEEE Conference on Requirements Engineering

114

(ICRE’00) in the USA [12]. The common objective of the panels was to bring together senior researchers and practitioners to discuss why it is so difficult to introduce RE research results into mainstream practice. A deeper understanding of this issue should help bridge the gap between theory and practice and should also contribute to more relevant research and better RE practice. Among the questions that the panellists were asked to address were the following: . What are the obstacles to transferring RE research results into practice? . Are the people working on requirements from the software perspective aware of RE research results? . How can the RE research community reach software developers? . Does RE research address the real issues arising in practice? . Is better tool support needed? . What are the social problems involved in changing practice? . Are practitioners satisfied with their current requirements process? . Are practitioners searching for better ways to handle requirements? This paper summarises and extends the discussions and conclusions of the two panels. First, we briefly review earlier work on RE technology transfer. We then describe obstacles from the perspective of both technology providers and users. In the following section we describe incentives for the adoption of RE research results by practitioners. Finally, we propose an agenda for improving the current situation. Throughout, the paper focuses on the points raised during the panel discussions, with clarifications and follow-up discussions where applicable. Because it summarises primarily panel discussions, the paper contains a diversity of views that may conflict. It is not intended to represent a consensus among all panellists. Nor is it intended as a survey of the topic and makes, therefore, no pretence to being comprehensive.

2. Previous Work At RE conferences over the years, technology transfer panels have been a staple (i.e., ‘a commodity for which the demand is constant’3). There are very good reasons why the topic makes it onto RE conference programs so often: without more technology transfer, RE practice is unlikely to improve and much RE research will remain irrelevant. The program at RE’97 included a panel 3

Merriam-Webster Online; see http://www.m-w.com/.

H. Kaindl et al.

entitled ‘How Can Requirements Engineering Research Become Requirements Engineering Practice?’ The abstract of the paper contains a clear statement of the general problem and identifies some of the key issues [13]: The path from conceptualisation of a good idea to its widespread use in industry is usually long, complicated, and fraught with peril. Too often, research justified as satisfying the needs of industry begins with a wrong or simplified understanding of real problems. Even given a real solution to a real problem, successful transfer of that solution into practice depends on many other factors such as funding, the emergence of champions, availability of tools, education, integration with existing methods, and all too often, plain luck.’

In another panel discussion [14], panellists included representatives from two in-depth projects looking at RE practice. The first project [15] generated a prioritised list of problems with ‘industrial uptake from RE research’. The following summarises the top problems identified in the study: 1. Training . If there are no funds for training, the introduction of new RE techniques, tools, processes is fruitless. . When there is a limited pool of human resources, there is no time to re-train. . Where RE practices are widely institutionalised, the adoption of new methods is hopeless without a formal process for changing the status quo. 2. Business culture . It is hard to rationalise high up-front costs to do a thorough job of requirements analysis, given that the potential benefits of RE are largely unproven. . Support for RE is low due to lack of recognition of RE as a bona fide engineering discipline. . RE is young and immature. 3. Internal business integration . Application of new RE methods interferes with other software development activities, requires the integration of new work processes and tools, and assumes new interaction patterns among stakeholders, including customers. . It is difficult to establish that new RE methods have preserved or improved the quality of business products/services or processes. 4. Inherent complexity . Requirements engineering is inherently difficult. . There is a great diversity of stakeholders, business objectives, system requirements, technical problems and alternative problem-solution mappings. . Requirements interactions, conflicts and ambiguities are difficult to detect, resolve and manage.

Requirements Engineering and TechnologyTransfer

. Requirements often change during downstream development activities, but there is generally no support for requirements management activities. . Complexity increases rapidly as requirements are added or changed, so scaling up is very difficult. Of course, any research on RE knowledge transfer needs to be aware of more general research on knowledge transfer, e.g. IFIP WG 8.6 on ‘Transfer and Diffusion of Information Technology’. In this context, Priscilla Fowler and Mac Patrick [16] collaborated to conduct a workshop, for the purpose of transitioning requirements management processes from theory to practice. One of the outcomes of the workshop was development of requirements management transition packages, in conjunction with workshop participants. The transition package would include workshop results, examples, tutorial material and the like. The goal of the transition package is to make it easier for groups to adopt new practices, without having to invent everything from scratch. In addition to the workshop proceedings, a discussion of this experience was presented at ICRE’98 [17]. The concept of transition workshops builds on the paper presented at the IFIP working group [18]. This is one of a small number of efforts focused exclusively on requirements management and technology transition. Technology transfer has been studied in many fields beyond IT. The process of transferring new theories and technologies from academia to industry is known as industrial diffusion [19]. Successful and failed innovations can be attributed to many factors, including the utility of the innovation both to the organisation and to the individual. Diffusion theory identifies five perceived characteristics of an innovation (PCIs), each influencing the adoption of IT: . . . . .

relative advantage; compatibility; complexity; trialability; and observability.

Relative advantage is the degree to which an innovation is perceived as superior to the idea that it supersedes. Compatibility is the degree to which an innovation is perceived as consistent with existing values, past experiences and perceived goals of the user. Complexity is the degree to which an innovation is perceived as being difficult to understand and use. Trialability is the degree to which an innovation may be experimented with on a limited basis. Observability is the degree to which the results of the innovation are visible to others [20,21]. In Fichman and Kemerer [22], for instance, these PCIs were investigated in relationship to the adoption of object-oriented technology.

115

This paper is not a formal study into the diffusion of RE innovations, and for the sake of simplicity we have grouped the two characteristics – complexity and compatibility – under the generic notion of ‘obstacles’ (i.e., deteriorating factors for adoption), and the three characteristics – relative advantage, trialability and observability – under ‘incentives’ (i.e., contributing factors for adoption). Obstacles to and incentives for successful transfer of RE innovations are discussed in the next two sections of this paper.

3. Obstacles In addition to the problems cited above, other obstacles to the adoption of new RE methods exist. This section describes two classes of obstacles: those that confront the producers of RE research, usually universities or research groups in government or industry, and those that confront technology consumers, typically industrial organisations.

3.1. Technology Providers 3.1.1. Universities

By their very nature, research prototypes such as requirements modelling and analysis tools from universities are not immediately ready for adoption by industry. In principle, universities could spearhead technology transfer. However, they do not have the resources or the skills to tackle large development projects. Moreover, there are significant cultural differences between universities and industrial organisations, which inhibit technology transfer. 3.1.2. Lack of RE Education

Few universities provide up-to-date RE courses at an advanced undergraduate or graduate level as part of their software curriculum. As a result, RE-related training must be provided by industry. Although such training is sometimes available in industry, it often focuses on one specific tool. Industry courses rarely provide broad education in RE. 3.1.3. Lack of Standard Specification Languages

While standard languages with precise semantics exist for hardware design (e.g. Verilog and VHDL), no standard languages exist for specifying requirements. Within the research community, it is common practice for research groups to invent new languages rather than build directly on the work of others. Not surprisingly, the

H. Kaindl et al.

116

documentation associated with such languages is often incomplete and not particularly user-friendly. Moreover, researchers generally limit their attention to small academic examples (e.g. automobile cruise control), and rarely validate their ideas on larger, more realistic examples. For these and other reasons, most requirements documents, if they are produced at all, are often written in natural language [1]. Of course, natural language descriptions have their merits for communication among humans, e.g. users and developers. There is a problem, however, when the only description of requirements is in natural language. Because natural language is inherently ambiguous, analysing such descriptions can be very difficult. Developed by the object-oriented community, with ideas adopted from several fields, UML has been standardised [2]. It is highly controversial, however, whether UML has a solid and well-accepted semantics. There is widespread agreement that large parts of UML are ambiguous. Still, many believe that UML has the potential to become a standard language for requirements modelling. However, the language has been designed and is used today primarily for object-oriented software design, rather than requirements. Thus, UML is intended for use by software engineers, and as such is not easily understandable by non-technical stakeholders, especially since it is complicated. Fortunately, only a small subset would have to be used for modelling requirements. UML’s big advantage is that its standardisation has ended the notational struggles, where numerous symbols and drawing styles had been proposed for the same concept. A related methodological issue is what kinds of objects a UML diagram models. For example, the simple class diagram in Fig. 1 defines that a class ‘Transaction’ has subclasses ‘Cashier Transaction’ and ‘Remote Transaction’. But it does not define whether they model transactions in a real-world banking domain or software objects inside a bank computer or automated teller machine, unless an appropriate naming convention is employed. While it may seem useful to employ the same notation for both, this can cause confusion even beyond requirements modelling [23].

3.1.4. Lack of Tools

Another significant area where research results are weak is tool support for proposed new languages and methods. A large industrial project is unlikely to adopt a method that lacks adequate tool support. While methods are rarely applicable for all kinds of problems, this issue is even more stringent for tool support. For example, developing business systems and high assurance systems are quite different problem domains. A promising approach to classifying, analysing and structuring software development problems are problem frames [24]. Even when tools are available as research prototypes, they are seldom robust, documented and scalable. Even when tool support for a new method exists, it is typically not integrated into a comprehensive collection of software engineering tools. Possible exceptions are the RETH (Requirements Engineering Through Hypertext) tool [10] for actively supporting a ‘lightweight’ approach to requirements definition, as well as the SCR (Software Cost Reduction) tools [6,7] and the RSML (Requirements State Machine Language) tools [25] for formal analysis of requirements. These tools are products of RE research, and have been applied to practical systems (e.g. [5,8,10,26,27]). Current commercial RE tools are well suited for managing large amounts of requirements written in natural language, but not for engineering requirements. Thayer and Dorfman [28] define software RE as the science and discipline concerned with establishing and documenting software requirements. They state that it consists of software requirements elicitation, analysis, specification, verification and management. They define software requirements management as ‘the planning and controlling of the requirements elicitation, specification, analysis, and verification activities’. Thus they consider requirements management to be part of requirements engineering. See Mead [29] for more about the distinction between managing and engineering requirements. There is also some doubt that the requirements collected in practice today are worth managing, given their low quality. Rather, more effort should be invested in the production of high-quality requirements using results from ongoing RE research.

3.1.5. Pressure to Transfer Anything and Everything into Practice

Fig. 1. A simple UML class diagram.

To justify investment in RE research, there is often pressure to transfer anything and everything into practice, and the sooner the better. This leads to poorly conceived short-term research, at the expense of longterm research. Today the operative word in the world of

Requirements Engineering and TechnologyTransfer

117

3.2.1. Organisational Inertia

Many engineers and their managers stick to tried-andtrue methods. Although a new method might have potential, often no time or budget is available to teach developers how to use the method. Moreover, because budgets are frequently allocated according to activity, the RE portion of the life cycle often has to absorb the entire cost of adopting new requirements engineering methods. Very few organisations are sufficiently forward-thinking to average the cost of learning new methods across the entire life cycle or across several projects, or to cover the risk in corporate overhead. 3.2.2. Competitive Environment Fig. 2. A dependency chain of research results.

R&D is innovation. Innovation is, of course, a major ingredient of any healthy economy, but it connotes pressure to focus only on work that quickly and directly yields patent-worthy and/or marketable results. Figure 2 describes a process which leads from ‘less applied’ to ‘more applied’ to ‘ready for prime time’ results. In the column labelled ‘RE’, each level depends on the levels below. There is a path from theories and models to prototypes and experiments, and then to RE technologies that can be applied in practice. Figure 2 also indicates dependencies of this process on supporting disciplines. RE is by its very nature interdisciplinary and needs to adapt and integrate results from other disciplines, such as management studies, sociology and cognitive science. When the definition of research is limited to opportunistic innovation, then all levels of research are expected to result in technology transfer (e.g. because researchers need funding). Thus, newly conceived and untested models or experimental prototypes are often thrown together into tools that become the objects of (failed) technology transfer attempts. Such practices only lead to disillusionment in industry. Innovation is best achieved through a mix of long-term and short-term research. The best short-term research is usually derived from solid long-term research.

3.2. Technology Users We also identified several obstacles primarily related to technology users.

As the industrial environment becomes more competitive, tight schedules tend to reinforce inertia, creating the feeling that there is ‘no time’ to try something new on a particular project. This view has been reinforced by previous workshop results [15]. Schedule pressure in a real-world project means that the requirements process receives the least attention and that frequently requirements are intentionally or unwittingly forgotten. The highly competitive environment also means that organisations face intense pressure on costs, while also trying to remain flexible to adapt to rapidly changing requirements. At the same time, the range of development choices has opened up a brave new world of kernels, components and COTS, as well as outsourcing [30]. Contemporary sourcing policy demands new skills – commercial and process management, including requirements management – but RE and requirements management are not usually institutionalised. Software providers are under the same pressures as their customers. Incorporating new methods into a contract means justifying the extra cost and time to their customers, and to their hard-pressed staff. 3.2.3. Lack of Technical Support

Project team members often need to consult an expert when they start to use a new method. It is often the case, however, that there is little or no opportunity for technical consultation, leaving the software engineer to feel lost and isolated. This problem is exacerbated by the fact that many organisations are generally reluctant to use consultants from outside the company, or even outside the project, when expertise is needed. Corporate rules reinforce this by requiring formal contracts and other time-consuming mechanisms before such help can be brought in.

H. Kaindl et al.

118

Fig. 3. Illustration of a business case.

3.2.4. Cycle Time Between (Re)formulation of Business Objectives and the (Re)specification of Requirements

Another serious problem for RE is that the cycle time between (re)formulation of business objectives and the (re)specification of requirements needs to be very short. Consequently, the communication between business and technical people needs improvement. Moreover, business planning must include more systems analysis, and systems analysis must be less isolated from business concerns. Incorporating enterprise modelling into RE is one way to move RE closer to business [31]. Conversely, the business analogue to system requirements is the business case (see Fig. 3). A business case expresses objectives, some notion of a plan for achieving them, and an analysis of (e.g. financial) benefits and risks. Business cases typically contain the least amount of detail required to gain approval for funding. It is often useful to include in a business case descriptions of achieving the objectives and models of the operational environment (as-is, or as desired). This additional conceptual information can play a useful role in business analysis, RE and even in monitoring an operational environment. Such information can also lead to better predictions of business outcomes, such as reduced production costs, faster service and fewer orders lost, and would ultimately aid the formulation of requirements that express what the system(s) must achieve to produce acceptable actual business outcomes. This intertwining of business analysis and requirements analysis creates a locus of activity where RE research and technology may have a smoother technology transfer path. 3.2.5. Evolving Requirements

The fact that requirements are a moving target, continuously changing and never complete, makes it difficult to apply the concept of frozen requirements. Understanding that requirements are a moving target is,

in itself, an important point to software professionals and researchers. Evolving requirements is a challenge to requirements research [32]. A practical approach for dealing with evolving requirements is an iterative and incremental development process as proposed in Jacobson et al. [33]. Evolutionary development as proposed in Boehm and Hansen [34] has the same spirit in this respect. While special life cycle approaches are defined for this kind of development [33,34], it can well be implemented in many ways [35,36]. The common and important point with regard to evolving requirements is the following: a possibly small and preliminary set of requirements is defined first and frozen, but only for a short time period (in the order of a few weeks), when they are immediately implemented. Based on the insights from that effort, new constraints from the environment and possibly early experience, a new set of requirements is defined for the next iteration of development. Part of these new requirements may even contradict earlier requirements, reflecting the changes in the course of the evolution. Whenever requirements change, it is desirable to quickly see the impact of these changes. This can be achieved through applying the concept of traceability [37–39]. 3.2.6. Negative Perception of Formal Techniques

Another barrier is the widespread perception among software developers that formal notations and analysis techniques are hard to learn, provide no clear benefits and require too much effort (e.g. specification using temporal logic) and too much detail early in the development process. Moreover, while conceding that formal techniques may be quite useful in developing high assurance systems, practitioners also express serious doubts about the scalability and cost-effectiveness of formal techniques. This difficulty is due partly to the lack of standard RE languages with well-accepted semantics (see above). In contrast, integrating a formal technique such as a model checker into a hardware design process is relatively easy because other tools, such as simulators and synthesis tools, are already a standard part of the design process at many hardware companies. Worth noting is that sometimes the existence of tools other than RE tools that software developers find useful can encourage developers to adopt a requirements language other than natural language. For example, the existence of an automatic test case generator (for checking the correctness of a software implementation against a requirements specification) has led three Lockheed sites to adopt the SCR notation for documenting requirements. Most industrial organisations prefer

Requirements Engineering and TechnologyTransfer

tool suites that cover several phases of the software life cycle over standalone products that cover only one activity [40]. Hence the integration of RE tools with other tools, such as automatic test case generators and code synthesis tools, could lead software developers to adopt more rigorous RE methods.

4. Incentives Fortunately, there are also incentives for using RE methods. We need to advertise them more widely, however, because many people in industry are not fully aware of them.

4.1. Early Error Detection It seems obvious that errors detected during the early phases of software development are much cheaper to correct than errors detected during the later phases. Estimates are that correcting errors, such as missing cases and safety and security violations, during coding, testing and initial operational usage costs from 10 to 100 times more than correcting errors during the requirements phase. New quantitative studies in practice need to substantiate such estimates, because the argument that it costs $1 to fix an error at the requirements stage and $100 to fix it after release can make a persuasive case for the exploitation of the mature fruits of requirements research. This figure reaches thousands of euros for software products vendors when errors in requirements are to be repaired on all installations at customer sites. Hence, it pays both economically and in saved human effort to detect and correct defects in the requirements early in development.

119

system behaviour agreed to by all the stakeholders, and highlights those areas where disagreement remains, but can be managed.

4.3. Solid Foundation for Later Phases If such an agreed-upon requirements document is precise and unambiguous, it is a solid foundation for the later phases of development – software design, coding, testing and maintenance. Representing the requirements in a notation with a formal semantics and applying formally based analysis techniques, such as consistency checking, simulation, model checking, specification execution and theorem proving, can find specification errors that inspections miss and can result in a very high-quality requirements document (e.g. [7,27,41]). Further, a highquality requirements document can be the basis for automatically generating test sets that are useful in determining whether the source code satisfies the requirements (e.g. [42]). Automatic construction of test cases from requirements specifications should save significant time, money and human effort.

4.4. Improved Quality and Productivity Many new RE methods claim to improve both quality and productivity. This is always appealing to both managers and practitioners. Some methods provide data to support this claim or provide formulas for arriving at the improvement projections for a project. If a project does indeed result in improved quality and/or productivity, the project, and the person who suggested use of the method, will be held in high regard.

4.5. Improved Management Visibility and Control 4.2. Early Detection of Differences Among Stakeholders A system requirements document has many different stakeholders, including the customers, the users, the program manager and the software developers, among others. These stakeholders often have different notions of the required system behaviour and its constraints. A precise, unambiguous requirements document clarifies differences among the stakeholders early in the development process. Exposing and resolving these differences during the requirements process has clear benefits. Ideally, the product of the requirements effort is a requirements document that aims to be as precise and unambiguous as possible by describing the required

Managers are always interested in improving the predictability of projects, and new methods often claim to do this. If a new method provides management with a good view of what is happening in RE, management will not have to extract this information directly from the requirements engineers. The engineers, on the other hand, will not have to spend time producing specialised reports for management. They can simply provide the reports that naturally result from use of the new method. In the best of all worlds, an automated tool produces the desired management data, with no extra effort on the part of the engineer. Managers also have the advantage of producing reports easily, to show how well they are doing.

H. Kaindl et al.

120

4.6. Using Leading-Edge Methods In many organisations it is always good to be viewed as using the latest and greatest technology. It shows that the practitioner is forward-thinking, and enhances his or her reputation as a visionary with management. It also has the potential for bringing credit to the project and its management if the new technology is successful. Use of a leading-edge method sometimes helps an organisation recruit people who want to work with new methods rather than using the same old stuff. It also enhances a practitioner’s resume to have experience with leadingedge methods. When practitioners look for jobs later, it helps them to have experience with as many technologies as possible.

5. An Agenda for Improvement Below, we sketch a few ideas to be put on an agenda for improving on the current situation. We hope that it will help the RE community to come up with a more concrete action list, which we believe practitioners badly need. While our agenda for improvement already indicates the types of mechanisms for addressing the problems listed above, concrete actions will have to be defined and executed for really solving them.

5.1. Broader Application of Existing Approaches In the short run, it would be beneficial to see an even broader application of already existing approaches. Such approaches should be advertised to practitioners in the trenches even more intensively, but with a warning that they are no panacea. It is also important for practitioners to understand that RE is not really a discipline in its own right, but rather a sub-area of software and systems engineering. Finding the right requirements is ‘just’ one set of activities in a chain of activities that must work seamlessly together: initiated by business analysis and design, and followed by RE, software design, implementation and testing. Because of the broad aspect of software requirements,4 social sciences play an important role in RE. The book [44] describes some social aspects related to RE.

5.2. Two-Way Transfer In retrospect we can see that the panel discussions focused mostly on the flow of ideas from research 4

‘Software engineering problems are problems of constructing machines to serve useful purposes in the world’ [43].

(primarily from academia) to practice (primarily to industry). This seems to reflect a dominant mind-set in the RE community that has been towards technology transfer from academia to industry, which may have even been a source for the previous and current problems with technology transfer in RE. In order to improve this situation, we think the way forward should be the exchange of knowledge between the two parts of the community. The discussion needs to focus on how knowledge creation and exchange takes place between researchers and practitioners. Successful technology transfer will depend on continuing two-way collaborations between researchers and practitioners. They need one another due to their complementary skills, knowledge and experience.

5.3. Standards Still, RE practice will most likely remain immature until . there are professional software engineering standards that require a rigorous requirements definition process with concrete outputs (note that even evolving requirements can be dealt with rigorously as indicated above); . notational standards (such as those UML is striving to establish) are generally accepted and used; . we build on what others have done, rather than inventing yet another modelling technique; . more ‘practical’ formalisations (i.e., formalisms that are more easily used by practitioners) are available and adopted by practitioners; and . rigorous analysis techniques, such as consistency checking, model checking and mechanical theorem proving, are applied to requirements documents. In fact, there is already some market pressure for standards in software production, such as the Capability Maturity Model and ISO standards. Of course, setting standards is in conflict with the ever-shorter development cycles, and also with the need to handle evolving requirements. But as in other engineering disciplines, we expect that it will be possible to accommodate professional standards while being realistic at the same time and about the need to deliver software on time.

5.4. RE as Innovation A way forward can also be to treat the introduction of new RE methods as a problem in innovation and strategic change, and manage the change. To do that we must marshal the strategic as well as the operational

Requirements Engineering and TechnologyTransfer

arguments. And we must . get senior management commitment [45]; . be able to evaluate RE activity that can identify and justify costs and risks, as well as promote benefits [46]; . design effective reward structures for good practice; . advertise success [45]; . leverage and optimise skills across the supply network [47]; . make better use of universities’ core competencies – teaching and the critical imagination; and . use universities for projects that are high-risk, highgain problems, 2–5 years away.

5.5. The Direction of RE Research The need to rethink the research direction in RE has been signposted in Siddiqi and Shekran [48]. In the last decade requirements-as-contract has become less relevant to many software developers because of the shift from custom-designed to off-the-shelf software (also called product or packaged software) [49], which is being produced on market-driven criteria. This means that researchers must change their agenda if they are to meet practitioners’ needs, because industry may legitimately ask to have critical issues of RE practice investigated in mainstream RE research. Thus, it is important to provide effective mechanisms for a twoway exchange between researchers and practitioners. For example, any requirements listing of an arbitrary IT project will contain a complex myriad of statements expressing wishes of users/customers on a hardware/ software artefact to be engineered by a team. Hence it is important to improve structuring, understandability and formulation. Several other high-level critical issues deserve further research without delay, including composition and communication of requirements. In this regard, scalability is especially important for dealing with large volumes of requirements. This research would include, for example, exploring new structuring mechanisms for (large) requirements documents/models, quality of requirements structures, defining metrics for requirements structures, empirical studies on existing large requirements documents/models, base-lining and scoping for release-based software development, and empirical investigations of real-life projects, tracking and tracing from requirements to designs and code, and vice versa. Finally, we strongly recommend more research on the economics of RE. To the best of our knowledge, there has been little research on this topic. It remains the case that lack of concrete knowledge of what organisations can gain from applying state-of-the-art – but also time-

121

consuming – requirements approaches is one of the major obstacles in getting research results adopted by practitioners. The only way to gain more knowledge about the economics of RE is for researchers to work together with practitioners.

6. Conclusion Given the obstacles that exist to both the technology provider and the technology user, it is clearly difficult to introduce results from RE research into mainstream practice. In addition to previously published issues, we have elaborated on obstacles related to both the technology provider and the technology user. Nevertheless, there exist important incentives for using RE methods, which may help to overcome at least some of the obstacles. One major incentive is the estimated economic benefit of resolving errors during the requirements process, rather than later on. A barrier is the need to wait for awareness of research results to mature, which can act as a quality-assurance check. Although we have not yet been able to provide a concrete action list, we have proposed an agenda for improving the current situation. While the panel discussions ‘seeding’ this paper focused mostly on the flow of ideas from research to practice, successful technology transfer will depend on two-way collaborations between researchers and practitioners. They should pursue more serious research on RE technology transfer together. Acknowledgements We would like to thank Pei Hsia for email discussions about the topic of the proposed panels and his help in getting things started. We acknowledge the ideas of Alan Davis, Stuart Faulk and Martin Feather that also influenced the ICRE panel. We also thank Ivar Jacobson for his contribution as a CAiSE panellist and for his comments to earlier drafts of this paper. Julio Cesar Sampaio do Prado Leite acknowledges the partial support from CNPq and Faperj, the Software Engineering Group of Universita¨t Kaiserslautern (AGSE) and the Fraunhofer IESE. Finally, we thank the anonymous reviewers for their very useful comments which led to numerous improvements in our submission.

References 1. Hsia P, Davis A, Kung D. Status report: requirements engineering. IEEE Software 1993;10(6):75–79 2. Rumbaugh J, Jacobson I, Booch G. The Unified Modeling Language reference manual. Addison-Wesley, Reading, MA, 1999. The standardised specification of UML is available at http://www.omg.org ¨ vergaard G. Object3. Jacobson I, Christerson M, Jonsson P, O oriented software engineering: a use case driven approach. Addison-Wesley, Reading, MA, 1992 4. Jarke M, Bui TX, Carroll J. Scenario management: an interdisciplinary approach. Requirements Eng 1998;3(4):155–173 5. Kaindl H. A design process based on a model combining scenarios with goals and functions. IEEE Trans Syst Man Cybernetics (SMC) Part A 2000;30(5):537–551

122

6. Heitmeyer C, Jeffords R, Labaw B. Automated consistency checking of requirements specifications. ACM Trans Software Eng Methodol 1996;5(3):231–261 7. Heitmeyer C, Kirby J, Labaw B, Archer M, Bharadwaj R. Using abstraction and model checking to detect safety violations in requirements specifications. IEEE Trans Software Eng 1998; 24(11):927–948 8. Blackburn M et al. TAF quickly identifies error in Mars Polar Lander software. In: Lockheed Martin joint symposium, 2000 9. Greenspan S, Mylopoulos J, Borgida A. Capturing more world knowledge in the requirements specification. In: Proceedings of the sixth international conference on software engineering (ICSE’82), 1982. Also published in Freeman and Wasserman (eds). Software design techniques. IEEE Computer Society Press, Los Alamitos, CA, 1983 10. Kaindl H. A practical approach to combining requirements definition and object-oriented analysis. Ann Software Eng 1997;3:319–343 11. Kaindl H, Mylopoulos J. Why is it so difficult to introduce requirements engineering research results into mainstream requirements engineering practice? Panellists: S. Brinkkemper, J.A. Bubenko, B. Farbey and I. Jacobson. In: Proceedings of the 12th conference on advanced information systems engineering (CAiSE 2000), Stockholm, Sweden, June 2000. Springer, Heidelberg, 2000, pp 7–12 12. Kaindl H. Why is it so difficult to introduce requirements engineering research results into mainstream requirements engineering practice? Panellists: S.J. Greenspan, C. Heitmeyer, J.C.S. do Prado Leite, N.R. Mead and J. Siddiqi. In: Proceedings of the fourth IEEE international conference on requirements engineering. Schaumburg, IL, June 2000, pp 67–68 13. Miller S. Panel: how can requirements engineering research become requirements engineering practice? In: Proceedings of the third IEEE international symposium on requirements engineering, 6–10 January 1997, Annapolis, MD. IEEE Computer Society Press, Los Alamitos, CA, 1997, p 260 14. Greenspan S. Delivering requirements engineering. In: Proceedings of the third IEEE international conference on requirements engineering, Colorado Springs, CO, April 1998. IEEE Computer Society Press, Los Alamitos, CA, 1998, pp 128–129 15. Morris P, Masera M, Wilikens M. Requirements engineering and industrial uptake. In: Proceedings of the third IEEE international conference on requirements engineering, Colorado Springs, CO, 6–10 April 1998. IEEE Computer Society Press, Los Alamitos, CA, 1998, pp 130–137 16. Fowler P, Patrick M. Experience using a benchmarking workshop to explore one route to practical technology introduction. In: Facilitating technology transfer through partnership: learning from practice and research, Proceedings IFIP technical committee 8 working group 8.6, international working conference on diffusion, adoption, and implementation of information technology, Ambleside, UK, 25–27 June 1997. Chapman & Hall, London, 1997, pp 304–318 17. Fowler P, Patrick M, Carleton A, Merrin B. Transition packages: an experiment in expediting the introduction of requirements management. In: Proceedings of the international conference on requirements engineering, Colorado Springs, CO, 6–10 April 1998. IEEE Computer Society Press, Los Alamitos, CA, 1998, pp 138–145 18. Fowler P, Patrick M. Proceedings of the introducing requirements management into organizations workshop: requirements management transition packages (CMU/SEI-97-SR-001, ADA325553). Pittsburgh, PA, 11–13 November 1996. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1997 19. Committee on Innovations in Computing and Communications. Lessons from history, National Research Council. Funding a revolution: government support for computing research. National Academic Press, 1999 20. Chin WW, Marcolin BL (eds). Special issue on adoption, diffusion, and infusion of IT. Database 2001;32(3) 21. Rogers EM. Diffusion of innovations (4th edn). Free Press, New York, 1995

H. Kaindl et al. 22. Fichman RG, Kemerer CF. The assimilation of software process innovations: an organizational learning perspective. Manage Sci 1997;43(10):1235–1363 23. Kaindl H. Difficulties in the transition from OO analysis to design. IEEE Software 1999;September/October:94–102 24. Jackson M. Problem frames: analysing and structuring software development problems. Addison-Wesley and ACM Press, 2001 25. Thompson J, Heimdahl MPE, Erikson D. Structuring formal control systems specifications for reuse: surviving hardware changes. In Proceedings of the fifth Langley formal methods workshop, Williamsburg, VA, June 2000 26. Leveson NG, Heimdahl MP, Hildreth H, Reese JD. Requirements specification for process-control systems. IEEE Trans Software Eng 1994;20(9):684–707 27. Kirby J, Archer M, Heitmeyer C. SCR: a practical approach to building a high assurance COMSEC system. In: Proceedings of the 15th annual computer security applications conference (ACSAC’99). IEEE Computer Society Press, Los Alamitos, CA, 1999 28. Thayer R, Dorfman M. Software requirements engineering (2nd edn). IEEE Computer Society Press, Los Alamitos, CA, 1997 29. Mead NR. Requirements management and requirements engineering: You can’t have one without the other. Cutter IT J 1999;3(5):4–8 30. Farbey B, Finkelstein A. Software acquisition: a business strategy analysis. In: Proceedings of the fifth IEEE international symposium on requirements engineering, August 2001, Toronto, Canada. IEEE Computer Society Press, Los Alamitos, CA, 2001, pp 76–83 31. Yu ESK. Towards modeling and reasoning support for earlyphase requirements engineering. In: Proceedings of the third IEEE international symposium on requirements engineering, 6– 10 January 1997, Annapolis, MD. IEEE Computer Society Press, Los Alamitos, CA, pp 226–235 32. Leite JCSP, Rossi G, Maiorana V, Balaguer F, Kaplan G, Hadad G, Oliveros A. Enhancing a requirements baseline with scenarios. Requirements Eng J 1997;2(4):184–198 33. Jacobson I, Booch G, Rumbaugh J. The unified software development process. Addison-Wesley, Reading, MA, 1999 34. Boehm BW, Hansen WJ. Understanding the spiral model as a tool for evolutionary acquisition, 2001. USC-CSE-2001-501. Online at http://sunset.usc.edu/publications/TECHRPTS/2001/usccse 2001-501/usccse2001-501.pdf 35. European Space Agency. ESA software engineering standards. PSS-O5-1. 1992 36. Kaindl H, Lutz B, Tippold P. Methodik der Softwareentwicklung: Vorgehensmodell und State-of-the-Art der professionellen Praxis. Vieweg, Braunschweig/Wiesbaden, 1998 37. Pinheiro FC. Formal and informal aspects of requirements tracing. Anais do III Workshop de Engenharia de Requisitos, 13–14 July 2000, Rio de Janeiro, Brazil. Dep. de Informa´tica, PUC-Rio, 2000, pp 1–21. (Also available at http://www.inf. puc-rio.br/~wer00/Anais.html) 38. Ramesh B, Jarke M. Toward reference models of requirements traceability. IEEE Trans Software Eng 2001;27(1):58–93 39. Ebner G, Kaindl H. Tracing all around in reengineering. IEEE Software 2002;May/June:70–77 40. El Emam K, Madhavi NH. A field study of requirements engineering practices in information systems development. In: Proceedings of the second IEEE international symposium on requirements engineering, York, UK, March 1995. IEEE Computer Society Press, Los Alamitos, CA, 1995, pp 68–80 41. Siddiqi JI, Morrey IC, Roast CR, Ozcan MB. Towards quality requirements via animated formal specifications. Ann Software Eng 1997;3:131–155 42. Gargantini A, Heitmeyer C. Automatic generation of tests from requirements specifications. In: Proceedings of ACM seventh European software engineering conference and seventh ACM SIGSOFT symposium on the foundations of software engineering (ESEC/FSE99), Toulouse, France, September 1999 43. Jackson MA. A discipline of description. Requirements Eng J 1998;3:73–78

Requirements Engineering and TechnologyTransfer 44. Jirotka M, Goguen J. Requirements engineering: social and technical issues. Academic Press, New York, 1994 45. Pugh D. Understanding and managing organisational change. In: Maby C, Mayon-White W (eds). Managing change (2nd edn). Paul Chapman, London, 1993, pp 108–112 46. Farbey B, Land FF, Targett D. How to evaluate your I/T investment: a study of methods and practice. Butterworth Heinemann, Oxford, 1993

123

47. Wikstro¨m S, Normann R, Anell B, Ekvall G, Forslin J, Ska¨rvad PH. Knowledge and value: a new perspective on corporate transformation. Routledge, London, 1994 48. Siddiqi J, Shekran M. Requirements engineering: the emerging wisdom. IEEE Software 1996;March/April:15–19 49. Brownsword L, Oberndorf T, Sledge CA. Developing new processes for COTS-based systems. IEEE Software 2000;July/ August:48–55.