Quality Requirements in Practice: An Interview Study in Requirements Engineering for Embedded Systems

Svensson, Richard Berntsson; Gorschek, Tony; Regnell, Björn

doi:10.1007/978-3-642-02050-6_19

Cited by 44 publications

(45 citation statements)

References 21 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…As shown in Figure 5, the most concerned nonfunctional requirements regard to OSS components are performance, reliability, maintainability and cost. The list of concerned non-functional requirements in our study is different from the most concerned requirements in Berntsson Svensson et al, namely usability, performance and flexibility [21]. Their context was limited to the embedded system and market-driven projects and it may be the reason for the conflicting results.…”

Section: 4mentioning

confidence: 84%

Collaborative Resolution of Requirements Mismatches When Adopting Open Source Components

Ánh

Cruzes

Conradi

et al. 2012

Requirements Engineering: Foundation for Software Quality

View full text Add to dashboard Cite

Abstract. [Context and motivation]There is considerable flexibility in requirements specifications (both functional and non-functional), as well as in the features of available OSS components. This allows a collaborative matching and negotiation process between stakeholders such as: customers, software contractors and OSS communities, regarding desired requirements versus available and thus reusable OSS components.[Problem] However, inconclusive research exists on such cooperative processes. Not much empirical data exists supporting the conduction of such research based on observation of industrial OSS adoption projects. This paper investigates how functional and non-functional requirement mismatches are handled in practice.[Results] We found two common approaches to handle functional mismatches. The main resolution approach is to get the components changed by the development team, OSS community or commercial vendor. The other resolution approach is to influence requirements, often by postponing requirements. Overall, non-functional requirements are satisfactorily achieved by using OSS components. Last but not least, we found that the customer involvement could enhance functional mismatch resolution while OSS community involvement could improve nonfunctional mismatch resolution.[Contribution] Our data suggests that the selecting components should be done iteratively with close collaboration with stakeholders. Improvement in requirement mismatch resolution to requirements could be achieved by careful consideration of mismatches size, requirements flexibility and components quality.

show abstract

Section: 4mentioning

confidence: 84%

Collaborative Resolution of Requirements Mismatches When Adopting Open Source Components

Ánh

Cruzes

Conradi

et al. 2012

Requirements Engineering: Foundation for Software Quality

View full text Add to dashboard Cite

show abstract

“…After ten interviews from five companies, a short paper [6] was presented at an international workshop. The study focuses on the elicitation, analysis and negotiation, management, and general handling of QR in industry.…”

Section: Introductionmentioning

confidence: 99%

Quality Requirements in Industrial Practice—An Extended Interview Study at Eleven Companies

Svensson

Gorschek

Regnell

et al. 2012

IIEEE Trans. Software Eng.

Self Cite

View full text Add to dashboard Cite

“…Moreover, in 19 of the 49 papers the findings can be generalised, and in a further 26 papers the findings can be partially generalised. One reason for the large number of partially generalisable results is that most of the studies use [5] Barney, Aurum, and Wohlin, "A product management challenge: Creating software product value through requirements selection" p38 [24] Fricker, Gorschek, and Glinz, "Goal-oriented requirements communication in new product development" p39 [2] Akker et al, "Software Product Release Planning through Optimization and What-If Analysis" p40 [33] Herrmann and Daneva, "Requirements prioritization based on benefit and cost prediction: An agenda for future research" p41 [60] Mohamed and Wahba, "Value estimation for software product management" p42 [70] Regnell, Berntsson-Svensson, and Olsson, "Supporting Road-Mapping of Quality Requirements" p43 [8] Berntsson Svensson, Gorschek, and Regnell, "Quality requirements in practice: An interview study in requirements engineering for embedded systems" p44 [86] Wilby, "Roadmap transformation: from obstacle to catalyst" p45 [ Can the findings of the study be generalised?…”

Section: General Characteristicamentioning

confidence: 99%

Uni-REPM: a framework for requirements engineering process assessment

et al. 2013

Self Cite

View full text Add to dashboard Cite

PostprintThis is the accepted version of a paper published in Requirements Engineering. This paper has been peer-reviewed but does not include the final publisher proof-corrections or journal pagination.Citation for the original published paper (version of record):Svahnberg, M., Gorschek, T., Nguyen, T., Nguyen, M. (2015) Uni-REPM: a framework for requirements engineering process assessment. (will be inserted by the editor) Uni-REPM -a Framework for Requirements Engineering Process AssessmentMikael Svahnberg · Tony Gorschek · Thi Than Loan Nguyen · Mai Nguyen the date of receipt and acceptance should be inserted later Abstract Context. It has been shown that potential business benefits could be achieved by assessing and improving the requirements engineering (RE) process. However, process assessment models such as CMMI and ISO9000 only cover RE shallowly. Tailored models such as REGPG and REPM, on the other hand, do not cover market-driven requirements engineering. Other attempts, such as MDREPM covers market-driven requirements engineering, but correspondlingly neglects bespoke requirements engineering. Moreover, the area itself has evolved so practices that once were cutting edge are now commonplace. Objectives. In this article we develop and evaluate a unified requirements engineering process maturity model (Uni-REPM) that can be used in a market-driven as well as a bespoke context. This model is based on REPM, but has evolved to reflect contemporary requirements engineering practices. Methods. Uni-REPM is primarily created based on a systematic literature review of market-driven requirements engineering practices and a literature review of bespoke practices. Conclusions. Based on the results, Uni-REPM is formulated. The objective of Uni-REPM is twofold. Firstly, it is expected to be applicable for assessing the maturity of RE processes in various scenarios where an organization would use different development approaches. Secondly, it instructs practitioners about which RE practices to perform and their expected benefits. As an assessment instrument, Uni-REPM provides a simple and low cost solution for practitioners to identify the status of their RE process. As a guidance tool, Uni-REPM lessens the gap between theoretical and practical worlds by transferring the available RE technologies from research to industry practice.

show abstract

Quality Requirements in Practice: An Interview Study in Requirements Engineering for Embedded Systems

Cited by 44 publications

References 21 publications

Collaborative Resolution of Requirements Mismatches When Adopting Open Source Components

Collaborative Resolution of Requirements Mismatches When Adopting Open Source Components

Quality Requirements in Industrial Practice—An Extended Interview Study at Eleven Companies

Uni-REPM: a framework for requirements engineering process assessment

Contact Info

Product

Resources

About