## 4 Proposed Approach
### Relation Definition Markup Language  
In our approach, the relationship from one model to another is defined by exploiting XML technologies. The relationship is formalized through a formal XML structure called RDML, whose syntax is defined using the XML schema. RDML stands for relation definition markup language based on an XML schema that comprises specific elements to define the relationship between models [16]. For each model, an \"RDML\" definition will be available that defines the relationship with other models, the type of relationship, the relationship of each model part, _etc._ We propose the RDML structure in order to express the derived and referenced relationship between the different models in a formal manner. Each model will have a separate RDML file (Figure 2), based on an XML schema. Each RDML file will have an entry for the model, for instance, \(<\)Scenario\(>\), \(<\)DesignModel\(>\), \(<\)TestScenario\(>\). Relationship is represented by the element \(<\)Relationship\(>\) that will contain the \(<\)DerivedRelationship\(>\) and \(<\)ReferencedRelationship\(>\) elements. \(<\)DerivedRelationship\(>\) element will have two subelements referring to the derived models. For example, the requirements.RDML will contain two elements \(<\)DesignModel\(>\) and \(<\)TestModel\(>\) within the \(<\)DerivedRelationship\(>\). Each model part derived will be denoted in the \(<\)DerivedRelationship\(>\), both the source model part and the corresponding derived model part will be grouped here. Figure 3a shows how the derived relationship is defined for each model part to another model part. Figure 2: RDML for each model. Similarly, the <ReferencedRelationship> element will have two subelements referring to the derived models. For example, in the DesignModel, RDML will contain two elements <RequirementsModel> and <TestModel> under the <ReferencedRelationship>. Figure 3b shows how the referenced relationship is defined for each model part to another model part. A detailed view of RDML is given in the later sections. Our approach starts with formulating the requirements, a scenario-based requirements elicitation. A major advantage of scenarios is that they allow for an effective exploration of users' problems and goals [17]. Scenarios encourage designers to envision outcomes before attempting to specify outcomes, thereby helping to make requirements more proactive in system development [18]. Our scenario-based requirement elicitation comprises the following terminologies (see Table 1):  
Typically, a business analyst will identify different scenarios from the informal requirements specification and is formally organized, so that the design analyst can derive the design models easily. The main tasks during this phase are identifying the scenarios, the actors, and the activities involved in the scenario. A formal scenario tree can be considered for organizing the scenario (see Figure 4). The business analyst identifies different usage scenarios defined in the informal requirements and each \begin{table}
\begin{tabular}{c c} \hline \hline
**Terminology** & **Meaning** \\ \hline Scenario & A group of predefined actions and actors for accomplishing a goal \\ Objective & Objective or the main goal of the scenario \\ Actors & Actors are players involved either in the scenario or in an action \\ Precondition & Assumptions or conditions for achieving a particular goal \\ Postcondition & State of the system after executing the scenario \\ Trigger & A trigger is an interaction that starts the scenario. It could be either an action or a scenario \\ Action & A set of operations performed by different actors to achieve a subgoal \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Scenario based requirements—terminology. Figure 3: **(a)** requirements.RDML; **(b)** designmodel.RDML. usage scenario is further analyzed to find the different activities and actors. A scenario can contain any number of actors and actions. Each action is further analyzed to find the actors involved in this action.