Below is an abstract I wrote recently about the interesting article “From conceptual modeling to requirements engineering” by Colette Rolland, my requirements engineering lecturer!!!
Information systems (IS) used to be designed via conceptual modeling. The output of that traditional way of engineering is a system specification which prescripts what the system should do, assuming that its exigencies are fixed and can be assimilated to its functionalities. Nowadays, economic pressure and new technologies emergence within organizations make their requirements continuously changing. Therefore the functionality approach of IS design is no longer suitable and from then on, there is a real need of efficient requirements elicitation, validation and representation through what is called “Requirements Engineering”. What kind of issues does conceptual modeling address? How is it processed? Since designing IS only via this approach doesn’t fit anymore the shaky business requirements, what additional aspects of IS requirements engineering does tackle?
Conceptual modeling aims at building up conceptual data model, based on analysis of the things of significance to an organization. As there was the need to capture as many aspects of real world semantics as possible, several conceptual models have emerged, each one viewing the universe of discourse from a given angle. Therefore, frameworks have been developed to understand and classify them according to their viewpoint. The Three dimensional framework proposes an organization into classes of process, data and behavior oriented models. If the first one addresses system components hierarchy building, the second one in contrast acts like a storehouse or data manager of organizations information contents, whereas the third one deals with interesting events, their causes and impacts. Taken apart, each one of these ways of looking upon IS is deficient as for instance process-oriented models don’t show interactions between components. Consequently a new generation of conceptual models which either integrates the three ways (object oriented models), or consists of loosely connected conceptual models each according to a different perspective emerged. As far as processes are concerned, conceptual models are activity based. In other words, they look upon process as consisting of a set of decomposed activities linearly ordered.
Whereas conceptual modeling scopes the “what is done by the system”, requirements engineering on one hand extends that notion to the “why is the system like this” view, and on the other hand explore the various ways in which the system might be used.
Mainly, requirements either come from informal statements of goals by users (user-defined) or from constraints and facts of real world (domain-imposed). This implies a discernment of two worlds of usage and subject which interact with the environment of the system also called world of specification or system world. In such organization, the user-defined requirements are captured via two kinds of relationship between usage and system world, namely usage fit and intentional relationship. These relationships introduce respectively goal-driven and scenario-based approach of requirements engineering. The former models organization objectives so as to relate them to the functions of the system, while the latter one purpose is to capture, describe, explain and explore all possible scenarios. In order to overcome some of the deficiencies and limitations of goal-driven and scenario-based approaches, models combining goals and scenarios have been developed. The added value is that they help operationalizing goals as well as checking whether scenarios achieve these goals. In addition to the representation relationship between subject and system world (main focus of conceptual modeling), the remaining requirements come from the domain genericity which results also from a relationship between subject and system world. In fact, since many new applications have same requirements as earlier ones, reusing already created and generic domain models can only make the modeling process easier.
Several aspects of requirements engineering process are also addressed in the article. Guidance for instance should be performed while modeling processes, as existing models (activity, product and decision oriented models) lack of completeness in their way of doing requirements engineering. This arises the importance of situatedness, which will help handling deviation that satisfies system’s constraints on one hand, and allowing changes to be made when needed on the other hand. Additionally, contextual and decisional modeling contribute to the requirements engineering process guiding. If the former’s purpose is to build a hierarchy of alternatives and select the best suiting to the situation at hand, the latter focuses on generation of the set of decisions that can be applied to a given product’s situation. Ensuring requirements traceability is also a fundamental aspect in implementing a quality system, as it is supposed to undergo requirements changes. Finally, all these approaches and methods processing can be automated in computer based environment. There’s been a broad range of Computer-Aided Software Engineering (CASE) tools, which help providing edition and maintenance for graphical specification, as well as documentation and verification; unfortunately they are lacking in adaptability to other methods and in providing process support. These limitations are addressed by the repository based approach.
Requirements engineering takes up the challenges of embedding system in their larger usage context and change management by taking in account almost all aspects of information systems. This efficiency is reached because of its ability to keep track of connections between goals, activities and requirements at any level of abstraction.