Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse

G Model

COMIND-2569; No. of Pages 15 Computers in Industry xxx (2014) xxx–xxx

Contents lists available at ScienceDirect

Computers in Industry journal homepage: www.elsevier.com/locate/compind

Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse Dagny´ Hauksdo´ttir a,*, Niels Henrik Mortensen b, Poul Erik Nielsen c a

Danmarks Tekniske Universitet, Produktionstorvet, Bygning 426, rum 133, 2800 Kgs. Lyngby, Denmark Danmarks Tekniske Universitet, Produktionstorvet, Bygning 426, rum 154, 2800 Kgs. Lyngby, Denmark c Ulsnæs 1, 6300 Gra˚sten, Sønderborg, Denmark b

A R T I C L E I N F O

A B S T R A C T

Article history: Received 7 August 2013 Received in revised form 24 January 2014 Accepted 11 February 2014 Available online xxx

A requirements reuse setups typically includes reusable requirement set(s) containing a collection of reusable requirements and a number of product specific requirements sets which are drawn from the reusable set(s). The ideal scenario when reusing requirements is that all the product requirements can be drawn directly from the reusable set. However, this is rarely the case in product development as new requirements are likely to surface. A critical issue in requirements reuse therefore becomes how to enable products to efficiently reuse requirements as well incorporating changes to the product set. In this paper the objective is not to present a specific method for requirements reuse but to introduce and discuss the possible dimensions of adjustability when generating a product requirement set by reusing requirements from a reusable set. Six adjustability dimensions have been identified. An extensive state of the art is included to introduce the presented methods related to each adjustability dimensions. The options for implementing each adjustability dimensions in a requirement reuse approach are illustrated along with a discussion regarding the benefits and issues resulting from each option. This discussion should help practitioners to better understand the possible methods that can be implemented and to design a user friendly and sustainable approach. A case study, describing how the dimensions are incorporated in two requirements reuse approaches, for Danfoss Solar Inverters (SI) and Danfoss Frequency Drives is provided. As a result an overview of how each adjustability dimensions is implemented in each case is presented. The case study demonstrates that all the identified adjustability dimensions were important elements in requirements reuse implementation. The case study furthermore highlights the need, not only to understand the effects of each adjustability dimension but also of the dependencies to case specific criterions. The classification of adjustability dimensions in requirements reuse and the options for their implementation has not been outlined by previous research and should be a useful contribution both to researchers and practitioners working in the field of requirements reuse. ß 2014 Elsevier B.V. All rights reserved.

Keywords: Requirements reuse Requirements specification Product development Adjustability dimensions

1. Introduction Industrial product development is under increasing pressure to perform better in terms of efficiency, high-quality and high value output [1]. New product success or failure is strongly related to effective use of market information [2] and economy of scope for gaining a competitive edge [3]. One approach to improve

* Corresponding author at: Ved Kløvermarken 12, 4 sal, tv, 2300 København S, Denmark. Tel.: +45 31756046. E-mail addresses: [email protected], [email protected] (D. Hauksdo´ttir), [email protected] (N.H. Mortensen), [email protected] (P.E. Nielsen).

engineering design and achieving fast time-to-market is through reusing previous knowledge when creating products that share characteristics with previously developed systems [1,4]. Because the work products have already been created, tested, and documented, productivity increases because consumers of reusable work products need to do less work [7]. Performing reuse at a certain level usually carries with it reuse at subsequent levels [6] therefore, higher the level of abstraction at which reuse takes place, the larger its benefits [8]. Requirements engineering emphasises on understanding the problem domain of a planned product, encourages the discovery of the true stakeholder needs and prevents premature solution selection. Poor requirements management has often been found to be one of the major causes for product failure in product

http://dx.doi.org/10.1016/j.compind.2014.02.011 0166-3615/ß 2014 Elsevier B.V. All rights reserved.

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 2

D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

development projects [5,7]. However, analysing and documenting requirements requires considerable effort and it might therefore be tempting to cut corners in this activity. Reusing requirements is beneficial in terms of improving quality, development productivity and time to market [5,8,9]. Requirements reuse has been pointed out as one of the most pressing needs and grand challenges in Requirements Engineering [6,10]. A requirements reuse setups typically includes reusable requirement set(s) containing a collection of reusable requirements and a number of product specific requirements sets which are drawn from the reusable set(s). The ideal scenario when generating a new product requirement set is that all customer requirements can be satisfied by exploiting existing assets and their variability [11]. The more realistic scenario, however, is that new and unpredicted requirements will surface [12]. The critical issue in requirements reuse therefore becomes how to enable products to efficiently reuse requirements as well as capturing product specific characteristics. In this context the adjustments that can be made when generating a product specific requirement set are an important issue. A number of contributions have been dedicated to the task of building a reusable requirement set but only a few publications specifically deal with the task of generating a product requirement set [8]. Several approaches presenting defined methods for requirements reuse management have been provided such as MARM [8], PRS [13] and SIREN [9]. These approaches differentiate greatly in their implementation for working with reusable information in the product set. A generic overview of the possibilities available for adjusting the reusable requirement set to the product set is missing. In requirements reuse there is no ‘‘one size fits all’’ and the most appropriate solution depends on the characteristics of the product domain and the organization developing it. In this paper the objective is not to present a specific method for requirements reuse but rather to give an overview of the dimensions of adjustability that can be incorporated in requirement reuse approaches and to provide a discussion on each dimension. An extensive state of the art is included to introduce the presented methods that can be applied in relation to the each adjustability dimensions. The identified adjustability dimensions are present in all requirements reuse approaches and it is important to consider each dimension when designing a requirements reuse approach. Having this overview should provide practitioners with a better knowledge platform for creating an optimal requirements reuse approach that best fits their needs. This will also provide better defined criterions to evaluate the most suitable requirement tool support, since the tool support needs to be aligned with the types of adjustability that shall be supported when generating a product set. This paper is relevant for every organization that wants to incorporate requirements reuse and might be relevant for requirement tool providers as well. The paper begins by identifying the adjustability dimensions that are the subject of this paper. Section 3 summarizes what methods have been suggested by previous research related to each dimension. In Section 4, the options for incorporating each adjustability dimension are presented and elaborated on. A case study, describing how the dimensions are incorporated in two requirements reuse approaches, for Danfoss Solar Inverters (SI) and Danfoss Frequency Drives, is presented in Section 5. Results are illustrated in Section 6, followed with discussions in Section 7 and finally the paper is concluded in Section 8.

introduction of the identified dimensions of adjustability in requirements reuse, when generating a new product set. The adjustability dimensions are identified by taking a look at the elements existing in a setup of text based requirement sets. The elements are classified into three levels of abstraction.  Requirement set structure: In requirements reuse the objective is to manage a number of specification sets, some containing reusable information and some contain project specific information. These could be repositories in a database or configuration tool, or they could be documents using Microsoft Word etc.  Requirement structure: Within a requirement set there will be an approach to group and structure the requirements items. The requirements items are thus given a contextual relationship and order.  Requirements items: The requirements items specify individual requirements information. The requirements can be split into two parts; the text field documenting the requirement and attributes and knowledge fields giving the requirement further identification. Based on this classification, the possible adjustability dimensions are identified. They are the following: 1. Constructing the requirements sets; the reusable and product specific sets can be organized using different setup mechanisms. E.g. is it allowed to reuse requirements from one or more reusable sets? 2. Changing the requirements structure; is it allowed to change the structuring logic or move requirements around in the requirements structure? 3. Free selection and combination of requirements; it allowed to select any combination of requirements or is the selection constrained somehow? 4. Adding new requirements; is it allowed to add new requirements when generating a product requirement set? 5. Changing attributes; is it allowed to change requirement attributes when generating a product requirement set? 6. Changing content of requirements; is it allowed to moderate the content of the requirement when generating a product requirement set? An overview of the abstraction levels and identified adjustability dimensions for each level is shown in Fig. 1. This is an introduction to the identified adjustability dimensions that will be the subject of this paper. Section 5 will contribute to the existing theory by identifying the different implementation options available for each adjustability dimensions and by elaborating on the effects of which option is taken when designing a requirement reuse approach. First the adjustability dimensions will be analyzed by discovering what previous research has written about the dimension. We will look for which suggestions have been provided for implementing each adjustability dimension. This provides a non-existing overview, summarizing the existing approaches from the viewpoint of adjustability dimensions. 3. State of the art This section will provide an overview of how each of the identified adjustability dimensions has been addressed by theory, in the order they appear in, in Section 2.

