A Comparative Study of the Decisional Needs Engineering Approaches

Requirements Engineering (RE) is an important phase in a project of systems development. It helps designanalysts to design and to model the expression of the end-user needs, and their expectations vis-a-vis their future system. This engineering is studying two major issues that are: What should the system do in order to have a complete needs specification, and reason on the why: "Why do we need to build this system? ", without looking for how to build it. The vast majority of needs engineering approaches are based on two concepts: scenario or goal; there are generally three types of approaches: ScenarioOriented Approaches, Goal-Oriented Approaches and approaches generated by the couple: goals and scenarios at the same time. In the remainder of this paper, we present a comparative study of the three types of the RE approaches, then models of needs representation, and finally we conclude with the conclusions. Keywords—Decisional information systems; decisional needs engineering; needs engineering approaches; goal; scenario; model of needs representation


I. INTRODUCTION
Today, decisional information systems have become indispensable to help in making the decision.According to earlier studies, about 60% of the errors in the projects of system development come up during the Requirements Engineering (RE) phase [1], a relatively young field of research: until the end of the 80s was still referred to as "analysis" to qualify the upstream phase of system design; the analysis phase is essential to produce the specifications of the system to be developed.
Needs Engineering (NE) was introduced by J. Hagelstein [2] and E. Dubois [3] to designate the part of the development of information systems that concerns the investigation of users' problems and needs, and the development of the future system specifications.It helps to express what the system has to do, but not how it should do it.Moreover, in order to have a complete specification of needs, we must, also, reason on the why: "Why do we have to build the future system?".
In classical information systems, the RE was presented by Rolland and al. [4] as a process that derives from requirements through the exploration of the objectives of the actors and the activities to achieve them, and in the decisional domain, we talk about the Decisional Needs Engineering (DNE) which is defined according to Nuseibeh and al. [5] as a discipline that takes care of : elicitation, analysis, specification, validation and management of needs and constraints for the construction of a system phases.
Several approaches have been proposed to analyze the decision-makers' needs, this approaches are oriented by a process formed by a set of phases which are broken down into a set of steps (Fig. 1), this process is accompanied by models of representation of the needs during the analysis phase.
In the formalization of decision-making needs (DN), the vast majority of DNE approaches are based on the following concepts: goal or scenario.These two concepts are the source of three types of approaches: Scenario-Oriented Approaches, Goal-Oriented Approaches and approaches generated by the couple: goals and scenarios at the same time.
The remainder of this paper is a DNE approaches comparative study, using the following structure: Section 2 presents a comparative study of the approaches to the DN analysis.In Section 3, we discuss a state of the art of the decisional needs representation models.This work will be completed by conclusions in Section 4.

II. NEEDS ENGINEERING APPROACHES
The success of a NE project relies heavily on the success of the NE process, which typically consists of the following phases:  Elicitation of the needs: A phase that helps to understand the organizational situation and the expression of needs [6], [7], [8], [9], [10].
 Specification: Defines the relation between the business objective and the functional and non-functional components of the system [11], [12], [4], [13].
 Negotiation: The phase in which we define the deliberation context of the whole process [14], [15].
 Validation: phase of validation of the system specifications with regard to the needs expressed / expected by the users [16], [17].
To ensure the quality of this process, it is essential to have appropriate techniques, approaches and tools; the choice of these three elements influences the quality of the resulting needs.
In the next section, we first look at the Goal-Oriented Approaches.Next, we cite the Scenario-Oriented Approaches.Finally, we review the approaches that combine goals and scenarios.

