Outlook

respect to an underlying domain model and then uncover terms that are neither part of the consolidated terminology nor defined through the pattern semantics.

A long-term vision that emerges from our results is that we might be able to better integrate requirements categorizations into a holistic software and system development process in the future. Such an integration would yield, for instance, seamless modeling of all properties associated with a system. The benefits of such an integration include that specific categories would not be neglected during development activities, as it is too often current state of practice; from an improvement in the traceability of requirements over an improvement of possibilities for progress control to an improvement of validation and verification.

10.3. Outlook

In this section, we describe possible future research directions.

10.3.1. Application of the Approach to further Quality Attributes In this dissertation, we proposed an approach for defining, specifying, and integrating QRs. We instantiated our approach for two specific quality attributes (performance and availability) and conducted an empirical evaluation with respect to its applicability. The results indicate that the approach is applicable and besides the constructive nature of our approach, further supports analytical quality assessment with syntactic analyses.

For example, the question how can we assess that all information necessary for the subsequent development activities are documented in a given textual requirement (i.e., the completeness of the individual requirement)?

Our approach captures the content of a requirement as a model. Building such models for industrial requirements allows reasoning about several statements that are presumed to be common knowledge about QRs. For example, the assertion that QRs are cross-functional and affect the whole system is challenged by the fact that a reasonable share of examined requirements regarded the scope “function” or “component” instead of

“system”.

We consider the (re)definition of individual quality attributes, as we did with perfor-mance and availability in this paper, based on their impact to development activities as beneficial for the definition of quality attributes. Thus, our approach could be applied to other quality attributes, resulting in a content model and a notion of completeness for other quality attributes based on literature and on the question which content is necessary to perform specific activities. This would result in activity-based definitions of quality factors, which are actionable and applicable by practitioners.

As a long term vision, the resulting content models could be analyzed with respect to their commonalities and eventually unified in one content model for quality requirements (for all quality attributes). This would result in a model of all content elements that characterize the specification of quality requirements. Based on this, we could give a precise and explicit definition of quality requirements and, furthermore, an integration in

10. Conclusions & Outlook

the development process by means of the respective sentence patterns. Given this unified content model, further questions arise like its applicability, usefulness, and adequacy.

10.3.2. Integration in Analytical Quality Assessments

The results of the instantiation of our approach to performance requirements suggest that natural language performance requirements in practice are, to a large extent, incomplete with respect to our notion of completeness or at least need to be interpreted to be implemented and tested. Our approach is a step towards increasing the completeness of quality requirements in general. The operationalization via sentence patterns could be easily implemented in a requirements authoring or management tool. Such a tool may provide instant feedback to the requirements engineer about missing or optional content elements. Furthermore, the tool might check the terms used in a requirement with respect to an underlying domain model to uncover terms, the reader must interpret because the term is not part of the consolidated terminology. Furthermore, it would be interesting to integrate the notion of completeness that is associated with our approach with requirements smells [Femmer et al., 2014a,b, 2016; Vogelsang et al., 2016], i.e., we could automatically analyze requirements documents and provide an indication for a quality defect if requirements are incomplete with respect to our notion.

An additional benefit of our approach is that it makes content in natural language requirements explicit and traceable through content elements. This allows connecting specific content elements of requirements with specific content elements in related artifacts such as test cases or components within the implementation. Updates within requirements may then be propagated directly to corresponding test cases for example, making maintenance activities more efficient and effective.

10.3.3. Evaluation of the Cost and Benefits of our Approach

So far, our approach provides a means for practitioners to specify requirements concerning a specific quality attribute. Furthermore, it provides an assessment of quality requirements with respect to our notion of completeness. Considering the constructive nature of sentence patterns, if requirements are specified based on these sentence patterns, they are complete by construction. However, conducting our approach for a quality attribute is labor intensive. Thus, the question is about the cost benefit ratio; Building a cost model for our approach and connecting this cost model with the associated benefits is a challenging task. The results will help to better understand when to apply the approach and when not to apply it.

10.3.4. Integration of our Approach in a Specification Methodology for Requirements

In Chapter 8, we have seen that in contrast to the prevailing opinion that QRs are cross-functional, the scope of only 58% is the whole system, for 34% it is a function and for 8% a component. For time behavior requirements, the percentage of requirements having a function as scope (49%) even rules out the percentage of requirements having

188

10.3. Outlook

the system as scope (46%). In contrast to this, for capacity requirements, 85% of the requirements specify the system as scope and only 15% a component as scope.

These results lead to an interesting question: How can we integrate our approach in a requirements specification methodology. For example, if we consider the requirements that have a function as scope. Can we integrate them with a use case-based methodology, i.e. to structure the functionality and also the QRs of a system by functions [Broy, 2010b;

Vogelsang, 2015; Vogelsang et al., 2015]?

10.3.5. Application Beyond Quality Requirements

So far, we have set the scope to product-related requirements and traditional quality requirements according to the ISO/IEC 25010-2011 [2011]. Thus, we explicitly excluded process-related requirements and also requirements that concern physical aspects of a system, like spatial requirement, i.e., requirements that describe properties about the spatial relationship of a system with physical objects. As an interesting open question, we propose to apply our approach also to these types of requirements, resulting in a precise definition and an operationalization by means of sentence patterns. For example, if we apply our approach to process-related requirements, it would result in a model of content elements that are relevant to specify these kind of requirements. In contrast to this work, a process model could then be used to precisely define the content elements. It would be interesting to analyze the relationships between these requirements and functional/quality requirements by leveraging the connection between system models and process models.

If we are able to unify these models, we would enable a requirements engineer to specify quality requirements, physical requirements, and functional requirements based on one unified method.