2. Dimensions of adjustability in requirements reuse 3.1. Constructing the requirement set This paper is based on the assumption that when generating a product requirement set there are a definite number of ways that it is possible to incorporate adjustments. This section gives an

Different approaches can be selected for how to construct or organize the reusable and product specific requirements sets. If

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

3

Fig. 1. Adjustability dimensions in requirements reuse.

this issue is not defined in the industrial application the relationships between the requirements sets might easily become complex and unclear. In some cases requirements are reused informally. In this case the organization does not use much effort in building the reusable set and might not even have a specific one. Basically requirement authors look into similar projects and reuse as much as they can. Unfortunately this results in a lack of overview and breaks traceability. It therefore becomes impossible to compare products or know what the updated and correct version of a requirement is. However this approach is inexpensive requires no start-up cost and will likely take less time than starting from scratch [14]. Several reuse approaches such as PRS [13], MARM [8], Core requirements [15] and FORE [16], suggest having only one reusable requirement set from which all products draw from. In this case, when creating a product requirement set one must consider the whole range of variability applying to the product family. For product families with many product variants this makes the number of selections unnecessarily high. As a result reuse can lose efficiency because time will be wasted in evaluating requirements which are not relevant for the new product [8]. A product in a large product family is likely especially similar to one other product in the family. Therefore the number of common requirements between the products is high which makes reusing requirements from the similar product and then emphasizing those requirements that are different an effective approach [17]. Lam et al. suggest that a view of system families could be a promising organization of requirements for reuse. A tree diagram can be used to depict a family of systems, and help identify subfamilies where the requirements between family members may be more closely aligned [18]. Consistency management between the sub-families might be an issue with this approach as the product family structure grows in size and complexity [17]. One possible way to achieve scalability is to divide the reusable requirement set into separate, independently manageable parts that can be combined to create a product requirement set [17]. To do this, the choice of the re-useable building block must be defined [19]. An example of a building block can be a scenario, a feature or a use case, etc. In SIREN the reusable requirements are organized by means of catalogues that use predefined templates of documents. A product requirement set is then a combination of many catalogues [8]. A challenge with this approach is that the independent reuse sets might have hidden dependencies and therefore some form of centralized management of the dependencies between the sets must occur [17].

This summary provides a none-existing overview of the options that have been presented for organizing the requirements sets. In Section 5.1 these options will be presented and further elaborated on. 3.2. Changes in the requirements structure Before starting to build a reusable requirement model it is necessary to identify a method for structuring and organizing the reusable requirements knowledge [18,20]. This is a precondition facilitating reuse, since the time devoted to searching for requirements from the repository is reduced [8]. This is typically a significantly more complex activity than for a single system [23]. To capture project specific views users might be allowed to move or regroup requirements. Criterions for a good reusable structure have been identified in [21] and [20] and few publications are available for how to group and categorize requirements, for a text based requirements reuse. Mannion et al. proposed using domain viewpoints to define product line requirements. A viewpoint is an entity which presents a specific view of the system and encapsulates some but not all information about a system’s requirement [22,23]. It can be expected that if the product sets share viewpoints they will share groups in the top level of the structure but their order might be different and unshared viewpoints will also result in differences. The sub-structure for each viewpoint can furthermore be expected to be stable. Kuusela and Savolainen present a method called Definition hierarchy consisting of nodes that represent design objectives and design decisions. The topmost nodes in the definition hierarchy represent the architectural drivers and other quality aspects for the system [24]. From the perspective of reusability, the structure might differentiate between projects, since they are likely to have architectural different drivers. Hauksdo´ttir et al. present the Complete Reusable Requirement Structure. The objective of the structuring technique is that it shall be stable between products. The structure identifies five requirements types that should be general for most products and a second layer structure identifying general problem domains for the specific type of product [20]. However, it remains a challenge to establish optimal views for specific roles and technological expertise in the development process. Requirements reuse approaches do not always address how to structure of the requirement set. An example of a method that allows structure adjustments on product level is the SIREN method [9], while the MARM approach using stakeholder viewpoints to keep the structure consistent [8].

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 4

D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

3.3. Free selection and combination of requirements When selecting requirements for a new product the users are either allowed to select any combination of requirements or they are restricted in which selections are available. Such restrictions need to be built into the reusable model. To support the selection of requirements at reuse time the application of selection constraints has been introduced [8,25,26]. A common classification of selection constraints is the following:  Mandatory: Requirements that are common to all the products in the application family.  Mutual exclusion (single adaptor): A set of requirements from which only one can be chosen.  A list of alternatives (multiple adaptor), a set of requirements from which at least one must be chosen.  Option: A single requirement that may be chosen or not. At reuse time the selection constraints demand that users select mandatory requirements, take decision on adaptors and options, and restrict them from making invalid selections. When the product family extends in scope, new products emerge that break existing assumptions on variability. In time, this could lead to most selection constrains becoming optional ones, therefore increasing the number of required selections. If the requirements sets are organized into sub-families as described in Section 3.1, selection constrains might remain more consistent within the sub-families [17]. Requirements can have relationships additional to those captured by the hierarchical tree structure [1]. Examples of relationships commonly existing in a requirement model are: inclusive- and exclusive relationships [9]. The relationship minimizes the risk of inconsistencies. Changes to one reusable requirement can furthermore have an impact on others [8]. When the requirement set evolves, traceability relationships can be used to assess the impact of changing a requirement [9]. Constructing traceability links between requirements can be a difficult, subjective, time consuming but an important task [8]. The implementation of selection constraints and relationships can make the selection process considerably more effective. When selecting a single requirement one immediately becomes aware of its dependencies and requirements can be automatically selected based on previous selections. If selection constraints are included, it is only necessary to make choices where the products differentiate from one another, rather than for each requirement. Using free selection one would need to capture incorrect selections and errors manually generating a considerable overhead in validation checking [8]. However, not all requirements tools have a build in application to define selection constraints or relationships, or to automate the selection process. Although tractability relationships are included in the reusable requirement model, they usually do not capture all invalid combination of requirements. This is because the effort of identifying and maintaining all possible relationships would likely not be cost effective. By concentrating only on the key constraints the evolution costs may be reduced. The engineers generating the requirement set are furthermore expected to have enough domain knowledge to avoid some invalid configurations. If the key constraints are well documented creating invalid configuration has not been a problem in practice. However, for some application domains e.g. where safety is important, including a more extensive definition of relationships might be appropriate [17]. The application of traceability relationships varies in the requirements reuse approaches (see Section 3.7). The PRS method suggest a decision model where all relationships between and among variations of requirements are captured and guide the user

