2 Related work

Requirements reuse has been investigated in various research directions. Table 1 displays works from four of these directions: (1) approach (principles, recommendations, vision, etc.): Akers (Reference Akers2008), Mussbacher and Kienzle (Reference Mussbacher and Kienzle2013), and Niu et al. (Reference Niu, Savolainen, Niu, Jin and Cheng2014); (2) method (framework, systems, etc.): Myklebust et al. (Reference Myklebust, Lyngby, Bains and Hanssen2014), Palomares et al. (Reference Palomares, Quer, Franch, Guerlain and Renault2012), and Pacheco et al. (Reference Pacheco, Garcia, Calvo-Manzano and Arcilla2015); (3) survey (understanding the state of the practice of requirements reuse and the factors that impact reuse effectiveness): Chernak (Reference Chernak2012) and Palomares et al. (Reference Palomares, Quer and Franch2014); and (4) case study (best practices and successful stories): Hauksdottir et al. (Reference Hauksdottir, Vermehren and Savolainen2012) and Tastekin et al. (Reference Tastekin, Erten and Bilgen2012).

Table 1

Research directions in the related work

RE=requirements engineering; IT=information technology.

The authors in Akers (Reference Akers2008) discussed the elements that compose a requirement and established a common understanding of how requirements evolve, how that evolution is retained, and how organizations can reuse requirements to speed business innovation, reduce complexity, and control costs. The authors argued that requirements reuse is not for everyone, and organizations first need to know where they lie on the requirements maturity curve. As organizations evolve along the curve, the need for reuse within their requirements management framework exists. Indeed, according to these authors, many companies are still in the infancy of requirements management because they have not yet adopted a requirements management tool. These organizations are not yet at a point of requirements sophistication where reuse support is necessary. However, if an organization has progressed on the maturity curve with respect to requirements management; manages multiple projects and thousands of requirements in parallel; and seeks to reduce complexity, lower the cost of development, and shorten innovation cycles, requirements reuse is a concept that should be investigated. The authors finally concluded that reuse may not be part of the short-term strategy, but successful strategic companies invest in the future, and this means that a process and tool framework will grow with the organization as it matures over time.

The authors in Mussbacher and Kienzle (Reference Mussbacher and Kienzle2013) proposed arguments in favor of generic requirements reuse rooted in the vision that effectiveness requires a focus on the coordinated composition of reusable artifacts across the entire software development lifecycle. They then outlined for the RE community a research agenda associated with the vision presented for such an approach to reuse those requirements that build on concern orientation, that is, the ability to modularize and compose important requirements concerns throughout the software development lifecycle and model-driven engineering principles. In addition, early research results have been presented briefly that illustrate favorably the feasibility of such an approach.

Product line engineering has become the main method for achieving systematic software reuse. Embracing requirements in a product line’s asset base enhances the effectiveness of reuse because engineers can work on abstractions closer to the domain’s initial concepts. The authors in Niu et al. (Reference Niu, Savolainen, Niu, Jin and Cheng2014) proposed a system-oriented approach for extracting functional requirements (FRs) profiles. The validated extraction constructs are amenable to semantic case analysis and orthogonal variability modeling for discovering the variation structure and constraints. To evaluate their approach, they presented an experiment for quantifying extraction effectiveness and a case study to assess their approach’s usefulness.

The authors in Toval et al. (Reference Toval, Nicols, Moros and Garca2008) identified and validated eight key issues to be considered for an effective and practical reuse-based RE process based on their experience gained through the SImple REuse of RequiremeNts (SIREN) method definition and application (Toval et al., Reference Toval, Moros, Nicols and Lasheras2002).

In a requirement process for cross-border maintainability and maintenance operations, including renewal, it is important for the infrastructure managers to gain an overview of all applicable regulations and be able to extract relevant requirements with regard to maintainability and maintenance. As an aid to achieving an overview of all requirements, the authors in Myklebust et al. (Reference Myklebust, Lyngby, Bains and Hanssen2014) developed the CoVeR method (CoVer all Requirements), which ensures that all the regulatory requirements are extracted and adapted, and the result from the work can be reused. The CoVeR method is a structured approach for ensuring the control of all relevant requirements. A commercial tool has been utilized: IBM Rational DOORS (Dynamic Object Oriented Requirements System), which has been designed to manage large sets of requirements. The tool makes it possible to achieve linking and traceability between requirements on different levels. It also allows linking between requirements and evidence of verification, and it is capable of detecting linking gaps between requirements and sub-requirements, and/or gaps between requirements and evidence of verification.

