## 7 Conclusions  
Especially in the early development phase, ambiguities are very common in Requirements documents due to the use of natural language. In this paper, we examined contradictive requirements, which we defined using formal logic. In contrast to other papers, we did not classify contradictions according to our data set or our code, but according to a generally accepted, well-tested systematic model. Then, we created a classification tailored to RE, in which conditions and effects now take a prominent role. Finally, we proposed a way to identify our contradictions using clear questions. We have analyzed about 6500 objects, approximately 3500 of which were requirements. In total, we were able to identify many different conflicts, 49 of which were LNC-related contradictions that could be identified using our method. The majority of the detected contradictions were of the Alius Contraries. Furthermore, most of the contradictions were found at the deeper system levels, namely those of the software requirements. This corresponds to our expectations, since requirements on the higher levels are written less concretely and describe the general functionality of the product. As a result, there is often no risk of contradictions in the first place. With our method, contradictions can be found in a semi-automated way: The classification into cause and effect, as well as variable and condition, are fully automated, for example by using [PERSON]'s parser [19]. This way our method can be applied automatically up to the step \"Building Blocks\". In the then following formalization the building blocks must be replaced by symbols and formulas. However, this step is not automated. To the best of our knowledge, there are currently no methods available which allow for this. Therefore, further research is required, as mentioned in Section 6_Discussion_. Once the formalization is done, answering the questions in Figure 5 presents a simple--yet manual--task. This was shown with examples in Section 5.2_Results_. When applying our method, a requirements reviewer does not have to be familiar with requirements in general or with the topic of the document anymore, to recognize contradictions, as our method provides a simple recipe for detecting LNC-related contradictions. Future work could entail automation, quality analysis and non-LNC-contradictions. Requirements documents can become very extensive due to the necessary level of detail [20]. Therefore, an automated determination of contradictions would be useful. The formalization of contradictions proposed in this paper provides strong implications for automation, by serving as the basis for a fully automated contradiction-detection method. The queries that would have to be made in such a code are already mathematically formulated here. We can also derive implications for an automated quality analysis. The classification into different types of contradictions is an important step to quantify the quality of a requirements document. The logical next step would be to assess the criticality of the contradiction. Based on this, a meaningful key performance indicator could be determined. This would require analyzing a large number of inconsistencies, to assess the impact on the product, as well as any different resolution methods per type of contradiction. The greater the impact and the more difficult the solution, the more critical the contradiction. As we saw in Section 2_Fundamentals_, there are other types of contradictions besides LNC-contradictions, that have not been discussed in this paper: dialectic contradictions and antinomies. In our opinion, dialectic contradictions cannot be detected by applying simple rules, instead, they require context and language comprehension. It might be possible to achieve results with a sufficiently large and clean data set and by using machine learning algorithms. Regarding antinomies, it should first be checked whether they occur at all in requirements documents.