though the selection [13]. The careful management of the common and varying characteristics of the product family differentiates PLE from other forms of reuse [27] suggests that selection constrains and tractability relationships are therefore critical tools for accomplishing PLE requirements management. 3.4. Adding new requirements A major concern of application requirements engineering is the detection of deltas between application requirements and the available requirements [11]. During selection there is sometimes a need of introducing new requirements. Mannion et al. identifies two cases: (i) to change the reusable set and introduce the new requirement (ii) to introduce the new requirement into the product set first and then consolidate it to the reusable set [8]. In case of the first option new requirements can only be added to the reusable set. This locking mechanism ensures the integrity of common requirements [28]. In MARM [8] and FORE [16] new requirements are added as a new point of variation to generic requirements in the reusable requirement set. The MIA reuse approach on the other hand permits adding project specific requirements which are unaffected by the reuse and behave like ordinary, stand-alone project requirements. Many approaches do not explicitly address this important issue [9,13,18]. 3.5. Changing attributes Knowledge fields presented in attributes can be important used to manage and classify requirements. Some common items included in the requirement template are as example; name, unequal identifier, requirement type, status, priority and technology domain [29,30]. It needs to be decided if the users shall be able to change the attribute values in the product set. Parameterized requirements allow an easier way to represent e.g. a continuous range of values as a part of a variable requirement. Parameterized requirements contain some parts that have to be adapted to each application or system and that have to be instantiated when it is reused [9]. They encourage reuse by factoring out system-specific details as parameters of the requirement, thus enabling engineers to specify requirements with a higher degree of flexibility [9]. Parameterization is a powerful concept that has been extensively used in to favour reuse. One way to express parameters is by attribute values. In requirements engineering, this concept has been translated into parameterized features in FODA [31] and FORM [32], parameterized requirements [9,18,33,34] and by decision variables in PRS [13]. 3.6. Changing content of requirements Requirements will not be identical for all products that include the requirement [35]. It must be defined if it is allowed to change the content of requirements to capture product specific modifications when generating the product set. To enable requirements reuse without modifications the content of the requirements needs to be presented in a reusable way. Few guidelines exist on the topic of how to write reusable requirements other than the guidelines presented by [36]. They illustrate that certain patterns exist which can be identified to write requirements in a more reusable way [8]. One strategy to make requirements with minor variations more reusable might be to exploit resemblances between systems in a domain [18,19]. Such modelling approaches suggest a content generic for the domain in the reusable repository, ignoring all the variations and not allowing changes in content for specific products [25]. Although this approach provides an improved starting point

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

compared with developing a system from nothing, it can also be deceptive, as important details might be lost and the information might become of little practical value [18]. Another approach is to specify requirements as atomic, self-contained elements without product or model-specific terms [8]. By making the requirements atomic creates flexibility because the pieces can be put together in many ways and therefore avoid changes in the requirement content [21]. A popular strategy to maximize reuse and prevent changes to product requirements is by explicitly modelling variations in the product family with a formalized approach. The approach to separating specification of stable common parts of a system from the changeable components was first introduced by Jackson [37,38]. The content of the general part remains consistent and all variations from it are expressed in separate nodes. A significant body of research is available on modelling approaches and notations for this purpose [11,43]. Feature modelling has become a popular way to manage and express variability [39] e.g. FODA [31], FORM [32] and FetuRSEB [40]. Requirements are typically used to define the features in detail [39]. In the area of requirements engineering several techniques for modelling reusable requirements have been suggested, such as; CoRE [41] the Orthogonal Variability Model [11], and FORE [16]. A major issue in the domain-modelling approaches concerns how effectively they addresses scale-up. The problem is not so much the size of the domain but the degree of variability and volatility. A relatively stable, well-understood application domain is likely to be the best candidate for domain modelling while too much variation or instability can lead to a combinatorial explosion [25]. Lam suggests a broader view of reuse beyond generalization, by use of pluggable parts to complement generalization [18]. Reuse, can increase if requirements that are not common to all product domains but are frequent in the product set are considered specifically. The variability of such semi-generic requirements can be captured with a pluggable part that may then be adjusted in the product set, allowing a quick construction of requirements with a high degree of flexibility [18]. However, this approach fails to capture knowledge about variations of the family of systems in the reusable repository [12,25]. The MIA approached presented by Manson suggest a requirements reuse approach where the reusable set consists of two types of requirements; strong and weak, which are managed separately (in addition to project specific requirements) [28]. Weak reused requirements can evolve separately from its source while the strong reused requirements shall be consistent between the product variants. The main difference from a traditional copy-paste approach is that weak reused requirements stay linked to the source even if they change separately [28]. This differentiates from the approach presented using by Lam since the changes are not limited to the pluggable part of the requirements. Waldmann and Jones report that due to a dynamic market environment it was not possible to define an entire family of products, so therefore the entire product portfolio is not defined, before the first product is developed. Instead artefacts are created (a) for which the exact scope of reuse becomes apparent only at a later time, when a derived product is defined, and (b) which may be slightly modified, rather than reused as-is, for subsequent products [35]. This concludes the overview of the options, the existing requirements reuse theory proposes, for how to address the identified adjustability dimensions. However this section does not summarize how specific requirements reuse methods have addressed the adjustability dimension. To provide such an overview and to summarize the research overview, Table 1, in Section 4 compares the identified requirements reuse approaches in terms of the adjustability dimensions.

5

3.7. Summary of previous work Prior contributions have presented useful techniques for how to construct the reusable requirement set with the purpose of managing commonality and variability as well as to support the activity of generating a product requirements set. Table 1 summarizes identified requirements reuse methods by providing an overview of how they suggest addressing each of the adjustability dimensions identified in Section 3. The overview provided in Table 1 is limited to textual requirements specifications and leaves out model based requirements engineering. Feature modelling methods are also not included although feature models often address similar issues as requirements reuse methods. From the summary overview in Table 1 it can be seen that the requirements reuse methods have chosen different approaches to implementing the adjustability dimensions. As the purpose of these contributions is most often to present a specific method other possibilities or the rationale for how the adjustability dimensions are implemented are therefore often not discussed. Mannion et al. is the only contribution that clearly identifies two different options of inserting new requirements; that is that they can either be inserted into the reusable set or be introduced to the product set first and then consolidated to the reusable model. The approach also compares the application of free selection versus applying selection constraints to support requirements election. The SIREN approach presented by Toval et al. and MARM approach presented by Mannion et al. address the adjustability dimension in an especially sufficient manner. It can however be seen that none of the methods clearly addresses all the adjustability dimensions and often they are addressed indirectly by related descriptions of the method. No contribution has provided a sufficient overview of the different options for how the requirements set can be adjusted when generating a product set. These decisions however, affect the sustainability and usability of the requirement reuse method. An overview of the different options for each adjustability dimension can help to better understand how requirements reuse approaches could be designed and to ensure that the approach is well thought through. Many factors such as the maturity and volatility of the product domain and the requirement tool can influence what is the optimal approach. Therefore having an overview of the different adjustability dimensions and their implementation options could help to design the requirement reuse approach. Next the options for each dimension will be introduced along with a discussion regarding their benefits, issues and effects. 4. Approaches for implementing adjustability dimensions In requirements reuse a fundamental difference in implementation is related to the level and type of adjustability allowed by users on project level. The implementation options for each adjustability dimension presented in Section 2 will now be discussed. 4.1. Constructing the requirements sets The following approaches for organizing the requirements sets have been identified (Table 2): The benefits and issues for each of these options have been analyzed. These findings are presented in Table 3. If the requirements in the product set are allowed to evolve separately from the reusable set, it might be appropriate to keep a simple structure since other vice it becomes difficult to maintain traceability between the requirements sets or know what the updated version of a requirement is. For Case C as an example, it must be ensured that the predecessor requirement set for a new product variant is still valid.

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

6

Table 1 Summary presenting how previous contributions address each adjustability dimension.

Requirements Constructing the Reuse requirements set Methods