The authors in Palomares et al. (Reference Palomares, Quer, Franch, Guerlain and Renault2012) presented SRP (Software Requirement Patterns) as an artifact for fostering requirements reuse. PABRE (Pattern-Based Requirements Elicitation) is a framework that promotes the use of these patterns as a means for requirements elicitation, validation, and documentation. A catalogue of non-technical patterns is included in the framework. The authors presented the overall structure of a set of non-technical patterns integrated in the PABRE framework that are part of the catalogue constituted by 113 patterns (functional, non-functional, and non-technical).

The authors in Pacheco et al. (Reference Pacheco, Garcia, Calvo-Manzano and Arcilla2015) proposed a model for reusing the requirements in a Requirements Catalog. Their model aims to define the guidelines for performing the requirements reuse process through four principal activities: searching, selecting, adapting, and implementing. In addition, the commercial tool Computer-Aided Requirements Engineering (CARE) Rational RequisitePro was tailored to make feasible the implementation of the proposed model.

The authors in Toval et al. (Reference Toval, Moros, Nicols and Lasheras2002) proposed the SIREN method. This is a practical approach for selecting and specifying the requirements of a software system based on requirements reuse and software engineering standards. SIREN encompasses a spiral process model, requirements documents templates, a reusable requirements repository organized by catalogs, and a supporting CARE tool called SirenTool.

Implementing reuse in practice remains challenging, and the IT (information technology) community has scant visibility into the state of the practice specifically as it pertains to reusing requirements. The authors in Chernak (Reference Chernak2012) presented the results of a survey conducted in the global IT industry in 2010, and discussed the state of the practice for requirements reuse. The survey studied reuse adoption in two different contexts, that is, Software Product Lines and Software Maintenance. Analysis of the survey data focuses on the latter context as a more common case in practice and investigates the impact of various factors on reuse adoption and effectiveness. An important finding of the survey is that most of the survey respondents believe that requirements reuse is important and can help teams reduce time-to-market and development costs. However, implementing reuse remains challenging in practice where the main obstacle is the poor quality of existing requirements.

The same authors in Palomares et al. (Reference Palomares, Quer, Franch, Guerlain and Renault2012) presented in Palomares et al. (Reference Palomares, Quer and Franch2014) the preliminary results of a survey that addressed the question, ‘what is the current level of adoption of reuse practices during RE processes in organizations?’.

The survey first investigated requirements reuse in general, and then elaborated by asking about a specific technique SRP. The survey results showed that requirements reuse is not a widespread practice in IT projects, where the most common techniques are those based on the copy and later modification by hand of requirements originated from previous projects. With regard to the use of SRP, the results seem to support the hypothesis that SRP could help ameliorate some common problems related to requirements specifications, such as lack of uniformity and incompleteness.

The study in Hauksdottir et al. (Reference Hauksdottir, Vermehren and Savolainen2012) described two different approaches for requirements reuse at Danfoss. The first approach reused those requirements envisioned as common between two consecutive projects, and allowed changing and parameterizing parts of the requirements. The second approach organized all requirements into a common model and explicitly managed variability and different requirement variants in this common model. The results showed that both approaches result in significant savings in reduced effort by reusing common requirements. The first approach was found to be effective when the domain maturity is low and the significant set of requirements were changed from project to project. The second approach allowed high reuse potential and significant savings for stable domains, where most requirements tend to be minor changes of existing requirements.

Product development time estimation is important for project management tasks. The study in Tastekin et al. (Reference Tastekin, Erten and Bilgen2012) investigated the impact of requirements reuse on product development duration for different products in a similar domain. An analytical tool was proposed for estimating the minimum time to be saved given the percentage of requirements reused from earlier projects. Empirical results of industrial case studies were used as inputs to this study. Three cases from different organizations were studied. The results of the case studies were compared with a study in the literature on product development time. According to the industrial empirical results, a modified product development time estimation method was proposed for projects.

From the previous related works, more especially those that cover the approach and method directions, three critical observations can be concluded: (1) there is a lack of maturity in research in the field of requirements reuse; (2) the two processes of development for reuse and by reuse need to be complementary and not stand-alone activities of requirements reuse. They should interact with each other through a common repository framework; and (3) there has been less emphasis on requirements metadata, which could lead to the aforementioned difficulties in requirements reuse.

