Naveen Prakash

A Multi-Model View of Process Modelling

Situatedness of development processes is a key issue in both the software engineering and the method engineering communities, as there is a strong felt need for process prescriptions to be adapted to the situation at hand. The assumption of the process modelling approach presented in this paper is that process prescriptions should be selected according to the actual situation at hand, i.e. dynamically in the course of the process. The paper focuses on a multi-model view of process modelling which supports this dynamicity. The approach builds on the notion of a labelled graph of intentions and strategies called amap as well as its associated guidelines. The map is a navigational structure which supports the dynamic selection of the intention to be achieved next and the appropriate strategy to achieve it, whereas guidelines help in the operationalisation of the selected intention. The paper presents the map and guidelines and exemplifies the approach using the CREWS-L’Ecritoire method for requirements engineering.

A proposal for context-specific method engineering

The new emerging method engineering discipline acknowledges the need for the construction of methods tuned to specific situations of development projects. This raises at least three problems (1) the representation of method fragments in a method base, (2) the formalization of the notion of project situation and, (3) the retrieval of relevant fragments for the project situation at hand. Our contribution to the first two of these problems lies in the definition of a contextual approach which enables us to represent both method knowledge (i.e. the method base contents) and method meta-knowledge (i.e. knowledge about the potential use of method fragments) as pairs of the form . This emphasizes both engineering decisions and method engineering decisions, their rationale and situations of applicability. We contribute to the third problem by proposing a tight coupling of method knowledge and method meta-knowledge in the method base. This enables the formal description of the context of use of every method fragment and shall facilitate the retrieval of relevant fragments according to the situation of the project under development. The paper presents and exemplifies the method knowledge and method meta-knowledge levels.

Matching ERP system functionality to customer requirements

Although procuring enterprise resource planning systems from commercial suppliers is becoming increasingly popular in our industry, fitting those systems to customer requirements remains problematic. The authors propose an approach for matching ERP system functionality to customer requirements. The assumption made is that the ERP system postulates a set of requirements that are worth eliciting from the ERP documentation as abstractions of the ERP system functionality. Then, the requirements engineering process is a process that matches the ERP set of requirements against organisational requirements. Those requirements that match, perhaps after adaptation, identify the ERP system features and their adaptations, that must be included in the ERP installation. To facilitate the matching process, the ERP requirements and the organisational requirements are both expressed using the same representation system, that of a map. The paper presents the map representation system and the matching process. The process is illustrated by considering the Treasury module of SAP and its installation in the financial management of a cultural exchanges unit.

From conceptual modelling to requirements engineering

Conceptual modelling is situated in the broader view of information systems requirements engineering. Requirements Engineering (RE) explores the objectives of different stakeholders and the activities carried out by them to meet these objectives in order to derive purposeful system requirements and therefore lead to better quality systems, i.e., systems that meet the requirements of their users. Thus RE product models use concepts for modelling these instead of concepts like data, process, events, etc., used in conceptual models. Since the former are more stable than the latter, requirements engineering manages change better. The paper gives the rationale for extending traditional conceptual models and introduces some RE product models. Furthermore, in contrast to conceptual modelling, requirements engineering lays great stress on the engineering process employed. The paper introduces some RE process models and considers their effect on tool support.

Engineering Methods from Method Requirements Specifications

By analogy with a Software Requirements Specification (SRS), it is argued that a Method Requirements Specification (MRS) should be introduced in method engineering. It shares with the SRS the property of implementation-independence. This means that an MRS must be an instance of an abstract metamodel and not of a technical metamodel like GOPRR (Graph, Object, Property, Relationship, and Role). The MRS is then translated to be an instantiation of a technical metamodel. We develop a representation system for an MRS and describe an automated process for instantiating a technical metamodel with an MRS. This instantiation is used to produce the actual method which is then given to a metaCASE to produce a CASE tool. Thus, we propose a method engineering approach rooted in the MRS.

Towards a formal definition of methods

The absence of a formal specification of methods permits application engineers to interpret method concepts in any way they want. Further, different CASE tool designers can implement the same method concepts in different ways. The approach to formal method specification described here is in three levels: the generic level, the method independent level, and the method level. The generic level provides a model of a method which can be instantiated to yield a method-independent view of methods. This view can, in turn, be instantiated to yield the formal method of interest. The attempt is to represent methods independently of any underlying way-of-working or paradigm, remove the process/product dichtomy by tight coupling of the process and product aspects of methods, and permit extensibility of methods. The formal specification can be used as a basis for building CASE tools, as an output to be produced by a CAME tool, and for defining development processes.

Reusable Process Chunks

Reusability of project components, either at the code level or at the conceptual specification level, is considered a fundamental aspect in application development. More recently it as been argued that project histories can support reuse of design decisions. We propose a solution based on so-called process chunks which are generic process frames to resolve the issue stated by a generic requirements engineering (RE) situation. Chunks are classified into micro-chunks and macro-chunks. The latter support the decision making process whereas the former help in implementing the decision. The RE activity based on these chunks consists of (1) recognising a situation as belonging to the class of situations treated by a chunk and (2) the instanciation of the process frame. The benefit expected from this approach is threefold: (1) to speed up the requirements engineering process; (2) to improve the quality of the conceptual specifications; and (3) to offer an extensible way for capturing generic RE process knowledge.

A Process View of Methodologies

It is argued that a methodology provides primitives using which the developer can construct the desired process. From the point of view of a process, a methodology is a passive device which only specifies a set of steps and step transition constraints. A step of a methodology can be modelled in terms of the triplet, . A methodology is a collection of such triplets. The decisions of triplets articulate different kinds of methodology primitives like the creation, deletion, and modification of methodology-specific situations. Under this model, the development process becomes a decision making activity rooted in a methodology. The validation constraints of a methodology constrain this activity by regulating the transition from one decision to another.

Decisions and Decision Requirements for Data Warehouse Systems

We develop the notion of a decision requirement as the pair where ‘information’ is that required by the decision maker to assess if the ‘decision’ is to be taken or not. It is shown that there are two kinds of decisions, imperative and managerial. The former are decisions about which transactional service out of a choice of transactional services is to be provided. Managerial decisions determine what infrastructure out of a set of possibilities is to be put in place. It is shown that a decision is the reason why a functionality of an information system is invoked. The notion of decision requirement is clarified through a decisional requirement meta model. This is supported by a decision and information meta model. The example of a health scheme is taken to illustrate the different kinds of decisions and decision requirements.

Towards Better Fitting Data Warehouse Systems

In order to produce data warehouse systems that reflect organizational decisional needs, development should be rooted in the goals and decisions of organizations. The goal-decision-information model and associated information elicitation techniques for decision making are presented. There are four main techniques, Ends analysis, Means analysis, Critical Success Factor analysis, and Outcome Feedback analysis. Using these, the requirements engineer is able to elicit the required information as well as the sub decisions of a given decision. The elicitation techniques are then applied to these sub decisions. The elicitation process ends when all decisions/sub decisions have been thus processed. A comparison of this approach is made with data base driven and ER driven development approaches to data warehouse development to show that it produces systems that fit well with decisional requirements.