MIA [28]

MARM[8]

SIREN [9]

PRS [13]

Changing the requirements structure

Different req. sets can be a source of reusable req.

Seems to be allowed.

One application family mod el.

Identify a stable structure based on stakeholder viewpo ints.

Many catalogu es used in on e repo sitory.

÷

Adding new requirements

Structure A system of documented on Suggests patterns Criterions for families where req. the notation of of teq. that are e.g. Requ irements between family often used issues typ ical for reuse [18] members are more the particular together. closely aligned. domain.

The Orthogon al Variability Model [11]

÷

Changing content of requirements

÷

Allowed to adjust week req. bu t strong req. can only be mod ified from "parent" document.

÷

Atomic req. but tool allows chang es of requ iremetns.

÷

Allowed in the product set.

Allowed to change con tent in the project but not in reusable repo sitory, on ly through an administrator.

÷

Decision variables Text replacement present variables that change variable on the instantiation of values that decision variables. are selected among .

÷

÷

Variable parts of generic req. identified as "plugg able parts" and changes allowed in the product req. set.

÷

Not allowed

÷

Not allowed

÷

Allowed only for none core req.

Discriminant New req. added based selection to the reusable using selection al set. Identify two con straints and options for traceability inserting rew req. relation ships.

Specify any con straints and traces among variations.

÷

Changing attributes

Project specific req. allowed.

Traceability relation ships

Allowed

Sing le do cument characterizing the family as a whole.

Free selection and combination of requirements

New app lication Req. specified as req. do cumented mand atory or separately and option al req. only integrated Variability to the produ ct depend encies, line if they requ ires or address needs of excludes used. the domain.

÷

FORE [16]

High est-level One reusable req. nodes correspond set to the generic produ ct concept.

÷

New req. add ed as variation to the generic req. set.

Core Requ irements [15]

All variants compared against the basic product

÷

Allowed.

Subject add ress ed

÷

14 Subject ind irectly address ed

The choice of the most optimal repository structure will depend on the similarity between the product variants, the type of tool support, the planned management and maintenance approach and finally how some of the following adjustability dimensions are implemented. If the organization has limited experience of requirements reuse or limited tool support it might a good strategy to keep the repository structure simple. Most importantly the organization of the requirement set must be clearly communicated to all stakeholders.

÷ Subject not address ed

4.2. Changes in the requirements structure To generate product specific views or for improvements it might be relevant to adjust the structure of the product requirement set. When generating a product set there are two options; changes in the structure are either allowed or they are not allowed (Table 4). If changes in the requirement structure are not allowed it can be that changes can be incorporated through a change process. It is impossible to create one structure that is optimal for all stakeholders

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

7

Table 2 Options for constructing the requirements sets. Case A: Reuse from one source

One reusable requirement set from where every product set reuses from.

Case B. Reuse from many sources

More than one defined reusable set from where the product set reuses from.

Case C. A view of system families

Requirements sets organized into different granularity levels based on sub-families and similarities between products. A child repository can either contain a complete product requirement set or only the deltas from the parent repository.

Case D. Combined or unrestricted construction

The approaches above might be combined or it might not be defined how to organize the requirements sets, identifying no specific reusable repository. This is how the repository structure might evolve if the organization of reusable sets is not clearly defined.

as they have different needs. Existing tools are quite limited in providing specific views of the requirement set other than creating filtered lists based on attribute values. If traceability between reused and product requirements is established, it is be possible to track the moved requirements. For case B and D in Section 4.1 one can imagine how complicated it would be to establish an overview, if the requirements structure would be different for each product set. In requirements tools there is not always a built in functionality that prohibits users in moving requirements and on the other hand, in other tools it is not possible to move requirements in the product set. Training and administration is how to structure requirements is important for the sustainability of the reuse asset. 4.3. Free selection and combination of requirements Constraints might be added to reusable requirement set for how requirements can be selected. Including such constraints can increase the efficiency of generating a product requirement set, ease evaluation of requirements and can improve quality by ensuring consistency as described in Section 3.3. Table 5 summarizes the benefits and issues resulting from the available options for restricting the requirements selection.

The state of the art section on this adjustability dimension presented in Section 3.3 gives a quite sufficient overview of the methods available for managing the requirement selection. The decision on which method to implement depends mostly on the maturity of the product domain. For a product domain that is still evolving it can be expected that the existing constraints will change considerably and might not be known well enough to give true value. Selection constraints will therefore be most beneficial for mature product domains where it has really been established which requirement combinations should be offered to customers. The process of deciding on the provided variability and the commonality between product family variants might be even more valuable than the effects it has on the requirements reuse process itself. The decisions taken are critical for complexity management and affect complexity at all proceeding levels in the product development process. Finally, the decision of including selectional constraints and traceability relationship directly affect tool selection, since not all tools will support these applications. 4.4. Adding new requirements When generating a new product requirement set, it can be expected that new requirements will surface. It needs to be clear if

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

8

Table 3 Options for how to construct a reusable requirement repository. Approach

Benefits

Issues

Case A

    

Simple and clear structure. Easy to implement. Requires limited tool support. Easy to ensure consistency. Fits well for cases where there is a considerable difference between products.

 Might result in an unnecessary number of selections and therefore reduce reuse efficiency.  For a product family with many product variants a large part of the reusable requirements might become optional.

Case B

 Allows maintaining information in smaller more manageable parts.  Specific subjects can be managed independently.  Can support implementing different granularity levels. For example, one set might contain information for all products while another set is only reusable for specific applicaiton.  Limited tool support required.

 Possible lack of overview of which requirements sets are reusable or how they can be put together. Dependencies between separate requirements sets must be identified.  Not possible in all tools.

Case C

 Requires fewer selections as the parent and child product are more similar.  Highlights the differences between two products.  Selection constraints and traceability relationships might remain more consistent for sub-families.

 It might not always be clear what the correct parent requirement set is.  Requires sufficient tool support.  Difficult to manage consistency for the entire product family.

Case D

 Low startup cost.  High flexibility.  Limited tool support required.

   

Maintenance difficult. Lack of consistency between requirements in different sets. Lack of overview of variations between family members. Difficult to find the newest requirement version.

Table 4 Options of allowing or not allowing changes in structure when generating a product requirement set. Options

Benefits

Issues

Consistent structure

 Easier to make a comparison between projects.  Creates familiarity for the users, i.e. they know where to find things.

 Difficult to establish customized views.  Difficult to incorporate incremental improvements in structure.

Adjustable structure

 Possible to provide a customized view for specific projects or specific users.  Possible to incorporate improvements in structure.

 Difficult to establish overview of commonality and variations between products if traceability is not established.

Table 5 Options for restricting requirement selection when generating a product requirement set. Options

Benefits

Issues

Free selection

 High flexibility in requirement selection.  Less effort to build the reusable model.

 Less efficiency of requirement selection.  Selection requires higher understanding of product family.

Selection constrained by selectional constraints

 Reduces number of selections and increases efficiency.  Ensures validity of selected requirements.

 More effort in building the reusable set.  Not supported by all tools.  Selection constraints change as product family evolves.

Selection constrained by traceability relationships

 Supports consistency of the product set.  Requirements excluded or included based on previous selections making selection more efficient.

 More effort in building the reusable set.  Existing relationships might be broken for new products and therefore need maintenance.  Not supported by all tools.

Table 6 Options for adding new requirements when generating a product requirement set. Options

Benefits

Issues

Not allowed

 High control of variability in the product family.

 Requirements generation becomes rigorous if many new requirements need to be added.

