Cristina Palomares Carme Quer Xavier Franch

Requirements Reuse

Requirements Reuse with the PABRE Framework

In this paper we present the Pattern-Based Requirements Elicitation (PABRE) framework, which proposes the use of Software Requirement Patterns (SRP) as a means to capture and reuse requirements knowledge in the context of IT procurement projects. The paper also presents the first results of a survey we are conducting and that has as goal to know the state of the practice on the topic, hoping to encourage the reader to participate in it.

Introduction

The final quality of software products and services depends on the requirements stated in the Software Requirements Specification (SRS). However, some problems have been reported in the writing of SRS, e.g. ambiguity, incompleteness and inconsistency ^[Swi13], especially when natural language is used.
Requirements reuse has been proposed as a key asset for requirement engineers to efficiently elicit, validate and document software requirements and as a consequence, obtain SRS of better quality through more effective engineering processes.

Requirements reuse, its success factors, barriers, and suitable processes around it are attracting the interest of IT practitioners and researchers due to its potential benefits. Latest releases of requirement management tools are including requirements reuse as part of their functionality ^{[DOORS, JAMA, P&PM, ViReq]}; researchers are increasingly investigating the state of the practice in the field by conducting surveys ^{[Che12, HJH+13, PFQ13a]} or organizing workshops ^[RePa13]; very recent textbooks include software reuse in their topics ^[WiB13]; and social media like LinkedIn are witnessing the creation of groups dedicated to the topic.

One of the possible techniques to achieve reuse is the adoption of patterns. In their most classical form, patterns describe problems that occur over and over again, and then describe the core of the solution to these problems. Software engineering practitioners have adopted the notion of pattern in several contexts, in particular related to software design (e.g., design patterns and software architectural patterns), but also in other software development phases, both earlier and later. Following this strategy, Software Requirement Patterns (SRP) ^[Wit07] emerge as a natural way to reuse knowledge during the Requirements Engineering stage.

In this paper we present an overview of the PABRE framework ^[RMFQ09], which proposes the use of SRP as a means to capture and reuse requirements knowledge in the context of IT procurement projects. The framework embraces a metamodel of SRP, the method or process of reuse through SRP, a catalogue of 111 SRP, and a software system that supports the management and use of the catalogue. The paper also presents the first results of a survey we are conducting and that has as a goal to know the state of the practice on the topic, hoping to encourage the reader to participate in it.

The PABRE Framework

We introduce the PABRE framework adopting as a guide the dimensions of requirements reuse defined in ^[WiB13]: the extent of reuse or material that is reused, in our case the SRP; the extent of modifications that are allowed to make on an SRP to apply it in a reuse process; and the reuse mechanism.

Extent of Reuse

An SRP is a set of requirements that pursue the same goal in a system to be developed, and where all specific elements of a certain project have been eliminated and converted into templates. Aside from these templates, the SRP has other attributes to guide the application of the pattern. The extent of reuse in our framework can be from individual SRP, or in fact from parts of a SRP, to sets of SRP that address the same software domain, functionality, standard regulation, etc. The sets of requirements that may be jointly reused are established by the classification of SRP in a catalogue. In order to accept an SRP in the catalogue, the quality of requirement specifications that will be obtained in applying it has to be analyzed. Thus, the writing style, consistency and dependencies among SRP are analyzed in order to avoid poor requirements generated from the patterns.

To facilitate the understanding of the structure and use of SRP, we present them through an example, the User Capacity pattern (see Figure 1), that illustrates the structure of patterns, their attributes and relationships allowed among them ^[FPQ+10].

An SRP is a pattern that, when applied, produces software requirements related to the objective (goal) of that pattern. Applying the User Capacity SRP we may produce requirements related to the goal of Supporting a required number of users in the system under development. Goals correspond to problems to be solved by applying the SRP.

