Modeling the Requirements Engineering Process

3rd European-Japanese Seminar on Information Modelling and Knowledge Bases 1

Budapest, Hungary ; 06/1993

Modeling the Requirements Engineering

Process

Colette Rolland

Universite de Paris 1 Pantheon-Sorbonne UFR06

17, Rue de la Sorbonne 75231 Paris Cedex 05 FRANCE

email : rolland@masi.ibp.fr

Abstract : Information System Engineering has made the assumption that an

Information System is supposed to capture some excerpt of the real world history

and hence has concentrated on modeling. This has caused the introduction of a

large variety of models and especially conceptual models by which an information

system can be modelled in high level conceptual terms. By contrast, very little

attention has been paid to the conceptual modeling process which has the purpose

of investigating the requirements of the users community and abstracting from

that the conceptual specification of the information system. This results in a low

level of support provided to requirements engineers. However, the emphasis on

system modeling is shifting to process modeling. The need for process modeling

motivates the process stream of the NATURE Esprit project. The Requirements

Engineering Process model developed within this project is the main topic of this

paper. The particular RE process modeling approach chosen in NATURE

emphasises the notion of decision within the context in which it is taken. The

paper outlines the modeling approach. It details and exemplifies the main

concepts proposed to model the RE process and their relationships. Finally, it

sketches the advantages of the process model by introducing its different usages.

1. Introduction

Information System Engineering has made the assumption that an Information System (IS) is

supposed to capture some excerpt of world history and hence has concentrated on modeling,

that is capturing information about the world.

It is usual to view an IS as "a model of some slice of reality of an organisation" [1] and

even to regard the IS development as a problem of models construction and description. As

shown in figure 1 these models are developed as part of two major development activities

namely the Requirements Engineering and the Design Engineering activities.

USERS

REQUIREMENTS

CONCEPTUAL

SCHEMA

IMPLEMENTED

SYSTEM

SPECIFICATION

REQUIREMENTS ENGINEERING

DESIGN ENGINEERING

REQUIREMENTS

ENGINEERING

PROCESS

DESIGN

PROCESS

CONCEPTUAL

MODELLING

SYSTEM

MODELLING

3rd European-Japanese Seminar on Information Modelling and Knowledge Bases 2

Budapest, Hungary ; 06/1993

Figure 1 : IS development process

The term Requirements Engineering has been introduced by J. Hagelstein [2] and E.

Dubois [3] for this part of the IS development that involves investigating problems and

requirements of the users community and developing a specification of the future system, the

so-called conceptual schema.

The succeding development part, where the specification is used to design and implement a

working system that is specified against the specification, may be called Design Engineering.

This practise provides an answer of sorts to the fundamental question : what does the

information handled by my information system means? It also tends to draw the attention

away from another equally fundamental question : how to define which information has to be

handled by my information system?

The emphasis on product i.e. the system models has hidden the importance of process i.e.

the route to deliver the product.

Our central thesis is that process modeling is as important as system modeling is. For lack

of process modeling, understanding of what is the development process, what happens,

when, why, on what, by whom, is very poor. The process semantics is not well captured,

with the required level of detail, in existing process models.

Consequently the way-of-working prescribed by methodologies are hardly defined. They

give few insights on how developers can/must proceed to progressively transform the initial

requirements into an efficient and reliable computerised system which matches these

requirements. Subsequently CASE tools are not able to provide a true assistance to

developers. They are efficient in recording, retrieving and manipulating system models but