Allowed to add requirements to the reusable set

 Requirements visible for reuse as soon as they are added.  Less risk of defining the same requirement more than once.

 All requirement information collected in the reusable set. Number of requirements in the reusable set might explode and it may contain many requirements with low reuse potential. * Less efficient selection * High complexity.  Less control of variability and quality in reusable set.

Allowed to add requirements to the product set

 High flexibility for users.  Possibility of keeping requirements with low reuse potential product specific.

 New requirements not visible in reusable set until they have been consolidated.  Little control of variability in the product set.  Risk that the same requirement is identified more than once for different products.

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

new requirements shall be added directly to the product repository, if they should be added to the reusable repository and then mapped to the product repository, or if they cannot be added directly at all. The benefits and issues of these options are outlined in Table 6. For a mature product family it can be important for complexity management to ensure that individual projects utilize the existing variability and that new variations are carefully introduces to the requirements set. Not allowing users to add requirements to the reusable nor the product set enables the organization to be in control of the variability in the product family and can also ensure that only requirements of sufficient quality level are added to the reusable model. This also ensures that only authorized users have access to the reusable repository. Special requirements engineers, skilled in requirement writing, might have the responsibility to add new requirements. If the users need to add a new requirement they can document it separately and then send a change request to the requirement repository. However this is a restrictive approach and can slow down the progress of documenting the product requirements. If generic and variable parts of the requirement set have been successfully modelled, adding new requirements and variation points to the reusable set becomes easier. Effort will be required to integrate the new requirements to the existing model, however since if users are enabled to add new variations directly, it will not cause delays for the project progression. Another issue is if all requirements should be added to the reusable set at all, or if some requirements should remain product specific. If many requirements in the product domain are specific for individual products it can simplify the reusable set to leave them out. This creates a risk that a similar requirement will be created more than once. The trade-off for the performance of the requirements reuse process is the time going through a high number of reusable requirements that will likely not be used, versus the time needed to re-document some requirements. However, if the setup of the requirement repository is as described in Case C above, this might not be a problem, since product specific requirements for unrelated products are already left out in the parent requirement set, a new individual product reuses from. Finally if the requirements are mapped to existing solutions or other design elements, all product requirements should be added to the reusable set to guide users to the existing work products. Adding new requirements on product level is flexible and easy for the users. The approach will require less training and skills of the users and it protects the reusable repository from unskilled requirement authors. Most importantly it enables the option of keeping some requirement product specific. However, adding new requirements to the reusable set will require a sufficient consolidation processes. If the requirements are selected using a configuration tool, the tool might not support adding new requirement on product level and therefore all requirements must be collected in the reusable model. 4.5. Changing attributes To characterize and manage requirements they are often given attributes. The attribute values are either general or they can be changed on product level (Table 7). Modifying attribute values on product level can be a valuable application to support requirement management. Attributes such as ‘‘Status’’ and ‘‘Priority’’ might be valuable for managing the requirements in projects. Parameterization is a promising method to express variability and has the potential to increase the expressiveness and reusability of common requirements. Thus, instead of presenting

9

Table 7 Options for changing attributes when generating a product requirements set. Options

Benefits

Issues

Allowed

 Enables project management support.  Enables using parameters to present product specific values.

 Version number might change causing inconsistency with linked elements.  Not supported by all tools.

Not allowed

 Consistency of attributes between projects.

 Prevents managing project specific information for the requirements.  Limits expressiveness of reusable requirements.

each variation point in a generic requirement as a separate note in the system they could be added as attributes to the requirement. However, to implement parameterized requirements the tool needs to support adding different attribute types to requirements in the same set. This is not supported by many requirements tools. 4.6. Changing content of requirements Many requirements will be reusable by many products but they might need adjustments e.g. to change customer specific values, incorporating improvements or adding customer comments. Four options to incorporate requirements changes are identified; (1) No changes allowed: The users then either create a variant of the requirement or they document the requirement separately and send a change request to the reusable set. (2) Changes allowed in reusable model: Requirement authors directly change the reusable model. (3) Changes allowed in pluggable parts: Product specific changes allowed but limited to clearly marked parts. (4) Adjustments allowed in the product set: Users can add product specific detail or improve the requirements in the product set as they see fit. These options are elaborated in Table 8. The first two options do not allow adjustment of requirements content on product level. For both options it is therefore important that the general and variable information have separated so that it is easy to capture product specific needs in variation points of the general requirements. In practice the first option is usually implemented by using a change request process. Requirement authors send a change request, suggesting a change to the reusable model which is later accepted or rejected by a change board. This will ensure that the reusable requirements are aligned between products and that the implemented changes are correct. This can however, be a rigorous process if there are frequent changes and delay the proceeding of the project. The authors might therefore avoid small changes and incremental improvements. There is furthermore a risk that the requirement authors will create a completely new requirement instead of trying to adjust the existing one or exclude specific knowledge to make the requirements more general. Variability modelling and management is a key in order to achieve successful reuse in the development of a product line [17]. Adjustments of requirements in the product sets prevent a systematic management of the variability of the product family and should therefore not be allowed for such approaches. Allowing changes directly in the reusable model on the other hand creates the risk that un-experienced requirements author change the reusable requirements in unwanted ways. If existing

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 10

D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

Table 8 Options for adjusting requirement’s content when generating a product requirement set. Options

Benefits

Issues

Not allowed

 More control and less frequency of changes of the reusable asset.  Reusable model protected from unskilled users.

   

Allowed in reusable set

 Supports alignment between reusable and product requirements sets.  Less effort to consolidate changes.

 Consistency with products reusing the requirement must be ensured.  Requires users to have sufficient understanding of the product family and how changes affect other products.  Risk that incremental quality improvements are ignored.  Risk that users du incorrect changes.

Adjustments of pluggable parts

 Possible to capture project specific values without generating a specific item in the requirement set.  Reusable model protected from unskilled users.  Fewer variation points in reusable asset might simply the reusable set.

 Variation points not explicitly presented.  Might not be possible to capture dependencies between variations points using explicit selectional constraints and traceability relationships.

Adjustments allowed in product set

 Supports incremental quality improvements.  Allows capturing project specific information.  Reusable model protected from unskilled users.

 Users might do incorrect changes.  Inconsistency of requirements between projects.

product sets are reusing a requirement, changes in the requirement might trigger updates of the product requirement sets. Having sufficient overview of the effects of such changes for the product family requires expert knowledge. Requirement authors working in projects might not have the necessary overview of the product domain, to make decisions regarding changes to the reusable requirements. There is a risk that an organization might lock for changes in the reusable requirements content, prematurely, before it is really ready to be reused without changes because (a) the general and specific part have not been separated or (b) the quality of the requirement is not sufficient. If this is the case it might result in the users not following the approach and also the reusable requirements will not improve in quality. When there is a strong project focus, flexibility is of essence and one of the most relevant requirements imposed by the enduser [28]. Allowing product specific changes will create flexibility for the users and enable them to capture product specific details and promote them to make incremental text improvements of the requirements text allowing the repository to evolve and improve through project efforts. This will also enable requirements reuse without explicitly separating the general and the variable requirements part in the reusable model, therefore requiring less upfront effort to build the reusable set. However, by changing the product requirements, traceability to the reusable repository might be lost and it becomes difficult to have an overview of the compatibility between products. Finally, a possible risk of allowing product specific changes is that the users might make incorrect changes, which will need to be captured through review processes. However, review is always demanded and if the quality of the requirements improves project by project, it can be expected that review effort will decrease in the long run. No matter which type of adjustability is implemented, it will require a sufficient approach to data management and a process to support it. Next a case study to further enrich the understanding of the adjustability dimensions, by analysing how they appear in a industrial product development setting, will be presented. 5. Case study This research is based on cooperation with Danfoss Power Electronics (PE). Danfoss PE is a Danish company with more than

