As for many other comp lex systems, designing an aircraft is not an easy task; be it the new version of an existing model or creating fro m the scratch. Generally, the stage following the collect of customer needs is the requirements definit ion, starting by elicitation and analysis. This process continues with the cascading of requirements that often is a mirror o f the product breakdown structure. Then, for each system level, requirements set are used to define the system elements. The other requirements are allocated to sub-system at the lower levels and the process continuing till the development of co mponents. The market driven incremental p roduct development and delivery (release) is becoming increasingly co mmonplace in software industry [3]. Incremental product development is planned and executed with the goal o f delivering an optimal subset of requirements in a certain release (version of a product that is distributed to customers) [2]. In parallel, 'Agile' methodologies are an alternative to traditional sequential development, addressing unpredictability response through incremental and iterative work cadences, known as sprints [4]. Incremental Design Processes is a pro mising emerging discipline related to, but not specifically a subset of, the market driven incremental product development and ag ile methodologies. These processes combine both approaches, trying to merge the agility methods and the incremental process to address the specificity of designing based variants products. A system design process could be said to be " incremental design process" if he is based on the use of high quality generic requirements instantiated into specific requirements dedicated to the definition of variants or increments of a system. Our interest is to identify whether the incremental design process could be applied for the development of mult iple variants of complex products (based on product line engineering), considering the current methods for creating high quality generic requirements. But idea of using incremental design processes raises challenges that could be interesting for the community of requirements engineering researchers.
Our p roblem lies in the way we could formu late the high quality system requirements to be added in the incremental design processes. As the sources of the requirements vary it is not surprising that requirements come in different shapes and forms, at mu ltiple levels of abstraction, and described on varying levels of refinement [1]. Requirements are specified for many different purposes and fro m many d ifferent engineering activit ies [5]. Du ring authoring, natural language remains a universal means of exp ressing requirements and studies indicates that 89% of engineers [7] shown their preference to use of natural language requirements. However ambiguity or vagueness of requirements are the two main problems arising fro m the over-flexib ility of the natural language [28], making their interpretation challenging fo r any natural language processing systems to reasonably understand the subject-matter. The requirement writer in many occasions is skewed by their own personal e xperiences hence semantics, vocabulary and terms differ widely fro m one person to anot her as illustrated by Dickerson [6]. Not much research has investigated whether different domains need different kinds of semantic tools displaying different kinds of semantic relat ions. To address the challenge of writ ing the requirements right, we have identified two main industrial problems.
Fro m the statistic survey established by Fanmuy and Foughali [7], it was found that the most common leading defects in the natural language requirements falls under: semantic contradiction, not verifiable, not complete, ambiguous, not understandable and not precise enough. On the conclusion of the survey, it was stated that the problems still persist despite the use of several requirement engineering approach like writing 'SMART' requirements right fro m the very first attempt. Dedicated to assist the system engineers, this approach leads to eliminate unnecessary informat ion in requirements, to improve readability (i.e. text length, number of punctuation marks, etc.) and reduce complexity. Another approach: the formal notation and graphical representation based on models albeit offers alternative means to natural language. Go rschek proposes a Requirement Abstraction Model [1]. Ho wever, these approaches remain not so convenient to cover wide range of concepts, to manage co mpliance and to address the needs creativity of system engineers. In practice, the requirements do not exhib it all the acceptable characteristics of good requirements. As an example, this bad requirement "New and modified air distribution components shall be designed to minimize noise levels " should be replaced by "New and modified air distribution components installed in cabin areas shall emit less than 30 dB(A) of acoustic noise." The consequence of these mistakes is felt during all downstream act ivities such as architecting, design, imp lementation, and testing. Organizations struggle to bring consistency to their project and 47% of unsuccessful projects fail to meet goals due to poor requirements management [20].
Requirement Verificat ion is about verifying sufficiently early in the develop ment process whether the requirements have sufficient quality (i.e. they are well-formed according to the ISO/IEC/IEEE 29148 standard) to avoid many negative impacts subsequent activities. When eventually discovered, these defects will be significantly more expensive and take mo re t ime to fix them. The following picture shows the cost to extract defects.
To address the hereunder issues, the following research tasks were identified.
First of all, improvement of requirements quality is given through a better structuring of requirements sentences. This structuring goes through the definition of models allo wing the creat ion of one or several types of requirements. To do so Mavin considers a simple and efficient set of sentence structures to improve drastically the quality of requirements [8]. Each sentence structure can be based on full sentence models as proposed by Al-Safadi [9] and in the Cesar pro ject [10]. This study proves the interest to use sentences model based on predefined (frozen) or progressive, adaptive stru ctures to support the authoring of requirements . This structure is generally called 'patterns' or 'boilerplate'. The concept of using boilerp lates for writ ing statements of requirements is quite simp le: choose an appropriate predefined pattern, and fill in the gaps. Each statement of requirement is then based on a boilerp late where the selected attributes have specific terms. Example of boilerplate: The <system> shall be able to <capability_verb> at a maximu m rate of at least <quantity> times per <time unit>.
The corresponding requirement could be: 'The light shall be ab le to flash at a maximu m rate of at least 5 t imes per second.' The benefits of using boilerplates to structure sentence for the syntactic analysis of requirements are numerous. The most important ones are an aid in the articulation of sentence, a uniformity of language and a one-stop control over expression.
The improvement of requirements is also possible thanks to an analysis of their meaning. Indeed, even if a requirement could be correctly written with boilerp late, this solution does ensure neither its intrinsic quality (i.e.: what is the requirement mea ning?) nor its global quality (is the requirement redundant, contradictory or similar with regard to the other requirements?). The consistency quality of a requirement may rely on a semantic analysis of its sentences. To carry out this analysis we use outcomes given in the Cesar project [10], by Kof [11] and Jureta [12] wh ich have already tackled these issues through different approaches, in particular with a domain ontology (like in some of the early works by Lin [13] Yu [14] and Cadih lac [16]). Fro m all available definitions of ontologies, the best suitable for our purpose is given by Gruber [15]. In simp le terms, ontology represents a domain of knowledge. To build and manage our ontologies, different tools exist on the market. Our aim is not to make a benchmark of these tools but to define a method to apply them. The process supporting this method of do main ontology definition is summarized in the next figure.
Starting fro m the collection of corpus and requirements sets, the global process is based on five main sub-processes (the terminology, thesaurus, pattern definition, pattern matching and formalization) grouped together into two main phases. The result of this process is double; a domain terms-based ontology (i.e. light ontology) and a set of structured formu lation of sentences (i.e. bo ilerplates). Both are lin ked together, therefore the ontology is mapped on the boilerplates that support the analysis of quality. Indeed, only the comb ination of structured sentences and well known te rminology ensures the definition of better quality requirements.
Future directions focus on extending our understanding of boilerp lates and ontology techniques implemented for aircraft industry. Currently, we are in the process of constructive generic method to define clearly the process of ontology and boilerplate creations. So far we identified different requirement error taxono my, semantic based requirement engineering concepts [17], formal expression language used in ontology [18], ru les to construct domain ontology and issues concerning maintainability and interoperability of ontology [19]. Practical work covers the construction of thesaurus and its rules for ontology. Next activity will be to apply the process dedicated to the implementation and use of the boilerplates and ontology. However, the next problem will be the complexity of incremental design processes that requires the creation of high quality generic requirements. This drives to research issues: how ensuring requirements consistent and complete in incremental design processes? Which methods and techniques drive to requirements quality for product line processes ? Rather than affirming at this stage, what shall be done in the next years down the line, we can only expect some ground breaking results thanks to new research activities.
The current practices and techniques of the requirement engineering are wide. Expe riments, case studies, survey and action research will be evaluated by the end users in near future to determine suitability and interest of our boilerplate and ontology based method. As a result of the integration of our research methodology it is expected to create synergy and to contribute to the quality improvement of requirement s. An interesting opportunity will be to carry out implementation of future methods and solutions to improve the quality of requirements for the purpose of incremental design processes.