MINIMUM REQUIREMENTS ENGINEERING: AN APPROACH TO TECHNOLOGY TRANSFER FOR SMALL PROJECTS Uolevi Nikula Department of Information Technology, Lappeenranta University of Technology, P.O. Box 20, FIN-53851 Lappeenranta, Finland
[email protected] ABSTRACT The current research and literature in requirements engineering (RE) has focused on large and complex systems. Even if this is understandable it causes two fundamental problems to the field. First it leaves the impression that small projects really do not need to do systematic RE. The second more serious problem is that small projects, with little resources and in the lack of any concrete and practical advice from literature, do not have realistic chances to establish own RE practices. In our opinion even the small software development projects should utilize the state-of-the-art RE practices in their daily work. To support this goal we are working on the identification of minimum RE practices for small software projects that fit in the Jackson’s Simple IS problem frame. We hope to show that a reasonable minimum set of RE practices can be identified based on the software type. Moreover, we investigate the possibility of applying minimum RE without explicitly addressing application domain specific issues. In general a clear set of RE practices that can be taken in use without extensive tuning should encourage the majority of software developers to start practicing RE. 1. INTRODUCTION The technology transfer gap between requirements engineering (RE) research and practice has persisted ever since the introduction RE in mid 70’s. The gap can be seen in basically all the published RE state-of-the-practices surveys as well as in articles and panels discussing the topic [10]. Even if the problem has not yet disappeared the situation has changed a lot during the past decades. The number of trade literature in RE is increasing rapidly but despite the volume of available literature the majority of software developers have not yet started to work on improving their RE practices. The problem seems to be the mismatch of available literature and the needs of the practitioners. Most of the existing literature discuss the problems of large and complex software systems while much of the software is developed in small or medium sized projects. Many of the software vendors have immature software development processes and consequently spend a lot of time struggling
with their daily software development tasks. In our stateof-the-practice survey this problem was also apparent as the companies were interested in improving RE practices but did not know how to start it [10]. If we consider the existing body of literature and the adopter categories as defined by [12], we can assume that the innovators and early adopters have already found RE. This should provide us sufficient experiences to convince also the early majority to do RE. The early majority is in critical position in the adoption process since it tends to work as opinion leaders and thus they are in a natural position to get the rest o f software developers to adopt RE. The [2] study on technology transfer packages gives very promising results on helping the majority adopter categories to get started with requirements management. We are working to define a minimum RE package to be applied to Jackson’s Simple IS (Information System) problem frame [7]. In general the problem frames are used as generalizations of problem classes (e.g. control, transformation, or connection problems). We chose the Simple IS frame to be able to consider all the key issues of one context and to form a clear and simple package for it. Consequently, this package should provide a balanced combination of techniques, documents, and tools so that practitioners could start using it with minimal adoption. Of course, such a package is only intended as a start-up package; it is not expected to be satisfactory in the long term but to remove the first obstacles when taking the first steps in process improvement efforts. 2. MINIMUM REQUIREMENTS ENGINEERING A wider industrial adoption of RE in every day work requires small and clear technology transfer packages [2] and success stories of applying the package in practice. In our opinion for most companies the question is really not what the “best practices” are but what are the minimum practices. The goal of minimum practices is that companies can start applying them with minimal effort but still the practices would clearly demonstrate the benefits of doing RE. A ready to use RE package must define a balanced combination of requirements engineering process (REP), requirements documents, and tool support for these tasks.
This kind of package would make the introduction of RE a straightforward task. By definition such a package will confirm to the SPICE level 3 (defined) process [1]. However, as the package is also expected to demonstrate the benefit of doing RE, performance measurements should be done, too. Thus the technology transfer package should be in the SPICE level 4 (measured). The process is one of the critical factors in taking RE into practice. The high level issues are a seamless integration of the REP to the overall software development process and the smooth REP itself. This means that the REP should utilize the information available from the general process and it should produce information that is useful for the general process through standard interfaces. Even if we believe that continuous RE is the only feasible way of doing RE [13] we feel that the distinction between requirements development and management should also be made. The somewhat artificial separation of these two phases is done with the baselining of the requirements document for software development. In the following we will focus on the requirements development phase. A realistic REP is hardly possible without elicitation, documentation, and negotiation phases done in an iterative manner [14]. The iteration provides many benefits but it also introduces a big problem – when are the requirements well enough understood for the development to commence with them? Thus the requirements validation and verification that justifies baselining of requirements must be an integral part of the REP. Requirements documents are the key outputs of RE. Even if there are many attempting alternatives for printed documents the old-fashioned paper versions still provide a high visibility and concrete deliverable for the REP. The contents and style of the documentation has been extensively described in literature in, for example, forms of standards (e.g. [4], [5]), books (e.g. [3], [8], [9], [11], [14]), and templates (e.g. [11]). However, especially the standards have been designed for really large projects so adopting them to a small project is far from a trivial task. The tool support for RE is needed to balance the inevitable increase of effort caused by systematic RE practices. Namely, in short term documenting and resolving open issues requires extra work. Since this trend is hardly desirable the routine tasks should be eliminated with the help of some requirements management tool. The extra effort needed for tool selection, on the other hand, can be reduced by providing selection guidelines and pointers to requirements management tool literature (e.g. [6]). Measurement is often considered as a difficult issue and it is rarely done. However, demonstrating the improvement of practices is hard unless some metrics are available. In our opinion minimal measurement should be done in each project with basic metrics that are readily adaptable by practitioners. To achieve this goal the metrics should be collected as a by-product, preferable automatically with
the help of the used tools. For example, having a requirement template with a time stamp and a requirements management system with version control should allow easy retrieval requirement number at different project phases (dates) to see when the requirements were actually identified. Or the number of requirements that have been added, changed, or deleted to assess the stability and trends of the collected requirements. The final issue for minimum RE is that the validation must be done in industrial projects. Thus a serious of case studies must be done to see how the approach performs with real life problems. 3. DISCUSSION In this paper we have proposed the idea of minimum RE. The notion of best practices is well accepted in industry but in our opinion that is an unrealistic goal in the situation which is best characterized by lack of any systematic practices. Minimum RE has been developed based on three facts. First the early majority of innovation adopters work as opinion leaders and getting them to do RE is a prerequisite for achieving a wider acceptance for RE. Second small technology transfer packages are needed to make the adoption process feasible for small projects and companies. And third the context for RE – the problem frame – must be clearly defined. The approach addresses two issues that need further study in practical RE at present. The first one is providing example cases on how to do RE and the other one is to provide an easy and quick start on doing RE. Once the first steps in improving the practices have been taken it is assumed that more advanced methods and techniques will be needed. For example, the application domain specific features will surely affect the RE in more mature organizations. The identification of minimum RE practices could have a significant effect on the way we approach RE. The most pronounced effect could be in the education, training, and self-study of RE since small packages are easier to handle in short courses and in self-study. As the package should balance all the aspects necessary for introducing RE the comprehension of it would provide a sound and solid basis for also adopting the approach when necessary. And finally the approach would give industry clear example cases on how to start doing RE – just what they keep on asking today.
Acknowledgements The author would like to thank the instructors prof. Jorma Sajaniemi and prof. Heikki Kälviäinen for the support and help in developing the paper. The East Finland Universities Graduate School in Computer Science and Engineering (ECSE) is acknowledged for scientific and
financial support.
[10]
Nikula, U., Sajaniemi, J. and Kälviäinen, H. (2000), Management View on Current Requirements Engineering Practices in Small and Medium Enterprises, in: Conference Proceedings of the Fifth Australian Workshop on Requirements Engineering, Brisbane, Australia: University of Technology, Sydney, pp. 81-89.
[11]
Robertson, S. and Robertson, J. (1999), Mastering the Requirements Process. Harlow, England: Addison-Wesley.
[12]
Rogers, E.M. (1995), Diffusion of Innovations, 4 th edition. New York: Free Press.
[13]
Sawyer, P. (2000), Package Software: Challenges for RE, in: Proceedings of the 12th International Conference in Advanced Information Systems Engineering, Stockholm, Sweden: Springer, pp. 137-142, (Lecture Notes in Computer Science).
[14]
Sommerville, I. and Sawyer, P. (1997), Requirements Engineering – A Good Practice Guide. Chichester, England: John Wiley & Sons.
4. REFERENCES [1]
Flynn, D. (1998), Information Systems Requirements: Determination & Analysis, 2nd edition. Berkshire: McGraw-Hill.
[2]
Fowler, P., Patrick, M., Carleton, A. and Merrin, B. (1998), Transition Packages: An Experiment in Expediting the Introduction of Requirements Management, in: Proceedings of the Third IEEE International Conference on Requirements Engineering, Colorado Springs, Colorado: IEEE Computer Society, pp. 138-145.
[3]
Gilb, T. (1999), Competitive Engineering, September 1999 manuscript of a book to be published by Addison-Wesley in June 2001, Available World Wide Web: URL http://www.stsc.hill.af.mil/swtesting/gilb.asp (Accessed 7 March 2001).
[4]
IEEE Std 830-1998, Institute for Electrical and Electronics Engineers (1998), IEEE Recommended Practice for Software Requirements Specifications, in: Software Requirements Engineering, Second Edition, eds. Richard H. Thayer and Merlin Dorfman, Los Alamitos, California: IEEE Computer Society Press, pp. 207-244.
[5]
IEEE Std 1362-1998, Institute for Electrical and Electronics Engineers (1998), IEEE Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document, in: Software Requirements Engineering, Second Edition, eds. Richard H. Thayer and Merlin Dorfman, Los Alamitos, California: IEEE Computer Society Press, pp. 107-135.
[6]
INCOSE, International Council On Systems Engineering (2001), Tools Survey: Requirements Management (RM) Tools (Online), Available World Wide Web: URL: http://www.incose.org/tools/tooltax.html (Accessed 7 March 2001).
[7]
Jackson, M. (1995), Software Requirements & Specifications – a lexicon of practice, principles and prejudices. Addison-Wesley.
[8]
Kovitz, B.L. (1999), Practical Software Requirements: A Manual of Content and Style. Greenwich: Manning Publications Company.
[9]
Lauesen, S. (1999), Software Requirements – Styles and Techniques. Frediksberg: Forlaget Samfundslitteratur.