Variation points might explode in number. Incremental quality improvements might be ignored. Reusable model must be complete. Restricting for users.

3000 employees around the world. The company manufactures a wide range of electrical and electronic products and has provided Frequency converters (drives) for more than 40 years. Requirements reuse practices have been used at the company for number of years. The company has an objective of continuously improving the quality of the requirements and increasing the efficiency and ease of creating requirement specifications. The main author of this paper has for three years worked in close cooperation with the company focusing on requirements reuse, while simultaneously researching the topic. At Danfoss PE, the authors have experience from working with three approaches to requirements reuse. Those are;  The Direct reuse approach where the authors are not allowed to make changes to requirements when generating a product requirement set.  A PLE approach which has been implemented for software requirements.  The adjustable requirements reuse approach implemented at Danfoss SI (seen in [39]).

This has provided the authors of this paper the theoretical and practical experience needed to provide a discussion about the different adjustability dimensions identified in Section 2. This section will discuss how each of the adjustability dimensions was designed for the Software PLE approach for the frequency converters and the adjustable requirements reuse approach for Danfoss SI. 5.1. Background VLT software Danfoss has a long history of developing VLT frequency converters and has actively managed requirements for many years. A large asset of legacy software requirements exists. However challenges were identified in managing requirements reuse especially in terms to variation management, using the traditional direct reuse approach and the implemented tool. Due to the maturity of the product the organization saw a potential of implementing a PLE approach for the software requirements. A software PLE team has been established that has the objective of implementing and managing PLE in the organization. All requirements from existing product have been collected and a

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

reusable requirements model has been built. Having a dedicated team was a key element to achieve this. Tool support that could better support variability and configuration was furthermore established. 5.2. Background Danfoss solar inverters The Danfoss SI business unit was merged with Danfoss PE in 2009. There are several different applications of the Solar Inverter for example it can be used in a home owner installation or it can be installed in a solar energy power plant. Although solar systems have been around for a number of years the market is still evolving in unpredictable ways and therefore the requirements to the product are volatile. There is therefore a need for flexibility to adjust requirements and to specify new requirements in an agile way. After the merge with Danfoss PE, Danfoss SI needed to adopt many of the processes and tools from the PE organization, including requirement management. The organization had the opportunity to make a fresh start in requirement documentation and to get things right from the beginning. Due to the high volatility of the product, compared to the frequency converters, it was recognized that the same approach to requirement reuse would not be an optimal for Danfoss SI. 5.3. Requirements tools The requirement tool can be an important enabler or constrainer of the implementation of adjustability dimensions and the requirement reuse approach. In practice the organization might likely already be managing the requirements in a specific tool which affects the implementation of the adjustability dimensions unless the organization is willing to shift to a new tool. 5.3.1. CaliberRM Danfoss PE uses CaliberRM (Caliber) provided by Borland for documenting and managing requirements. In requirements are documented in repository folders where they are presented as nodes in a hierarchical tree structure and are given a unique ID number. When a requirement is reused, it is mapped from a reusable set to a product set. When a requirement is mapped a clone of the company requirement is created in the product set where it is given a unique ID number and has a life of its own. It is not possible to change the text field of a mapped requirement in the product set without breaking the mapping link (un-mapping the requirement), the whole text field of the requirement must therefore be valid for reuse. When the text of a requirement in the reusable set is changed, product requirements mapped to it are automatically updated. Therefore, it must be evaluated if the product requirements should be updated, or other vice un-map it. However, if a requirement is un-mapped there is no longer any traceability between the requirements. 5.3.2. Pure::variants The increasing Software Product Line (SPL) use in the engineering process leads to the development of tools supporting variant management for software product lines. Pure::variants created by pure-systems is created for the purpose of modelling and managing variants of SPL [42]. Pure::variants provides the functionality to automatically generate solutions from stored information. Pure::variants has a model structure where each model has its field of application that is:  Problem space for designing the SPL,  Solution space for realizing the SPL,

11

 Configuration space for configuring single solutions of the SPL. The basic modules of the models are elements, which can have attributes. Elements may have relations to other elements or may be constrained by so-called restrictions. The problem space is embodied through a feature model, which determines the SPL. Four different feature types are possible: mandatory, optional, alternative and or. The opportunity to model and display the dependencies and relations of a feature model is given by these feature types. It is also possible to include require and exclude relations with special rules. The solution space is embodied through a so-called family model. While the feature model shows the variants of a SPL, the family model connects to the corresponding components, which have to be considered when choosing a feature. The configuration space displays all elements of a SPL and provides the possibility to configure individual solutions and concrete products. It also offers the facility to test the chosen configuration. 5.4. Requirements reuse approach for Danfoss VLT software The SPL approach at Danfoss VLT is implemented using Caliber and pure::variants in combination. Requirements are documented in Caliber and then imported to the problem space in pure::variants. In pure::variants a model for the requirements containing selection constraints and relationships is maintained. The requirements for a product set are then selected in the configuration space. When the configuration is finalized the product requirements are sent back to Caliber where they are presented in a read only version which is used to store and baseline the product requirement set, and generate documents. Fig. 2 shows an overview of the tool implementation for the VLT software requirements reuse approach. A product configuration application was selected to better manage variability and ease the selection of requirements. To support a configuration of the product set a reusable model explicitly presenting general and variable requirement information was created. Selection constraints were added to the model in pure::variants and are used to guide the requirement selection. Requirements relationships are furthermore added but only a few important ones since there are simply not many actual relationships existing, meaning that there are not many cross-tree relations that would not be allowed to change if the product application required them to. However, the requirements are mapped to the architecture and the constraints of the existing architecture have an impact on which requirements can be selected together. If the users identify missing requirement or defects during the selection process, they shall insert the change to the reusable set in Caliber. All changes to existing requirements shall be added as a variation point in a new requirement node. The existing requirements cannot be changed. This is to ensure the integrity of the already established traces between the reusable model and other design elements and product requirements, and to avoid incorrect changes. This ensures that the new requirement becomes reusable for other projects and enables an overview of added variations. It is also not possible to add new items or change requirements in the configuration space in pure::variants. At a later point the new variation points are evaluated and integrated to the reusable set. A status attribute is used to detect new items that have not been integrated to the reusable requirement set. It is however not allowed to change attributes in the product set and therefore no product specific attributes can be used. A complication of allowing changes in attributes on product level is that changing attributes results in an update of the requirement version number. This could

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 12

D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

Fig. 2. Tool setup for the VLT SW requirements reuse approach.

cause incompatibility since design elements might be linked to a specific version of a requirement. The structure of the requirements sets is stable based on the major features of the software family. This is relatively easy to accomplish due to that the requirement set is only used for a single technical domain. Finally, the SPL consists of natural sub-families that are identified. The tool support and the integrity of the requirement’s content enables a configuration on product instances based on an existing configuration, i.e. constructing the repository as specified in case C in Section 5.1. 5.5. Requirements reuse approach for Danfoss SI For Danfoss SI Caliber is used to manage requirements. As the product domain of solar inverters is still evolving flexibility was needed to capture new and changed requirements. The volatility of the product domain furthermore made it unattractive to pursue building a complete reusable model. An approach was therefore taken where the reusable set is built up by projects and where projects are allowed to specify product specific requirements. Pluggable parts are identified for requirement information that is expected to vary between the products. The pluggable parts are highlighted with specific fonts that indicate that the users can adjust the information and might need to take a decision about product specific value. If values in the requirement text are not highlighted it can indicate that the users are not supposed to change the values. The requirements authors are however also allowed to make changes in the text outside the pluggable parts if they identify improvement opportunities or to add details or