Therefore, because of the diversity of requirements and the heterogeneity of their styles, requirements reuse is particularly complex and requires an appropriate methodology. We resolve this problem by:

1. 1. Differentiating between two processes: the AFR process of capitalizing existing requirements from old or current software projects, and the ABR process of reusing them in writing new requirements. Only the first process is covered in this present research, where a sequence of steps is defined.

2. 2. Designing RML (Requirements Metadata Language).

3. 3. Supplementing RK of existing requirements with its KR based on RML metadata in order to facilitate its reuse.

4. 4. Creating a conceptual requirement reuse model that provides a set of features that support their organization within a repository.

5. 5. Developing a requirements reuse framework that supports the AFR process.

3 Component-based approach

Our research hypothesis is that it is very likely that different software products of the same family have many common requirements. Accordingly, if these requirements were stored, maintained, and shared in a central requirement repository, requirements engineers could partially or entirely reuse them in authoring new requirements in similar products. This reuse is motivated by at least the two following reasons:

1. 1. Reducing elicitation and analysis efforts, and thus increasing productivity:

   1. i. It is faster to reuse than perform the work from the start (‘from scratch’);

   2. ii. The requirements have already been verified and tested, and therefore the project risk is reduced.

2. 2. Facilitating system interoperability by ensuring more common core requirements between products of the same family.

Furthermore, we argue that in order to develop a new reuse approach, we need to perform two specific actions: (1) AFR: to define the adequate way of capitalizing existing requirements as RK within the repository, and qualify them with KR using RML metadata; (2) ABR: to define a process for retrieving the previous RKs from the repository, and adapt them during a new requirements analysis.

In this research, we focus only on the first action. Sections 3.1 and 3.2, respectively, present the concepts of RK and KR. Section 3.3 presents the conceptual requirement reuse model that encompasses both RK and KR. Section 3.4 presents the AFR process. Section 3.5 illustrates the AFR process through a case study.

3.2 Knowledge of reuse

We define KR as the metadata associated to RK according to RML. Indeed, in order to describe and manage RKs, some domain-specific vocabularies are needed to support their semantic retrieval. In this section, we present the RML structure, which corresponds to the metadata schema building block presented in Haslhofer and Klas (Reference Haslhofer and Klas2010). The RML structure is mainly inspired by LOM (Learning Object Metadata), a standard that specifies the syntax and semantics of Learning Object Metadata, defined as the attributes required to describe a Learning Object (IEEE, 2002). In fact, the RML data model is structured as a hierarchy that includes the categories, aggregate data elements, and simple data elements that represent the leaf nodes. Simple data elements have individual values defined through their matching value space and data type. All data elements are optional. A data element could contain a list of ordered or unordered values, rather than a single value. A vocabulary, which is a recommended list of appropriate values, could be assigned to some data elements.

Table 2 lists the RML base schema that identifies the categories and their embedded data elements, explanation, and corresponding value space.

Table 2

The Requirements Metadata Language base schema

RK=reusable knowledge.

The category ‘Meta-Metadata’ is domain independent, and thus its composition is similar to that of the corresponding category in LOM (IEEE, 2002).

The categories ‘General’ ‘Lifecycle’ ‘Technical’ ‘Rights’, and ‘Annotations’ are almost similar to their corresponding categories in LOM. Nevertheless, their content was adapted to the field of RE.

Finally, the three categories ‘Requirements specific’, ‘Traceability’, and ‘Taxonomy’ which are domain dependent, were completely designed to fit the particularities of the RE domain.

These last categories and some of their most important embedded data elements are described below.

3.2.1 Requirements specific

1. 1. Style (RML Metadata 5.1): the style used to represent RKs, such as data models; data dictionaries; data expressions; virtual windows for data requirements (DaR), context diagrams, and event lists; and use cases for FRs.

2. 2. Scope (RML Metadata 5.5): the product family where the RK is reusable, such as accounting and human resources management.

3. 3. Commonality (RML Metadata 5.6): it is interesting to analyze within families of software products those RKs that are common or optional. Common RKs are those that all products of that family must have. Optional RKs are those that some products of that family have.

4. 4. Granularity (RML Metadata 5.7): RKs might range from high-level abstract statements of a service or constraint to a detailed mathematical functional specification (Sommerville, Reference Sommerville2011).

5. 5. Reusability (RML Metadata 5.8): it is interesting to analyze within families of software products those RKs that are completely or partially reusable. Indeed, when generic RKs might be reusable without any modification, more specific RKs might need some context adaptation efforts.