A goal can be achieved in different ways. An SRP consists of several Forms, each one representing a different solution for achieving the goal. In our example SRP, its goal can be attained by defining the user capacity depending on the user profiles (User Capacity by Profile form), or by defining the global capacity of users, i.e. without taking into account the different types of users in the system (Global User Capacity form).

We organize Forms into Parts, each of them being a phrase template: a Fixed Part always applied if the form is chosen and some Extended Parts which may be applied or not. Extended parts are only used if more precise requirements are required in the specification. For instance, in our example, the fixed part of the first Form is The system shall be able to support %usersNumber% users (usersNumber will be substituted in applying the SRP by “any number of” or by an integer greater than 0). The extended parts allow to specify the growth in number of users of the system. The first one states the growth by amount: The system shall allow a growth of a minimum of %usersNumber1% users (usersNumber1 will be substituted in applying the part by an integer greater than 0); whilst the second one states the growth by percentage: The system shall allow a growth of %volPercentage% on the number of users (volPercentage will be substituted in applying the part by an integer greater than 0).

Both fixed and extended parts are similar from a syntactic point of view. They are composed by a phrase template, i.e. the text to be used as a requirement and, if necessary, some optional Parameters to be instantiated when applying the pattern, e.g. usersNumber in the example above. Parameters have established their Metric, and eventually a correctness condition Inv (see these on the bottom of Figure 1) to define the values they may take.

Usually, fixed and extended parts must conform to some Restrictions for declaring multiplicities or dependencies among parts. In the User Capacity SRP, aside from restrictions on the possible number of appearances of each part in a specific SRS, there exist restrictions on the parameters’ values in each application. For instance, in the second form of the example, the fixed part can be applied more than once in an SRS as long as the values assigned to the parameter userProfile are different. This allows to state restrictions on the user capacity of the system for different types of profiles, such as Administrator or End-User.

SRP: User Capacity Goal: Supporting a required number of users in the system
Does the customer require different capacities depending on the profiles of the users?

	Global User Capacity Form	User Capacity by Profile Form
SRP Parts	Fixed: The system shall be able to support usersNumber users. Extended 1: The system shall allow a growth of a minimum of usersNumber1 users. Extended 2: The system shall allow a growth of volPercentage on the number of users.	Fixed: The system shall be able to support usersNumber users of the userProfile profile. Extended 1: The system shall allow a growth of a minimum of usersNumber1 users of the userProfile profile. Extended 2: The system shall allow a growth of volPercentage on the number of users of the userProfile profile.
Restrictions	Fixed, Extended 1, Extended 2 parts cannot be applied more than once. Extended 1 and Extended 2 cannot be applied together.	Fixed, Extended 1, Extended 2 parts can be applied more than once if they are applied with disjoint values of userProfile. Extended 1 and Extended 2 cannot be applied together for the same value of userProfile. Extended 1 and Extended 2 applications should use the same userProfile as the ones used in Fixed applications. Soft Restriction. Fixed applications should use the same userProfile as the ones used in applications of the following SRP: Authorization, Interface Learnability, Help Desk, Online Help.

Parameters Metrics usersNumber: “any number of” / integer inv: integer > 0 usersNumber1:  integer  inv: integer > 0 volPercentage: integer inv: integer > 0 userProfile: domain {Administrator, Author, Editor, End-user....}

Dependences User Capacity may imply Concurrent User Capacity Authorization may contribute to User Capacity

Classification in Schemas ISO/IEC 2501 (NF and NT) -> Performance Efficiency -> Resource Utilization ISO/IEC 9126-1 (NF and NT) -> Non-Functional -> Efficiency -> Resource Utilization

There is also another type of soft restriction that allows giving recommendations to maintain the consistency of the SRS. One example of such a restriction is using the same values for the userProfile in each application of SRP parts that uses this parameter (not only those ones of the example SRP, but also in its appearance in other SRPs such as Authorization and Online Help).

