An Approach for Requirements Engineering for Software Library-Components and Patterns to be Reused in and across Product Lines

In the development of product lines one of the challenges is to exploit commonalities among products such that development cost is reduced. For software, this implies to identify parts that are sufficiently similar to define library-components or patterns for reuse. The detailed definition of scope, responsibilities and interfaces for library-components and patterns is part of their design process, which makes requirements engineering different for them. The paper presents a method to determine a set of requirements that forms a suitable starting point for the design. This assures that the component or pattern to be designed fits well to all systems under consideration. Established design principles like abstraction or parameterization are applied to requirement engineering and management. The method has been successfully applied in several automotive cross-product-line development projects. Motivation and Introduction Solid requirement engineering is the base for successful delivery of products in time, with the desired quality and within the cost limit [1, 2]. Good requirements are necessary for appropriate designs and reliable and complete tests. The reason for about 40-50% of the problems (cost or time overruns and deficiencies) in software projects is closely related to requirements [3, 4, 5] – 15 years ago and still today. So, effective requirement engineering and management techniques are crucial for the success of projects, and they belong to the biggest challenges [6]. In general there is more than one requirement engineering phase during the development of systems. For example according to Automotive SPICE [7] there is the phase of elicitation and analysis of the system requirements as well as the phase of software requirements analysis. Often – especially in larger projects – there are additional phases of requirements analysis, e. g. for system or software components. Another additional phase of requirements engineering is necessary in the development of product lines, the scoping [8, 9, 10, 11], targeting top-level requirements. The paper is about handling of requirements for components and patterns that shall be used in different contexts. It focuses on stakeholder communication and the documentation of the results of one requirement engineering phase. In particular we look at components or patterns for which the detailed scope yet has to be decided and for which therefore also the external interface is subject to design considerations (in contrast to standard components as defined by AUTOSAR [12]). One of the key points is that commonalities and variability have to be managed efficiently. This holds for product line development, but even more for component development for different product lines or products. The fact that we are concentrating on only one phase is no restriction for general applicability, since all requirement engineering and management phases of a project can be combined in a natural way for the sake of obtaining the overall requirements traceability demanded by [7, 13]. Our approach was applied successfully in several cross-product-line development projects, like replacing a set of rivaling component implementations by a common solution, extending a component's scope of reuse to a new context, developing architecture level design patterns, redesigning an existing library and developing a new software component. The term requirement in this paper is meant to cover requirements of all kinds: functional as well as non-functional, qualitative as well as quantitative, problem space focused as well as solution space focused, externally observable or not. Consequences if scope and interfaces are subject to design decisions Assume that embedded software for a number of products has to be developed, and it is observed that there is some commonality between the products. For example, the designers might realize that there is the need for some kind of sorting capability to fulfill the requirements of several products. In such a scenario, in order to improve development efficiency, it appears plausible to investigate the possibility of developing a sorting library that is to be reused between the products. What are the requirements on such a sorting library? This question is difficult to answer at the described stage of development: An Approach for Requirements Engineering for Software Library-Components and Patterns to be Reused in and across Product Lines