Janis A. Bubenko jr
Department of Computer and Systems Sciences
Royal Institute of Technology, ELECTRUM 230, S-164-40, Sweden
and
Swedish Institute for Systems Development (SISU)
ELECTRUM 212, S-164 40, Kista, Sweden
janis@sisu.se
Abstract of invited talk at RE'95, Second IEEE International Symposium
on Requirements Engineering, 27-29 March, 1995, York, England
Abstract
We discuss a number of essential problems of requirements engineering related to management, organisations, users, stakeholders, methodology, tools, and education. Most of the problems seem to have their roots in how requirements engineering is appreciated at the business management and IT-management levels.
In our view, Requirements Engineering can be said to be the area of knowledge concerned with communicating with organisational actors with respect to their visions, intentions, and activities regarding their need for computer support, and developing and maintaining an adequate requirements specification of an information system. This definition suggests that RE includes managerial, organisational, economic, social, as well as technical issues and problems.
A requirements specification plays several roles in a systems procurement and development process. It should be the basis for a contract between requirements "stakeholders" and system developers or vendors. It should also be an architectural, implementation independent "drawing" of the future system to be ordered. It should provide a basis for reasoning with clients about various traits of the system to be built. Later, it should be an instrument to check if the implemented system is what has been ordered.
When the environment and the requirements on an information system change, as they frequently do, the requirements specification should become a reference description to be used to reason about changes of the environment to be introduced in the IS. One of the objectives of research in Requirements Engineering is to develop a framework of concepts, models, and methods by which requirements can be effectively elicited, specified, and communicated.
Ideally a requirements specification could include a description of basic assumptions, needs, and knowledge of the problem domain, needed for designing and implementing an information system. More specifically, it could include interrelated components describing issues like: - why is the system needed? - which are the objectives of the environment and/or the application? - what are the priorities? - what concepts or subjects is the enterprise about (including its objectives, "business rules", and activities)? - how and by whom are the work processes, tasks etc. performed? - what are the functional and the non-functional IS requirements?, etc.
A methodology for RE needs, however, also methods and processes that support the work with and the production of such descriptions. Methods are needed for how to work with users and clients in the very early stages in order to, in a participative way, acquire and validate requirements and domain knowledge (at several levels of fuzziness and completeness) as effectively as possible. Requirements acquisition is, at least in the Nordic countries, characterised by co-operative work between individuals as well as groups, where co-ordination is vital. It includes often ill-defined, "wicked" and unclear problem situations [11], and problems of (mutual) understanding, and consensus regarding visions, concepts, and other issues. More often than not, there is a need to resolve conflicting user/client views and requirements, and the need to consider many situational factors in order to take the best approach.
Requirements acquisition for information systems is a strongly communicative, iterative and creative design activity. In many respects, in particular concerning the acquisition and management of initial, "fuzzy" requirements, it resembles the problems and the process of requirements capture and the design of "forms" and objects in architecture [2,7].
The growing competitive importance of information systems for running the business, indicates the need of both better understanding the business, and deriving information system requirements from this understanding. A good information system can be a competitive asset of the business, while a system not conforming to the business needs can severely hinder running of the business. This is why we now can observe the beginning of a paradigm shift from the more technology oriented Requirements and Information Engineering approaches to frameworks which focus on modelling of "the enterprise", "the business", and "business goals and rules", e.g. [1,6], and [14]. The importance of establishing explicit links between the development of business objectives and strategies and information system development, is recognised [3,9].
A huge number of commercially marketed system development methods and CASE tools exist today. These products address, however, mainly the middle and/or late stages of the systems development life-cycle. Practically none of them address, in a structured way, the early, business objectives analysis and requirements generating stages, and the problem of moving from the vague and informal to the formal domain. Existing methods are not adequate for explicit capturing, and representing, in a structured way, "business and organisational knowledge" to be subsequently used to drive the information system development phases. Links between business and enterprise models and information system specifications are not maintained. This makes it impossible to reason about changes required in the information system, as a consequence of changes of the enterprise.
In the following sections we summarise a number of challenges that the practice in RE is facing. Solutions to these cannot be achieved by extended academic research alone.
Relationships between RE and investment analysis [13]. are weak. Inadequate investment methods are used. Alternative solutions are not often documented and analysed. Knowledge of how to quantify benefits and risks of different alternative designs and requirements is lacking. Intangible benefits are normally neglected. Competitive edge issues of the business are not considered. Improving internal efficiency is instead focused upon.
The role and responsibility of the IT department in organisations is often not clear. The same holds for the customer - supplier relationship. Goals for the IS are not explicitly stated. This often leads to sloppy control and project management, unclear budgets, and lack of cost follow-up. Even if the "value of the information system" to the organisation is discussed in the early stages of development, the assessment of the utility of the IS is often "lost" in the later stages of development.
Organisations tend not to "learn" from earlier experiences in RE. Requirements specifications are not used as knowledge sources for future RE projects.
This leads to that users and stakeholders, are often not fully enthusiastic participants in RE. But, it happens also that, due to management attitude, user departments are not even consulted [13]. Management attitude regarding RE may also imply that users are not given sufficient authority and time to participate seriously. Therefore, sizeable portions of a requirements specification are often not validated with users [4]. In Sweden it was found that in many cases not even the labour union was particularly interested in participation.
The challenge we have here is to devise new ways of working in RE such that the participative aspect can better be satisfied. One of the obstacles is, however, that many existing professionals in IT/IS are not motivated to change to new principles and methods for systems development.
We do not know much of the RE process, considering all situational factors and possible alternative actions. It is, for instance, not true that requirements specifications in all situations have to be 100% complete, unambiguous, etc. Situational factors strongly influence to what level of detail and completeness to develop specifications.
In many cases the application characteristics and user perception of needs are evolving faster than the RE process itself. Changes in the design stage are not documented by updating the original requirements specification.
In the early RE stages, the models are mainly used to document natural language statements. This presents a difficulty to perform checking and analysis, and "quality assurance" in general. Also, facilities for good group-work support are lacking. In fact, we are not even sure what we need here. In this connection we need to develop technologies also for distributed work.
Current tools have also the drawback that they are not able to deal with all the types of documents used and developed in a RE project, like reports, memos, mail, video sequences, etc.
Many of our academic researchers in SE and RE continue to tackle "interesting and researchable" RE problems, often without knowledge of relevant issues and problems in practical life. More empirical research is needed to determine what the problems are and what types of solutions may become applicable in practical life.
Our academic education in SE and RE is, in many places, not quite adequate for practical work in the field. There is a need to look at software and requirements engineering education, indeed, as a question of producing engineers instead of computer scientists.
2. Cross, N., "Developments in Design Methodology", 1984, John Wiley & Sons.
3. Dobson, J., "A Methodology for Managing Organisational Requirements", University of Newcastle upon Tyne, Newcastle NE1 7RU, UK., 1992.
4. Flynn, D. J. and R. Warhurst, "An empirical study of the validation process within requirements determination", Information Systems Journal, 4(3): 185-212, 1994.
5. IEEE, "An American National Standard. IEEE Guide to Software Requirements Specifications", The Istititute of Electrical and Electronics Engineers, Inc. 345 47th Street, New York, NY 10017, USA, ANSI/IEEE Std 830-1984, 1984.
6. Kirikova, M. and J. A. Bubenko jr, "Enterprise Modelling: Improving the Quality of Requirements Specification", Information systems Research seminar In Scandinavia, IRIS-17, Oulu, Finland, 1994,
7. Lawson, B., How Designers Think. The Design Process Demystified., Butterworth Architecture, London, 1988.
8. Lubars, M., C. Potts and C. Richter, "A Review of the State of the Practice in Requirements Modelling", IEEE International Symposium on Requirements Engineering, San Diego, CA, USA, 1993, IEEE CS Press.
9. Moriarty, T., "The Next Paradigm", Database Programming and Design, (February 1993): 66-69, 1993.
10. Paulk, M. C., B. Curtis, M. B. Chrissis and C. V. Weber, "Capability Maturity Model, Version 1.1", IEEE Software, 10(4): 18-27, 1993.
11. Rittel, H. W. J. and M. M. Webber, "Planning Problems are Wicked Problems", Developments in Design Methodology, Cross (Ed.), John Wiley & Sons, Chichester, 1984.
12. Roman, G.-C., "A Taxonomy of Current Issues in Requrements Engineering", IEEE Computer, April 1985: 14-22, 1985.
13. Willcocks, L., "Evaluating Information Technology Investments: Research Findings and Apprisal", J of Info Systems, 1992(2): 243-268, 1992.
14. Yu, E. and J. Mylopoulos, "From E-R to "A-R" - Modelling Strategic Actor Relationships for Business Process Reengineering", 13th Int. Conf. on the Entity-Relationship Approach, Manchester, U.K., 1994, Loucopoulos (Ed.),