There exist dependencies among SRP in the same way as they exist among requirements. The example SRP is involved in two dependence relationships: the first one with the Concurrent User Capacity SRP, as there is a clear relationship among the number of users to support and the number of concurrent users to support; the second one with the Authorization SRP (provided the User Capacity per Profile form of the example SRP is used), since it allows defining the user roles of the system to develop.

SRPs are classified using Schemas, which are hierarchies of classifiers that facilitate the organization of SRP. It is possible to classify SRP following several schemas. The SRP in Figure 1 is classified according to two different classification schemas: ISO/IEC 25010 and its previous version ISO/IEC 9126-1. This classification makes the use of the catalogue easier according to both standard versions. These schemas also allow joining, in one classifier, SRP that may be applied as a group, and that address a same functionality or describe the same regulation required in the new system. In Figure 2, we see the classification of the User Capacity SRP in the ISO/IEC 25010 standard.

Extent of Modification and Reuse Mechanism

In our framework it is difficult to separate the extent of modification and reuse mechanism. For this reason we include both in this section by describing the two steps in which reuse is implemented: browsing the SRP catalogue and applying the selected SRP. We will illustrate these steps focusing on the use of the User Capacity SRP introduced in the previous section under an ISO/IEC 25010-based classification. See the description of scenario C of figure 3 below for understanding the extent of modification of SRP.

A. Browsing the SRP Catalogue

The aim of this step is to identify SRP that may be adequate for the Customer needs. In our example, the Requirements Analyst (RA) may conduct this identification in different ways.

First, the Customer may explain that s/he is interested in a requirement with a similar goal to the one of the example SRP, which is Supporting a required number of users in the system. In this case the RA will search in the catalogue the most suitable SRP.

Second, the RA may propose the SRP to the Customer because s/he considers that may be relevant to the project; this may be inferred because a requirement related to this proposed SRP was already applied. There are two types of relationships in the PABRE catalogue: dependence relationships and classification relationships. As an example of the use of dependence relationships (see Figure 1), if the User Capacity per Profile form of the SRP is chosen, the RA will propose to the Customer the application of the Authorization SRP that allows defining the roles that the system to develop has to have. Taking into account the classification relationships (see Figure 2), the RA may propose the application of the Data Capacity SRP, since both patterns are classified under the same subcategory of the classification schema. It is worth remarking that in both cases, the SRP goal is the key knowledge asset to decide the adequacy of an SRP pattern in the given project.

B. Apply SRP

Assuming that the customer is interested in achieving the goal of the User Capacity SRP, the following tasks show the scenario of application of this SRP in order to derive the appropriate requirements (see scenario M in Figure 3).

1. Choose Form to Apply. In case the Customer is interested in the goal of an SRP, the RA explains the different forms to achieve it. In our SRP example there are two forms (Figure 1) depending on whether the Customer needs different capacities according to the types of user profiles, or s/he is just interested in stating the global user capacity of the system. It may happen that the Customer is not interested in any of the proposed solutions, for instance in our example s/he could be interested in stating the user capacity for each one of the platforms of the system (alternative scenario A in Figure 3).

2. Choose Parts to Apply. Assuming that the Customer chooses an existing form, the RA enumerates the requirements that would derive from the SRP parts of that form. In the example SRP, assuming the form to state user capacity by profile is selected (right form of Figure 1), its requirements allow the RA to state the user capacity and its growth (either by amount or by percentage) for different types of user profiles. It may happen that the SRP is not comprehensive enough and that the Customer wants to state other aspects related to the supported user capacity not present in the SRP form, for instance stating the growth of supported users only when certain conditions are met. In that case new requirements related to the SRP form will be defined (alternative scenario B in Figure 3).