3.2.2 Traceability

1. 1. Other RKs (RML Metadata 7.1): they allow linking the current RK with other RKs according to different types of traceability, such as overlap, satisfiability, dependency, evolution, generalization/refinement, conflict, and rationalization (Ramesh & Jarke, Reference Ramesh and Jarke2001).

2. 2. Sources (RML Metadata 7.2): this is concerned with the notion of pre-traceability relationships (Gotel & Finkelstein, Reference Gotel and Finkelstein1994). It includes the relationship between RKs and the sources from which the RKs originated, such as regulations, contracts, standards, and software projects.

3. 3. Design artifact (RML Metadata 7.3): this is concerned with the notion of post-traceability relationships (Gotel & Finkelstein, Reference Gotel and Finkelstein1994). It includes the relationship between RKs and the design artifacts created in architectural and detailed designs, such as class, state machine, and sequence diagrams.

4. 4. Reusing software (RML Metadata 7.4): RKs should be reused in software products whose family must be the same as their scope (RML Metadata 5.5).

5. 5. Alternatives (RML Metadata 7.5): it is interesting to consider alternative RKs of a given RK. This increases its reusability.

Based on their semantics, traceability relationships present information that can lead to the reuse of system components when these components are related to RKs of existing systems that are similar to RKs of new systems (Spanoudakis & Zisman, Reference Spanoudakis and Zisman2005).

3.2.3 Taxonomy

1. 1. Level (Metadata 9.1 in RML): RKs might belong to one level based on the goal level scale defined by Lauesen (Reference Lauesen2002): business, user, system, and design. Business requirements aim to justify why the customer wants to spend money on a given product. This can be verified, although only after some period of operation. URs (user requirements) outline the user tasks involved and require support for these tasks. SRs (system requirements) specify what comes in and goes out of the product. It identifies only the functions and features. DRs (design requirements) specify one of the product interfaces in detail.

2. 2. Typology (Metadata 9.2 and 9.3 in RML): RKs might be either FRs or NFRs (non-functional requirements). We have added DaR to this former classification. What data should the system input and output, and what data should the system store internally? (Lauesen, Reference Lauesen2002). NFRs might be classified according to Sommerville (Reference Sommerville2011) as follows: product, organizational, and external requirements.

KRs are used in information retrieval for calculating the similarity between components during AFR on one hand, and between components and a requirement query during ABR on the other.

3.3 Repository organization

Awareness of the critical nature of requirements on one side and the experience accumulated by practitioners in reuse determine the adoption of proper best practices that can increase the probability of capitalizing existing requirements during software projects. We aim to help requirements engineers to accomplish their tasks during the AFR process, thus allowing them to share their best practices that reflect their experience and know-how. These best practices, which are materialized with RKs and their corresponding KRs, can be managed, classified, stored, and retrieved from a systematic repository.

The conceptual requirement reuse model provides a set of features that support the organization of the repository.

Figure 1 illustrates this model using a UML (Unified Modeling Language) class diagram. At the center of the diagram, we have the main class ‘RK’ that corresponds to the RK. It has two subclasses, ‘Atomic’ and ‘Composite’ (RML Metadata 1.3). The classes ‘KR’ and ‘RK’ are connected through the association ‘Qualify’. The use of RML metadata as KR is represented with the composition between the classes ‘KR’ and ‘RML category’ on one side and the nine subclasses of the class ‘RML category’ on the other.

Figure 1

UML class diagram of the conceptual requirement reuse model. KR=knowledge of reuse; RK=reusable knowledge; RML=Requirements Metadata Language

The text description part of RK, such as ‘The system should/shall store data according to the following data model’ is stored as a value of the description attribute of the class ‘RK’. The content part of RK, such as the entity relationship diagram itself, is stored separately from the class ‘RK’ as an instance of the class ‘Content’ linked to the former class through the association ‘Has content’.

The reflexive association ‘Is alternative’ attached to the class ‘RK’ represents the different alternative RKs (RML Metadata 7.5) of a given RK. The association ‘Extracted from’ between the classes ‘RK’ and ‘Product’ shows the product from where the given RK was capitalized (RML Metadata 7.2). Reciprocally, the association ‘Reused in’ shows the product where RK was reused (RML Metadata 7.4). The association ‘Belong to’ between the classes ‘Product’ and ‘Family’ represents the family of a given software product. The association ‘Has scope’ between the classes ‘RK’ and ‘Family’ represents the RML Metadata 1.3. The commonality characteristic (RML Metadata 5.6) of RKs within a family of software products is represented with an attribute of the former association.