A. The Goal-Oriented Approaches
According to Ben Achour [18], a goal is defined as "Something that someone hopes to achieve in the future".We find in other works that the goal can be defined as "an objective to be achieved in the future system" [19].In other words, a goal is an image of an intention, which is subsequently operated on by a set of objectives that are planned to be realized in a precise duration, without specifying how they can be reached, it is associated with a result that we want to have and materialize by a set of object states.Fig. 2. Structure of a Goal [Prat, 1999].
1) Structure of a goal: In general, the goal is expressed in natural language, and formalized according to a structure composed of a verb accompanied by a set of parameters, each of them has a semantic function and provides in their instances answers to the different questions that are Around this verb: who, what, when, how much, how etc.This structure is proposed at the beginning in the works of Prat [20] (Fig. 2) which in turn relies on the grammar of the cases of Fillmore [21] and on its extensions.This goal structure is subsequently improved in other works [22], [23].
In this structure, we have mandatory components to define: the verb and the target, but the other parameters are optional:  Target: The target is a complement to the action concerning the entities affected by the goal.There are two types of targets: the object and the result.The object exists before achieving the goal and may, eventually, be modified or deleted by the goal; whereas the result is the entity resulting from the realization of the goal designated by the action.
 Quantity: it measures the quantity of the object that should be produced.
 Quality: This is a property that must be achieved or preserved.
 Direction: Contains two types of directions named: source and destination, their role is to identify, respectively, the initial and final locations of the object:  Source: Represents the starting point of the goal (source of information or physical location).
 Destination: Represents the ending point of the goal (to whom or to what).
 Beneficiary: Expresses the person or group for whom the goal should be obtained.
 Way: It consists of two parameters:  The manner: Specifies how the goal can be achieved.
 The means: Specifies by what means (tool) can the goal be achieved.
 Locality: It positions the goal with regard to space.
 Time: It positions the goal with respect to time.
Reference: it is the entity according to which an action, of the fact table, is performed or a state is achieved or maintained.
The advantage of using natural language is to simplify and to facilitate the manipulation of these intentions, which are represented in the form of a linguistic formulation, and their understanding by the different actors / participants in the Decisional Information Systems (DIS) and more particularly in the process of the RE.In Elgoli's work [22], she was inspired by this linguistic formulation and she proposed a new version in the form of a meta-model (Fig. 3) expressing the semantics and facilitating automatic exploitation while remaining understandable by the actors.www.ijacsa.thesai.orgBy following the same approach, Sabri [23] in her work extended this work of Elgoli [22] by trying to make appear the facts" parameters and the dimensions" parameters at the moment of the semantic representation of the informational goal (Fig. 4).To facilitate the way for the operational actors of the DIS to develop the decision data dictionary on which we will base to build the multidimensional star schema.
2) Levels of goal abstraction: In the decisional field, a strategic goal (level 1) does not offer an operational view and must be decomposed into tactical goals, this level (Level 2) does not yet give us the possibility to deduct our facts and our dimensions; thus we move on to the third level (level 3), which is operational, by dividing each tactical goal into a set of informational goals (Fig. 5).The treatment and decomposition of a goal into sub-goals has been studied in several works that we decompose according to three categories: The first category: We use AND / OR [11], [24], [25], [26] and [27] reduction graphs which have inspired this method of artificial intelligence [28].www.ijacsa.thesai.orgA goal 'A' can be decomposed into several sub-goals: A1, ... An.
If an AND relation is associated with goals {A1 AND A2}, {A1 AND A3} ... implies that all of these goals must be achieved to achieve the desired result of goal A, and that one cannot replace the other.
In this case the satisfaction of one goal (A1 for example) ensures the satisfaction of the other (A2).
The second category: several approaches have extended the method used in the first category, with some variations from one approach to another; we find those that have adopted a new hierarchical organization of goals based on the relations AND, OR and REFINED BY [29], this last link "Refined by" is deduced when the two goals share a syntactic part of the goal and are complementary, but do not aim at the same result.
In other works [23], another type of "complemented" link is used to represent a particular case of the OR relation; this link is used to express a relation between two goals that share a syntactic part and the two syntaxes are complementary and aim to achieve the same result.
The third category: It is a contribution that we have proposed in our work [30].To facilitate its treatment, each goal is decomposed into a result and a canal; the result is decomposed into a set of actions and the canal is decomposed into a set of means and a set of manners.
The analyst-designer can represent the links between the goals of the same type by the relations" matrices between the {Strategic / Tactical / Informational} goals.The link is a combination of {R: same Result, ⌐R: Different result} And {C: same Canal, ⌐C: Different canal}, after this matrix it is treated with a set of rules that have already been developed according to the possible cases [30].