3. State Parameter Values. Assuming that the Customer chooses one form and one or more parts of an SRP to apply, the parameters in those parts must be filled (marked in bold and italics in the SRP parts of Figure 1). In our example, the Customer may be interested in supporting 5,000 End-Users and 5 Administrators, and allowing a growth of a minimum of 15 administrators, so the fixed and the first extended parts of the SRP form need to be applied (see scenario M). It may happen that the Customer does not like the concrete writing of some part. In that case, it can be changed during its application (alternative scenario C of Figure 3, where the customer prefers to state that the growth should be of “at least” some quantity rather than “a minimum of” a quantity).

The PABRE System

The PABRE System (see Figures 4 and 5) is the technological support of the PABRE framework, helping requirements analysts and requirements engineering experts to use, maintain and evolve the SRP catalogue. It is composed of three subsystems: PABRE-Man, PABRE-Proj and PABRE-WS.

RA may use the SRP Catalogue through the PABRE-Proj tool, or he/she could use it through his/her own Requirement Management Tools (RMT) if this RMT had an implemented access to the catalogue by using the web services of PABRE-WS (Figure 4).

PABRE-Proj’s goal is to facilitate the definition of the requirements for a particular IT project. During the requirements elicitation of a specific project, the tool helps RA in the browsing of the SRP catalogue and application of the SRP. Once the elicitation process finishes, the tool also allows the generation of the SRS document, as well as a Call-for-Tenders (CFT) document to be sent to potential providers. This CFT document can be generated thanks to the Question assigned to each part of an SRP. This question is an SRP attribute not described in the previous section for space reasons, which asks the system provider about the possibility of provision of some aspect of the system to be developed. When an SRP part is applied the corresponding question will be added to the CFT. Also, a report with the SRP usage data can be generated, together with other data on defined requirements that can be used in the evolution of the catalogue.

PABRE-WS is an API of web services that provides access to the SRP catalogue. The idea is to allow existent RMTs in the market to access the catalogue and to use patterns in their own way during requirements elicitation and documentation.

Finally, Requirements Engineering Experts may use PABRE-Man as the SRP management tool (Figure 5). Its goal is to facilitate the evolution of the SRP catalogue. With this tool, RE experts can add new SRP, analyze the SRP usage data provided by PABRE-Proj to evolve the catalogue, and maintain the classification schemas used to organize the SRP. As a way to support the work of the experts that define or edit SRP we currently provide a thesaurus that proposes changes in terminology that improve the wording and the consistency among SRP.

Benefits and Success Factors of SRP

The current PABRE SRP catalogue has 111 patterns. They were obtained and validated in collaboration with IT professionals from the SSI department at the Public Research Centre Henri Tudor (TUDOR) in Luxembourg, who provided raw data (i.e., SRS from call-for-tender projects) and expert assessment. However, we would like in the future to construct and validate the framework in other contexts and organizations. Here we state the potential benefits and the factors that we think influence the success of an application of PABRE SRP, and that we plan to validate in the future in collaboration with interested organizations.

• Less time required in the elicitation of recurrent requirements (requirements for different projects addressing the same domain, requirements addressing functionalities shared by different products, requirements addressing certain regulations, etc.). Consequently, analysts have more time available for the definition of creative requirements (requirements that may change the typical behavior of organizations and that provide them an added value).
• Improved quality of requirement specifications (consistency, non-ambiguity, completeness, etc.), thanks to the uniformity of SRP, the dependencies and relationships defined among them and the checklist character that the catalogue may take.
• Improved requirements management (e.g., clear traceability from requirements to goals).
• Tool support that offers an infrastructure that facilitates the classification, browsing and search of SRP and the guidance during an elicitation process.

We are aware of several factors that may compromise this success, remarkably:

• The cost of maintenance of the SRP catalogue. The return of investment in this maintenance has to be defined and validated, since it could be used as a way to convince IT CEOs to invest in it.
• The integration of the reuse method in the requirement engineering processes of organizations.
• The willingness of requirement engineers to apply the reuse and adapt their processes to them.
• The context of use of an SRP catalogue. This factor is a challenge in case the SRP are constructed and maintained by a different team than the one using it, or in a different organization. The success would depend on agreed terminology, etc.
• Their impact in innovation. SRP are based on reusing consolidated knowledge, therefore analysts may rely too much on them, hindering the elicitation of innovative requirements. The right balance is therefore needed.
• The existence of tool support for the evolution and maintenance of the SRP catalogue. It is important to provide tools to support the analysis of SRS to help in the evolution of the SRP catalogue and to help in the maintenance of its quality.

Survey

As researchers in the topic of requirements reuse in general, and SRP in particular, we need to know the state of the practice and problems that exist in industry to take them up as challenges for our research. One common way to achieve this knowledge is through surveys. Surveys are a way to elicit the needs of a wide population of practitioners and to know if the solutions that we are proposing are suitable from their point of view. This is what we are doing with the survey we are conducting about requirements reuse and patterns ^[PFQ13b], which is implemented as an online questionnaire.

