The Requirements Engineering Magazine appears quarterly. It is cost free and provides you with up-to-date articles reflecting the activities of the RE and BA community.
Simply sign up for being notified about new issues of the Requirements Engineering Magazine.
You may unregister at any time by sending a mail to email@example.com from the e-mail address which you have registered with.
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.
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.
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.
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|
Classification in Schemas
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.
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.
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.
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 (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.
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.
We are aware of several factors that may compromise this success, remarkably:
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.
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: