A Metamodel for Software Requirement Patterns - Semantic Scholar

A Metamodel for Software Requirement Patterns Xavier Franch1, Cristina Palomares1, Carme Quer1, Samuel Renault2, François De Lazzer2 1

Universitat Politècnica de Catalunya (UPC) UPC – Campus Nord, Omega building, 08034 Barcelona (Spain) {franch | cpalomares | cquer }@essi.upc.edu 2 CITI, CRP Henri Tudor 29 avenue John F Kennedy, Luxembourg (Luxembourg) {samuel.renault | francois.delazzer}@tudor.lu

Abstract. [Context and motivation] Software Requirement Patterns (SRP) are a type of artifact that may be used during requirements elicitation and that also impact positively in other activities like documentation and validation. In our preliminary experiences at the CITI-CPRHT department, SRP show a great percentage of reuse for the non-functional requirements needed in several callfor-tender requirement books. [Question/problem] Once the concept of SRP has been stabilized, we are facing the need to formulate its accurate definition which will allow reasoning rigorously and know more about their semantics and applicability. [Principal ideas/results] We provide a metamodel around three main concepts: 1) the structure of SRP themselves; 2) the relationships among them; 3) the classification criteria for grouping them. [Contribution] Concerning theory, we provide a rigorous definition that shows the concepts that are of interest when defining and applying SRP. Concerning the practice, we may use the metamodel as the starting point for a data model to be used in a supporting software system (for which we already have a prototype). Keywords: software requirement patterns, requirements reuse, metamodel.

1

Introduction

Reuse is a fundamental activity in all software development related processes [Kru92, MC07]. The concept of software reuse emerged since the very beginning of the discipline and it is the cornerstone of software development based on Off-The-Shelf (OTS) components [Li+06] and more generally, any kind of software component [Lam+09]. However, reuse also embraces artefacts other than pure software, therefore also architectural designs, test suites, documentation, etc., may be reused. Of course, software requirements are not an exception to this rule [LMV97]. The reuse of software requirements may help requirement engineers to elicit, validate and document software requirements and as a consequence, obtain software requirement documents of better quality both in contents and syntax [RR06]. There are many approaches to reuse. Among them, patterns hold a prominent position. According to Alexander, “each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over,

2 Xavier Franch, Cristina Palomares, Carme Quer, Samuel Renault, François De Lazzer without ever doing it the same way twice” [Ale79]. Software engineering practitioners have adopted the notion of pattern in several contexts, remarkably related with software design (software design patterns [Gam+95] and software architectural patterns [Buc+96] being the most representative approaches), but also in other software development phases, both earlier and later. According to our needs, we are interested in patterns for the software analysis stage, namely Software Requirement Patterns (SRP). As explained in Section 2, SRPs have been approached in different ways by several people. In this paper, our approach to SRPs can be graphically summarised as in Fig. 1: they are stored in a SRP catalogue that may be browsed in order to identify which one applies in a given situation, and then tailored to the particular project under analysis, in a way such that a software requirements specification (SRS) document can be incrementally constructed.

Adaptation Adaptación Aplicación Pattern de patrones Application

Repositorio Pattern de patrones Catalogue Identification

Fig. 1. Using an SRP catalogue in the requirements engineering process.

Section 3 describes the work done by the CITI department at CRPHT that motivated our research in knowledge reuse and our proposal of construction and application of a pattern catalogue. The PABRE process of SRP application has been described in [Ren+09], thus, in this paper we focus on the structure of SRPs and catalogues that contain them. This structure will be formulated in terms of a metamodel expressed with a UML class diagram, built according to a research method outlined in Section 4. Section 5 provides the basic metamodel for the patterns themselves, Section 6 explores the relationships among them that appear when putting them together in a catalogue, and Section 7 incorporates classification schemas to the catalogue. Section 8 provides the conclusions and future work.

2

Background

The general concept of requirements reuse and their potential advantages have been already discussed [LMV97, RR06]. Techniques like analogy [MS93] or domain analysis [Pri90] have been proposed and used but there is not evidence of their massive transfer to industrial practice.

A Metamodel for Software Requirement Patterns

3

Table 1. Comparison of approaches to software requirement patterns. [Rob96] [DBRT99] [LLG02] [KC02] [MRRH05] [Wit07] [MVT08] [YL08] Our approach

Scope Business applications General purpose General purpose

Notation Event-Use case Natural language Semi-formal models

Metamodel? No No, just templates Yes

UML class diagrams Natural language Object models Problem frames + i*

