A metamodel for software requirement patterns

[Context and motivation] Software Requirement Patterns (SRP) are a type of artifact that may be used during requirements elicitation that also impact positively in other activities like documentation and validation. In our experiences, SRP show a great percentage of reuse for the non-functional requirements needed in call-for-tender requirement specifications. [Question/problem] We are facing the need of formulating the accurate definition of SRP for their use in call-for-tender processes to allow reasoning rigorously and know more about their semantics and applicability. [Principal ideas/results] In this paper we present a metamodel for SRP around three main concepts: 1) the structure of SRP themselves; 2) the relationships among them; 3) the classification criteria for grouping them. [Contribution] We provide a rigorous definition that shows the concepts that are of interest when defining and applying SRP.Peer ReviewedPostprint (author's final draft

PABRE-Proj: applying patterns in requirements elicitation

© 2013 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Software requirement patterns have been proposed as a type of artifact for fostering requirements reuse. In this paper, we present PABRE-Proj, a tool aimed at supporting requirements elicitation and specification.Peer ReviewedPostprint (author's final draft

A catalogue of non-technical requirement patterns

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Software Requirement Patterns (SRP) have been proposed as an artifact for fostering requirements reuse. PABRE is a framework that promotes the use of SRP as a means for requirements elicitation, validation and documentation in the context of IT procurement projects. In this paper, we present a catalogue of non-technical SRP included in the framework and present in detail some of them. We also introduce the motivation to arrive to these patterns.Peer ReviewedPostprint (author's final draft

Definition and use of software requirement patterns in requirements engineering activities

The final quality of software products and services depends on the requirements stated in the Software Requirements Specification (SRS). However, some problems like ambiguity, incompleteness and inconsistency, have been reported in the writing of SRS, 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. Among all the possible techniques to achieve reuse, patterns hold a prominent position. Although there have been several techniques proposed to reuse requirements, it may be observed that no concrete proposal has achieved a wide acceptance. Due to that, this research proposes the PABRE framework, which uses Software Requirement Patterns (SRP) as a means to capture and reuse requirements knowledge in the context of IT projects.Peer ReviewedPostprint (published version

On the use of requirement patterns to analyse request for proposal documents

Requirements reuse is still today a difficult goal to achieve. One particular context in which requirements reuse may give more benefits than costs is that of call for tenders projects, due to the similarity of the requirements documents (which take the form of requests for proposal documents, RfPs) from one project to another. In this paper, we present an approach aimed at making systematic the assessment of RfPs that technology providers need to conduct in order to decide whether they present a bid or not in a call for tenders project. The approach extends a metamodel we already defined for the former PABRE method, which has a similar goal but from the perspective of the organization that issues the call for tenders. The method is illustrated with an exploratory case study in the field of the railway systems domain.Peer ReviewedPostprint (author's final draft

An approach for creating sentence patterns for quality requirements

Requirements are usually categorized in functional requirements (FRs) and quality requirements (QR). FRs describe "things the product must do" while QRs describe "qualities the product must have". Besides the definition, classification, and representation problems identified by Glinz, there are two further problems with current definitions of quality requirements: (i) the definitions are imprecise and thus difficult to understand and apply, and (ii) the definitions provide no guidance or support for their application in a given organizational context. To tackle these two problems, we propose an approach that - given a quality attribute (e.g., performance) as input - provides a means to specify quality requirements by sentence patterns regarding this quality attribute. In this paper, we contribute a detailed presentation and description of our approach and a discussion of our lessons learnt while instantiating it for performance requirements. Additionally, we give guidance on how to apply our approach for further quality attributes. Through this approach, we aim at encouraging researchers to help us improve the precision of definitions for quality requirements and support practitioners in eliciting and documenting better quality requirements

TWENTY SOFTWARE REQUIREMENT PATTERNS TO SPECIFY RECOMMENDER SYSTEMS THAT USERS WILL TRUST

Trust has been shown as a crucial factor for the adoption of new technologies. Surprisingly, trust literature offers very little guidance for systematically integrating the vast amount of insights from behavioral research on trust into the development of computing systems. The aim of this article is to translate results from behavioral sciences into software requirement patterns that address user trust in recommender systems. Software requirement patterns are used in requirements engineering to recognize important and recurring issues and reduce the effort of compiling a list of software requirements. We collected antecedents that build trust, and developed software requirement patterns that demand functionality to support these antecedents. This paper contributes by presenting software requirement patterns consisting of the name, the goal and the pre-defined requirement template that can be used to specify trust requirements in recommender system development projects

Challenging incompleteness of performance requirements by sentence patterns

Performance requirements play an important role in software development. They describe system behavior that directly impacts the user experience. Specifying performance requirements in a way that all necessary content is contained, i.e., the completeness of the individual requirements, is challenging, yet project critical. Furthermore, it is still an open question, what content is necessary to make a performance requirement complete. To address this problem, we introduce a framework for specifying performance requirements. This framework (i) consists of a unified model derived from existing performance classifications, (ii) denotes completeness through a content model, and (iii) is operationalized through sentence patterns. We evaluate both the applicability of the framework as well as its ability uncover incompleteness with performance requirements taken from 11 industrial specifications. In our study, we were able to specify 86% of the examined performance requirements by means of our framework. Furthermore, we show that 68% of the specified performance requirements are incomplete with respect to our notion of completeness. We argue that our framework provides an actionable definition of completeness for performance requirements