The value of this survey depends on the number of answers being large enough to allow statistical analysis. We strongly believe that the IREB community is a key asset in attaining this objective; therefore, we facilitate in this paper the opportunity of participating in the survey (Figure 6) ^[PFQ13b]. It will be open until mid-2014. Also a report of results will be kept updated in the survey web page (http://www.upc.edu/gessi/PABRE/Survey.html), and final results will be sent to the participants that provide their e-mail address at finishing the questionnaire (this is optional).

Help us answering the PABRE Online Survey

At the time of writing this paper, we have 50 responses from practitioners and researchers with industrial experience, from 19 countries around the world (mostly from North America and Europe). From them, 27 (54%) were requirement engineers in industry, 10 (20%) researchers with significant experience as requirement engineers, and 13 (26%) researchers with some limited experience as requirement engineers.

Regarding the level of requirements reuse that participants stated in their projects, 38 participants (76%) stated the level as equal or greater than Low. However, reuse seems not to be an established practice in IT projects, since only 22% marked it as equal or greater than High.

The most common techniques used to implement requirements reuse seem to be those based on the Copy & paste with posterior modification of requirements coming from previous projects (more than 50% of the participants use them). Less common techniques seem to be the Fill in of predefined templates and the Use of a requirement patterns catalogue, this last technique being the least used (only 13% of the participants).

Concerning our specific research subject, that is SRP, the success factors for the introduction of a SRP catalogue that are stated as most common are: Having a well-defined use process, Having tool support and The existence of a ready-to-use SRP catalogue. The highest rated barriers are: The resistance of requirements engineers to change, The integration of the catalogue with the existing requirements engineering process, and The lack of the SRP catalogue management support.

Other surveys on the topic have been recently conducted [^Che12, ^HJH+13]. The first one addressed requirements reuse in general and was conducted also online in 2010. 59% of participants answered that they reused requirements in their latest projects. The second one addressed reuse through patterns, and was conducted through interviews with five requirements analysts. In this case our survey will obtain more results, although the problem introduced for the fact of being online can introduce some noise.

Conclusions and Future Work

In this paper we have presented the PABRE framework for reusing requirements knowledge following a pattern-based approach. The core components of the PABRE framework have been introduced: SRP, the processes supported, and the system to support both these SRPs and these processes (the PABRE system). The main benefits and factors that influence in the success of the PABRE SRP application have been highlighted. Finally, we have presented the preliminary results of a survey to study the state of the practice on requirements reuse, and on the possible advantages and success factors of using SRP as a reuse artifact.

The current SRP catalogue and the PABRE system are available under a specific Creative Commons license that allows its use in a non-commercial way (e.g. for research and experimentation purpose) but without derivative works. Some possible scenarios of collaboration with organizations may be found in the PABRE web page.

Future work spreads over several dimensions:

• Adoption of clear rules and best practices for writing SRP templates (see e.g. EARS ^[Ma09]).
• Extension of the SRP catalogue with functional patterns from other domains (e.g. ERP and CRM).
• Improving capabilities of the PABRE system, mainly by: adding new functionalities for searching into the SRP catalogue; improving the SRP recommendation system (e.g., by introducing recommendation capabilities such as “projects that used this pattern usually use this other” or “maybe you could use this pattern to write this requirement”); adding new functionalities for the analysis of the SRP usage data and the evolution of the catalogue.
• Extension of the study behind the preliminary survey results presented in this paper, by gathering more responses, and conducting correlation analysis and cluster analysis of responses, considering also other general questions included in the questionnaire.
• More validation of the framework. We have so far conducted postmortem analyses of the SRS coming from past projects to validate that the PABRE SRP structure covers the features expressed in those SRS and the coverage of the SRP catalogue was satisfactory. Still, we need to apply it to real cases in an action-research basis.

References

• [Che12] Chernak, Y.: Requirements Reuse: The State of the Practice. In: Software Science, Technology and Engineering (SWSTE). IEEE CS Press, 2012.
• [DOORS] IBM Rational DOORS Tool. http://www-03.ibm.com/software/products/en/ratidoor/
• [FPQ+10] Franch,X., Palomares,C., Quer,C., Renault,S., De Lazzer,F. A Metamodel for Software Requirement Patterns.17th International Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ), 2010.
• [FQR+12] Franch,X., Quer,C., Renault,S., Guerlain,C., Palomares,C. Constructing and Using Software Requirements Patterns. Managing Requirements Knowledge.Eds: WalidMaalej and Anil Kumar Thurimella, Springer, 2012.
• [HJH+13] Hoffmann, A., Janzen, A., Hoffmann, H., Leimeister, J.M.: Success Factors for Requirement Patterns Approaches. In: Sozio-technisches Systemdesign im Zeitalter des Ubiquitous Computing (SUBICO) im Rahmen der Informatik, 2013.
• [JAMA] JAMA Software Tool. http://www.jamasoftware.com/
• [Ma09] Mavin A, Wilkinson P, Harwood A, Novak M: Easy approach to requirements syntax (EARS). In: IEEE international symposium on requirements engineering (RE), 2009.
• [PFQ13a] Palomares,C., Franch,X.,Quer,C.: Using a Pattern Catalogue in Requirements Engineering Activities. Online questionnaire presented at Int. Work. Conf. on Requirements Engineering: Foundation for Software Quality (REFSQ), 2013.
• [PFQ13b] Palomares,C., Franch,X., Quer,C.: Access Online Survey about Requirements Reuse and Patterns (open until half-2014). http://www.upc.edu/gessi/PABRE/Survey.html
• [PQF+12] Palomares,C., Quer,C., Franch,X., Guerlain,C., Renault,S. A Catalogue of Non-Technical Requirement Patterns, Second International Workshop on Requirements Patterns (RePa), 2012.
• [PQF13] Palomares, C., Quer,C., Franch,X. PABRE-Proj: Applying Patterns in Requirements Elicitation. Tool Demo presented at 20th IEEE International Requirements Engineering Conference (RE), 2013.
• [P&PM] P&PM Solutions Tool. http://www.p-and-pm.com
• [RMFQ09] Renault,S., Mendez,O., Franch,X., Quer,C. A Pattern-based Method for building Requirements Documents in Call-for-tender Processes. Intl. Journal of Computer Science & Applications (IJCSA), 6(5), 2009.
• [RePa13] International Workshop on Requirement Patterns (RePa), 2013.
• [Swi13] Swiss Requirements Engineering Trends & Benchmarks Report 2013. http://www.swissq.it/
• [ViReq] Visure Requirements Tool. http://www.visuresolutions.com/requirements-engineering-tool
• [WiB13] Wiegers,K., Beatty, J. Software Requirements, 3rd Edition. Microsoft Pr., August 2013.
• [Wit07] Withall, J. (2007). Software Requirements Patterns. Microsoft Press.