project specific information. Examples of pluggable fields are shown in Fig. 3. After the requirements specification has been carefully reviewed and accepted a consolidation process is initiated. Only information that is considered reusable is consolidated to the reusable set and some information therefore remains product specific. Before the consolidation is conducted all requirements in the product set are un-mapped, this is so the reusable set can be changed without automatically changing the product requirements. To maintain traceability of reused requirements attribute values are added. Fig. 4 provides an overview of the adjustable requirements reuse approach. Since variations between the products are not presented explicitly in the model and because of the low maturity of the product domain, selection constrains were not applied. For the same reason it was not possible to identify explicit relationships between requirements variants. The tool furthermore does not provide the application of selection constraints. Important dependencies between requirements were however presented in text based form. Attributes are allowed to change in the product set which is valuable for requirement management at Danfoss SI as development is project driven. For this application it is important that the specification structure remains consistent. Because the requirements content can change and the variation is not modelled explicitly it would other vice be difficult to compare products. This is however more challenging than for the VLT software specification because the requirement set covers all product requirements relevant for many stakeholders.

Fig. 3. Example of pluggable parts in reusable requirements.

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

13

Fig. 4. Overview of the requirements reuse approach implemented at Danfoss SI.

6. Results The requirements reuse approaches for Danfoss VLT software and Danfoss SI were compared from the perspective of the identified adjustability dimensions. The results are illustrated in Table 9. The Danfoss VLT software product domain is mature and the main objective is to manage complexity and ensure consistency and alignment of reusable assets. Therefore it is important to remain in control of variability in the reusable asset. This is only accomplished by limiting the allowed changes when generating a product requirement set. For Danfoss SI on the other hand the main objective is to enable capturing requirements for new products while reusing as much as possible and to build up a high quality reusable repository by project efforts. At this point there are extensive changes in requirements for each new product. To ensure usability of the reuse approach it was therefore important to enable changes in a practical way. For Danfoss SI, the VLT software approach would have resulted in a rigorous process, which might result in the users either avoiding product specific changes and general improvements, or bending the process. The build-up of the reusable requirement model was a precondition for implementing the VLT software reuse approach and it would not have been without the tool support. The pure::variants tool for example enables the implementation of

selection constrains and of traceability relationships. The selectional constraints have been a critical element to manage and communicate variability in the product family. At Danfoss SI the same level of legacy requirements does not exist and future requirements might change in unanticipated ways. It is therefore not attractive to pursue building a complete reusable model. The pluggable parts were valuable applications as many requirements were reused by all projects but required changes in specific parameters. Danfoss VLT furthermore has the objective to reuse existing software solutions based on a configuration of requirements. Explicitly presenting variability of requirements is critical to enable traces to the corresponding software component. 7. Discussion The case study shows that the identify adjustability dimensions are major elements in defining the reuse approach. It highly affects the usability of the reuse approach in practice; its sustainability, the flexibility for the users, the control of the product complexity etc. In both of the presented cases the identified adjustability dimensions were important elements and strongly affected the reuse approach. The case study furthermore highlights the dependency of the adjustability dimension to the characteristics of the product domain and circumstances in the organization. The correct implementation might depend on:

Table 9 Comparison of implemented adjustability dimensions. Adjustability dimension

Danfoss VLT

Danfoss SI

1. Constructing the requirements sets 2. Changes in the requirements structure 3. Free selection and combination of requirements

Case C Not allowed Restricted with selectional constraint and traceability relationships. Allowed in the reusable repository Not allowed Not allowed

Case A Not allowed Free selection

4. Adding new requirements 5. Changing attributes 6. Changing content of requirements

Allowed on product level Allowed on product level Changes in pluggable parts as well as generic adjustments on product level.

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 14

       

D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx

Maturity of product and the volatility of the requirements. Differentiation level between product variants. Experience with requirements reuse Quality and completeness of existing requirements. Available resources to build up the reusable wet. Tool support. Objectives with requirements reuse. Technical domain characteristics, e.g. is it a customer or a technical requirements domain, is it for one or many technologies.

The approaches presented in the case study would not have been successful in practice without considering these characteristics and understanding the effects of the adjustability dimensions on the usability of the requirements reuse approach. Usually implementing more advanced modelling techniques can provide high flexibility but it requires that a considerable effort has been used to create a reusable model. If a central control of a defined product family is the objective this level of formality is appropriate. However, for organizations with less experience with requirements reuse, products that are still evolving or do not have a defined product family, a more flexible and simple implantation of the adjustability dimensions might be more practical. It cannot be expected that many practitioners will have the opportunity to build up a complete, reusable model containing correct variability assumptions and requirement of optimal quality prior to starting to generate product requirements sets. Previous contributions do not take sufficient consideration of this issue and approaches taking into account continuous improvements and maintenance of the reusable model are therefore needed. In this paper a quite untraditional viewpoint is taken on requirements reuse approaches, i.e. the adjustability dimension. There are many other issues that need to defined when defining a requirements reuse approach, however the discussion in this paper is more to help practitioners to consider what the level of flexibility and control that can be built into their approach and what are the affects from how the adjustability dimensions options. 8. Conclusions In this paper the possible dimensions of adjustability when generating a product requirement set by reusing requirements from a reusable set have been identified and discussed. Six adjustability dimensions have been identified. An overview of what the existing research has contributed to each of the adjustability dimensions has been presented. The options for implementing each adjustability dimensions in a requirement reuse approach have furthermore been illustrated along with a discussion regarding the benefits and issues resulting from each option. This discussion should help practitioners and tool providers to better understand the possible methods that can be implemented and for practitioners to design a user friendly and sustainable approach. The case study introduces two different approaches to requirements reuse. As a result an overview of how each adjustability dimensions is implemented in each case is presented. The case study furthermore highlights the need, not only to understand the effects of each adjustability dimension but also of the dependencies to case specific criterions. The requirement tool selected is an important enabler of the adjustability dimensions. A requirement tool that is flexible in customizing the adjustability dimensions in different ways would be valuable as it would provide organization more options for implementing an optimal approach for their case and enable them to change the approach without changing the tool. The classification of adjustability dimensions in requirements reuse and the options for their implementation has not

been outlined by previous research and should be a useful contribution both to researchers and practitioners working in the field of requirements reuse. It is however impossible to ensure that the listing of options for the adjustability dimensions is complete and further insight into the dimensions might also be provided by further experience with implementing different requirements reuse approaches. A description and practical experience with requirements reuse approaches combining different levels of adjustability and results on how different implementations affect the result of the process performance would therefore be valuable.

