Use case modelling is a widely accepted requirements specification method in practice and we got positive feedback of our proposed RUCM (Restricted Use Case Modelling) approach from our industrial partners; therefore, inspecting defects in RUCM use case models in a cost-effective manner is an important challenge. However, it does not exist a systematic mutation analysis approach for evaluating inspection techniques for use case models. Being aware of this, we followed a systematic method to derive mutation operators for RUCM, which are also applicable for the common use case models. More specifically, we first proposed a defect taxonomy defining 94 defect types, based on the IEEE Std. 830-1998 standard. Second, we systematically applied the basic guide words of the standardized Hazard and Operability Study (HAZOP) methodology to define 191 mutation operators. Last, we defined a set of guidelines for devising defect seeding strategies. The proposed methodology was evaluated by a real world case study and six case studies from the literature. Results show that all the derived mutation operators for RUCM models are feasible to apply and the defect taxonomy is the most comprehensive one to compare with the literature.
The overview of the RUCM mutation analysis methodology is presented as a conceptual model in the following figure. The methodology is defined to evaluate RUCM-based inspection methods. As for mutation testing, the effectiveness of such an inspection method is measured and evaluated with mutation scores. Taking a RUCM model as the input, a RUCM mutation operator mutates the RUCM model and generates a corresponding RUCM mutant, which contains a defect. The defect seeding strategy is used to guide a mutation seeding process to generate mutants.
In the RUCM mutation analysis methodology, defects are classified by the RUCM defect taxonomy, which is systematically derived by following the IEEE Std. 830-1998 standard. Each RUCM mutation operator is derived by following HAZOP, which is a systematic process for analyzing any deviation of a system design, e.g., reflected in requirements and design models from the design intent. More specifically, based on the Extended Backus-Naur Form of UCMeta, we systematically map each RUCM element to each basic HAZOP guide word defined in IEC 61882: 2001. We therefore define RUCM mutation operators based on the RUCM defect taxonomy. Each RUCM mutation operator can be derived if and only if the consequence of the corresponding deviation of the RUCM model can be interpreted as a particular defect defined in the RUCM defect taxonomy.
|C1||Incorrectness||Such defects reflect misunderstanding of user’s intention and can be identified by a user and/or by comparing RUCM use case specifications with other documents (e.g., contract documents).|
|C2||Incompleteness||In context of RUCM models, any omission of RUCM model elements (e.g., Action Step) leads to the incompleteness of a RUCM model.|
|C3||Inconsistency||For RUCM, we focus on the consistency between the use case diagram and the use case specifications of a RUCM model, and the internal consistency of a use case specification, e.g., two steps or flows of events conflict to each other.|
|C4||Ambiguity||To eliminate such defects, it requires that requirements engineers use consistent terminologies when specifying RUCM models. Moreover, RUCM defines 26 restriction rules, which help to reduce ambiguities in use case models to certain extent.|
|C5||Incomprehensibility||In case of RUCM, it addresses that each specified requirement should be comprehensible to different stakeholders such as requirements engineers and developers.|
|C6||Intestability||When deriving the RUCM defect taxonomy, we put our focus on Pre-conditions and Post-conditions of RUCM specifications from the perspective of test engineers.|
|C7||Unmodifiability||In the context of RUCM, a piece of shared behavior should be specified as a use case and reused (via Include and Extend), rather than be specified in different places of the use case model.|
|C8||Infeasibility||It is also used to characterize unverifiable requirements from the perspective of system developers. More specifically, this category focuses more on requirements that cannot be implemented from the viewpoint of system developers.|
|C9||Over-Specification||It states that the RUCM use case specification should not contain unnecessary information.|
As defined in the IEC 61882 standard, the basic guide words of HAZOP include NO, MORE, LESS, AS WELL AS, PART OF, REVERSE, and OTHER THAN. We apply the seven HAZOP guide words and identify RUCM elements, to which the guide words are applicable. In our mechanism, we map each HAZOP guide word to each RUCM model element and we derive the RUCM mutation operators by analyzing the corresponding consequences of applying them, as shown in the following figure.