The Player-Role Pattern is used in order to avoid multiple inheritance of the class ‘RK’, where the class ‘RK’ is the player and the classes ‘Level’ and ‘Type’ are the roles. The class ‘Level’ is specialized into four subclasses ‘Business Req’, ‘User Req’, ‘System Req’, and ‘Design Req’ that correspond, respectively, to the business, user, system, and DRs (RML Metadata 9.1). Each of the three-ordered pairs of these subclasses is related by the association ‘Derived from’. The class ‘Type’ represents the ‘Functional’, ‘Non-functional’ and ‘Data’ types (RML Metadata 9.2) represented by the ‘F-Req’, ‘Non-F-Req’, and ‘Data-Req’ classes. The two first former classes are related by the association ‘Correspond’.

The repository is structured into three layers: the first layer contains the families of software products (Class ‘Family’), such as accounting and human resources management. The second layer includes the potential catalogs (Class ‘Catalog’) of reusable requirements within a given family of software products. A catalog groups a set of related components (Class ‘Component’) that correspond to the function of an application domain. Examples of such functions in the human resources management domain could be ‘Hiring’ and ‘Promotion’. The third layer includes the components. A component encompasses a hierarchy of functional RKs (Association ‘Has root’), their alternatives, and their eventual corresponding RKs of type ‘Non Functional Requirement’, along with their associated KRs. It is the application of this organization to all reusable requirements that positions such requirements as valuable assets in full alignment with the strategic goals of the organization.

3.4 Analysis for reuse process

The repository should not be considered a final fixed product, but an evolutionary one to be enriched (Toval et al., Reference Toval, Nicols, Moros and Garca2008). Hence, we should first discover those sources that are relevant for capitalizing new relevant reusable requirements. Among the potential sources, we might identify the following two:

1. 1. Current/past software projects: they might be selected and extracted from software requirements specification of current or past software projects because of their high reusability and quality. These candidates need quality improvement, and more likely neutralization (to hide some specific names or confidential content) and parameterization (to make them more reusable).

2. 2. Other repositories: they might be imported from other existing repositories or catalogs. Naturally, the rules of reuse rights should be respected.

Finally, we mentioned that reusable requirements might also be built, especially for reuse purposes. This could be triggered, for example, by a manager’s decision in order to cover certain voids or the absence of such requirements in the repository.

Naturally, we mentioned that it is not necessary to complete KRs for all candidate requirements before the preprocessing step. Instead, only partial information is required. A requirements engineer or any other actor responsible for the AFR process could complete only some pertinent metadata from RML that reflect his/her search goals and whose data are available. Such metadata could be mainly combined from the most important embedded data elements of the categories ‘Requirements specific’ and ‘Taxonomy’ described in Section 3.b. A query example could retrieve SRs (RML Metadata 9.1) that are functional (RML Metadata 9.2) and represented in some style, such as use case diagrams (RML Metadata 5.1). The other RML categories and embedded data elements could be used simply for refining results in case their number is very important.

A candidate RK undergoes the three steps described below. These macro-steps are repeated for each candidate RK (RK _x ) to be capitalized.

1. 1. Preprocessing: aimed at checking RK _x (a candidate RK) according to the following algorithm:

This algorithm is based on the following Boolean functions:

1. i. Sem-Simil: automatic similarity computation between RK _x and RK _y based on their respective KRs to indicate their semantic overlap. We assume that both KRs for RK _x and RK _y have the same representation structure. When we compare these KRs, we must consider the metadata language, type of metadata, metadata values, and how we can access them all. When we match KR of RK _x with KR of RK _y , it is not efficient to use all metadata from RML because the process of doing so is difficult and hard to maintain, especially in a repository that contains thousands of requirements.

   We adopt the metric proposed in Menndez-Domnguez et al. (Reference Menndez-Domnguez, Zapata, Prieto-Mendez, Romero and Serrano-Guerrero2011), which we adapt to serve our purposes with regard to the RE context. The formula then calculates the similarity degree (Sim) between requirements (RK _x , RK _y ) and considers the similarity average (simMeta) of the value (v) of the metadata within a RE context (C):

   $$Sim(RK_{x} ,RK_{y} ){\,\equals\,}{{\mathop{\sum}\nolimits_{i{\equals}1}^n simMeta(vx_{i} ,vy_{i} )C_{i} } \over n}$$
   where n is the number of metadata pieces to compare, simMeta(vx _i , vy _i ) the semantic distance between value v of metadata i for RK _x and RK _y .
   $$SimMeta\in[0,1].$$
   C _i is the relevance of metadata i in a particular C context. $$Ci\in[0,1]$$ .