Application Identify patterns Reqt. elicitation Writing req. models From informal to formal reqts. Security goals elicit. Writing SRSs Variability modeling Knowledge mgmt.

Embedded systems

Logic-based

Security requirements General purpose General purpose General purpose General purpose

Natural language

Writing SRSs

Yes

No No No, just template Yes No

Patterns offer a powerful alternative to these techniques for implementing software reuse. We may find in the literature several pattern-related proposals [Rob96, DBRT99, LLG02, KC02, MRRH05, Wit07, MVT08, YL08] that differ in criteria like the scope of the approach, the formalism used to write the patterns, the intended main use of patterns and the existence of an explicit metamodel. Table 1 shows the classification of these approaches with respect to the mentioned criteria. In the last row we describe our own method as general-purpose, representing patterns in natural language, aiming at writing SRSs and metamodel-based. About the two approaches that propose a metamodel, [DBRT99] focus on reuse of semi-formal models (e.g., UML class diagrams and sequence diagrams), thus the kind of concepts managed are quite different. Concerning [MVT08], their focus is on variability modeling for handling the different relationships that requirements may have. From this point of view, it is a very powerful approach, but other aspects that we will tackle here, like the existence of different forms that a pattern may take, or multiple classification criteria, are not present in their metamodel.

3

Requirement Patterns in Call-for-tender Processes

One of the missions of the CITI department of the Centre de Recherche Publique Henri Tudor (CRPHT) is to constantly look for Information Technologies (IT) innovation in the Small and Medium sized-Enterprises. In the early 2000s, the CITICRPHT department developed a specific method to select Off-The-Shelf (OTS) solutions [KB03]. This method consists on helping SMEs with no background in requirements engineering to handle requirements analysis activities and to design requirements books (SRSs) in order to conduct call-for-tender processes. Usually this is performed with the support of a third party (generally an IT Consultant). According to the OTS selection method, we structure requirements into three categories: functional requirements, non-functional requirements and so-called “callfor-tender constraints” that usually express the service requirements from the OTS provider. We chose natural language as notation for requirements. Thus requirements found in Requirement Books are expressed by one or more sentence (trying to fulfill the IEEE-830 quality criteria for requirements). Figure 2 shows examples related to availability and audit logs.

4 Xavier Franch, Cristina Palomares, Carme Quer, Samuel Renault, François De Lazzer The system must be available 12 hours per day and 7 days per week. The system should not stop more than 1 hour per working day. The solution’s availability rate should be 98% minimum. The solution should permit the trace of the modifications and access to the encrypted data in the database. The essential data to trace are: user name, date, accessed or modified data.

Fig. 2: Examples of software requirements in CITI-CRPHT requirement books

Through the past nine years, 40 projects ran successfully following this methodology (and so, more than 40 requirement books were produced). The need of reusing knowledge rapidly arose, and simple techniques like starting a new project by editing the most similar requirement book demonstrated their weaknesses especially when mobility of IT experts and consultants existed. It became necessary to provide better means to capitalize requirements in a high-level manner by creating reusable artifacts like patterns, supporting consultants’ need of creating new requirement books. The need becomes more evident when we look at concrete examples like in Figure 3. The requirements at the left are typical requirements that could easily matched into patterns. The ones at the right are requirements that are more complex to compare, indeed they are not similar at a glance. For this kind of requirements, an abstraction process is required, using other sources of information about the subject of the requirements, such as other related requirements books, specialized literature or expert assessment (see Section 4). The system must be available 22 hours per day and 7 days per week. The system should not stop more than 1 hour per working day. The solution’s availability rate should be 98%

The solution should permit the trace of the modifications and access to the encrypted data in the database. The essential data to trace are: user name, date, accessed or modified data.

minimum.

The solution should permit to trace all the user actions. The data to trace are: user name, date, accessed or modified data.

The system must be available 10 hours per day and 5 days

All the operations made over a type of object (dossier, document files, etc.) may be traced

per week. The system should not stop more than 10 minutes per working day. The solution’s availability rate should be 98% minimum.

The solution should permit to trace all the access to protected data. The data to trace are: user name, date, accessed or modified data. An historical record of this accesses must be maintained

Fig. 3. Examples of software requirements in CITI-CRPHT requirement books.

For an IT consultant acting as a requirements engineer, the advantages of using requirements patterns would be: less time spent in the requirements analysis and more quality in the production of requirements book. On the one hand, spending less time comes from the “ready-to-use” quality of a pattern. On the other hand, improving the quality of realization of requirements books depends on the sufficiency of the set of patterns available. But to take advantages of using patterns, we needed to figure out how to structure them and what would be the best way to do it. We develop in the next section the research method we used to answer this question.

4

Research Method

Three sources were used to build the metamodel for the SRP catalogue: available requirement books from several call-for-tender real projects; experts’ knowledge; and


5

background on requirements engineering literature and especially on requirement patterns. These sources contributed in different ways to the construction of the pattern catalogue and during the decisions of the metamodel of the patterns in the catalogue. Although it is true that most of our work comes from the analysis of requirement books and from this point of view and given the way we treated the data, our work could be considered an application of grounded theory [CS90], we also undertook a previous literature review [Coo98] that complemented and validated our findings. The process of construction of the catalogue and the underlying metamodel consisted of two phases. The first phase resulted in a preliminary version of the catalogue focusing on non-functional requirements, composed of 48 SRP and a preliminary version of the metamodel embracing the most relevant elements. The second phase resulted in the current version of the catalogue that includes 29 nonfunctional SRP and some modifications that yield to the final form of the metamodel. Requirement Books. Requirements books were the main source to elaborate our approach. We grounded our theory on 7 requirement books coming from real projects undertaken by CITI-CRPHT in the domains of CRM, DM and ERP systems. Since non-functional requirements are the requirements that are the least context-dependent, we started by extracting patterns from these types of requirements. These books contained about 70 non-functional requirements in average. In these documents, on the one hand, we searched and found similarities among requirements of different or even the same book, and the resulting clustering together with the corresponding expert assessment (see below) drove us to a first version of our SRP catalogue. On the other hand, we observed and analyzed the structure, relationships and organization of requirements, and we obtained a first version of the metamodel that follow these patterns and that we present in this paper. The requirements books were later used during the construction of the second version of the catalogue in a validation that consisted in applying the patterns for recreating the requirement books. The metamodel underwent also under a process of adjustment, especially in the relationships part. Experts’ knowledge. Three type of experts have been involved in the process. GESSI-UPC academic experts, with a good background on the several aspects of requirements engineering (including patterns [MFQ08]) and knowledge on metamodeling, conducted the construction of the first version of the catalogue in close collaboration with CITI experts. These practitioners, who are experienced in the statement of requirements expressed in natural language, continuously provided feedback and suggestions for improvement, and issued some requirements on the pattern structure. GESSI-UPC experts also developed the metamodel with validation from CITI experts. CITI experts then interacted with requirement engineers experienced in OTS-based selection processes who played a fundamental role when reviewing the first version of the catalogue and its structure (and indirectly thus the metamodel). They considered most of the attributes of the SRP proposal as necessary and rellevant, although some of them (e.g., metadata introduced for traceability and history purposes) were identified as not useful during the elicitation process, but useful for browsing it. Thus probably different views on the catalogue would help them on focusing on the important information depending on their activity. On the other hand, requirement engineers pointed out some aspects of the structure of the catalogue that were not identified in the first version of the catalogue (such as the notion of “question”,

6 Xavier Franch, Cristina Palomares, Carme Quer, Samuel Renault, François De Lazzer widely used in CITI’s call-for-tender processes). Last, CITI experts conducted two case studies. The first one (a digital library system) contributed to the improvement of both the contents and the metamodel of the catalogue, and the second one (a CRM SaaS project) was used for validation to obtain feedback of the adequacy of the resulting catalogue (see [Ren+09] for details on these case studies). Literature review. Three types of sources were used: 1) classical software requirement textbooks and papers; 2) software requirement patterns focused literature; 3) specific literature dedicated to knowledge in one particular type of requirement (e.g., what does Mean Time Between Failures exactly mean). The main influential works on patterns have been mentioned in Section 2. They provided a valuable starting point and helped us to structure and put into context all the data gathered from requirement books and all the knowledge communicated by experts.

5

Basic Structure of a Requirement Pattern

The first fundamental question to answer is what the structure of a SRP is. Fig. 3 depicts all the metaconcepts that will be progressively presented throughout the section. To start with, we clarify the difference among the concept of SRP and individual requirements.

Fig. 3. Metamodel excerpt: basic structure of a software requirement pattern.

Observation. SRPs are not about individual requirements, but about groups of related requirements. Rationale. As defined by Whitall, “a requirement pattern is a guide to writing a particular type of requirement” [Wit07]. In this sense, a type must be considered as a set of requirements. For instance, the pattern Upgrade duration includes three parts that each generates a single requirement: one about duration itself, another about preferred time to update, and the last one about update of critical processes. On the other hand, inspection on CITI requirement books clearly shows that requirements cluster around concepts, so that some requirements just have sense when considered as subordinated to others. An example of cluster of requirements is: “The system should authenticate the users, no matter their profile. Authentication should be based on Windows login”. As it can be seen there are two requirements in this cluster, and the second one does not make sense if the first one is removed. In the requirement books studied, we find as average 70 requirements grouped into around of 40 clusters.


7

Consequence. This observation justifies that the metaclass Requirement Pattern for SRPs is not simply an abstraction of the concept of requirement, instead it requires careful analysis to deduce an internal structure that is able to identify components of an SRP and their relationships. ■ The first thing we noticed from the observation of requirement books is that the same underlying concept, which we wanted to represent through a single SRP in our catalogue, is not necessary expressed in the books in a similar way. Observation. The concept represented by a SRP may take different forms in different projects. Rationale. Inspection on CITI requirement books shows this situation several times. An example is related with the interface load time of a system (Interface Load Time pattern). We found that the requirements that drove to this pattern took two different forms in the books, one that expresses the general need of loading the user interface in a certain amount of time and another one that expresses the general need of loading some part, or executing actions on the user interface, in a certain amount of time. It is important to notice that these forms need to coexist, i.e. we cannot aim at reducing all of them to a kind of canonical form for the SRP, because each form captures a particular context that may be the most appropriate for a software project. We may find further evidence in the literature. Withall again reflects this observation although there is no explicit reference to this need, in fact it is hidden in the pattern definition and application. The conceptual gap from the formulation of the pattern to text that is obtained by its application arguably is one of the main drawbacks of his proposal. Consequence. The metaclass Requirement Pattern is defined as a composition of Requirement Forms. Applying a SRP means choosing and applying one of its forms, i.e. requirements that come from different SRP forms cannot be mixed in a single project. ■ If we focus now on forms, we realize that there is a fundamental property that helps to identify them. Observation. Each SRP form has a part that characterizes that form, and zero or more parts that may appear or not. Rationale. This situation occurs in CITI requirement books often, in fact for most of the patterns. One of the cases is in requirements corresponding to the users capacity that a system must support (Users Capacity pattern). In these requirements we have found that there is a part that always appears stating the number of users that the system should be able to manage. But in different projects we find that this part is followed of different parts, for example for expressing the need of supporting a growing in the number of users, or a growing of the percentage of users depending on the user profile. Most SRPs fulfill this property of having a common part. It could be argued that to support our observation, this percentage should in fact be 100%, but we are complementing here inspection of requirement books with expert knowledge, and we have concluded from our analysis of the books that when this situation didn’t happen in the requirement books, the reason was that the books were not optimal.

8 Xavier Franch, Cristina Palomares, Carme Quer, Samuel Renault, François De Lazzer Consequence. The metaclass Requirement Form is defined as a composition of Fixed Part and Extended Part. Fixed Part stands for this part common to all applications, therefore it is stated that a Requirement Form has just one Fixed Part. For Extended Part, the multiplicity is not defined. ■ The existence of extended parts leads to the question of: is there any restriction when applying them? The following observation answers this question. Observation. Extended parts in SRP may exhibit arbitrary relationships among them. Rationale. Inspection of CITI requirement books shows that we cannot aim at finding a pattern of application of extended parts. Some examples follow: – The case of extended parts that must be used in a mutually exclusive way. This is the case of the requirement pattern that expresses the need of offering online help to system users (Online Help pattern). In this pattern we have found two extended parts that may not be used together: one asks for full online help at every screen of a system, whilst the other requires online help for just a subset of screens of the system, requiring as part of the application saying which ones. – The case of extended parts that may be applied more than once. This case appears in a requirement form for the Failure Alerts pattern. One of its extended parts binds sets of alerts to set of failure types, therefore it may be applied as many times as required. Therefore, we need to be flexible and allow extended parts to be applied differently depending on the SRP. But at the same time, we need to keep track of any relationship among them for avoiding incorrect applications. Consequence. The metaclass Requirement Form is bound to a class Extended Part Constraint that states these possible relationships. Each relationship is represented by a formula that should allow at least representing the relations above: dependency among extended parts (e.g., excludes, requires); multiplicity of an extended part (including optionality and obligatoriety as particular cases). ■ Once arrived at this level of decomposition, we have obtained the counterpart of requirements at the level of patterns, i.e. application of patterns will imply application of parts from one of its forms, and each part when applied will yield to a requirement. Observation. Both fixed and extended parts correspond to the atoms of requirement books and cannot be split further. They share the same structure, with some variable information that needs to be assigned a value when the pattern is applied. Rationale. We realized that this observation is correct once we had the SRP catalogue and we tried to establish a correspondence among the parts of SRPs and the requirements in the requirement books. There were cases of requirements in the books that did not have a correspondent part in a SRP, meaning very specific requirements that seemed not appropriate for abstracting into a pattern, as “The solution should permit navigation from a field to other in the same screen only with the keyboard”. But we never found a requirement corresponding to a pattern’s fixed or extended subpart. Consequence. An abstract class Pattern Item is defined as a superclass of both types of parts, Fixed Part and Extended Part. This class includes the metainformation


9

common to both parts (e.g., information source, author, date, etc.; not explicitly shown in the figure) and an attribute template that represents the text of the item. The text contains the references to parameters that represent the “variable information” (see above) to be concreted when applied. Thus in the metamodel the class Parameter has an association with Pattern Item with an ordered role. Parameters have three kind of information bound: 1) A metric, whose concrete structure is not refined in the figure. 2) An association related that links to other parameters (belonging to other patterns) such that they must have the same value; an example is the parameter language appearing in parts belonging to both the patterns Interface Language and Language Documentation. 3) A correctness condition (e.g., non-empty sets). ■ Fig. 4 shows an example of SRP from this metamodel. For the sake of brevity, we do not include its metainformation (e.g., description, goal author). This pattern would be used in a project in case the client needs a system that provides alerts when system failures occur. It has two different forms used depending on whether it is relevant to have different types of alerts depending on the types of failures, or not. In case it is a specific need of certain alerts or failures, then the extended parts should be used.

6

Relationships between Patterns

In this section we introduce just one, but fundamental observation, that arises when considering patterns not individually as in the previous section, but as a collection with a common objective. Observation. SRPs are not isolated units of knowledge, instead there are several types of relationships among them. Rationale. Pattern current approaches do recognize the need of such relationships. The creator of the concept, Alexander, identified in his seminal work clauses like “may be part of” and “may contain” [Ale79]. Also the proposal of design patterns included a “related with” clause to declare any kind of relationship [Gam+95]. In the context of SRPs, Withall structures his SRP catalogues using a more detailed proposal of relationships, that may be purely structural like “has”, “uses” and “is-a”, or with a semantic meaning like “displays” and “is across” [Whi07] (see Fig. 5). Even generic (unlabelled) relationships are used. These relationship types are just used when needed, they are not formally defined. The stated relationships, however, are not complete, e.g. efficiency patterns are presented as isolated whilst in fact they have many relationships with others. On the other hand, existence of relationships among software requirements is also a well-documented fact [RR06]. The NFR framework approach proposes a rich range of possibilities that facilitates even some automatic treatment (Make, Break, Help, Hurt, Some+, Some-, Equal, Unknown) [CNYM00]. Other approaches use intermediate artifacts to help in discovering, tracing and expanding those relationships, like [FC03, EG04] that use quality models with this purpose.

10 Xavier Franch, Cristina Palomares, Carme Quer, Samuel Renault, François De Lazzer Requirement Pattern Failure Alerts Template

The system shall trigger different types of alerts depending on the type of failure

Extended Parts Constraint

multiplicity(Alerts for Failure Types) = 0..*

Template

The system shall trigger %alerts% alerts in case of %failures% failures

Fixed Part

Requirement Form Extended Heterogeneous Part Failure Alerts Alerts for Failure Types

Parameter alerts: non-empty set of alert types failures: non-empty set of failure types

Fixed Part

Requirement Form Homogeneous Failure Alerts

Extended Part Alert Types

Extended Part Failure Types

Metric alerts: Set(AlertType) AlertType: Domain of possible types of alerts failures: Set(FailureType) FailureType: Domain of possible types of failures

Template

The system shall trigger an alert in case of failure.

Extended Parts Constraint

multiplicity(AlertsTypes) = 0..1 and

Template

The solution shall trigger %alerts% alerts in case of failure

multiplicity(Failure Types) = 0..1

Parameter

Metric alerts: Set(AlertType)

alerts: non-empty set of alert types

AlertType: Domain of possible types of alerts

Template

The system shall trigger alerts in case of %failures% failures

Parameter failures: non-empty set of failure types

Metric failures: Set(FailureType) FailureType: Domain of possible types of failures

Fig. 4. An example of software requirement pattern (parameters appear among ‘%’) Data Structure

Uses

Report

Inquiry Information Storage

Displays Data Entity

…

…

Report

Transaction

Fig. 5. A network of pattern relationships: excerpt from Withall’s proposal.

Both kinds of proposals work at a different level of granularity. In other words, Whitall does not establish relationships among SRP components which may lead to incomplete information. For instance, it is declared that the ID SRP uses the Data Structure SRP, but in fact this relationship does not affect every single ID’s subcomponent, e.g. the “Each shall be unique subcomponent (i.e., part of template in Withall’s terms) is a universal property not depending on any particular Data Structure. On the other hand, stating relationships only at the level of individual requirements may imply to declare some of them in a redundant manner.


11

Our requirement books show clearly these relationships and also the granularity problem. Examples are: –

Relationships at the pattern level. One example is among the Authentication and Authorization patterns. It is quite clear that it is necessary to have the capability of identifying users for having the capability of allowing the access to resources depending on users’ privileges. A relationship at the level of patterns implies that all their forms and all the forms’ parts exhibit the same relationship.

–

Relationships at the form level. One example is among two forms in the Installation Procedures and Update Procedures patterns. These two forms require the installation and update of the system to be automatic. Thus, if one of these forms is chosen, the other must be considered, since it will be possibly of interest for the project. A relationship at the level of forms implies that all their parts exhibit the same relationship.

–

Relationships at the part level. For instance, two parts link individually failure types, the one in Fig. 4 (Alerts for Failure Types) and Data Integrity by Failure. In this case, the types of failure may be different but of course there is some relationship, then we establish that there are related. The relationship only applies to these two parts.

Consequence. A metaassociation class Relationship is included (see Fig. 6). It is an abstract metaclass with three heirs, one for each level identified above (see association ends). Also it includes an attribute with the type of relationship, in our case we are using requires, conflicts, supports and the most general one relates-to. ■

Fig. 6. Metamodel excerpt: pattern relationships.

Integrity constraints play a fundamental role in this part of metamodel. The basic idea is that a relationship declared at one level among two elements A and B cannot contradict a relationship stated one level above (i.e., of greater granularity) to some components of A and B. Since we have three levels, we just state two integrity constraints that appear as OCL invariants. We show one of them below, leaving the notContradictory predicate unrefined for the sake of brevity. For each form relationship ab, it is necessary to check that the relationships papb and pbpa among the patterns that contain a and b respectively, are not contradictory to ab, if they exist.

