Towards Engineering Purposeful Systems: A Requirements Engineering Perspective

Abstract

A number of studies [1][2][3] show that systems fail due to an inadequate or insufficient understanding of the requirements they seek to address. Further, the amount of effort needed to fix these systems has been found to be very high [4]. To correct this situation, it is necessary to address the issue of requirements elicitation, validation, and specification in a relatively more focused manner. The expectation is that as a result of this, more acceptable systems will be developed in the future. The field of requirements engineering has emerged to meet this expectation. Requirements Engineering extends the ‘what is done by the system’ approach with the ‘why is the system like this’ view. This ‘why’ question is answered in terms of organizational objectives and their impact on information systems supporting the organization. In other words, information systems are seen as fulfilling a certain purpose in an organization and requirements engineering helps in the conceptualization of these purposeful systems.

The talk will focus on the above issue of conceptualising purposeful systems.

It will argue that the goal concept is central to resolving the issue of conceptualising purposeful systems and then, elaborate on goal modeling and reasoning with goals in order to demonstrate the various roles of goals in conceptualizing purposeful systems: Goal modeling proved to be an effective way to elicit requirements [7][8][9][10][11][12][13]. The assumption of goal-based requirements elicitation is that the rationale for developing a system is found outside the system itself, in the enterprise [14] in which the system shall function. In this movement from the ‘whats’ to the ‘whys’, it becomes mandatory to consider multiple view points of the various stakeholders, to explore alternative design choices and reason about them so as to make conceptual decisions on the basis of rationale arguments in favour and against the different alternatives. Alternative goal refinement proved helpful in the systematic exploration of system choices [8][14][15][16]. Recording these shall help to deal with changing requirements. Goals provide a means to ensure requirements pre-traceability [5][17][18]. They establish a conceptual link between the system and its environment, thus facilitating the propagation of organizational changes into the system functionality. This link provides the rationale for the system functionality [6][8][19][20][21] and facilitates the S.S. Bhowmick, J. Küng, and R. Wagner (Eds.): DEXA 2008, LNCS 5181, pp. 1-4, 2008. © Springer-Verlag Berlin Heidelberg 2008 2 C. Rolland explanation and justification of it to the stakeholders. Stakeholders provide useful and realistic viewpoints about the system To-Be expressed as goals. Negotiation techniques have been developed to help choosing the prevalent one [22][23]. Prioritization techniques aim at providing means to compare the different viewpoints on the basis of costs and value [24][25]. Multiple viewpoints are inherently associated to conflicts [26] and goals have been recognized to help in the detection of conflicts and their resolution [27][28][29][30].

In the rest of this talk, we will consider new challenges raised by emerging conditions of system development leading to variability in functionality modelling and customisation in the engineering process. Variability is imposed by the multi-purpose nature of information systems of today. We will use a particular goal model called goal/strategy map to illustrate how a goal model can make variability explicit and support goal-based reasoning to help in selecting the right variant for the project at hand. Our position is that variability implies a move from systems with a mono-facetted purpose to those with a multi-facetted purpose. Whereas the former concentrates on goal discovery, the multi-facetted nature of a purpose extends it to consider the many different ways of goal achievement. For example, for the goal Purchase Material, earlier it would be enough to know that an organization achieves this goal by forecasting material need. Thus, Purchase material was mono-facetted: it had exactly one strategy for its achievement. However, in the new context, it is necessary to introduce other strategies as well, say the Reorder Point strategy for purchasing material. Purchase Material now is multi-facetted; it has many strategies for goal achievement. These two strategies, among others, are made available, for example, in the SAP Materials Management module [31].

The foregoing points to the need to balance goal-orientation with the introduction of strategies for goal achievement. This is the essence of goal/strategy maps. A goal/strategy map, or map for short, is a graph, with nodes as intentions and strategies as edges. An edge entering a node identifies a strategy that can be used for achieving the intention of the node. The map therefore, shows which intentions can be achieved by which strategies once a preceding intention has been achieved. Evidently, the map is capable of expressing goals and their achievement in a declarative manner. The talk will introduce the concept of a map [32], illustrate it with an ERP system example and discuss how the model meets the aforementioned challenges.