2. ii. Alternative: empirical assessment of the condition about alternatives by a requirements engineer expert. This function aims to check whether RK _x could be considered an alternative to RK _y . Otherwise, its content is used to manually improve RK _y ’s content.

1. 2. Capitalization: aimed at capitalizing a candidate RK according to the decision made in the previous step, either: as a new distinct RK; as a new alternative to an existing RK; or by using it to improve the existing RK’s content.

2. 3. Qualification: aimed at qualifying the new capitalized RK with KR using RML metadata, or editing the existing KR.

Thus, all RKs are maintained in the repository, which increases continuously, thus requiring management efforts. Such management is mainly concerned with performance optimization that must be conducted periodically because analysts require that change according to the demand in software projects. On the other hand, repository evolution is concerned with maintaining the repository content up-to-date with respect to the strategic goals defined by the repository managers. Hence, statistics reports related to the use of RKs are produced in order to support them.

3.5 Case study

This case study is related to the capitalization of reusable requirements from an existing requirements documentation of virtual successful hotel management software. It aims to illustrate the first two steps of the AFR process for capitalizing reusable requirements from the ‘Make reservation’ use case. Table 3 describes the exchange of information between the three involved roles (the customer who initiates the process and the existing software). Table 4 describes a part of the functional SRs derived by requirements engineers from the three first steps of the previous use case. Table 5 describes part of the non-functional SRs derived by requirements engineers from the previous use case.

Table 3

A textual description of the functional user requirements (make reservation use case)

Table 4

A textual description of the functional system requirements

Table 5

A textual description of the non-functional system requirements

We now apply the AFR process for capitalizing reusable requirements from Tables 3, 4, and 5. We suppose that (1) we have initially selected the virtual successful hotel management software project as a potential source for capitalizing reusable requirements; (2) only those requirements related to the ‘Make reservation’ use case were selected as the more relevant reusable requirements. Only the two main macro-steps of the process, namely, the capitalization and qualification steps repeated for each candidate RK to be capitalized, are described below.

1. 1. Capitalization: in this example, we assume that no previous RK exists in the repository that belongs to the family of product ‘Hotel reservation systems’. Accordingly, we assume that we determined during the previous step (preprocessing) to capitalize all candidate RKs, URs (Table 3), and SRs (Tables 4 and 5) considered as new distinct RKs. Table 6 indicates how these RKs were capitalized within the repository according to the conceptual requirement reuse model presented in Figure 2. The first colon ‘ID’ of Table 6 shows the RK identifier within the repository. The second colon ‘No’ shows the original identifier within the existing source documentation. This helps manage the traceability between RK and its source. The third colon gives a short textual description stored in the description attribute of the class ‘RK’. The fourth colon ‘P’ contains the parent of the RK. Indeed, all the functional SRs of this case study form one hierarchy with rk1 (that corresponds to the use case UC1) as root. The fifth colon ‘D’ shows the RK of the upper level from which the current RK is derived. The sixth colon ‘A’ shows the RK for which the current RK is an alternative.

2. 2. Qualification: aimed at qualifying the previous RK in Table 6 with the KR that uses RML metadata. For clarity, Table 7 presents only the qualification of the part of this RK related to the functional SRs. We use a subset of RML metadata composed of the following metadata: 1.1. Identifier, 1.4. Structure, 5.1. Style, 5.5. Commonality, 5.8. Importance, 5.11. Fit criterion, 9.1. Req. level, and 9.2. Req. type.

Figure 2

Requirements Repository Framework architecture. RML=Requirements Metadata Language; RK=reusable knowledge; KR=knowledge of reuse

Table 6

Capitalization of the candidate reusable knowledges (Tables 3, 4 and 5)

Table 7

Qualification of some reusable knowledges using a subset of Requirements Metadata Language metadata