B. The Scenario-Oriented Approaches
Scenarios have been used to capture user needs [31] [32].According to Rolland [18] a scenario is defined as "a possible behavior limited to a set of interactions between several agents".It allows achieving a given goal by interacting two agents.It is also a way of describing the different behaviors and the different perspectives that the actors wish to have or expect in relation to the use of their system.Hence, each scenario is characterized by its state, its result and a set of conditions likely to influence the behavior of the agents.
According to Rolland [33], a scenario can be presented as the "order of actions or events for a specific case of a certain generic task that a system must perform".Otherwise, it represents, in a comprehensible way, a sequence of events and activities (which are collected according to the needs of the various actors involved in the design of the system) Connected in a conditioned manner in order to achieve a result or realize a functionality.
1) Language structure of a scenario: In principle, natural language is used to represent the set of actions that constitute the scenario; these actions are chained, between an initial state and a final state, according to conditions.
Several structures are proposed to model the scenarios; in the work of Tawbi [34], he proposed a new linguistic model of a scenario (Fig. 7), based on that defined by Ben Achour [18].
In this model, Tawbi considers two states for the scenario: Initial and Final and distinguishes two types of scenarios: normal scenarios and exceptional scenarios.A normal scenario achieves the desired result of the goal, while an exceptional scenario ends with the non-satisfaction of the goal.The actions are of two types: atomic and flux.An atomic action is an interaction between two agents affecting an object.An agent and an object can appear in several different interactions.A flow of actions is used to define the scheduling between interactions in a scenario.It is composed of several actions.Action"s flows are classified into four types: sequence, competition, repetition or constraint.In Rolland's work [33], we define the scenario with four axes: its form, content, purpose and its cycle (Fig. 8).Fig. 7. Scenarios" Aspects [Rolland, 1998].www.ijacsa.thesai.orgIn the table (Table I) we have established a study of some description forms of the scenarios used in several methods.
For the description of a scenario, mainly three notations are found: informal (using natural language that is sometimes more appropriate for users), semi-formal [35] (based on structured notations such as tables [32] or The scripts [36]) or formal (scenarios are represented with languages based on regular grammars [37] or state diagrams [38], UML forms (scenarios are represented by sequence diagrams or collaboration diagrams), as well as other forms the automaton [39,40], statecharts [41,37], Formalisms derived from the Petri nets [42,43,44], etc.).This description of the scenarios is made, on the one hand, to simulate the different functionalities that the future system must have, and on the other hand, to link the reactions of the users who will trigger them.

b) Content:
The content refers to the type of information and knowledge that the scenarios will contain (Table II).
The content also depends on how the scenarios describe the system.There are abstract scenarios that refer to abstract objects: Customer, Provider.And concrete scenarios that refer to concrete objects that are particular instances of the object: Faculty of Science and Technologies (FST), University Cady Ayyad (UCA).c) Goal: The goal of scenarios is usually one of three things (Fig. 9):  Description: These are scenarios that describe the behavioral aspects of the system by representing the views of external users to the system [32], [46].
 Exploration: this type of scenarios is used to choose the best solution among many that is explored and evaluated [47], [48].
 Explanation: This is a type of a scenario that is used after exploratory scenarios in order to defend and explain the details of the chosen solution [49].

d) Scenario life cycle:
Considering the scenarios being objects describing the system, we have two types:  Persistent scenarios: According to Jacobson [31] and Potts [32], scenarios accompany the project from the needs" analysis to the production of the documentation.
 Temporary scenarios: In contrast to the first type, these scenarios intervene just in certain stages of the development cycle of a project (e.g.scenarios for the acquisition of needs, or for their validation [50]).
In the scenarios, we distinguish between a normal scenario and an exceptional scenario (a scenario that describes what happens if the normal scenario does not work) [8], but the limit always remains in describing what will not happen in exceptional cases and is not a real-life scenario since it does not help in achieving the goal.In our work [51], we proposed a new formalization of the associating for each goal two scenarios: normal(NS) and alternate(AS) which form both a set of steps.Each steep in the PS can have its alternation in the AS, so that we are on to have a mechanism to reach our goal before we begin our decision-making project by trying to avoid all problems of this kind.
2) Goal-Scenario directed approaches: The objective of these approaches is to discover the needs of the system by coupling each discovered goal with a scenario that illustrates the behavior of the system to achieve the goal.
A goal is "intentional" while a scenario is "operational".Therefore, is possible to combine the two concepts.Each goal can be attached to one and only one scenario (which operationalizes it), and each scenario describes the steps and constraints of achievement (describes a possible behavior of the system to achieve the goal) of one and only one goal.The couple <goal, scenario> is named a fragment of need [33] and explains a part of the specification of the system to be realized.The fragments of needs can be classified at various levels of abstraction: the contextual level to which the services rendered by the system in the context of the organization are identified, the level of interaction in which the behavior of the system is described and the interactions which must carry out with its users and the physical level in which the behaviors of the internal objects of the system are described.This approach was evaluated through four different experiments: a) Workshops [33] b) Case study [29]: Four characteristics that contribute to the satisfaction of the discovery of the needs of the system: 1) The notion of fragment of need is defined as the couple <goal, scenario>.2) The hierarchical organization of needs is based on the relations AND, OR and refined by, between fragments of needs.3) The elicitation process is based on a bidirectional movement between a goal and a scenario.For a given goal, a scenario is written to illustrate its realization.4) A methodological help, in the form of semi-automatic rules, is implemented by the software The Ecritoire.
The results obtained by these experiments validated the applicability and effectiveness of this approach.The ECRITOIRE approach [53] is the software application of the CREWS approach [34].It interprets and transforms a scenario to ensure its consistency, completeness and conformity to the goal.It proposes: 1) methodological guidelines for writing textual scenarios (written in natural language) and software tools to check their correction; 2) scenario analysis rules helping to discover variants; Exceptions and complements of a given scenario, and (3) a formalization of the process while guiding its development.

