Abstract Requirements specification is a core activity in the requirements engineering phase of a software development project. Researchers have contributed extensively to the field of requirements specification, but the extent to which their proposals have been adopted in practice remains unclear. We gathered evidence about the state of practice in requirements specification by focussing on the artefacts used in this activity, the application of templates or guidelines, how requirements are structured in the specification document, what tools practitioners use to specify requirements, and what challenges they face. We conducted an interview-based survey study involving 24 practitioners from 12 different Swedish IT companies. We recorded the interviews and analysed these recordings, primarily by using qualitative methods. Natural language constitutes the main specification artefact but is usually accompanied by some other type of instrument. Most requirements specifications use templates or guidelines, although they seldom follow any fixed standard. Requirements are always structured in the document according to the main functionalities of the system or to project areas or system parts. Different types of tools, including MS Office tools, are used, either individually or combined, in the compilation of requirements specifications. We also note that challenges related to the use of natural language (dealing with ambiguity, inconsistency, and incompleteness) are the most frequent challenges that practitioners face in the compilation of requirements specifications. These findings are contextualized in terms of demographic factors related to the individual interviewees, the organization they are affiliated with, and the project they selected to discuss during our interviews. A number of our findings have been previously reported in related studies. These findings show that, in spite of the large number of notations, models and tools proposed from academia for improving requirements specification, practitioners still mainly rely on plain natural language and general-purpose tool support. We expect more empirical studies in this area in order to better understand the reason of this low adoption of research results.

Context: Tertiary studies in software engineering ([email protected]) are widely used to synthesise evidence on a research topic systematically. As part of their protocol, [email protected] define inclusion and exclusion criteria (IC/EC) aimed at selecting those secondary studies (SS) to be included in the analysis. Aims: To provide a state of the art on the definition and application of IC/EC in [email protected], and from the results of this analysis, we outline an emerging framework, TSICEC, to be used by SE researchers. Method: To provide the state of the art, we conducted a systematic mapping (SM) combining automatic search and snowballing over the body of SE scientific literature, which led to 50 papers after application of our own IC/EC. The extracted data was synthesised using content analysis. The results were used to define a first version of TSICEC. Results: The SM resulted in a coding schema, and a thorough analysis of the selected papers on the basis of this coding. Our TSICEC framework includes guidelines for the definition of IC/EC in [email protected] Conclusion: This paper is a step forward establishing a foundation for researchers in two ways. As authors, understanding the different possibilities to define IC/EC and apply them to select SS. As readers, having an instrument to understand the methodological rigor upon which [email protected] may claim their findings.

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.

Software requirement patterns have been proposed as an artifact for fostering requirements reuse. In this paper we present PABRE-Man, a software subsystem aimed at managing a catalogue of patterns ready to be applied in requirements engineering projects.

This paper presents our PABRE method for facilitating requirements elicitation on the basis of requirement patterns with the goal of saving time and reducing errors during this activity. The process presented applies for elicitation in off-the-shelf selection projects driven by call for tenders processes and uses a requirement patterns catalogue. The process selects patterns from the catalogue that apply to the particular selection project, and convert them into the real requirements that finally configure the project requirements book. We show some benefits of the pattern approach for requirements engineers and IT consultants, as well as for customers. Finally we discuss the strengths and weaknesses of the proposal and identify some future work.

In this paper we present LEARN-SQL, a system conforming to the IMS QTI specification that allows on-line learning and assessment of students on SQL skills in an automatic, interactive, informative, scalable and extensible manner.

Goal- and agent-oriented models have become a consolidated type of artifact in various software and knowledge engineering activities. Several languages exist for representing such type of models but there is a lack of associated methodologies for guiding their construction up to the necessary level of detail. In this paper we present RiSD, a method for building Strategic Dependency (SD) models in the i* notation. RiSD is defined in a prescriptive way to reduce uncertainness when constructing the model. RiSD tackles three fundamental issues: (1) it tends to reduce the average size of the resulting models; (2) it defines some traceability relationships among model elements; (3) it provides some lexical and syntactical conventions. As a result, we may say that RiSD supports the construction process of goal- and agent-oriented models whilst increasing their understanding.

The selection of COTS components is made not only by an analysis of their technical quality but also (and sometimes mostly) by considering how they fulfill those non-technical requirements considered relevant, which refer to licensing, reputation, and similar issues. In this paper we present an approach for managing nontechnical requirements during COTS selection. The proposal is based on extending the ISO/IEC 9126-1 catalogue of quality factors by adding factors related to non-technical issues, obtaining a cohesive and comprehensive framework for managing requirements during selection.

DesCOTS is a system that has an aim to help clients in the selection of COTS components. This system is based in the use of quality models associated to a software domain for evaluating the products in that domain, and for defining in a formal way the requirements of the clients for finding a suitable product in that domain. The evaluation and the formal definition of requirements are facilitated by metrics of each quality entity in the quality models. Our ISO/IEC 9126-1 based quality models are a set of quality entities structured in hierarchies of characteristics, subcharacteristics and attributes; with possible intermediate hierarchies of sub-characteristics and attributes

In the last years, some methods have been proposed for dealing with COTS component selection. In all of them, a key point is the comparison of the user requirements, which drive the selection process, with the capabilities of the evaluated COTS. Quality models are a means to obtain structured descriptions of COTS domains. Once built, COTS in a domain may be evaluated with respect to the quality entities included therein, quality requirements may be stated with respect to the quality model, and the classical factor-requirement negotiation process may be used for the selection of the most appropriate COTS. Our goal is to have completely implemented in a near future a new version of the system DesCOTS (Grau et al., 2004) that supports all the above processes. This system is constituted by 4 subsystems: QM, that helps in the construction and management of quality models (Carvallo et al., 2004); EV, that helps in the evaluation of COTS components and that is the one presented in this paper; SL, that helps in the definition of requirements in a project and in the selection of COTS components that hold these requirements; and AD, that allows the administration of the whole system.