References [1] D. Baxtera, J. Gaob, K. Case, J. Harding, B. Young, S. Cochrane, D. Shilpa, A framework to integrate design knowledge reuse and requirements management in engineering design, Robotics and Computer-Integrated Manufacturing 24 (4) (2008) 585–593. [2] B.D. Ottum, W.L. Moore, The role of market information in new product success/failure, Journal of Product Innovation Management 14 (4) (1997) 258–273. [3] J.A. Harding, K. Popplewell, R.Y.K. Fung, A.R. Omar, An intelligent information framework relating customer requirements to product characteristics, Computers in Industry 44 (1) (2001) 51–65. [4] W.C. Lim, Effects of reuse on quality, productivity, and economics, IEEE Software 11 (5) (1994) 23–30. [5] L. Goldin, M. Matalon-Beck, Reuse of requirements reduces time to market, in: 2010 IEEE International Conference on Software Science, Technology & Engineering, 2010, 55–60. [6] B. Moros, C. Vicente-Chicote, A. Toval, REMM-Studio+. Modeling variability to enable requirements reuse, in: ER 2008, Proceedings, vol. 5231, 2008, pp. 530– 531. [7] C. Jones, Patterns of Software Systems Failure and Success, International Thomson Computer Press, London, 1996. [8] M. Mannion, H. Kaindl, J. Wheadon, Reusing single system requirements from application family requirements, in: International Conference on Software Engineering (ICSE’99), 1999, 453–462. [9] A. Toval, B. Moros, J. Nicola´s, J. Lasheras, Eight key issues for an effective reusebased requirements process, International Journal of Computer Systems Science & Engineering 23 (6) (2008) 373–385. [10] B.H.C. Cheng, J.M. Atlee, Research directions in requirements engineering, in: FOSE 2007: Future of Software Engineering, 2007, 285–303. [11] K. Pohl, G. Bo¨ckle, F.J. van der Linden, Software Product Line Engineering: Foundations, Principles, and Techniques, Springer, Berlin, Germany, 2005. [12] R. Rabiser, D. Dhungana, Integrated support for product configuration and requirements engineering in product derivation, in: Proceedings of the 33rd EUROMICRO Conference on Software Engineering and Advanced Applications, 2007, pp. 219–228. [13] S.R. Faulk, Product-line requirements specification (PRS): an approach and case study, in: Proceedings of the IEEE international symposium on Requirements Engineering, 2001, pp. 48–55. [14] I. Alexander, L. Beus-Dukic, Discovering Requirements, How to Specify Products and Services, John Wiley and Sons Ltd., Chichester, England, 2009. [15] L. James, Managing Variant Products and Their Requirements, Integrated Chipware, 2001 Technical Paper TP004-010115. [16] W. Lam, A case-study of requirements reuse through product families, Annals of Software Engineering 5 (1998) 253–277. [17] J.E. Savolainen, Product Line Management Techniques with Requirements and Feature Models, (Doctoral dissertations), Alto University, Department of Computer Science and Engineering, Helsinki, Finland, 2011. [18] W. Lam, J.A. McDermid, A.J. Vickers, Ten steps towards systematic requirements reuse, Requirements Engineering 2 (2) (1997) 102–113. [19] A. Finkelstein, Re-use of formatted requirements specifications, Software Engineering Journal 3 (5) (1988) 186–197. [20] D. Hauksdo´ttir, N.H. Mortensen, P.E. Nielsen, Identification of a reusable requirements structure for embedded products in a dynamic market environment, Computers in Industry 64 (4) (2013) 351–362. [21] L. Dr. Melikhova, A. Elcock, A.A. Dovzhikov, G. Bulatov, Dr. Dmitry, O. Vavilov, Reengineering for system requirements reuse: methodology and use-case, in: IEEE International Symposium on Consumer Electronics, vols. 1 and 2, 2007, 631–634. [22] I. Sommerville, P. Sawyer, Wiewpoints: principles, problems and a practical approach to requirements engineering, Annals of Software Engineering 3 (1997) 101–130. [23] M. Mannion, B. Keepence, D. Harper, Using viewpoints to define domain requirements, IEEE Software 15 (1) (1998) 95–102. [24] J. Kuusela, J. Savolainen, Requirements engineering for product families, in: Proceedings of the International Conference on Software Engineering (ICSE), 2000, pp. 61–69. [25] H. Gomma, Reusable software requirements and architecture for family of systems, Journal of Systems Software 28 (1995) 189–202.

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011

G Model

COMIND-2569; No. of Pages 15 D. Hauksdo´ttir et al. / Computers in Industry xxx (2014) xxx–xxx [26] J. Savolainen, I. Oliver, M. Mannion, H. Zuo, Transitioning from product line requirements to product line architecture, in: Proceedings of the 29th International Computer Software and Application Conference (COMPSAC’05), 2005, pp. 186–195. [27] P. Clements, L. Northop, Software Product Lines – Practices and Patterns, Addison-Wesley, Boston, 2002. [28] A. Monzon, Practical approach to requirements reuse in product families of onboard systems, in: 16th IEEE International Requirements Engineering Conference, 2008, 223–228. [29] S. Roberstson, J. Robertson, Mastering the Requirements Process, AddisonWeslay, London, 1999. [30] A. van Lamsweerde, Requirements Engineering, From System Goals to UML Models with Software Specifications, John Whiley and Sons, Ltd, Chichester, 2009. [31] K. Kang, S. Cohen, et al., A Feature-Oriented Domain Analysis (FODA) Feasibility Study, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 1990. [32] K. Kang, S. Kim, et al., FORM: a feature-oriented reuse method with domainspecific reference architectures, Annals of Software Engineering 5 (1998) 143– 168. [33] A. Toval, J. Nicolas, et al., Requirements reuse for improving information systems security: a practitioner’s approach, Requirements Engineering Journal. Springer 6 (4) (2002) 205–219. [34] D.G. Firesmith, Specifying reusable security requirements, Journal of Object Technology 3 (1) (2004) 61–75. [35] B. Waldmann, P. Jones, Feature-oriented requirements satisfy needs for reuse and systems view, in: 17th IEEE International Requirements Engineering Conference, 2009, 329–334. [36] B. Keepence, M.A. Mannion, S. Smith, SMARTRe requirements writing reusable requirements, in: Proceedings of the IEEE Symposium on Engineering of Computer-based Systems, 1995, pp. 27–34. [37] M. Jackson, Systems Development, Prentice Hall, London, 1983. [38] A. Sutcliffe, G. Papamargaritis, L. Zhao, Comparing requirements analysis methods for developing reusable component libraries, Journal of Systems and Software 79 (2) (2006) 273–289. [39] D. Hauksdo´ttir, A. Varmehren, J. Savolainen, Requirements Reuse at Danfoss, in: Proceedings of the 20th IEEE International Requirements Engineering Conference, 2012, pp. 309–314. [40] M. Giss, J. Favaro, M. d’Alessandro, Integrating feature modeling with RSEB, in: Proceedings of the Fifth International Conference on Software Reuse, 1998, pp. 76–85. [41] S. Faulk, J. Brackett, J. Kirby, P. Ward, The core method for real-time requirements, IEEE Software 9 (5) (1992) 22–33. [42] http://www.pure-systems.com/Details.53+M591a3370e20.0.html.

15

[43] K. Schmid, I. John, A customizable approach to full-life cycle variability management, Journal of the Science of Computer Programming, Special Issue on Variability Management 53 (3) (2004) 259–284. Dagny´ Hauksdo´ttir is a Ph.D. student at the section of Engineering Design and Product Development at the Technical University of Denmark. The project involves a close industrial cooperation with Danfoss PE where Dagny´ has worked previously as a process specialist for development projects. Dagny´ specializes in research topics related to requirements engineering, product architecture and product design and has experience in research in the area of product configuration and mass customization. She can be contacted at [email protected].

Poul Erik Nielsen is R & D Process Management Director in Danfoss’ Power Electronics Division in Graasten, Denmark. He holds a M.Sc. in Mechanical Engineering and a Ph.D. in Control Engineering from the Technical University of Denmark. He is M.Sc. external examiner for more Danish universities. He has a broad experience from industry and has worked with control engineering, project and program management, product platform management and processes for lean product development, including requirement management processes. He can be contacted at: [email protected].

Niels Henrik Mortensen holds a Ph.D. and a M.Sc. in Mechanical Engineering and is employed as a Professor at the Technical University of Denmark. He is head of section at DTU Mechanical Engineering at the Technical University of Denmark. His main research focus is procedures and methods supporting development of Product Families based on Architectures and Platforms. Currently there are 9 researchers within the field of architecture based product development.

Please cite this article in press as: D. Hauksdo´ttir, et al., Identified adjustability dimensions when generating a product specific requirements specification by requirements reuse, Comput. Industry (2014), http://dx.doi.org/10.1016/j.compind.2014.02.011