III. MODELS OF THE NEEDS" REPRESENTATION
Each step of the DNE approaches corresponds to the establishment of a model, which facilitates the capitalization and archiving of the DNE process.The models of representation of the requirements are classified into five categories of models (Table III): www.ijacsa.thesai.org Goal models: Numerous studies are based on the "i *" goals' model [3], which is a modeling language; it is defined with the dependencies between various types of agents, in order to model situations where one of the agents depends on another to achieve a certain goal, or to carry out a task.Other works [4] propose a method for analyzing the decision-makers' needs using a goal model to represent the intentions and the implemented strategies to achieve a goal.

 Table models:
The collection of the decision-makers' needs in the table models is made via n-dimensional tables containing the concepts of : facts, dimensions, measurements, parameters, hierarchies and attributes.
To collect the needs, we ask decision-makers to express them in a syntactic model [5].Afterwards, the analystdesigner extracts and treats the multidimensional concepts and generates multidimensional schemas.
 Models based on relational schemas: The formalization of decisional needs is made by several types of relational schemas, such as the Entity / Association model [6].The authors use an ideal schema for the formalization, from which we define a candidate schema for the treatment phase; it is on the basis of this schema that our conceptual schema is generated.
 Query models: Queries, in this kind of approaches, are the basis of the modeling of decisional needs.Initially, the expressed requirements are captured in natural language from which the analyst-designer formalizes these needs in the form of queries.The next phase of needs' treatment, in which we extract fact indicators (fact table and its measurements) and dimension indicators (dimension tables and their attributes) is done with a matrix of needs [7].After this step, we define the first star schema extracted using the needs and we confront it with a second star schema which will be made using the data sources.
 Mixed models: In this category, two or more types of models are combined in order to collect, formalize and treat needs.For example, needs can be collected in the form of queries and subsequently be formulated into goals and into decisions.The authors use an owner goals' model GDI (Goal / Decision / Information) to represent them [8].In other works [9] to treat DNs, a model of analytical requirements' specification is used (queries / tables) to extract fact tables and dimension tables.

IV. CONCLUSION
In this paper, we have made a comparative study of engineering needs approaches and classified them into three categories: goal-directed approaches, scenario-based approaches, and approaches mixed goals and scenarios.
We also studied the structure of a goal and a scenario, the formalization of a study and the study of models of needs" representation.These concepts are the starting point for defining and organizing the needs of designers of models, which allows us to establish an intentional level of abstraction to facilitate the reuse of the modeling process and tools.
Goal-directed approaches, generally provide goal modeling by decomposition into the form of trees and/or.Scenariodriven approaches derive conceptual models from scenarios and are used to reason about design choices.Finally, in mixed approaches, the scenarios are used to describe different possible ways of achieving the same goal, so the goals are operationalized by the scenarios.
In the future work we will define a new modelization of decisional need, based on the goal levels of abstraction, we will define a new more relevant axes of goals treatment with new treatment rules and a new formalization of the informational goals to facilitate the extraction of indicators on fact tables (with its measurements) and indicators on their dimension tables (with their attributes) associated.

Fig. 8 .
Fig. 8. Structure of a Scenario [Tawbi, 2001].a) Form: The form of a scenario is very important during the acquisition, specification and representation of needs and goals in order to validate or evaluate them.

TABLE III .
COMPARATIVE STUDY OF THE MODELS OF THE NEEDS" REPRESENTATION.