1.1.=identifier; 1.4.=structure (1: Atomic, >1: Composite); 5.1.=style (SP=Screens and Prototypes; DFD=Data flow diagrams; AD=Activity diagrams); 5.6.=commonality (C=Common; O=Optional); 5.9.=importance (H=High; M=Medium; L=Low); 5.12.=fit criterion; 9.1.=Req. level (BR=business requirements; UR=user requirement; SR=system requirement; DR=design requirement); 9.2.=Req. type (FR=functional requirement; NFR=non-functional requirement).

We find from our practice during the capitalization step that most of the candidate RKs are from the UR level. This can be explained by the specificities of those from the SR level that make their reusability low. Indeed, URs are at a high level, thus giving a less detailed specification. As a result, there might be several SRs at a low level that give more detailed specifications for more or less of the same UR.

4 Analysis for reuse support framework

The AFR process is complex and requires a substantial supporting framework of services if it is to transform the experience of RE. Frameworks for different phases of RE are available, such as frameworks for requirements analysis, elicitation, traceability, and reuse. The authors in Husnain et al. (Reference Husnain, Waseem and Ghayyur2009) reviewed frameworks for the different SRE phases. This review was performed according to a conceptual framework that encompasses the (1) problem statement, (2) domain, (3) proposed solution, (4) phases discussed, (5) phases not discussed, and (6) reusability. We emphasize that the adoption of reuse is still extremely limited in real projects, whereas the need for solutions that reduce software analysis efforts is increasing. This gap is more likely due to a lack of commercial AFR tools.

Our proposed system R2F (Requirements Repository Framework) supports the AFR process presented in Section 3.d, and it is intended to be used mainly by requirements engineers and managers. R2F provides guidance and support to requirements engineers when they want to capitalize new RKs and to managers when they want to manage the requirements repository. The architecture shown in Figure 2 indicates the framework built around the four modules described below. The first three modules are mainly used by the requirements engineer when the fourth is used by the manager.

1. 1. Preprocessor: aimed at supporting step 1 of the AFR process. Techniques from information retrieval are used where similarities between RKs are calculated to indicate the semantic overlap between RKs.

2. 2. Capitalizer: aimed at supporting step 2 of the AFR process. It allows also editing an existing RK. This module is clearly necessary for the framework to support the creation of a new RK from an existing requirement. New RKs can also be built by aggregation of lower RKs of the same type and level. The creation and editing process might also need to be aware of the constraints imposed on RKs. Although constraints restrict possible RKs, there is a separate requirement for providing alternatives to an existing RK, thus acting as other variants. In addition to editing the text description part of RK, such as ‘The system should/shall store data according to the following data model’, it is also necessary to incorporate the content part of RK, such as the entity relationship diagram. This content tends to be created and managed separately from the RK instance, and then needs to be associated to it as shown in Figure 1.

3. 3. Annotator: aimed at supporting step 3 of the AFR process. It exploits the RML metadata in order to annotate RKs within the repository, create new KRs, and edit existing KRs. Semantic annotation adds diversity and richness to the search process and helps resolve the ambiguity of the natural language when translating notions into a formal computational language. By qualifying RKs using RML metadata, it is possible to process complex filters and search operations.

4. 4. Manager: aimed at supporting the management process. It mainly considers storage, change management, and traceability of RKs from the repository, in addition to maintenance issues related to the repository. RKs are indexed within the repository using KRs. An index database is then generated. In addition, different useful statistics are provided for the repository, thus allowing its optimization and reorganization. The manager module also allows its users to filter the repository content. Indeed, the combination of (1) types: ‘Functional’, ‘Non-functional’, and ‘Data’; (2) levels: ‘Business’, ‘User’, ‘System’, and ‘Design’; and (3) styles: such as use case diagrams and DFDs (data flow diagrams), is very expressive and permits a tremendous amount of flexibility for extracting a set of desired RKs. For example, a user might be interested in extracting functional SRs using DFDs.

Figure 3 shows a screenshot of the preprocessor module of R2F for checking the similarity of the candidate RK (RK-HM-RE-034), related to the hotel reservation system, with existing RKs from the repository. We can see the highest resulting similarity rate (0.17) with an existing RK (RK-SA-PO-181) from the catalog ‘Purchase Order’ of the product family ‘Sales management systems’. Because of this low value the recommended decision was to insert RK-HM-RE-034 in the repository as a new distinct RK.

Figure 3

Screenshot of the preprocessor module of Requirements Repository Framework