12 Xavier Franch, Cristina Palomares, Carme Quer, Samuel Renault, François De Lazzer context FormRelationship inv: FormRelationship.allInstances()-> forAll(r | r.from.reqPat.to->includes(r.to.reqPat) implies notContradictory(r, r.from.reqPat.patternRelationship[to]-> select(s | s.to = r.to.reqPat) and r.from.reqPat.from->includes(r.to.reqPat) implies notContradictory(r, r.from.reqPat.patternRelationship[from]-> select(s | s.to = r.to.reqPat))

Last, we have added a derived operation that computes the set of relationships that are applicable to one particular element (pattern, form or part). This operation takes into account propagation according to the observations described above. Its OCL definition for the form case appears below. Part (1) includes direct relationships from the chosen form, whilst part (2) takes propagates downwards relationships from the pattern that contains the chosen form into other forms, taking care of not overriding the former ones with the check at (2.a). context PatternForm::allRelationships(): TupleType(p: PatternForm, t: RelationType) derives: (1) self.formRelationship[to]-> forAll(r | result->includes(Tuple{p = r.to, r.type.type})) and (2) self.reqPat.patternRelationship[to]-> forAll(r | r.to.pform->forAll(f | (2.a)

7

if not self.FormRelationship[to]->includes(f) then result->includes(Tuple{p = f, self.FormRelationship[to]->select(f).type.type}))

Classification Schemas for Requirement Patterns

Section 6 provided an enrichment of the concept of individual patterns by considering them as a collection. But a pattern catalogue is more than a simple collection of items, we need to provide some further structure as the following observation states. Observation. SRPs need to be classified over some criteria. Rationale. Up to our knowledge, there is no single proposal of requirements, or SRPs, presented sequentially without any kind of indexing facility. Both classical and pattern-related textbook and papers that present a kind of requirements-related catalogue impose some index either explicitly, by providing a clearly defined artifact (index, faceted structure, taxonomy, …) or implicitly by organizing the contents into a series of sections each one with a title. In case of taxonomies, the index is multi-level. The same happened in our experiences, where requirement books presented three big categories (functional, non-functional and call-for-tender constraints) and these parts divided into another level, e.g. the non-functional category was organized into around 10 big sections (performance, ergonomy, …). The sections are used to structure the requirement books and also to help later browsing of the document. In fact, our PABRE method [Ren+09] proposes the use of this index as the main input for deciding the order in which SRPs are applied. But the second observation is almost as important as the previous one. Observation. Different contexts (organizations, projects, standards, etc.) may, and usually do, define or require different classification schemas.


13

Rationale. Almost every single source that we have looked up uses a different classification schema. This fact that could be considered harmful at a first sight, in fact just reflects the different cultures, contexts and background of organizations and individuals that work on requirements engineering. History shows that trying to impose a particular classification schema will not work, therefore we decided that our approach should reflect this fact. The key point here is to decouple SRPs and classifiers as shown in Fig. 7. The catalogue is considered as flat (with the relationships mentioned in Section 6) and the classification schemas just impose different structuring schemas on top of it. Classification schema 1

Pattern 1

Classification schema 2

relationship

Pattern 2

…

Pattern k

…

Classification schema k

SRP catalogue

Fig. 7. Adding classification schemas to the pattern catalogue.

Consequences (of both observations). We introduce the notion of Classifier and we bind SRPs to them (see Fig. 8). In order to reflect the most complex (and powerful) case, classifiers are organized into a hierarchy and then SRPs are in fact bound to Basic Classifiers, whilst Compound Classifiers just impose this hierarchical structure. The use of aggregation avoids cycles without further integrity constraints. Last, a derived class Root is introduced as a facilitation mechanism.

Fig. 8. Metamodel excerpt: classification schemas for software requirement patterns.

The existence of different classification schemas yields to a new class that composes its classifiers and more fundamentally, the multiplicity roles are many-tomany: a SRP may be bound to several classification schemas, and even to more than one classifier in a single classification schemas (since no further restrictions are declared). Also note that we do not impose unnecessary constraints that could lead the

14 Xavier Franch, Cristina Palomares, Carme Quer, Samuel Renault, François De Lazzer catalogue to be rigid. For instance, we may mention that a classification schema may not cover all existing SRP (i.e., some SRP are not classified). Although this situation could be thought as a kind of incompleteness, in fact we are allowing having dedicated classification schemas for particular categories of patterns, e.g. a performance classification schema, a classification schema just for the non-technical criteria [FC06] and then allowing to compound them for having a multi-source global classification schema. Also we remark that the PABRE method [Ren+09] benefits for this existence of multiple classification schemas since nothing prevents changing from one schema to another during catalogue browsing. ■

8

Conclusions and Future Work

In this paper we have presented a metamodel for software requirement patterns (SRP) as used by the PABRE method [Ren+09]. The creation of this metamodel has helped to fix the concepts behind the idea of SRP, improving the quality of the current SRP catalogue and process. Also, it has been taken as the starting point of the data model of an ongoing support tool. Following methodological advices [Gla92], to validate the built conceptual model after a kind of grounded theory process like this (although in Section 4 we commented that it was not pure grounded theory), we must check the result in terms of adequacy, relevance and modifiability. • Adequacy. By following good practices during the research process. We think that the two-stage method described in Section 4 combining analysis of real data, experts’ advice and literature review, together with a first validation in two real projects, is a good guarantee of adequacy. • Relevance. For researchers, having an explicit metamodel of SRPs that, as shown in Table 1, is usually missing in SRP proposals. For practitioners, they may benefit indirectly by having a better quality SRP catalogue and also tool support. • Modifiability. We have tried to compromise as little as possible in the metamodel. For instance, even the concrete notation (text) could be changed with little effort. Also decisions like allowing several classification schemas support modifiability by avoiding modifications. Future work spreads over two main directions. Concerning validation, we are planning to run new case studies to debug all the PABRE components: metamodel, catalogue contents and process. We intend to experiment deeper the application of the SRP in several contexts (public IT procurement projects and Small- and MediumSized companies related projects). By doing so, we aim at trying to validate the two assumptions of SRP as a mean of capitalising requirements’ knowledge throughout projects and SRP as a mean of improving the efficiency of requirements engineering activities. Concerning theory, the most significant extensions are to include in the model the problem of pattern application, i.e. going from domain to application; and to consider variability modeling techniques like in [BW07, MVT08] for representing combinations of extended parts inside patterns. The feasibility of other minor changes, e.g. concerning the allowed metrics, is going to be assessed also in future experiences.


15

References [Ale79] C. Alexander. The Timeless Way of Building. Oxford Books, 1979. [Buch+96] F. Buschmann et al. Pattern-oriented Software Architecture. A System of Patterns. Wiley 1996. [BW07] B. Berenbach, T. Wolf. “A Unified Requirements Model; Integrating Features, Use Cases, Requirements, Requirements Analysis and Hazard Analysis”. ICGSE 2007. [CFQ06] J.P. Carvallo, X. Franch, C. Quer. “Managing Non-Technical Requirements in COTS Components Selection”. RE 2006. [CNYM00] L. Chung, B.A. Nixon, E. Yu, J. Mylopoulos. Non-Functional Requirements in Software Engineering. Kluwer Academic Publishers, 2000. [Coo98] H.M. Cooper. Synthesizing research: a guide for literature reviews (3rd ed.). Sage Pubs., 1998. [CS90] J. Corbin, A. Strauss. “Grounded Theory Research: Procedures, Canons, and Evaluative Criteria”. Qualitative Sociology 13(1), Springer, 1990. [DBRT99] A. Durán, B. Bernárdez, A. Ruíz, M. Toro. “A Requirements Elicitation Approach Based in Templates and Patterns”. WER 1999. [EG04] A. Egyed, P. Grünbacher. “Identifying Requirements Conflicts and Cooperation: How Quality Attributes and Automated Traceability Can Help”. IEEE Software 21(6), 2004. [FC03] X. Franch, J.P. Carvallo. “Using Quality Models in Software Package Selection” IEEE Software 20(1), 2003. [Gam+95] E. Gamma et al. Design Patterns. Addison-Wesley, 1995. [Gla92] B.G. Glaser. Basics of Grounded Theory Analysis. Sociology Press Mill Valley, 1992. [KB03] M. Krystkowiak, B. Bucciarelli. “COTS Selection for SMEs: a Report on a Case Study and on a Supporting Tool”. RECOTS 2003. [KC02] S. Konrad, B.H.C. Cheng. “Requirements Patterns for Embedded Systems”. RE 2002. [Kru92] C.W. Krueger. “Software Reuse”. ACM Computing Surveys 24(2), 1992. [Lam+09] R. Land et al. “Reuse with Software Components - A Survey of Industrial State of Practice”. ICSR 2009. [Li+06] J. Li et al. “A State-of-the-Practice Survey of Off-the-Shelf Component-Based Development Processes”. ICSR 2006. [LLG02] O. López, M.A. Laguna, F.J. García. “Metamodeling for Requirements Reuse”. WER 2002. [LMV97] W. Lam, J. A. McDermid, A. J. Vickers. “Ten steps towards systematic requirements reuse”. Requirements Engineering Journal 2(2), Springer, 1997. [MC07] P. Mohagheghi, R. Conradi. “Quality, Productivity and Economic Benefits of Software Reuse: A Review of Industrial Studies”. Jnal. of Empirical Software Engineering 12(5), 2007. [MFQ08] O. Méndez, X. Franch, C. Quer. “Requirements Patterns for COTS Systems”. ICCBSS 2008. [MRRH05] D. Matheson, I. Ray, I. Ray, S. H. Houmb. “Building Security Requirement Patterns for Increased Effectiveness Early in the Development Process”. SREIS 2005. [MS93] N. Maiden, A. Sutcliffe. “Exploiting reusable specification through analogy”. Communications ACM 35(4), 1993. [MVT08] B. Moros, C. Vicente, A. Toval. “Metamodeling Variability to Enable Requirements Reuse”. EMMSAD 2008. [Pri90] R. Prieto-Díaz. “Domain analysis: an introduction”. ACM Software Engineering Notes 15(2), 1990. [Ren+09] S. Renault et al. “A Pattern-based Method for building Requirements Documents in Callfor-tender Processes”. Intl. Journal of Computer Science & Applications, 6(5), 2009. [Rob96] S. Robertson. “Requirements Patterns Via Events/Use Cases”. PLoP 1996. [RR06] S. Roberson, J. Robertson. Mastering the Requirements Process (2nd ed.). Addison-Wesley, 2006. [YL08] J. Yang, L. Liu. “Modelling Requirements Patterns with a Goal and PF Integrated Analysis Approach”. COMPSAC 2008.

[Wit07] J. Withall. Software Requirements Patterns. Microsoft Press, 2007.