SANNI Lookman

It’s well known that scenarios, description of real world facts and actions, are very powerful in so far as they get stakeholders to immerse themselves and understand more a given process. Performing requirements engineering then without “inviting scenarios to the party” will be very arduous or almost beyond the bounds of feasibility. The main issue for scenario based approaches will then concern the way scenarios are designed and organized. The “scenario classification framework” is an attempt to solve that issue and to make scenarios more effective in the requirements engineering process. How does it work?

The framework proposes a classification of scenarios along four different views: form, contents, purpose and lifecycle. Each view is sliced in dimensions called facets, to which a list of attributes is attached. Thus, characterizing a given scenario foreshadows giving a value to each attribute in each facet, for each one of the framework’s views.

The form view emphasizes the way the scenario is expressed. This expression can be seen along two dimensions which are the description facet and the presentation facet. If the former one is measured by the level of formality and the channel used, respectively notation and medium attributes, the latter evaluates the liveliness of the scenario through animation and interactivity attributes.

On the contents axis, the framework enlightens scenarios along four different dimensions. The abstraction facet, expressing the concreteness of a scenario, is evaluated by Boolean values (instance, type, mixed) which indicate whether a scenario describes a specific experience or situation, a generic one, or both. Then, there is the context facet, which expresses the amount of information embedded in a scenario, relating to the context of the To Be system. This is performed by determining whether properties like the internal behavior of the system, interactions in terms or role playing with its environment, the organizational context of the system including the organization’s structure and the organizational environment are included in the relevant scenario or not. Another angle of scenario analysis along the contents axis is about the argumentation knowledge enunciated in the relevant scenario. There again, the duty is to check if the scenario includes descriptions of alternative positions, arguments that go along with a given position, conflicts or issues that may arise and final decisions or not. According to the kind of information captured by the scenario, a last clarification could be made: there lays the concern of the coverage facet. A scenario may capture functional aspects (structure, function and behavior) of the system as much as non functional ones (security, performance, time). Moreover, intentional aspects of systems like goals, problems and objectives are taken in account in that facet.

Scenarios can play different role according to intended ambition or expectation. The purpose view identifies those roles during the scenario classification process. Thus, scenarios may be descriptive regarding a given process, exploratory by investigating different ways to meet a requirement or explanatory by elucidating a pronounced issue.

The lifecycle view, the last one, investigates in one hand on scenario’s progression and lifetime, and in another hand on operations or transformation they might overcome. Thus, this view exposes two facets: The lifespan facet which will help separating transient scenarios from persistent ones and the operation facet for a classification according to the type of operation the scenario carry out. It could either be a capture operation through scenario generation from scratch or by reuse, or a refinement or restructuration operation. A scenario may also serve for assembly purpose and will then be classified in the integration operations category, or extend knowledge in an existing scenario and then be tagged as expansion operation type. Finally when a scenario reaches the end of its lifetime, deletion operations appear to be ineluctable.

Unfortunately, like many other approaches, this classification doesn’t tackle the process aspect of scenarios. Nevertheless, there have been some approaches to the process of scenario generation. These may include the use of business actors and responsibilities to discover use cases and then scenarios, or the use of a predefined matching between scenarios templates and types of situations.

Finally, from a practical point of view, the framework has proven usefulness after conducting polls on scenario characterization in industrial projects, although there’s still a gap between what’s stated in literature by research, and used tools and methodologies in experience.

An abstract by Lookman SANNI

Author: Colette ROLLAND

It has been known through various surveys that Information Systems (IS) projects imperfection and failures are mainly due to a misapprehension of such systems requirements. An appropriate way of doing requirements engineering (RE) should dig different stakeholders’ objectives and activities carried out by them to reach those goals. Thus, IS will no longer be only technically good but also purposeful and of quality. This view of RE process which focuses on goal centric activities is the “goal-driven requirements engineering”.

This focus on goals can be explained by the ability of goal modeling to ensure efficient requirements elicitation, completeness and pre-traceability. It also helps in terms of exploration of systems choices, detection and resolution of conflicts that may arise from multiple viewpoints provided by stakeholders. All these can be performed by answering to the following set of inquiries: Why is a determined functionality or constraint needed or not? Are the elicited requirements enough to achieve the goal they promote? Where does each requirement originate from and how to track changes it undergoes? What different ways of satisfying a given goal exit?

In order to make the goal-driven RE more efficient, some key issues have been raised by different approaches while trying to support the process. For instance, to automate goal analysis, efforts have been undertaken in terms of formalizing or semi-formalizing goals formulation. Propositions have also been made to match goals with scenario in order to make them more concrete, more illustrative with respect to undertaken actions by systems’ agents. Additionally, in pursuance of supporting a better understanding of goals, the notions of relationship and levels of abstraction have been introduced. Thus, goals can be distilled in either more or alternative sub-goals; they can also be influencing one another or straightforwardly be conflicting. Obviously, top level goals also known as business objectives linking to low level ones or systems requirements should then arise. “L’ECRITOIRE”[1], a goal-based approach to RE addresses all these issues.

An abstract by Lookman SANNI

Author: Colette ROLLAND

[1]: http://crinfo.univ-paris1.fr/CREWS/Process/chunk19_index.html

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.