Figure 4 shows a screenshot of the capitalizer module of R2F for editing an existing RK (RK-HM-RE-034). The screen displays the selected RK identifier (left top corner) as well as its corresponding text. Also the user has a set of gray buttons on the left which allow him to browse, edit, save, print, delete, and export the RK content. Finally the ‘Qualify’ button (left bottom corner) allows to switch to the qualification task using RML metadata (Figure 5).

Figure 4

Screenshot of the capitalizer module of Requirements Repository Framework

Figure 5

Screenshot of the annotator module of Requirements Repository Framework. RML=Requirements Metadata Language

Figure 5 shows a screenshot of the annotator module of R2F for qualifying editing the previous RK (RK-HM-RE-034) using the ‘Requirements specific’ category of RML. The screen displays first the RK identifier as well as its corresponding text. The left panel displays the nine metadata categories of RML. The central part contains the form used to edit the metadata related to the active category ‘Requirements specific’. We remark that all the values have been selected from predefined set of values as explained in the RML base schema (Table 2) except for the value for the fit criterion metadata which has been directly entered by the user. Also the user has a set of gray buttons on the bottom that allow him to edit, save, erase, print, and export the displayed metadata (KR).

5 Experimentation

In order to validate our framework, we opted to conduct a live-user experiment. Therefore, we developed a first prototype of R2F as a Windows application using VB within the .NET visual studio framework.

We started using the R2F prototype locally at the experimental level with our IS240 (Information Systems Analysis and Design) students and our senior project students. Here, we present the results of the experiment with three second-level student sections (composed of 25 students each), that used R2F in their IS240 (Information Systems Analysis and Design) course project; as well as with four Information Systems student groups (composed of three students each), that used R2F in their respective senior projects. The objective of this experiment was to measure the usability of the proposed AFR process. This helped us to examine, through direct observation and survey, the users’ feedback with regard to R2F use.

The students used R2F to capitalize some existing RKs in the field of Information Systems. Two families of products were explored: SA (sales management systems) and HR (human resource systems). The projects used for extracting RKs were developed by TGI (Technology Group International), an ERP (Enterprise Resource Planning) vendor that specializes in the development, sale, implementation, and support of their fully integrated ERP system for small and mid-market manufacturing and distribution companies (http://www.tgiltd.com/erp-vendor-tgi). More than 1000 RKs were capitalized for each of the two families of products. Table 8 demonstrates an extract of these RKs, where only three requirements were selected from each catalog within a family of products.

Table 8

Extract of the capitalized reusable knowledges (RKs) for experimenting Requirements Repository Framework

SA=sales management systems; HR=human resource systems.

The experimentation was performed in three steps: (1) ask senior project students (12) to use R2F in their senior projects and directly observe them; (2) ask IS240 students (74) to use R2F in their course projects and conduct a survey on them; and (3) analyze the results of the direct feedback from the senior project students on one hand and the indirect feedback from the IS240 students on the other hand. Qualitative data were collected in two different means: direct participant observation and survey.

1. 1. Direct observation: we participated with the four student groups in:

1. i. Manually selecting and extracting RKs from the TGI documentation for both families of products (HR) and (SA). At the start of our experiment, because no previous RK that belongs to the two families of products existed in the repository, all the selected RKs were found by the R2F preprocessor module as distinct RKs.

2. ii. Automatically capitalizing some of these RKs according to the conceptual requirement reuse model.

3. iii. Qualifying those RKs using some RML metadata (KR).

Finally, in order to check the preprocessor module, a set of alternatives and some very similar RKs were created for some already capitalized RKs.

This initial experiment allowed us to assist the students in learning how to use the prototype. The experiment showed how easy and intuitive is R2F. In addition, the experiment mainly allowed us to improve the graphical interface of R2F, thus making it more intuitive. We note that 66.66% of students (8 out of 12) succeeded in using R2F without any assistance.

1. 2. Survey: we used a Likert scale (Runeson & Hst, Reference Runeson and Hst2009) from 1 (strongly disagree) to 5 (strongly agree) to characterize the users’ answers.

Table 9 lists the eight asked questions selected for analyzing the following hypothesis: R2F is easy to use. As indicated in Figure 6, the mean values for the eight questions of the questionnaire are between 2.64 and 4.58. Seven mean values are superior to 3 (neutral answer) suggesting R2F users’ attitudes to be very positive. Only the mean value (2.64) for question 7 is less than 3. This guides us to improve the manager module.

Figure 6

Mean Likert scale values of the eight questions

Table 9

Requirements Repository Framework questionnaire

RK=reusable knowledge; RML=Requirements Metadata Language.